+1Hey all!
Been struggling with the auto screensaver setting for a while now. Whenever i set the "start screensaver after" setting to 20 minutes in "configuration profile -> login window" nothing happens and it's still stuck to 1 minute. I want this to be set tot 20 minutes or I want my users to be able to set their own time. Setting it to 0 or disabling it kept it still at 1 minute without being able to change it.
Let me know if you need more info! Pretty new to this..
+2I'm not sure why setting "start screensaver after" isn't working for you. If you tick the box and enter 20 as a the value it should work. Are you able to look at System Preferences / Profiles on a machine to see if the configuration profile applied and what setting it says has been set ?
Using a configuration profile will set a specific value and prevent the user from changing this value, there is no flexibility unless you get a little creative. Keep in mind the following might not actually be considered as a good security practise as it allows for periods of non compliance.
First you want an Extension Attribute (EA) script which check for the current logged on users screensaver settings:
#!/bin/bash
#Returns "Compliant" if current logged in user has a screensaver timeout between 1 and 20 mins
#Otherwise returns "NonCompliant"
#Errors return as "Indeterminate" to cater for scenario when no user is logged in or the sudo or the key is missing
loggedInUser="$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk '/Name :/ && ! /loginwindow/ { print $3 }')"
currentTimeout="$(sudo -u "$loggedInUser" defaults -currentHost read com.apple.screensaver idleTime)"
# if user has never changed screensaver settings or the sudo fails then we might not receive back a clean integer
if ! [[ $currentTimeout =~ ^[0-9]+$ ]]; then
echo "<result>Indeterminate</result>"
else
# check if current timeout is within tolerances
if [ "$currentTimeout" -le 0 ] || [ "$currentTimeout" -gt 1200 ]; then
echo "<result>NotCompliant</result>"
else
echo "<result>Compliant</result>"
fi
fi
Secondly create a smart group which contains any computer for which the above EA returns "NonCompliant".
Next create a policy scoped to the above smart group which runs just once per day. This could be changed perhaps if you want to remediate the non compliant systems on a different schedule.
The policy can run the following script to set the screensaver back to something like 10 mins.
#!/bin/bash
loggedInUser="$(/usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk '/Name :/ && ! /loginwindow/ { print $3 }')"
currentTimeout="$(sudo -u "$loggedInUser" defaults -currentHost read com.apple.screensaver idleTime)"
echo "Current Screensaver Timeout: $currentTimeout"
# if user has never changed screensaver settings or the sudo fails then we might not receive back a clean integer
if ! [[ $currentTimeout =~ ^[0-9]+$ ]]; then
echo "which is not a number so exiting"
exit 1
fi
# check if current timeout is within tolerances, if outside, ie less than 1 or greater than 1200 then reset to 10 mins
if [ "$currentTimeout" -le 0 ] || [ "$currentTimeout" -gt 1200 ]; then
echo "Current value outside of tolerances so resetting to 10 mins"
sudo -u "$loggedInUser" defaults -currentHost write com.apple.screensaver idleTime -int 600
fi
Depending on how often you perform inventory updates across your fleet, the computer should then drop out of the smart group at the next recon which is hopefully before the remediation script is run again.
This is a trade off between security and flexibility and allows for some users to set themselves short time outs and others longer timeouts when they are working from home etc.
It saves having to classify your users into groups which want different settings, but that might also be an option for if you don't want to use the scripts above and want users to be set to a specific value. Make a group for users who need short timeouts (5 mins) , another group for those who want really long timeouts (20), and keep everyone else at 10 mins. You can make 3 different configuration profiles with those values and scope them to the each group.
You could also add some policies to Self Service which sets/removes people into those groups, allowing for people to self select between the 3 values. Usually you do a little trick by writing a file to disk and triggering a recon in order to change an EA. This EA can be used as the basis for the smart groups. This avoids coding an API call which may store API credentials insecurely on each computer.
When a configuration profile is scoped to a group and that group changes, the addition or removal usually only takes a few seconds to apply so it is generally a quick operation.
+2Hey there,
this topic is pretty old but I've resolved my own issue with this topic today and wanted to make this solution public:
If you set "Maximum Auto-Lock" in the "Passcode" Payload, you're configuring the "Lock Screen, setting the time for "Start Screen Saver when inactive" and you're setting it with a profile thus locking it down.
When I remove this setting from the payload I could set the time freely or change it within a radius of 1-15 minutes. When you want to set longer time, that can be done through a custom plist but I was only able to set 2,5 hours (9000 seconds) also the gui offers 3 hours but "10800" seconds would result in 3 minutes instead of 3 hours.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.