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.

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.

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/

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.

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

@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

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.

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

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.

: )

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

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.

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.

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.

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

I have resolved this issue with JAMF support by creating a signed config profile with both login screen and security and privacy settings and then importing it to the JSS.

@jlong would you be open to sharing screenshots of your Security and Login config profiles? Our users are experiencing the screen lock issue badly.

Sure, @jenieze Definitely interested to know whether it helps you or not.

Originally we had a configuration profile setup for each payload, on the advice of our jump start tech. So we had one profile that contained a Security payload, and another that contained a Login. I revoked both of these first, and then issued a new profile with the combined payloads (as mentioned by several others). The profile looks like this:

This alone was enough for some clients, and seems to have been all that was necessary for most in this thread. But in our environment we also had run a script in a separate policy, once per computer. Additionally, after both updating the profiles and running the script some clients had to reboot before the settings took effect.

Someone with more scripting experience could easily do a better job, but here's the script I used:

#!/bin/bash

#

# get current logged in user

loggedInUser=$(python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "

");')

#

# Set screen lock delay preference for user to 0 seconds

defaults write /Users/$loggedInUser/Library/Preferences/com.apple.screensaver.plist askForPasswordDelay -int 0

#

# change ownership of preference back to user

chown -R $loggedInUser /Users/$loggedInUser/Library/Preferences/com.apple.screensaver.plist

Instead of running a separate script -- add a Custom Setting (screensaver plist) into the config profile.

Our config profile contains the following payloads:

Login Window
Security & Privacy:- Require password immediately after sleep or screen saver begins
Custom Payload: com.apple.screensaver

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

    <real>0.0</real>

    <key>tokenRemovalAction</key>

    <integer>0</integer>

</dict>

</plist>

This works perfectly for current and newly imaged machines. It applies instantly to both 10.10 and 10.11 machines. We are on 9.82

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

@jlong Thanks so much! So far so good with the fixes you've sent!

@acorn Thanks for the suggestion. I did attempt John Kitzmiller's method, and while it worked for some clients, it unfortunately did not work for all. Running the script to force the defaults settings paired with the combination payload in the config profile was the only thing that's worked consistently for us. This might have been because we were using the defaults command to set the screen lock delay value before adjusting that option was supported in the config profiles but that is little more than a guess.

@jenieze No problem, and glad to hear it is working so far.

Followed instructions on http://www.johnkitzmiller.com/blog/security-privacy-configuration-profile-bug-in-casper-9-82/ and now issue resolved.

Methinks that folks at JAMF should've fixed this during QA.

Corbin

It's not just Jamf it's all MDMs .....Apple has the same issue just in a different profile.. The real issue is that everyone is still using MCX as the model and profiles are different also after 6 years Apple hasn't changes how the MCX setting are nested in the OS.

One setting = one profile is the only real way to prevent this issue in the future... We are going to have to all build custom profiles and then sign them before we upload them to the JSS.

C

After all of these issues related to lock screens, screen saver times, sleep times etc, I have decided to simply diable the setting altogether. Not worth the trouble at my company because we dont have a top-down mandatpry policy for lock screens (we are not bound by SOX or HIPPA etc).

I have unchecked the setting "Require password X after sleep or screen saver begins" in the Security & Privacy Payload, and I have unchecked the setting "Start screen saver after X" in the Login Window Payload, but my end users are still complaining that they still cant disable/change these settings.

Screenshot below clearly shows the setting is no longer enabled on the JSS, but the clients are still prompted for passwords at 5 seconds. Apparently this is making users grumpy.

I just want to punt on this particular Profile. Not worth the energy and time to babysit it.

If I nuke the entire Profile (delete it from the JSS) will it remove itself from all managed Mac systems?

@dstranathan The problem is, I think this setting is applied by default starting with 10.10.x. In fact, I've had the complete opposite problem, I can't get the Require password box unchecked! See this thread:

https://jamfnation.jamfsoftware.com/discussion.html?id=12927

I still don't have a workaround.

hey all -

i installed 9.9 on my test JSS yesterday to see if it fixed this and it did not.

I am still having the same issues in my environment:
1) Screen lock setting not being properly applied with config profile
2) Systems intermittently freezing upon waking from sleep (keyboard stops responding)

Both issues happened on my 10.11.4 laptop. (Second issue is documented here: https://jamfnation.jamfsoftware.com/discussion.html?id=19067)

Has anyone else had any luck with 9.9 fixing these issues?

Thanks,
skoonin