MCX vs the screensaver (and Leopard!)
Enforcing a screensaver for security reasons has given me a lot of headaches over the years.
You’d think something as simple and basic as enforcing a screensaver would be easy. There have been plenty of hacks to do so. I developed one for 10.1 that I also used for 10.2 and 10.3. Later, I moved to a script that ran at login that used
defaults -currentHost write com.apple.screensaver to set the desired preferences at each log in.
For Tiger, Apple documented a way to enforce the screensaver via MCX (Managed Client): you can read the article here.
With Leopard, Apple added a Preferences Manifest for the screensaver. In Workgroup Manager, in the Preferences management Details view, if you add /System/Library/CoreServices/ManagedClient.app, you import a bunch of useful preference manifests. Among them is one for the Screen Saver:
The manifest leads you to try something like this:
Which looks reasonable. So I set this up, did some minimal testing on my personal laptop, and rolled it out. I was happy and confident: I was now managing this the “Apple-supported way”, instead of relying on elaborate hackery.
And then a company vice-president asked why the screensaver wasn’t being enforced on his new MacBook Air and why he couldn’t turn it on.
A little investigation, and he was right. How embarrassing: not only was the screensaver not being enforced — the checkbox in the Security preferences pane was greyed out and unavailable. Users couldn’t even turn it on manually. So in effect, I had done precisely the opposite of what I had intended: I had enforced the screensaver to be turned off by default and prevented users from turning it on.
It appears that the preferences from the manifest imported via ManagedClient.app do not work as intended. I’ll be filing a bug on that…
But I’ve found a workaround.
First, set the appropriate preference manually:
defaults -currentHost write com.apple.screensaver askForPassword -int 1
Then use Workgroup Manager to import the preference as in the aforementioned article from Apple.
When importing the preferences from ~/Library/Preferences/ByHost/com.apple.screensaver.xxxxxxxxxxxx.plist, choose “Manage imported preferences: Always”. You’ll note that the “Import as ByHost preferences” checkbox becomes unselected and greyed out. That’s OK, and in fact, is what we need to make this actually work.
You’ll have a new entry in the Details view for com.apple.screensaver (as opposed to com.apple.screensaver.ByHost). Double-click to edit, and make it look like this:
Note that for the key “askForPassword”., I’ve changed the type to “integer”, and the value to “1″. It will probably be imported as boolean/true, but that won’t work.
Apply this change to a client machine, then check the Security preference pane. It will look like this:
We’re most of the way there – “Require password” is now selected by default, and is enforced. But there’s a cosmetic issue – it appears the user can uncheck the box – but if they quit and re-open System Preferences, they’ll find it rechecked. If this bothers you, we can make one more change to make this checkbox unavailable…
Go back to Workgroup Manager and edit the com.apple.screensaver.ByHost preferences (yes, those again, the ones that betrayed us in the beginning…) If you had removed them since they weren’t working, put them back:
They are still broken in that they don’t force the screensaver password, but they do cause the checkbox to become unavailable in the Security preferences pane. Now it looks like this:
That’s better! Still too much work, and might break in the future…
To summarize: to get the behavior I wanted, which is to require a password when waking from sleep or screen saver, and to prevent users from changing this setting, I needed to use Managed Client to manage both the com.apple.screensaver and the com.apple.screensaver.ByHost preferences. I hope this saves someone some time and aggravation.
“Well, once again my friend, we find that science is a two-headed beast. One head is nice, it gives us aspirin and other modern conveniences, but the other head of science is bad! Oh, beware the other head of science, Arthur — it bites!” – The TickExplore posts in the same categories: General