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.

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.

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.

---

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

---

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.

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.

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

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.

Im hearing from a little birdie that 14.2 does indeed address a Lock Screen issue...however the description of the issue doesnt seem to align with what we are seeing in practice....so if anyone is using the 14.2 beta, and can test this.

That is good to know! What issue are you experiencing in your environment?

14.2 beta has not resolved the issue for me on a test machine. Lock screen shows no user icon and rejects valid password. Will continue to test the login window payload settings that are causing this.

That is disappointing about 14.2...HEY APPLE, DO BETTER! According to Apple Enterprise support, the setting that is causing this is "having a hidden admin account" which for us was because we build one during Pre-Stage enrollment and have it marked as hidden. Problem is that setting does not live in a Config Prof...so you can only change it after the fact via script and you can turn that setting off for new enrollments going forward. Once we sent a command to show the hidden admin account, the issue goes away. So we do it with a script (change UserAccountName to the name of your hidden admin account): 

sudo dscl . create /Users/UserAccountName IsHidden 0

I suppose there could be multiple causes of this issue -- but in our environment, we have no hidden users, and we're still seeing this.

Apple is wrong. We have zero hidden admin accounts and I was experiencing this issue, until my steps that I laid out abbove.

The following did not resolve the issue for me:

 @imnotajamfadmin From your note above I am not 100% clear what your resolution was? Can you clarify which payload caused the issue of the lock screen not accepting a valid password please?

Just updated to 14.1.1, this thing happens again!

I was able to temporarily resolve it in 14.1, using a way learned from a smart colleague, "log out of the current user and get to a screen where you can input both username and password".

It worked for 14.1(that smart guy didn't upgrade to 14.0, since I told him about the login password issue, and then he waited till 14.1).

It's just for 14.1.1 patch, I have to do it again, and so far so good.

* maybe for all future OS patches, before either Apple or Jamf solves this for good, I have to do the above again and again.

* use Apple watch and touchID unlock as much as you can to mitigate the impact.

Happening in our environment to random users( version 14.1.1) as well. Unable to repro. Any recommendations from Jamf/Apple if someone reached to them recently ? I am waiting for a response from Jamf support

So I just heard from Apple asking me to try the newest seed for 14.2 where they claim the issue is resolved....looks like I have homework to do.  Here are screen shots of our config prof for login window that Jamf Support helped me build. So send that config prof down (remove your previous one with Login Window settings), plus run a policy that unhides the hidden admin account using the execute command...if this doesn't work for you then there must be more variables that also cause the lock screen issue unfortunately. Might seem obvious, but make sure you don't have multiple config profiles doing things to the Login Window to conflict with this new one.

Create a policy with this command:

Create a new Config Prof (and remove your old Login Window prof):

As I said before. What they think it is and what is actually is are two different things. We can replicate this issue on a brand new out of box machine as well as machines not enrolled with Jamf. It’s purely an Apple Issue. They believe it’s related to hidden admin accounts but something else is at play since non enrolled Mac’s also have the issue. 

we got similar settings for login config as suggested to you by Jamf Support. The only difference is "Enable console login" and "allow external users" are not checked.

Is this intermittent for you or reproducible every time you get to a lock screen? Once I deploy these settings down, the "not accepting the password at lock screen" issue goes away. We just don't like having the jamf admin account being visible now though. 

Also--are you using local accounts or mobile accounts? Are you noticing the same behavior on FileVault encrypted devices as well as ones that don't have FileVault enabled?

So did that solve it for you or are you still experiencing the issue? Since making the change, my Sonoma users haven't experienced not being able to log back in.

I am planning to create a test config to validate

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

I suspect everyone's wrapping up for the long weekend right now, but have any of you good folks made any progress on this issue since the last post was made here a couple of weeks ago?