Sonoma Lock Screen wont take correct password


Is Anyone else experiencing this?


We have our screen saver set to come on after 10 minutes, and needs to be unlocked to get back into the device. 


I have an Intel device that will not accept the "correct" password. Have to reboot it to allow me to log back in. 


New Contributor III

well it fixed the issue on impacted computer in my company. it s confusing :(

Valued Contributor II

Late to this party, but just saw 3 Macs report this problem today. All Macs were on 14.3.0 or 14.3.1. Users unable to unlock screensaver. Thus far performing reboots did the trick.

-ARM and Intel CPUs are both affected
-Users AD passwords all happen to be expiring within next ~30 days
-Users lost their local admin rights (must be related somehow - cant be a coincidence...?)
-Macs are bound to AD and the binds looks good and DC is available (Im migrating off of AD to XCreds ASAP - actively testing!)
-We use vanilla NoMAD (not NoMADLogin) - password expirations are reporting correctly.
-FileVault is not enabled
-Users have Secure Tokens
-All Macs are managed in Jamf Pro 11
-We dont enforce password policies in Jamf
-Login window displays a name/password (not a list of users)
-We have a hidden PreStage admin account (rarely used)

I have heard that defaults read /Library/Preferences/ PasswordExpirationDays 0 might do the trick on affected Macs, but haven't tried it yet.

New Contributor III

We're experiencing it (3 devices so far, all between macOS 14.2.1 and 14.3.1).
   - One Intel Laptop, one M1 laptop, and one M1 Mini.
   - On-prem AD, all devices can see the Domain Controller. Password works to log in, authenticate to file servers, unlock System Settings, etc.
   - NoMAD 1.3.0

The only place it fails is when waking from sleep or screen saver. All you see is the password input prompt (not the "user" field or user icon). The password doesn't work there, but fingerprint authentication DOES work on supported hardware.

Curiously, the users assigned to these three machines (so far) all have their password expiring within 30 days (two users at 22 and 24 days out, one user at 4 days out).

For two of these users, resetting their password solves the problem, but not sure if that's a long-term fix yet or not. The passwords are still valid until they expire, so I don't think it's the password per se, but probably some other bit getting flipped when the credentials are reset.

New Contributor II

Yeah I am still getting reports of it happening here, users have reported this on 14.2x and 14.3x with no sight of resolve yet.

I have change our passcode policy to increase the pin attempts, and we have no login window policy to hide admins but we do have one that sets a disclaimer like you can do for Windows - it could be that.




New Contributor III

@TechyT- I've heard (from a source I trust) but haven't seen directly that a fix is planned for 14.4 (currently in RC, so probably available next week).

This is only happening on 3 machines so far (out of 400) and we can't find a way to replicate, but if we can find a way to confirm we'll post back.

New Contributor II

Thanks @jkf appreciate that info even if a potential fix to come.

We have seen it happen on around 20 devices since early January but that is what has been reported, I of course assume in some cases it is user error part there is no log locally on macOS to prove this.

New Contributor III

We're using AD credentials, and have NoMAD on these machines. Not sure if it's a coincidence (some other bit getting flipped when we reset the user's password) or if it's tied to a password expiration somehow. Our three users had credentials expiring within 30 days (24, 22, and 4 days respectively). After resetting their passwords, the problem went away for each person.

New Contributor II

We aren't using NoMAD nor any tool like that (JAMF Connect or Xcreds for IdPs etc)

We only have local user accounts currently and Macs and Entra ID joined with no current sync for local passwords to our IdP (hoping to change this with PSSO and avoid XCreds tbh)

Thanks for the feedback tho.


Valued Contributor II

Colleagues on Slack have stated that setting a key in domain. Example:

defaults write /Library/Preferences/ PasswordExpirationDays 0

So I am testing a simple profile to be scoped to specific Sonoma Macs (much easier than a script and policy that I may need to clean up/revert later).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

I can't verify this works at my org because I haven't ben able to reproduce the issue yet.

New Contributor II

We actually changed the expiration setting allow a max of 10 failed attempts, we were not sure if it was that the lock was not getting reset/cleared if/when users became locked after 3 failed attempts (that was our prod setting) so we decided to increase it to 10 attempts - essentially hoping no one makes it to 10 attempts 🤣

But it could also be that the setting itself is causing the issue...




New Contributor II

Sorry I should add we are using Intune but this issue seems to be MDM Agnostic so I am following this thread.

Valued Contributor II

Can anyone confirm if macOS Sonoma 14.4 resolved this issue?

New Contributor II

For the past two weeks we have been experiencing this same issue with 14.4 

Jamf Connect 2.33.0

screen saver has been set to : Never

The only conditions are set for battery and power supply inactivity. 

Require password is set to : Immediately


New Contributor II

It was pointed out by a user, when in a locked state and the "user list" is enabled. The user can select an alternate account this will then bring them into Jamf Connect and prompt for sso. When "Local Login" is selected from below then they have the ability to select their account and sign in. Not saying this is a fix but if Jamf Connect can be used as a workaround I'm all for it.  

Jamf Connect 2.33

Sonoma 14.4.1


New Contributor

We have noticed this issue with Sonoma Macs that are AD bound, has anyone found any sort of solid solution to this issue, it is occurring on multiple sites

Valued Contributor II

Im my case, yes we are still bound to AD (digging our way out of it soon I hope). Thus far we haven't seen this issue on macOS Sonoma 14.4.1 yet. I think all of our affected Macs happened to be on 14.3 or 14.3.1.