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. 

[GabeShack]

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.

[clarkep]

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

[isThisThing0n]

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.

[clarkep]

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

[imnotajamfadmin]

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

[jbyl]

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.

[isThisThing0n]

The following did not resolve the issue for me:

sudo dscl . create /Users/UserAccountName IsHidden 0

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

[trout]

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.

[ysdevgan]

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

[clarkep]

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):

 

   

[GabeShack]

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. 

[clarkep]

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?

[ysdevgan]

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.

[clarkep]

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.

[ysdevgan]

I am planning to create a test config to validate

[jbyl]

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?

[ccsshelpdesk]

14.2 released today and still having the issue, we do have a hidden admin account so i will see if unhiding it resolves it. not ideal tho and was hoping for a fix in 14.2.

[GabeShack]

14.2 isn’t out yet. This is a security update 14.1.2

[ccsshelpdesk]

14.2 Tested this morning and still having the issue 😕

[Andrew_N]

In our environment we've identified an issue with having both a loginwindow config to show Name & Password fields and having a config or pwpolicy set that has a maximum password age. The issue causes a Lock Screen to only show the password field, normally you would also see the username with the user's profile icon. Removing the maximum password age or changing the loginwindow to be a list "resolves" the issue, but now we can't use the configs.

We've long had issues with the login screen and passwords and they seem to just be getting worse, even though we submit feedback for all of them through the beta program. 14.2 appears to cause even bigger problems with macOS passwords and resetting for the first time without fixing the previous issues. It's been fun as we try to document everything, provide feedback and then develop a workaround.  

[Andrew_N]

Gonna need to test out the new macOS Sonoma Beta:

Resolved Issues in macOS 14.3 Beta

• (Beta 2) Passwords can be changed successfully at the login window when enforced by MDM or pwpolicy.

[ichavez]

I know it was suggested before to use

/usr/local/bin/authchanger -reset

and did not work. This was my situation too. What I ran was similar but with the added at the end

/usr/local/bin/authchanger -reset -JamfConnect

Then a restart. 

[FlameCoder]

I'm on an M1 MacBook Pro MacOS 14.2.1

We have the Mac bound to AD and what I've noticed is it will work outside the company network but not inside the office. When inside the office I have to shut off the WiFi and network connections and restart. After logging in I can then get the network going again. If I don't, it locks up when I try to wake up an account.

[Risdal]

We are still seeing this on some macOS Sonoma devices with 14.2.1 installed,  so not fixed for us yet. 

[jbyl]

I have found that the only consistent way to squash this bug is to not manage any login window settings. There’s probably a subset of those settings that trigger the issue in AD-bound environments, but I don’t care enough about managing the login screen to investigate further.

[clarkep]

You should open a ticket with jamf and have them take a look at your login window config profile. If you take a look at the config profile’s settings on a computer experiencing the issue, see if “hide local admin users” is set to true, you need to get that set to false. What I found was, even though I had that setting configured in the config prof, it was still hiding the admin…you would have to adjust the config profile outside of jamf and import it back in if that makes sense…but still worth having Jamf support see it I think. 

if you don’t manage the logging window, you can’t say “this laptop belong to…” or control the guest user account etc…..

[GabeShack]

I know I've mentioned this before, but this issue is not tied to "hide local admin users" since it affected unmanaged and personal computers without any tie to JAMF which I have documented.  Apple is unfortunately stating it to be a specific preference (which it very well may be with managed devices) but we are witnessing it affecting completely new devices out of box once they are logged into with a new user with no jamf management whatsoever.  So either they have multiple issues that are affecting the Lock Screen passcode, or they just don't know the extent of the issue.  Either way, this is an Apple issue and not specifically a JAMF one (even though the mitigation is bypassing hiding of admin accounts on managed devices).

[clarkep]

Did you open a ticket with Apple as well? You should report that finding to them too, they need to hear about these issues. 

[rachelspe]

Thanks I will :)

[jcx9228]

In our environment it seems to happen specifically once people install upgrade from Ventura to Sonoma. Once we change password issue seems to go away . 

But we also deploy login / screen saver / password expiration configs mentioned in the forum 

[jcx9228]

Hi. i got couple confirmations internally that installing 14.3 fixed this . Anybody else can confirm this ?

[rachelspe]

It did not fix the issue for me.

[clarkep]

Did you have any luck implementing the updated configuration profile to make sure local admins are being shown?

I haven't gotten a chance to see if 14.3 works with hidden admin. For me, that's been the reproducible issue. I know others have gotten it to break without any connection to Jamf whatsoever, but I haven't been able to reproduce that.

[rachelspe]

I don't see that in any of our config profiles. I did put in a ticket with jamf and they've escalated the issue.

[rachelspe]

14.3.1 might have fixed it... I upgraded one machine and so far so good.

[rachelspe]

nope, scratch that. Still having the same issue.

[GabeShack]

I think the inherent problem is Apple believes the issue to be fixed as of 14.2 since it was in the patch notes I believe back then. I doubt anything further will address it unless everyone contacts their Apple SE regarding it and opens a new radar. 

[rachelspe]

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.

[jcx9228]

Hi guys, any news after 14.3.1 ?

[rachelspe]

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.