Hey Jamf Nation,
Wondering if anyone has come up with a way from a macOS password reset to trigger an even in Jamf. We currently use Okta Device trust, which lives in the keychain, so everytime a user resets their password or we have to provide FV key for password reset, the Okta keychain needs to be replaced. Has anyone found a solution for this?
@lucas.cantor : I just re-run the same policy, however, there is concern b/c you can't re-issue more than 5 times. Has anyone run into that issue?
"A certificate becomes bound to a given user the first time that user accesses a device trust-secured application from a device trust-secured macOS device. Unused certificates are unbound. Okta can issue up to five unbound certificates to the device, one each time you perform the enrollment procedure. As a security precaution, Okta will not issue more than five unbound certificates to a given device. To avoid reaching the unbound certificate limit, ensure that users use the unbound certificates already on the device before you attempt to obtain more certificates through enrollment. If you reach the enrollment limit, the Syslog indicates an enrollment failure and the error message Maximum enrollment limit of 5 certificates for a device is reached appears in the JAMF log."
In the event that there isn't a readily available file that changes or something else you can use as the trigger, maybe take a different tack that accomplishes the same purpose: can you initiate the password change process you need to use from a Self Service item, and set a flag file or validate somehow that the password change completed from within that policy or a followup one, then perform the additional tasks that need to follow after the password change?
We had a requirement to be connected to the org network before changing passwords or things didn't sync properly. It was a bit obvious once we set up a Self Service "change password" item how the act of putting it in Self Service and training users to use only that item was the best solution (since, in our case, getting to Self Service required being on the org network.) Seems like a different scenario where a similar solution could drive this forward...
Does the login keychain get updated when a password reset occurs? If so, it is actually possible to monitor the logged in user's login.keychain for changes with a LaunchAgent. I've done it before. You could have a script run on every change to the keychain and try to determine if the Okta keychain has been replaced. Once that happens it would need to trigger something to get a policy to run. Perhaps have a corresponding LaunchDaemon watch a file that the LaunchAgent can write to when it detects the change to the Okta keychain entry, which in turn can run a Jamf policy.
It sounds complicated, and I suppose it is a little, but it's doable.