Sonoma Lock Screen wont take correct password

[TheITGuy69]

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. 

[TheITGuy69]

if finger print scanning is enabled, we can get back in with the fingerprint but not password.

[Discher]

Also experiencing this.  We are bound to AD, and do not use fast user switching.   When the screen is locked, there is no username, only a password field which does NOT authenticate.  This is very bad for us.

[TheITGuy69]

We are Jamf Connect, not bound but have fast user switching turned on. I am wonder since Apple is calling this a new lock screen if Jamf hasnt added the correct Configuration Profile parameters to Jamf Pro.

I have seen this on both intel and apple silcon devices.

My production Apple silicon device this is not happening to, its connected to icloud and has a 2nd FV enabled user , i can see both and switch between them. but my Intel the issue is happening to is a single user that is FV enabled. it doesnt show the users name , just the icon and password field.  

[JamesJhoung]

We're seeing something similar as well, but only seems to occur when enabled the Lock Screen is enabled via Apple > Lock Screen. If the device kicks off the screen saver and then locks, I'm still able to authenticate. This environment also has devices with a direct AD bind.

[dan_berlyoung]

Same thing but happening to us on a brand new 15" M2 MacBook Air. 

I started another thread about this here: https://community.jamf.com/t5/jamf-connect/sonoma-can-t-unlock-mac-after-sleep-or-screen-saver/m-p/3...

[GR]

Seeing this too, and so do some of my colleagues. SO annoying

😤

[SeaFarerGrip]

I have been experiencing this issue as well... based on some additional research, this appears to be a MacOS Sonoma issue, and not a Jamf issue as the same issue affects those with different MDMs. I just updated to 14.0(23A344) today and this seems to have resolved the issue. I believe this is still in Developer Beta, so I would assume it should roll out to the public pretty soon.

[TheITGuy69]

Agreed its not a Jamf issue but Sonoma issue. thanks for your feedback.

[Sprite]

I am seeing the same issue on 14.0 23A344, but it is not all machines. 1 user is seeing this issue on an Intel Mac but I am unable to replicate on my end.

[Sprite]

Immediately after posting this it started working again. Our company uses Intune and is not AD bound, product is Jamf Connect. I did 2 things and I am not sure which fixed it. 

1. In lock screen settings I changed "Show Large Clock" from "On Screen Saver and Lock Screen" to "On Lock Screen" (changing this setting on my Mac did not replicate the issue)

2. Re-enrolled into Intune.

Before all that I also ran ' sudo /usr/local/bin/authchanger -reset ' in terminal but that did not fix the issue.

It's possible that command combined with re-enrolling into intune fixed it

[Sprite]

The user is reporting this morning that the issue is back.

[fais_m]

Thank you i try the solution number 1. i Put Never first then after that is working thank again.

[fais_m]

If local user no issue. if mobile no choice need to add finger print.

[GabeShack]

enabling touch id seems to get around this, but yes still an issue currently.  I am thinking of locking the requirement for password on ss or sleep to off.

[joshuasee]

I have also encountered this, though only once out of three dozen AD bound Sonoma machines so far, so there is probably an additional trigger for the bug.

I was able to offer the workarounds of TouchID, which seemed unaffected, and pressing Shift-Option-Return to bring up a username/password dialog, which worked.

[jbyl]

In our environment, we’ve found that the trigger is how long the Mac sleeps: if less than 15 minutes, no issue; if more than 15 minutes, password doesn’t work. Using TouchID is a good workaround, but we’re still looking for a permanent fix.

[GabeShack]

shift option return allows the full name and password to be retyped

[SuSpense]

This key-comb isn't working for us. I suspect it's something with respect to our profile setting requirements around password after screensaver begins-immediately. 

[GabeShack]

Sorry its not letting me edit my previous comment...I typed the wrong key combo.

It should be command option return

[rachelspe]

This didn't work for us either

[imnotajamfadmin]

to anyone reading this, the issue is this: if you have "require passcode to unlock screen" turned on your config profile(security and privacy), but do not also have a screen saver policy(login window, options tab) set you will see this issue. 

[GabeShack]

So I don't believe that is true as we are seeing this same issue on unmanaged devices as well...this seems like a sonoma issue and nothing to do with jamf.

[SuSpense]

this isn't true. I just set a very basic profile without any passcode requirements and it fails. we have seen this as well with a brand new machine out of the box without being enrolled. The only thing that seems to be connected is whether or not the user has an AppleID signed in to the local user account that gets locked out. If you notice when the fail happens, ONLY when an Apple ID is signed in, will the lock screen show an icon for the local user and the AppleID icon supersedes the local user icon regardless of admin status. So it's almost like the system doesn't know what account to sign into when it goes to a lock state by way of screensaver or the lock screen being instantiated by pressing the TouchID button. 

