How to trigger an event from macOS password reset

@lukasindre Is there a file besides the login keychain database that gets modified when the user resets their password? If so you could use a LaunchDaemon with a WatchPaths key to call the jamf binary and run a policy any time that file changes.

That is an awesome starting point to look for. I’ll do some testing and see what I can find!

So we run into this issue as well. I just created a self service policy that reissues the cert. Would be curious to see what solution you come up with. Would be happy to collaborate!

@rqomsiya would you be willing to share that policy?

Are you just re-running the same normal initial Okta device trust enrollment policy, or something else?

We reissue the cert via silent policy that runs at checkin, we scope manually to affected users. I'm sure there is a better way to do this, but this just seems to work for us @lucas.cantor

@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."

Okta link for macOS device trust

As a follow-up, I run a quick script to delete the existing certificate before re-issuing. Is that what you are doing @lukasindre ?

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.