Require Password after sleep or screen saver begins.

[twoods450]

I have a Configuration Profile setup the require password after sleep or screen saver. I have it scoped to only my computer and one other. On my computer the box is greyed out and checked, but when I start screen saver it does not require the password to unlock, it jut reopens. On the second system the check box is empty but the selection is greyed out. My system is running 10.9.2
Second System is running 10.8.5

Any Ideas?

[rlincoln]

I'm having the same issue! Looking forward to a fix

[bentoms]

Both, try MCX instead. Works for us.

I can post screen shots of what we've set tomorrow.

[bentoms]

Both, try MCX instead. Works for us.

I can post screen shots of what we've set tomorrow.

[twoods450]

Bentoms, that would be much appreciated.

[Sonic84]

try removing the loginwindow payload and use a passcode payload in stead.

There appears to be a "askForPassword = false" hard coded into the login window MDM payload for some reason. On your client, check System Information --> "Profiles" and look for the askForPassword key under your LoginWindow MDM payload --> "com.apple.screensaver". I bet it's false on systems that do not prompt for a password. This setting conflicts with the effective permissions shown under System Information --> "Managed Client". If you use MCX ("Custom" MDM payload) to manage com.apple.screensaver AND a loginwindow MDM payload, it will look and act correct the first login or two, then the effective permissions for askForPasword will switch to false without warning. At least that's been my experience. "askForPassword = false" also seems to override "forcePIN = true" in cases where a loginwindow payload and a passcode payload are applied at the same time.

This issue has been recently escalated to both JAMF and Apple.

hope this helps

[tuinte]

I've had such inconsistency pushing this setting that I'm now just filling existing users and the user template with an appropriately configured com.apple.screensaver.plist.

[GabeShack]

Funny part is I DONT have this configured, but do have other configuration profiles managing Login screen and Energy Saver settings and we randomly see machines (on 10.8) asking for a password when waking from sleep (even though the energy saver settings I'm pushing are set not to let the machine sleep).
Really frustrating,
Gabe Shackney
Princeton Public Schools

[pbetancourth]

Has anyone else noticed this? I started noticing inconsistent result on laptops that would occasionally not ask for password, but I am having this issue consistently with all my Mac minis.

[rongrw]

I'm just wondering if there are any updates on this issue? We are currently facing this problem in our 10.9.2 SOE. We deploy all of our client settings with configuration profiles. The "Login Window" payload holds a number of settings that are required in our SOE. To eliminate the deployment of this payload just to resolve the screen lock password problem is simply not practical for us. Our JSS is 9.25.

Cheers, Ron.

[TreeMan]

having same issue with 10.10.3 macbook airs

I have: "Require password after sleep or screen saver begins" enabled in my security and Privacy config profile. But it has no affect

should be asking for password after these keyboard shortcuts:
shift+control+power or alt+command+power

jss v9.52

[RobertHammen]

Here's how I'm doing it: Script/LaunchAgent combination. This way, the script is run as the user when they log in, and it also sets default values, in case the users have changed things).

Script (named setscreensaveroptions.sh, located in /Library/Scripts with chmod +x permissions):

#!/bin/sh

#turn it on
defaults write com.apple.screensaver askForPassword -bool true
#set the delay in seconds, 0 = immediate
defaults write com.apple.screensaver askForPasswordDelay 0
#set the screen saver delay in seconds, 900 = 15 minutes
defaults -currentHost write com.apple.screensaver idleTime 900

LaunchAgent (named com.company.setscreensaveroptions.plist, located in /Library/LaunchAgents owned by root:wheel with POSIX 644 permissions):

<?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>Label</key>
  <string>com.company.setscreensaveroptions</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Library/Scripts/setscreensaveroptions.sh</string>
  </array>
 <key>KeepAlive</key>
<dict>
    <key>SuccessfulExit</key>
    <false/>
</dict>
</dict>
</plist>

[TreeMan]

still seems to work with 10.9.5 though...

[bentoms]

@TreeMan IIRC, JSS 9.6+ offer 10.10.x support.

[TreeMan]

Thanks Robert! I'll try that.

[TreeMan]

And thank you bentoms!

[Look]

