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.

[cy2k]

Following back up to share what I was able to figure out about this, in case anyone else comes along someday with the same issue.

Jamf Connect was the cause, and specifically Jamf Connect in conjunction with Google Workspace login. A Keychain issue can happen if you try to force Jamf Connect to automatically sync the user's password at login via Jamf Connect.

Here's what Jamf Support told me:

...you had these two keys in place:

• CreateJamfConnectPassword (effectively created a keychain item for Jamf Connect's user's password)
  It has a note under it in our docs that says:
  "Note: To use this setting, the Create a Separate Local Password (OIDCNewPassword) setting must be disabled (set to false)."

• OIDCNewPassword (our docs describe this as:)
  "If enabled (set to true), this setting prompts users to create a new password for their new local account.
  If disabled (set to false), this key prompts users to re-enter their network password, which also becomes the local account password. This ensures a user's network and local password are synced during user creation."

The two are not supported together and could potentially cause this.

The documentation, I feel, isn't clear enough about this, but here are some of the Jamf docs about it for reference:
https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Passthrough_Authentication.html
https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Initial_Local_Password_Creation.html

The long and short of it is, I had to use these two settings in the plist to avoid this issue:

<key>CreateJamfConnectPassword</key>
<false/>
<key>OIDCNewPassword</key>
<true/>