r/macsysadmin • • 5d ago

Jamf A user forgot their password to their jamf enrolled mac local account I reset it via an admin account, now the authentication is all messed up, how do I fix this?

Basically whenever I want to access the users keychain, it asks me for the users password (Which is synced to the AD password and jamf connect), and when I enter it, it takes it but it doesn't bring up the GUI of the keychain. Same thing when I try to add a fingerprint, it asks for the users password, it takes it, and then it doesn't take me to the GUI prompt.

I think something is broken with the keychain/authentication because now outlook kicks them out too. I had a work around, I was using their old password to access the keychain and that was working, but now it's not working.

Basically whenever a prompt comes up asking the user to enter their current password to change any setting, it accepts it, then it doesn't bring up GUI of the application I'm trying to access like Keychain cause the authentication is broken.

3 Upvotes

18 comments sorted by

7

u/PoeTheGhost 5d ago edited 5d ago

In my experience, this usually means the user’s login (or default) keychain password in the Keychain access app doesn’t match the current user password.

Since you are AD bound, sometimes switching their AD password back to the old one first and then following the guide usually works.

This is why binding Macs to AD isn’t considered best practices these days. Using Apple Business (ABM) with a federated domain and a supported IdP (that IS connected to your AD for automated onboarding/offboarding) and using Managed Apple Accounts is much better in the long run.

https://support.apple.com/guide/keychain-access/if-you-need-to-update-your-keychain-password-kyca2429/mac

1

u/Prior_Newt2871 5d ago edited 5d ago

So right now the local account and the AD password match, but now the keychain doesn't accept the old password. So would that even fix it? It accepts the new password, but doesn't open up the GUI window.

The problem is, everytime I try to do something that requires the users password, for example if it says "Enter The password for the user <username> to allow this" it will accept the current password, but doesn't bring up a gui or get to the next part. like it does nothing after accepting the new password.

1

u/PoeTheGhost 5d ago

The keychain password being reset should fix it, so long as the keychain is local and not stored on iCloud under a personal Apple ID.

1

u/Prior_Newt2871 5d ago

I actually tested unlocking the user's login keychain through Terminal using security unlock-keychain, and it successfully unlocks with his current macOS password.

The issue is broader than Keychain Access. Whenever macOS displays an authorization prompt saying "Enter the password for the user <username> to allow this," the current password is accepted, but the requested action never completes. This also happens when trying to enroll a fingerprint.

Would resetting the login keychain still help in that situation, even though it already unlocks with the current password?

1

u/PoeTheGhost 5d ago

Ah, I see. This issue might not be on the Mac at all, and you’re in the doldrums of AD now.

When a system dialog asks to "allow this" (changing system settings, etc), macOS delegates the request to the ⁠authd⁠ daemon.

In an Active Directory-bound environment, this system check often stalls or fails silently due to Directory Services evaluation timeouts, token acquisition failures, or Directory Utility plugin deadlocks rather than a keychain mismatch.

1

u/Prior_Newt2871 5d ago

But that is a local authentication, its asking for the local password. It doesn't seem to have anything to do with AD. It seems to be something on the mac.

3

u/PoeTheGhost 5d ago

Right?! This one drove me NUTS during my time at Apple.

Run this in terminal, then try an action that needs the user password:

sudo log stream --predicate 'process == "authd" or process == "opendirectoryd"' --info --debug

You might see DirectoryService timeouts.

6

u/diggy0529 5d ago

Go in to ~/Library/Keychains and delete the .db file and the folder with the nonsensical name, then reboot. The user should get prompted on next login to create a new login keychain password; set it to the same and that should fix it. This works for our folks when they mess up the keychain

1

u/Prior_Newt2871 5d ago

looks like this fixed it, thank you! I almost had to rebuild his profile, but it is good to know this is the fix if they forget their password.

1

u/diggy0529 5d ago

You're welcome, glad to be of help!

1

u/oneplane 5d ago

> Which is synced to the AD password 

And now you know why you shouldn't be doing that. In theory it should reduce service desk pressure with password related questions, in reality you just trade a medium volume of simple questions for a small volume of time consuming problems.

As for solving this: if you know the real password to the keychain, use the security cli to update it to the 'current' password and then log out and back in again. If you do not know this password, delete the keychain and reboot.

1

u/Prior_Newt2871 5d ago

I know the password to the current keychain, it works but it doesn't bring up the GUI so I can't access it cause the authentication is broken in someway.

2

u/oneplane 5d ago

Yeah, in that case use the security CLI, that'll work as long as it's not corrupted.

2

u/RandomlyMethodical 5d ago

What version of macOS?  Apple “fixed” some keychain vulnerabilities in 26.4 and 26.6 that caused a bunch of secondary issues with keychain passwords.

1

u/Jwblant 4d ago

Please, don’t bind Macs to AD. No one has long-term success with it anymore.

It’s almost guaranteed that a profile will get corrupted at some point and their local password will get out of sync with AD. On network, they use their AD password. Off network, they will have to use their local password. And everytime you switch between them, it will break the keychain and cause more problems.

I don’t know that I’ve had this specific issue, but I have had pop ups that continually ask for a password over and over, in which case I’ve found that hitting “always allow” usually helps. I would try rebooting it first and logging back in to see if that helps with anything.

2

u/derby_day_bourbon 4d ago

Not sure if anyone suggested it yet but when we were AD bound we had to disable FV, delete the keychain and turn secure token off/on then re-enable FV. It was suuuuuch a PIA

0

u/Aronacus 5d ago

You broke the keychain trust. You need to remove all device certificates from the device. IE Wifi Cert, VPN Cert, Okta cert. Then, repush the profiles that supply them. That should fix it.