[GabeShack]

Agreed....we can replicate this on a fully Unmanaged device that has no ties to JAMF whatsoever.

[imnotajamfadmin]

So, I was able to resolve it via JAMF. I set the screen lock timeout to 5 seconds, set screen saver to 15 minutes and in login items/mobility there are settings for local/network sync. Leave all of them unchecked. I think it's the lock screen/screen saver doing it.

My point is.. if I fixed it in JAMF, it's fixable locally. It's likely related to the settings I listed. Those are the only things I changed in a policy. Pre-policy update, no issue. Post policy update, issue. After policy fix, no issue.

[jcx9228]

Hello, can you confirm this works ? i can see you tried this in October last year 

[clarkep]

I figured this out with Jamf support. In your Configuration Profile, if you need to have the key "Hide Admin Users" set to false. Also, if your Pre-Stage Enrollment, you need to have your local admin user not set to hidden as well. You also want to be sure local users are set to not be hidden. Those 3 things are what makes the lock screen work me as of 14.3. The other thing to check is that you don't have conflicting Configuration Profiles set for Login Window. Hope this helps!

[rachelspe]

I'm trying this now. Fingers crossed it works!! Thank you :)

[imnotajamfadmin]

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

[jasonh11]

Facing the same issues here, I was able to fix only one laptop by tinkering with the lock screen options from Name and Password to list of users, then restarting. I noticed the username and profile picture was back and allowed login. Unfortunately I couldn't replicate this on other computers though so the hunt continues. 

[Ananai]

As mentioned on the related post, same issue. We're currently investigating what works to bypass the problem.

[Sprite]

As SuSpense said that it might be apple id related I tried logging out of the apple id. No good, still have the lock screen issue.

Some others mentioned a key combo command option return, again no good.

I reached out to Jamf support and they wanted us to update to Jamf Connect 2.28.1 as 2.27 is the first version that fully supports Sonoma. Took some time to get approved to pilot the update and no good either. Lock screen issues persist. Emailed support back but I am starting to think it is an apple issue.

[Ananai]

As a workaround we're trying with the app "Caffeine" to keep the computer awake. Yes it burns power and hinders security, and yes it's a good compromise for now.

[TheITGuy69]

---

 Anyone try Sonoma 14.1 update to see if it fixes the issue?

---

[clarkep]

Just here to report that 14.1 does not fix this issue :-( The only solution I have is to not deploy a configuration profile with a login window payload.

[cemguy]

@clarkep I had a user have this same issue with (v29 jamf connect & macOS v14.1) Last week. Removed Login window and no issue as he had the issue for at least 2 days in a row , twice a day. Probably best work around yet. Side note - I was going to remove the payload anyways b/c of other Jamf Connect User sign screen oddities. Thanks for sharing. 

[imnotajamfadmin]

So I understand that people have said this doesnt resolve the issue.. however Im posting this in a general reply because this 100% resolved the issue for me.

The reason Im here in this thread in the first place is because I was working on a new 802.1x policy. M2 Macbook Pro is the test device. The policy included 4 payloads: Certificate, Login Window, Mobility, Network.

Certificate: wifi cert thats 802.1x capable
Login Window: Window tab - show additional info, name and password text field, show shutdown
Options - disable auto login/apple id setup/siri setup, set computer name to record name - Screen saver was NOT set
Mobility - Account creation tab: Create mobile account at login with local home template and /bin/bash home directory
Network - personalized settings, however, use as a login window config, TTLS, PEAP, use directory auth, mschapv2 under protocols.

Thats it. Thats all that was in this policy. I applied it to the test device and started seeing this problem. Macbook would go to sleep, when you wake it up, only a password box and it doesnt accept your pw.

There was also a separate config policy that was a single security and privacy payload of Require Passcode to Unlock Screen. This was set to 15 minutes. I have only recently taken over JAMF and I think the previous person thought this was the screen saver policy. I set this config policy to 5 seconds and set the screen saver policy under Login Window above to 15 minutes.

After saving and sending, this immediately resolved the issue. The very next reboot, it stopped happening. When I woke the machine up, it gave me my name and then a password box. Accepted my password.

I hope this helps. Are you using 802.1x? Maybe setting the network payload with "Use as a Login Window configuration" would help if that fits your environment. Ive since pushed this policy to at least 5 other macbooks - mix of intel and silicon chips. None of them have shown the issue you're experiencing if youre in this thread.

[Sprite]

14.1 seems to have resolved the issue. 2 machines are working normally now.

[clarkep]

14.1 Does not solve the issue according to Apple Enterprise. as of 14.1 the only solution is to make the hidden admin account visible and then redeploy the configuration profile that contains the login window settings. So if it is working for you and you haven't made any changes, chances are you weren't experiencing the lock screen issue for the same reason--if you were at all.