We did and was told it's an MDM issue. I have not found this issue on any of our non enrolled devices. I have seen some others on here say they have but that has not been my experience and that's all I can go by.

Hi guys, any news after 14.3.1 ?

14.3.1 Did not fix my issue. But after working with Jamf support we found that for me, upgrading our jamf connect policy to the most current version fixed the issue.

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

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/com.apple.loginwindow PasswordExpirationDays 0 might do the trick on affected Macs, but haven't tried it yet.

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.

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.

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

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.

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.

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.

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

defaults write /Library/Preferences/com.apple.loginwindow 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" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PasswordExpirationDays</key>
<string>0</string>
</dict>
</plist>


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

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

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

Can anyone confirm if macOS Sonoma 14.4 resolved this issue?

I have not experienced this issue since the above settings were set.

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

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

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

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.

Interestingly, I have proposed that we update a few devices to 14.4.1 we have been hesitant to do so as there have been reports of printing issues.