Apple WTF

Looks like “WTF” will be the theme for today’s post as well as the previous Sesame Street post. Today, though, I’m going to complain about…


More specifically, OS X 10.6 in an enterprise environment.

We recently added a few OS X servers to our environment so we could take advantage of the OS X-specific tools to manage our enterprise Macs. Sure, we could have just changed the schema in Active Directory to enable some of the management features. The problem with that angle is that it would require tinkering with an already heavily-modified AD schema and directory, increasing risk of damage to things that ought not be tinkered with in our environment.

So, a dedicated Open Directory deployment on OS X Server, which is attached to AD should do the job.

On our enterprise Windows clients, we have some policies in place to enhance security. Drive encryption on laptops, password-protection, locked screen savers after a fixed period of time, preventing access to certain portions of the system to non-administrators, etc.

We can do many of those on OS X, too. Version 10.4 and 10.5 appear to be the most flexible when it comes to being good little secure members of the domain. Want to require a password when waking the computer from sleep or the screen saver? Easy enough — well, depending on your definition of easy:

  1. Open Workgroup Manager
  2. Select the computer or group that you want to apply the change to
  3. Click Details
  4. Add a object
  5. Under Always, add a key called “Require Password” with an integer value of 1
  6. Apply the changes
  7. Click Done
  8. The next time your 10.5 clients check in, they’ll get the new requirement.

Sure, it could be much, much easier than that — a checkbox would be awesome, Apple — but it’s not. I don’t know why. But it works beautifully on OS X 10.5 clients. A slight mod and it works good on 10.4, of which we only have one.

But what about on 10.6? You know — the OS version that every Apple device has shipped with for the last year?

Let’s try it!

Workgroup Manager’s key editor to enforce passwords to
unlock Mac from screensaver or sleep

After a few clicks and typing, I’m met by an interesting error while adding the preference: “**** Name doesn’t match preference manifest.”  Okay, well, that’s not a huge problem. I mean, how much could the feature have changed between 10.5 and 10.6?

A few more clicks, logout of my test machine, log back in, look at the mcxquery and it shows the settings… but System Preferences shows “Require password…” as unchecked.

Here’s the mcxquery:
    idleTime                                             everything (Computer Group)               often   840
    modulePath                                           everything (Computer Group)               once    /System/Library/Screen Savers/Flurry.saver
    Require Password                                     everything (Computer Group)               always  1
    showClock                                            everything (Computer Group)               once    1

Yes, the computer is a member of “everything”. Yes, it’s picking up every other setting applied to “everything”, but System Preferences has a different story:
Why isn’t Require Password checked?

A bit more typing, clicks, logouts, logins, reboots, Goggle-ing, much review of Apple’s discussion boards and much more harsh language, it appears that it may be quite impossible to enforce this trivial enterprise security policy on OS X 10.6 by using the Apple-supplied tools for managing OS X clients.

What? Really?

Granted, I only have about 35 or 40 enterprise Macs floating around the office, but how should we enforce our corporate security policy — and we aren’t the only company that uses this seemingly trivial feature — effectively when security has been lessened in the newer version of OS X?

Did the designers and engineers just decide, “Hey, this is the new version — let’s make it less secure to discourage people from using the product even more.”

WTF, Apple?

Back to research mode, I suppose.

5 thoughts on “Apple WTF

  1. Yes, I eventually did find an answer to this one for 10.6. I really should post a followup to that old post as it's pretty fuzzy in my mind. If memory serves, I had to add a new MCX called attributes I'm using now are:Always:- AdminMayDisableMCX, boolean, false-, boolean, true- DisableConsoleAccess, boolean, true- EnableExternalAccounts, boolean, true- RetriesUntilHint, integer, 0- UseComputerNameForComputerRecordName, boolean, falseAgain, it's a bit fuzzy in my mind, but I think what happened is that once that was set, and the addition of the "AdminMayDisableMCX = false" was the magic addition. I haven't time today to fully troubleshoot to see what it was, but you might try it out just the same.I'll have to go back and document this for our other engineers, too. So it's on the To Do list.

  2. My settings look the same as yours but it doesn't seems to work.Looking forward to your document to see exactly what you have done.

  3. I finally had a chance to dig around in our configs and I think I found it.Screen Saver Loginwindow ( Always: – Login Window Idle Time, integer, 480 – Login Window Screen Saver Module Path, string, /System/Library/Screen Savers/Flurry.saver (or whichever suitable screensaver is in that location) – Require Password, integer, 1I also use a MCX to periodically reset the timeout to 480 seconds whenever the user logs back in because a user can reset that timeout at-will.Screen Saver ByHost ( Once: – Module Name, string, Flurry – Module Path, string, /System/Library/Screen Savers/Flurry.saver (again, like above, you can change this to any screen saver in the system path) – Show Clock, boolean, true (just a creature-feature — we like to know what time it is)+ Often: – Idle Time: integer, 480So, on the MCX, we do a one-time set of the screensaver so the user can change it if desired. We also set the Often directive to change the timeout to 480 seconds whenever the user logs in.You'll might also need the options, too, to prevent that password prompt from being disabled.I'll get some screenshots together and get something more useful posted as time permits.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.