sonoma locking up on lock screen, apparently due to SHOWFULLNAME in loginwindow payload

[bernstei]

Has anyone else run across the Sonoma lockscreen lockup, similar to discussions like https://community.jamf.com/t5/jamf-nation/sonoma-lock-screen-wont-take-correct-password/m-p/300488 ? It either won't accept the known correct password, or if it does, it beachballs forever (more than 20 minutes anyway). Only a hard power cycle gets it out once that happens.

That thread being on a jamf board notwithstanding, it doesn't seem to be related to jamf. I got the idea from that one (or some other discussion) that it might be the loginwindow mobileconfig payload. Removing that payload entirely does seem to fix it, but so does keeping the other payload elements, but just removing SHOWFULLNAME=true, which is set by

macos_security/rules/system_settings/system_settings_loginwindow_prompt_username_password_enforce.yaml

Line 63 in c52b7ff

SHOWFULLNAME: true

Has anyone else seen this, and/or have a fix that makes it possible to satisfy that rule?

[jmahlman]

Have not personally seen this, have you opened an Apple support case? From the comments in that thread it seems like a macOS bug.

[bernstei]

I agree that it looks like an Apple bug, but we don't have a support contract, and there's not a lot of clear information online. I just hoped that someone here might have run across it. We also seem (so far as I can tell so far) to have multiple machines and it's not affecting all of them, despite supposedly identical configurations, but I'll take a closer look at one of them in the next few days.

[georgalis]

It is not necessary to have a support contract to submit support requests. I have two issues resolved after initial support expired. The pattern is engage in chat, then get escalated for a resource callback. Have serial numbers, os versions, phone numbers, update history, etc, handy, and use a second computer. My first issue was resolved several months later in an update cycle, in the second I was navigated through good debugging for resolution (although their heuristics were less than ideal for my issue). They won't admit to a bug or problem as the first case, but they did offer to escalate my issue to their internal developers.

In this case, if there is a beach ball, spinning wheel, there should also be a key sequence to record a trace of the event creating the lockout.

[bernstei]

Thanks, I'll see if I can get anywhere with that.

[GrahamWatts]

Release notes of 14.2 might be relevant: https://support.apple.com/en-us/HT213893
"The login password is correctly accepted at the Lock Screen when MDM has configured the login window to hide admin users."

[bernstei]

Sadly, no luck. I hid the existing admin users with the HiddenUsersList, and they are indeed hidden, but the behavior once I set SHOWFULLNAME (switch from list of users to username/password text boxes) is unchanged. It still rejects the correct password unless I hit escape and select the correct user, and then it accepts the password but beachballs forever. I guess I may try to reproduce it on a clean system and file a support request.

[bernstei]

Aha - I finally found the HideAdminUsers loginwindow payload key in https://developer.apple.com/documentation/devicemanagement/loginwindow, and that did indeed appear to fix it. Yeay. Thanks you @GrahamWatts

I do think that if that key is required for SHOWFULLNAMES to not break the unlocking process, macos_security should always include both if it includes SHOWFULLNAME at all. Unless someone convinces me otherwise, I'll open an issue for that.

[bernstei]

I'm also going to test the newly released 14.3 for this behavior.

[bernstei]

Tentatively looks like it's fine in 14.3, so maybe there's no need for a change to the macos_security behavior.