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:

Screen Saver preferences management

The manifest leads you to try something like this:

Screen Saver ByHost preferences

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:

com.apple.screensaver managed preferences

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:

Security prefs pane 1

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:

Screen Saver ByHost preferences

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:

Security prefs pane 2

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 Tick

Explore posts in the same categories: General

26 Comments on “MCX vs the screensaver (and Leopard!)”


  1. Did you bug report this? It really does seem broken that you have to do it this way.

  2. GregN Says:

    Bug ID# 5754897. Feel free to pile on.

    20-Feb-2008 11:37 AM Greg Neagle:
    Summary:
    Using Workgroup Manager to manage com.apple.screensaver.ByHost preferences does not work as expected.

    Steps to Reproduce:
    1) Launch Workgroup Manager and connect to the directory service of your choice. I chose the local DS.
    2) Choose a Computer or ComputerGroup object and select the Preferences->Details view.
    3) Import the preference manifests from /System/Library/CoreServices/ManagedClient.app
    4) Edit the newly-imported Screen Saver preferences (com.apple.screensaver.ByHost): Under “Always” add the key “Require Password” and set to boolean/true. Apply Now. Done.
    5) On a managed computer, logged into the machine, make sure the desired preference is not set locally:
    defaults -currentHost delete com.apple.screensaver askForPassword
    6) Refresh management settings on the managed computer. (Log out or reboot)
    7) Login as the same user in step 5, and use System Profiler to verify the managed preferences are being applied:

    com.apple.screensaver.ByHost:

    askForPassword:

    Value: 1
    State: always
    Source: screensaver (Computer Group)

    8) Open System Preferences and choose the Security preferences pane.

    Expected Results:
    “Require password to wake this computer from sleep or screensaver” should be checked and greyed out. More important than the GUI, the machine should actually ask for a password upon wake from sleep or screensaver.

    Actual Results:
    “Require password to wake this computer from sleep or screensaver” is unchecked and greyed out. Machine does not ask for a password upon wake from sleep or screensaver.

    Notes:
    The actual required value for askForPassword is -int 1 or -int 0, not boolean, but changing it has no effect.
    Instead of managing com.apple.screensaver.ByHost as the manifest leads you to, following these instructions works: http://docs.info.apple.com/article.html?artnum=303616
    More here: http://managingosx.wordpress.com/2008/02/20/mcx-vs-the-screensaver-and-leopard/


  3. [...] MCX vs the screensaver (and Leopard!): “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:” [...]

  4. stephen Says:

    I have tried this so many times with so many different configurations and it just won’t work. I agree that the .byhost RequirePassword key makes it so that the users can’t check or uncheck that box to require password to leave the screensaver but the askForPassword key will not make any difference at all. It does not check that box. I even set it in the terminal like you said to do defaults -currentHost write com.apple.screensaver askForPassword -int 1. If you have any ideas as to what I may be doing wrong I would love to hear it. I did follow these instructions exactly.

    Thanks.

  5. GregN Says:

    What does the output of mcxquery look like when run as a logged-in user?

    We’re really only interested in the lines like this:

    com.apple.screensaver
    askForPassword screensaver (Computer Group) always 1
    com.apple.screensaver.ByHost
    askForPassword screensaver (Computer Group) always 1

  6. Jason Says:

    Thanks for this write up, it worked great!

    However, how can I set the screen saver activate time AND set it so the user can’t change it.

    Right now by using the .ByHost preference of idleTime under “often” that will change the client computer but they are able to modify it, however on next log in it will reset. It doesn’t appear to be an option under “Always.”

  7. GregN Says:

    As far as I can tell… you can’t, at least via MCX.
    Possible hacks are a launchd or cron task that fires every 5 minutes or so and resets the time to your desired time, or disabling access to the Screen Saver preference pane.

  8. Jason Says:

    Thanks Greg. I thought I might of just been overlooking something.

  9. wyatt Says:

    This is a great article, very helpful and insightful.

    One question: How do you deal with this on an image though? Once you capture this image, it will be set for the localhost defined by the ethernet address and therefore it breaks on all other systems you deploy too.

  10. GregN Says:

    If your MCX records are coming from a central directory (OpenDirectory, Active Directory, LDAP), they’re not baked into the image. If you are using MCX in the local DS store, you need to implement a script that recreates the localhost computer record with the current machine’s MAC layer address. I give an example in one of my other posts on Local MCX.

  11. Volkan Says:

    “/System/Library/CoreServices/ManagedClient.app, you import a bunch of useful preference manifests.”

    How can we delete thosepreferences we do not want? The “-” button is inactive for those preferences …

    Thank you …

  12. AF Says:

    I’ve noticed that in Leopard 10.5 that the file: ~/Library/Preferences/ByHost/com.apple.screensaver..plist does not exist in the location listed here. How do I make these changes in Server 10.5?

  13. GregN Says:

    “I’ve noticed that in Leopard 10.5 that the file: ~/Library/Preferences/ByHost/com.apple.screensaver..plist does not exist in the location listed here. How do I make these changes in Server 10.5?”

    Sure it does. But first you have to make changes to the ScreenSaver settings – if you’re using the defaults, there won’t be any file there.

    And remember you can (and probably should) run Workgroup Manager on a client machine that’s connected to the directory – you don’t have to run it on the server itself.

  14. AF Says:

    I’ve managed to locate the file, I didn’t realize it was in the home folder…But now when I go to import I get an error:

    Debug Message
    Unexpected Error. File:/SourceCache/WorkgroupManager/Preferences/WorkGroupManagerPreferences-360/LowLevelEditor/PrefDetailsPi.MM Line:1463

    Any ideas?

  15. GregN Says:

    “I didn’t realize it was in the home folder”

    The notation “~/some/path” means the some/path in the current user’s home folder, wherever that might reside.

    No ideas on the error. I know Apple claims they’ve fixed this issue in recent releases of 10.5 (10.5.5 or later), so perhaps this workaround is no longer needed, and trying to do it trigger the error…

  16. AF Says:

    I am upgrading to 10.5.6 so we’ll see if that makes a difference. Thanks for your help.

  17. Sean Says:

    This is all well and good, and a huge help. But how do I enforce the timing of the screensaver? I set the idleTime key but it just won’t seem to take. Any suggestions?

  18. GregN Says:

    How are you trying to manage idleTime? There’s a known/observed bug/shortcoming/mal-feature where you cannot manage this Always. The best you can do is manage it Often. This means the user can change it, but on log out/log in, it will be reset back to your default.

  19. Michael Mock Says:

    I was trying to find out where to get more information on keywords to use to define the preferences I want. For example. I do not want my students to be able to see the connected servers on the sidebar of the finder. Not sure what string to enter to control that. Any resources?

  20. Mike Morales Says:

    Greg, thanks for this info. I was wondering how one would enforce the screensaver lock on systems. It seems crazy that Apple doesn’t provide an easier way to implement this, considering most corporate environs would want this done.

    @Sean- As for getting the screensaver to always kick in at a specified time, a simple launch agent pointed to a script can be configured to do this, provided your systems are on 10.5. I had a terrible time getting the same configuration to work correctly on 10.4 though. Tiger’s launchd system was pushed out a bit incomplete and buggy.
    I eventually got this to work using the sleepwatcher daemon from Bernhard Baehr on our 10.4 Macs. Its not as clean since the .sleep file must live in each user’s home folder, but most users are unaware of it, so have no way of disabling it.

  21. Jeff Says:

    I just found out that a Snow Leopard client is not having its screensaver locked. Luckily one of our servers is now running Snow Leopard. I added the ManagedClient.app to the Details view in Snow Leopard Workgroup Manager and I noticed there is a new screensaver plist. I was able to add a new Always item and set it to require password with integer set to 1. The little description box at the bottom will tell you the correct syntax and warn you if there is an error in the settings. Hopefully that fixes it.

  22. GregN Says:

    Jeff: You are correct! I wrote up the changes for a MacTech article (probably published in the Feb 2010 issue), but I’ll do a highlights reel for here…

    -Greg


  23. [...] envision this is something my IT department has rolled out using Managed Client (perhaps with these workarounds to make it actually work). Before starting the process of filing tickets with them, trying to [...]

  24. Cyrus Says:

    Hi Greg. I’m trying to implement this but I’m not certain how you roll this out and what gets rolled out. Is this solution using what you wrote up in “MCX, dslocal, and Leopard” or is it something much simpler that I’m missing?

    Thanx

    • GregN Says:

      This is just vanilla MCX. You can deploy MCX in your organization via Open Directory and an OS X Server, or by extending the schema if you use Active Directory or a third-party LDAP service, via Dual Directories, or via Local MCX.

      This book:

      covers many of the possibilities.

      -Greg


Comments are closed.


Follow

Get every new post delivered to your Inbox.

Join 187 other followers

%d bloggers like this: