I'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.
