Post

Replies

Boosts

Views

Activity

Updating a user’s login keychain after a password change
Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.
1
0
136
6d
Inconsistency in Location Services in macOS Apps
I am encountering some issues with location services in macOS apps. Despite including the necessary keys in the app’s info.plist, I am unable to request user location permission. Here are the details: Cannot request location permission using requestWhenInUseAuthorization(), ie., no location permission grant permissions popup is appearing. The app contains NSLocationUsageDescription in the info.plist. I have also tested by adding NSLocationAlwaysAndWhenInUseUsageDescription, NSLocationWhenInUseUsageDescription, and NSLocationAlwaysUsageDescription, but it didn't work. So to show the location request popup, I was directly(irrespective of the authorizationStatus) requesting location using requestLocation(), which showed the location permission grant permissions popup. But then I encountered another issue. If the popup is left as it is, every time requestLocation() is called a new location request popup appears (which comes after allowing/denying the popup). Also observed that didChangeAuthorization is only called on allowing/denying the last location request pop up. Initial calls to CLLocationManager().authorizationStatus return Not Determined. When I checked the location permission state of my app on launch, I used to get not Determined for some time, even if the permission was granted. Code snippet: private var locationManager: CLLocationManager { let lm = CLLocationManager() lm.delegate = self lm.desiredAccuracy = kCLLocationAccuracyBest return lm } private var currentAuthorizationStatus: CLAuthorizationStatus { if #available(macOS 11.0, *) { return CLLocationManager().authorizationStatus } else { return CLLocationManager.authorizationStatus() } } switch currentAuthorizationStatus { case .notDetermined: print("requesting permission") locationManager.requestWhenInUseAuthorization() case .restricted, .denied: print("location permission is restricted") case .authorizedAlways, .authorizedWhenInUse, .authorized: print("requesting location") locationManager.requestLocation() @unknown default: print("Unknown error occurred") } I would appreciate any guidance or suggestions on how to resolve these issues. Thank you!
1
5
728
Jul ’24
Updating a user’s login keychain after a password change
Hi, We are looking for guidance on synchronizing a user’s login keychain passphrase after changing that user’s local account password, when the user is not currently logged in. Context We have an MDM product for macOS, and we sometimes need to change a local account password while that user is not logged in. Updating the account password itself from our privileged daemon is fine. The hard part is keeping their login keychain in sync — that only seems to work when we run as that user, in their own session. So we perform the keychain update from a per-user LaunchAgent, not from root. What works (user is logged in) From the user’s LaunchAgent we run: # 1) Change account password (if not already changed) dscl . -passwd "/Users/<username>" "<currentPassword>" "<newPassword>" # 2) Sync login keychain passphrase security set-keychain-password -o "<currentPassword>" -p "<newPassword>" login.keychain-db With correct current/new secrets, this succeeds when the helper is running as that user while they are logged in. What fails (user is not logged in) Starting the same LaunchAgent for that user fails with: Bootstrap failed: 125: Domain does not support specified action So we cannot get user-context execution for the keychain update while the user is not logged in. Approaches we already tried Post-login LaunchAgent — We stage the current/new passwords and install a LaunchAgent that runs after the user logs in to migrate the keychain. By the time the user is logged in and the agent runs, macOS has already created a new login keychain and renamed the previous one (e.g. login.keychain-db-renamed-N). At that point we can no longer reliably migrate/restore the original keychain. sudo -u <username> security set-keychain-password … from a root daemon — Led to Keychain Access / keychain state corruption in our testing; we do not consider this a production path. Delete the login keychain — Works as a reset, but discards saved credentials. Acceptable for some admin reset flows; not acceptable for a password change where we know both secrets and want to preserve the keychain. Ask Is there a supported way to update login.keychain-db for a user who is not logged in, given known current and new passphrases, without deleting the keychain? If so, what is that way? If not is there a way to merge the old login keychain as we have the old password too? Also please confirm whether updating another user’s login keychain from root / sudo -u is unsupported, so we can exclude it from product design. Happy to provide sanitized logs (error 125, security failures, renamed keychain timelines) if useful. Thanks.
Replies
1
Boosts
0
Views
136
Activity
6d
Inconsistency in Location Services in macOS Apps
I am encountering some issues with location services in macOS apps. Despite including the necessary keys in the app’s info.plist, I am unable to request user location permission. Here are the details: Cannot request location permission using requestWhenInUseAuthorization(), ie., no location permission grant permissions popup is appearing. The app contains NSLocationUsageDescription in the info.plist. I have also tested by adding NSLocationAlwaysAndWhenInUseUsageDescription, NSLocationWhenInUseUsageDescription, and NSLocationAlwaysUsageDescription, but it didn't work. So to show the location request popup, I was directly(irrespective of the authorizationStatus) requesting location using requestLocation(), which showed the location permission grant permissions popup. But then I encountered another issue. If the popup is left as it is, every time requestLocation() is called a new location request popup appears (which comes after allowing/denying the popup). Also observed that didChangeAuthorization is only called on allowing/denying the last location request pop up. Initial calls to CLLocationManager().authorizationStatus return Not Determined. When I checked the location permission state of my app on launch, I used to get not Determined for some time, even if the permission was granted. Code snippet: private var locationManager: CLLocationManager { let lm = CLLocationManager() lm.delegate = self lm.desiredAccuracy = kCLLocationAccuracyBest return lm } private var currentAuthorizationStatus: CLAuthorizationStatus { if #available(macOS 11.0, *) { return CLLocationManager().authorizationStatus } else { return CLLocationManager.authorizationStatus() } } switch currentAuthorizationStatus { case .notDetermined: print("requesting permission") locationManager.requestWhenInUseAuthorization() case .restricted, .denied: print("location permission is restricted") case .authorizedAlways, .authorizedWhenInUse, .authorized: print("requesting location") locationManager.requestLocation() @unknown default: print("Unknown error occurred") } I would appreciate any guidance or suggestions on how to resolve these issues. Thank you!
Replies
1
Boosts
5
Views
728
Activity
Jul ’24