Macs do not obey "Require password after sleep begins" Profile

joelsenders
New Contributor III

I have two Macs that, regardless of what I do, always ask for a password immediately after being woken up from sleep/coming out of screen saver. Even if I remove Jamf from them completely they still do this. The user can change the setting to whatever they want, but the Mac will continue this behavior. Both are on 10.13.4. I tried removing a number of plists to see if there was a corrupt setting or something somewhere, but no dice. In the end, I tried setting a config profile with a payload for security and privacy and set the "Require password after sleep begins" to 4 hours, and it worked initially, but now has reverted back to the "immediately" behavior even though it says 4 hours on the Mac. I have another configuration profile on the Mac for Login Window, but hundreds of other Macs have this profile as well and are not seeing this issue, so I concluded it isn't that profile that's causing the issue.

Any ideas? Not sure what to do at this point other than wipe it and try again... however it seems to be settings related, something coming from the top down like a managed setting.

9 REPLIES 9

gachowski
Valued Contributor II

I have found in some of my testing that both require password and require pin are required to get some setting to "stick/work"

C

joelsenders
New Contributor III

I'm not sure what you mean by "require pin". Are you referring to the passcode payload?

gachowski
Valued Contributor II

Yep, the passcode payload.

C

talkingmoose
Honored Contributor II

Unfortunately, that preference setting is bundled within the Security & Privacy Settings payload. When applying it, a lot of the settings are all or nothing regardless of whether you change only one or two things.

Verify whether you have more than just one Configuration Profile with that Security & Privacy payload getting applied to your Macs. If so, remove the payload from all but one Configuration Profile and make your setting in it. Avoid distributing multiple Configuration Profiles with the same payload to your Macs. Apple says doing that will cause unknown results.

The following com.apple.screensaver.plist focuses on just the one setting from Security & Privacy. You can use a plain text editor such as BBEdit or TextWrangler to create the plist manually by pasting the following XML into it (naming the file as shown above) and then upload it to a new Configuration Profile with the Custom Settings payload.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>askForPassword</key>
    <integer>0</integer>
</dict>
</plist>

Alternatively, you can run these commands in Terminal to create your own plist on your Desktop to upload to the Custom Settings payload:

defaults write ~/Desktop/com.apple.screensaver.plist askForPassword -int 0
plutil -convert xml1 ~/Desktop/com.apple.screensaver.plist

After you deploy the profile, you should see the option unchecked and disabled in the Security & Privacy pane in System Preference on your Macs.

joelsenders
New Contributor III

@talkingmoose Thanks for the response. The machine in question only has two config profiles in scope, a Login Window payload and the Security and Privacy payload. I'm fine with removing the Security and Privacy payload and just using a Custom Settings payload, problem is I'm not sure why this machine is just reverting back to "immediately" even when there is no MDM installed. It's like the setting is stuck and I can't clear it. The only reason why I decided to use the Security and Privacy payload was to try and overwrite it as a last ditch effort, which seems to work for about 5 minutes and then it just reverts again.

By the way, is the integer for the "askForPassword" key in seconds?

talkingmoose
Honored Contributor II

@joelsenders, ah, this is a problem before even applying a profile? Didn't catch that part. Not sure why this would keep reverting unless you're running a policy with a script that changes the plist.

The integer is simply true/false. 0 = disabled. 1 = enabled. Any other number might be a crap shoot.

joelsenders
New Contributor III

@talkingmoose Yes I have two machines that, seemingly out of nowhere, both on 10.13.4 (and seems to have started upon upgrade to High Sierra) will stick on the "immediately" setting regardless of whether they are enrolled in Jamf or not.

joelsenders
New Contributor III

Just as an update, I reimaged the machine and everything seems fine now. Kinda sucks that I had to do that, but not sure what else to do besides the nuclear option.

brwnbn
New Contributor III

Where does OS Sierra store the com.apple.screensaver.plist?