On 10.10.3 the setting works but it defaults to 5 minutes after screensaver has activated.
We got around it by importing the immediate option as a custom entry for a configuration profile, seems to work without any issues.

[bbot]

@Look Can you tell me what settings you changed to the screensaver.plist file for the custom entry?

[bbot]

The check box for "require password after sleep or screen saver begins" doesn't appear to make a different in Casper. Running on mac version 10.10.3.

[Look]

Pretty sure all I did was edit my ~/Library/Preferences/com.apple.screensaver.plist file and then import it in as a custom configuration after editing the askForPasswordDelay key to 5.

<?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>1</integer>
    <key>askForPasswordDelay</key>
    <string>5</string>
    <key>tokenRemovalAction</key>
    <integer>0</integer>
</dict>
</plist>

What shows in Casper is

Preference Domain: 
com.apple.screensaver
Property List File:
{tokenRemovalAction=0, askForPassword=1, askForPasswordDelay=5}

[Look]

Set at Computer Level

[bbot]

What kind of editor are you using to edit plists? Thanks.

[bbot]

nevermind, i downloaded textwrangler. Thanks!

[Look]

@brandobot TextWrangler user from forever here :)

[TreeMan]

@Look Thanks! that did the trick for me!

[jason_bracy]

I'm having this issue after upgrading to ElCapitan.

All of the settings look correct, even edited the plist to the same settings as the Config Profile.

Screen will not lock. Anyone know if this is an Apple of JAMF bug?

[jason_bracy]

OK, I figured it out. I have not done enough testing to figure out if this is an issue with 10.11 or if it also happened in 10.10 or earlier. But what seems to happen is that a Login Window Configuration Profile includes a setting for Screen Saver "Ask For Password". This is set to FALSE by default, and the JSS does not show this setting when creating the profile. For whatever reason if your Security Settings are set in a different profile, then the Login Window settings take priority and the "Ask For Password" setting remains FALSE even though it shows as TRUE.

So it looks like the fix is to roll both Login Window and Security into the same Configuration Profile.

[Fishd]

Confirmed that this is an issue for us as well. Estate is a mix of 10.10.5 and 10.11.2 with JSS 9.82.

Will try combining the security and login window profiles in the morning and also see if it's just 10.11.2 users affected.

[dstranathan]

I'm seeing the bug on both 10.11.2 El Cap and 10.11.3 El Cap too. Havent tried 10.10.x Yosemite yet. My JSS is version is 9.81. Haven't upgraded to 9.82 yet.

I have a Profile payload set for "Require password after sleep or screen saver begins" to 5 seconds, but I have managed Macs that are showing various values (some are correctly set, some are incorrect). Very incosistent.

If I disable the setting it gets even weirder. Most users can set a value to their personal liking now, but other's revert back to a totally different (previous?) value - as if the Mac is still holding on to a specific "ghost" value.

I dont have any Loginwindow Profile Payloads right now. But I will doing testing with Loginwindow and Security togather.

My JAMF rep said there are (2) defects:

D-009503: Discovered in 9.73
D-010036: Discovered in 9.82

John Kitzmiller has a good write-up:

http://www.johnkitzmiller.com/blog/security-privacy-configuration-profile-bug-in-casper-9-82/

[jlong]

Unfortunately I spent most of my week troubleshooting this. It started cropping up shortly after upgrading to 9.82 last week. There were several different things that seemed to fix it, only for it to crop back up again later. For example, changing the screen lock value to 5 seconds seemed to work initially on one computer, only for it to fail again later (and not working at all for any other machines).

In addition to the screen lock, there was also another intermittent situation that seemed to be related in which the user could move the cursor but not interact with the system in any way. Only the gui was affected.. ssh still worked. It seemed as if the machine may have been attempting to screen lock, but was prevented from showing the screen lock overlay. Not sure if that's what was actually happening, but the below fix seemed to eliminate this problem as well.

Here's what ultimately seems to have fixed it for us:

1. Revoke any configuration profiles that contain both Security and Login payloads separately.
2. Push out a single replacement configuration profile that contains both a Security and Login payload, with the Security payload configured to activate screen lock after 0 seconds (other values may work, this is what we use and what was tested).
3. Issue a command for each user: defaults write /Users/<username>/Library/Preferences/com.apple.screensaver.plist askForPasswordDelay -int 0. Make sure to chown the plist to make the logged in user owner (chown <username> <path to screensaver.plist>).
4. At this point the screen lock will either work right away, or the system will require a reboot.

