Leopard Ain’t Enterprise-Ready

So I’ve wasted the last week and a half with a new project. Twenty new MacBooks arrived, and I was told to prepare them quickly for distribution to students with an image along the lines of the one that we built last summer for our 1-to-1 laptop pilot program. Easy, right? Wrong!

Problem #1:
These new machines come with Leopard, so I tried downgrading them to the image that we use on the Aluminum iMacs that we purchased at the end of summer. This image mostly works on the new MacBooks, but I could never get video drivers for it that would run under Tiger. No accelerated graphics, and no video out. Not a deal-breaker, but not particularly desirable, either. The bigger problem was the way that the computers would go off to la-la land whenever they fell asleep. The cursor would disappear, and the trackpad and keyboard became unresponsive. The power button would still bring up the restart/sleep/shutdown dialog, but you couldn’t then choose any options.

Back to Leopard.

Problem #2:
Our 1-to-1 laptop computers are set up to authenticate our users against their Active Directory accounts, and then get their machine privileges from Workgroup Manager running on our Xserve. Unfortunately, nothing that I tried could get Leopard to bind to Active Directory. In the end, I found two distinct errors: one that failed due apparently to kerberos, and one that created the computer account in AD but then deleted it again before the MacBook could do anything else with the bind. The funny thing about this is that these two results were totally reproducible, and both came from using Directory Utility, but the former came from the new AD interface, and the latter came from the old AD interface (hidden behind the “Services” button in the advanced settings). Three hours on the phone with Apple Education finally led to the old “it’s a known issue, and our engineers are working to fix it” line. I don’t doubt that that’s true, but it doesn’t help me now.

Ok, scratch the network logon. Let’s buckle down privileges with a local Workgroup Manager controlled user group.

Problem #3:
Permissions applied to groups don’t seem to propagate down to the users in those groups. I don’t know how they let this one out in the wild, since it renders Workgroup Manager nearly useless. If I’d noticed this problem first, then maybe I wouldn’t have wasted so much time trying to get the Active Directory logon working. But I did. And I’ll never get those days back.

My final option is now to just build out the new image in Leopard, and buckle down the permissions on a user level when the computers are distributed. Image machine; cut account; follow instructions for locking down the newly-created account. Icky, but not unmanageable. Since there’s no networked directory services on these new machines, though, I sure hope that we don’t have to change any permissions after we distribute them. We’ll see. But add all this to the fact that 10.4.11 actually seems to have made our earlier wireless problems worse, and it points to me being particularly sour with Apple lately. (No pun intended.)

2 Comments Add Yours ↓

  1. Tom McNIcholas #


    Glad you did this first! Sounds like a bear. Is your AD 2000 or 2003?

    Perhaps Leopard client was expecting to be managed by Leopard Server?


  2. 2

    AD 2000, Native Mode.

    I don’t think that the client was necessarily needing a Leopard Server, since Workgroup Manager running locally still didn’t work the way that I expected it to. But without a copy of Leopard Server against which to test, that’s just a hunch.

    Anyhow, if you have the chance, you should probably give it a shot. Some people are getting Leopard to talk w/ AD—apparently on smaller LANS w/ only a single subnet—and some are probably also getting WGM working like it used to under Tiger. I’m just not one of the lucky ones, but maybe you are. And if you do give it a whack, please let us know your results.

Your Comment