Apple OMFG — A WTF Update…

So, I was complaining earlier about what looked like a severe oversight on Apple’s part about a simple, trivial enterprise change that needed to be made.

Happy to say that the problem has been identified, tested, and resolved. I sure enjoyed spending the day poking around in the deep, dark, seedy underbelly of OS X…

Read this first as it has background on the problem.

The solution?

Don’t edit the “Screen Saver ByHost” object (  Instead, you’ll edit the “Screen Saver Loginwindow” object (

I now have these three items under “Always”:

  • Login Window Idle Time, integer, 300
  • Login Window Screen Saver Module Path, string, /System/Library/Screen Saver/Flurry.saver
  • Require Password, integer, 1

To wit:

How to force users to enter a password managed
OS X 10.6 after screen saver or sleep.

Sure, enough, after logging out and back in on that machine, I get this in the user’s view of System Preferences:

Yes, indeed. That’s what we want. “Require password… after sleep or screen saver begins” is checked as it should be and the user is not allowed to change it.

What kept throwing me — and I dismissed because of association — was that all other attributes said, “Login Window…” So, I kept thinking “Oh, the main login window. That’s not what I want.” When, instead, I should have been thinking, “All login windows.” When they say “login window”, consider that the act of unlocking a computer after sleep or screen saver is, in fact, through a login window.

I’ve heard there are some other people out there who’ve run into the same kind of thing on their 10.6 managed networks. If so, I hope this resolves the problem for you.

Next on the To Do list: figure out how to prevent the user from changing the screen saver idle time from the value we set.

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.

Sesame WTF

Because I have small children, I have the, um, pleasure of having Sesame Street on my DVR for their entertainment. That should explain why a grown man is going to share a wee story about a kids’ show.

So, in the current Sesame Street series, there’s a segment called Abby’s Flying Fairy School. It’s about fictitious fairies and magical creatures. In it, there’s a creature called a gerbilcorn. Think gerbil with a single horn on it’s head — like the fictitious unicorn.

The gerbilcorn lives in a cabinet, but they call it a hole–for reasons that could only be clear to, well, people whom I’m not so sure one would want involved with children.

In an episode of Flying Fairy School, the gerbilcorn wound up sequestering itself in his cabinet, er, hole. Abby, the schoolmaster?, told her students who were trying furiously to extract the creature:

No person, fairy, elf, or troll

Can open the door to a gerbilcorn hole

Don’t get it? Okay, read it out loud. No? Try looking up the definition of the colloquial word, cornhole.

When I heard that the first time, it occurred to me that there were some writers sitting in a room somewhere coming up with the concept for the show with only that joke in mind. How else could one explain the concept of a gerbilcorn?

I’ll see if I can grab a video of that segment so you can see it in context. It’s amusing, but curious.

In more Abby’s Flying Fairy School entertainment, there was a segment where one of the faries, named Gonnigan (pronounced “gone again” — yeah, they use that joke, too), had been magically turned into a prince. Gonnigan was upset about having to be turned back into a fairy. The schoolmaster replied, “you’ll always be the fairy who was formerly known as a prince.”

It’s a play on the reference to the pop musician called Prince. He had changed his name from Prince (presumably from some other traditional name as well) to the two symbols for male and female — as representation for his sexual orientation. Because his new name was for practical purposes, unpronounceable, he became known as “The artist formerly known as Prince.”

So, Sesame Street’s producers like referencing rodentia in rectus and make references to gays and bisexuals as fairies. Not quite the same polite, tolerant, kid-friendly Sesame Street of my childhood.

Guess what’s getting deleted from my DVR right now?

Backing Up an OSX Server

Just started to read over some of the administrative docs for OSX Server — since, after all, I recently deployed some at work. Deploy first, learn later, right?

At any rate, the servers are up and stable. There are some rough edges to clean up, but they’re working.

So, one of the big things we need to get sorted out is backups. All this time, I thought that we’d be able to take advantage of Time Machine for the server stuff, but it turns out that it doesn’t back up server content. No, really:

From Apple’s Advanced Server Admin v10.6, p. 19:

Service: Backup your data (websites, databases, calendar files, etc.)

Set in initial server setup: No

Server Preferences: No, use command-line tools and third-party backup solutions

Server Admin: No, use command-line tools and third-party backup solutions

Wow, not only did they say “No” but “No, figure it out on your own”… twice.
There’s also this little gem later on on page 36:

Time Machine is a limited tool for data backup and restoration of Mac OS X Server v10.6. It can back up some server configuration settings and the service state. Time Machine does not back up service data.

So, Time Machine will readily back up user profiles for desktop users — I use it for that all the time and have had computers totally pooched easily restored from a Time Machine backup. But it won’t back up the important stuff on a server. You know — all of the stuff that a server needs to actually have backed up.

Well, I’m not a Linux Engineer for nothing — guess I’ll have to break out the old-school Unix rsync and tar commands.