It also doesn't matter if you reverse steps 2 and 3, just as long as you don't have any profiles with a singular login and security payload installed. Step 3 was also crucial, and trying to instead push out the plist as a custom setting config profile did not work for us.

We pushed this out to everyone on Wednesday, and so far have had no other issues.

[Nix4Life]

I have been using the script posted @RobertHammen on 10.11.1 - 10.11.3 as a login script with outset since 10/15 with no issues

#!/bin/bash
defaults write com.apple.screensaver askForPassword -int 0
defaults -currentHost write com.apple.screensaver idleTime 7200
defaults write com.apple.screensaver askForPassword -bool false

[gachowski]

@jlong

I am seeing the same thing... has anyone opened a ticket with Apple? Are we sure it's a JSS issue.. It very strange that it works on some machines and not on other...

I kinda feel that this it's the OS that is confusing the setting as I would find it very surprising that the JSS is mixing up the profiles...

My setting are Ask For Password true and askForPasswordDelay 60

[chris_kemp]

We just went through this yesterday - it only cropped up after we made a change to one of the existing Config Profiles and re-deployed it, and suddenly we started getting multiple reports of this problem.

Same as @jlong, we found that using separate Config Profiles to deploy Security & Login Window payloads was the problem. The Login Window payload is passing a key that says password is not required, and this is overriding the key set in Security; and unfortunately, there is no way to change this setting in the Login Window payload. However, combining the two into a single Profile, for whatever reason, seems to work fine.

I did not bother with the "defaults write" commands, since that's an MCX-driven approach and isn't really necessary. I didn't find that it affected the timeout result.

Our TAM acknowledged a Product Issue, D-010036, that they are working on.

[jlong]

@gachowski If you look at the screen shot in the @jason.bracy post here: https://jamfnation.jamfsoftware.com/discussion.html?id=9982#responseChild109883

...you can clearly see that the Login payload contains an askForPassword value for the Screensaver. No such value is available in the configuration profile through JAMF, so it appears to be on their end.

@chris.kemp Thanks, Chris. In my case, some just needed the new Security/Login profile, others needed the defaults command as well (and there were many that needed a reboot too). We were setting the screen lock value via defaults previously, so that could be why it was necessary to set in our environment. But doing both (new config profile + defaults) was the only thing to work consistently for everyone.

[dunderwood3]

I'll just throw my 2 cents in. I was having this same issue and combining my "Login Window" settings and "Security & Privacy" settings into one profile worked for me too.

[gachowski]

: )

I can't use the Security & Privacy setting because it cancels out my, dontAllowFDEDisable=true profile, That setting is hidden in the Security & Privacy profile and set to false.

C

[jcandalino]

I've been struggling with this issue all week. Additionally, the Login Window policy seems to disable fast user switching even if it's enabled in the policy. Very frustrating.

[Matt]

This problem is plaguing one of my environments as well. I did the combined policy and its still causing issues. Do we have an official response or fix yet? This is a huge security issue for enterprises.

[ant89]

We noticed this issue here too with newly imaged machines. The config would not stick, it would be greyed out and set to 5 minutes. Seems that from factory, the default time to lock screen is set at 5 minutes.

What did was I also combined both config profiles together (login window & Security and privacy) - Set the require password to immediately AND also added Custom Settings (screensaver plist) found here http://www.johnkitzmiller.com/blog/security-privacy-configuration-profile-bug-in-casper-9-82/

So far so good. I re-imaged a test machine on 10.11.3 and the screen lock took effect immediatly after sleep or screen saver. My login window stayed the same. Im still able to see our banner.

Hope this helps you guys.

[marktaylor]

This issue has started happening on our machines here too in the last few days.

We have one configuration profile on the problem machines which just has the mobility payload enabled, we are not using the Security & Privacy payload.

Our machines now have the “require password after sleep setting” option checked, set to 5 minutes & greyed out even after authenticating as an admin. When waking the machine up it does not require the password which is a security issue now.

JSS 9.82 & 10.10.5 & 10.11.3 machines