users getting locked out with no way to get back in

[cy2k]

Has anyone run into this?

I've got some Sonoma devices, Mac Studios, managed with Jamf and with settings based on the NIST 800-53 Rev 5 Moderate package. They also have Jamf Connect on them, authenticated with Google. Just setting the stage...

Every one and a while, a user will get locked out, after authenticating successfully via Jamf Connect and Google, with a message saying "credential verification failed because account is temporarily locked." Users report seeing this immediately upon login, and not because of repeated password attempts.

In the logs on the device, I've seen things like this which are super strange... It could have nothing to do with the security settings we're applying, but I'm grasping at straws trying to find anyone talking about this so I was wondering if anyone here has seen anything like this before

2024-11-26 10:35:53.522079-0500 localhost SecurityAgent[82975]: (loginsupport) [com.apple.loginwindow:UserController] The user "" is not allowed to authenticate.

2024-11-26 10:37:22.830363-0500 localhost authorizationhost[78599]: (libpam.2.dylib) in pam_sm_setcred(): pam_sm_setcred: ntlm user doesn't have a password

thanks for any help you can provide

[robertgendler]

Have you open a ticket with Apple? This seems like a good ticket for AppleCare.

[georgalis]

I've got some Sonoma devices, Mac Studios, managed with Jamf and with settings based on the NIST 800-53 Rev 5 Moderate package. They also have Jamf Connect on them, authenticated with Google. Just setting the stage...

Every one and a while, a user will get locked out, after authenticating successfully via Jamf Connect and Google, with a message saying "credential verification failed because account is temporarily locked." Users report seeing this immediately upon login, and not because of repeated password attempts.

In the logs on the device, I've seen things like this which are super strange... It could have nothing to do with the security settings we're applying, but I'm grasping at straws trying to find anyone talking about this so I was wondering if anyone here has seen anything like this before

2024-11-26 10:35:53.522079-0500 localhost SecurityAgent[82975]: (loginsupport) [com.apple.loginwindow:UserController] The user "" is not allowed to authenticate.

2024-11-26 10:37:22.830363-0500 localhost authorizationhost[78599]: (libpam.2.dylib) in pam_sm_setcred(): pam_sm_setcred: ntlm user doesn't have a password

that sounds like a network/service issue during crypto handshake within the LDAP/IDp auth layer, eg multiple network service connections required for auth but not resilient to wifi, router, or server packet loss. if you can manage to capture tcpdump data during the lockout, you may see multiple auth retry attempts unrelated to user input, and triggering repeated password attempts lockout.

as for a fix, if that is the case, "password attempts" should probably not be incremented unless each element of the auth is completed without error, and the user actually initiated a new password attempted. Easiest to implement at the OS layer, but if you are enforcing repeated password attempts at the Jamf/Google services, those services "should not" increment attempts invalidated by network errors.

I've never heard of an API that considers 3 way handshake for count incrementing, a robust solution might cache auth from each network service and locally assemble credentials. Key/cert signing across services could make that difficult, or impossible.

A robust workaround might be to "always" auth a secondary account first, to establish/initialize network and service availability.