Skip to main content

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. 

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


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.


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.


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.  


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.


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/300450#M3185


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

😤


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.


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.


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


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.


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.


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


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


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


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.


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.


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


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


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


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


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.


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


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


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. 


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. 


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

It should be command option return

 


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. 


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. 


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.


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. 


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. 


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. 


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


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. 


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


Reply