Volume Number: 24
Issue Number: 11
Column Tag: MacEnterprise
By Greg Neagle, MacEnterprise.org
There is a certain type of question that pops up over and over again on the MacEnterprise mailing list, the radmind-users list, and other lists, forums, and discussion groups where Mac admins hang out. You'll also hear these questions at the Macworld IT track, and at WWDC. The questions go like this: "How do I manage the screen saver so it always asks for a password?" "How can I prevent the OS from asking the user if they want to use a newly connected FireWire/USB disk as a Time Machine backup destination?" "How do I get the Office 2008 Setup Assistant to not pop up for new users?" Or more generally, "How do I manage the user experience on all my machines?" Nine times out of ten, this question can be answered with "Use MCX!".
For several years, Apple has had a technology for managing workstations and the user experience, often referred to as MCX, or Managed Client for OS X. To take advantage of MCX to manage users, groups, and computers, an administrator uses Apple's Workgroup Manager utility to edit records in a directory service - typically Open Directory, but sometimes Active Directory or third-party LDAPv3 with Apple's schema extensions.
If your organization did not use Open Directory as its central directory service, and was unwilling or unable to extend the schema on its existing directory service, it was difficult to get the benefits of using MCX to manage your Macs and their users.
There were a few options: one, often referred to as the "Magic Triangle", involved binding client Macs to both the organization's central directory services, and to a locally-managed Open Directory server. Mac clients would then receive their user and group info from the central directory, and their client management data from Open Directory.
Another option was for admins to write scripts that replicated some of the behavior provided by MCX - usually by modifying plist files with the defaults command or PlistBuddy.
Far less frequently used was the option to store MCX data in the client's local directory service. This was possible with NetInfo, but the trouble was replicating those settings across multiple machines. You could not simply replicate the NetInfo database across multiple machines; you had to find a way to export the MCX data (and the objects it was attached to), and import this data on other machines.
So when a Mac administrator asked "How do I manage...", and you replied "Use MCX!", they'd often object: "But I don't have an Open Directory server, and my Active Directory admins won't let us extend the schema! So is there another way?" Using MCX data in the local NetInfo was too difficult, so they spent a lot of time writing scripts to manage things, and then pushed those scripts out to every machine.
Leopard changes the equation. Now there is really no excuse at all to not use MCX to manage your machines. If you don't have a central MCX-friendly directory service, you can store the MCX data in the local directory service. More importantly, since this data is stored as simple files, replicating this to other machines is as simple as copying a few files. If you manage multiple OS X machines, you must have a way to copy files to each machine - that might be a software distribution mechanism like Casper or FileWave, a filesystem management utility like radmind, or even something as basic as Apple Remote Desktop or the scp utility.
This method also allows administrators to ease into MCX management: you do not need an Open Directory server or extended schema to get started. Instead, you can start with the local directory service. Once the powers-that-be in your organization can see the benefits of MCX, they may be more inclined to invest in the resources needed to set up a "Magic Triangle" or extend the schema on your existing directory service.
Let's demonstrate what can be done with MCX and the local directory service.
You'll need Workgroup Manager, which is part of Apple's Server Admin Tools 10.5. Get them from your Leopard Server install media, or search Apple's website for "Server Admin Tools".
To work with the local directory service, launch Workgroup Manager on a OS X client machine. When presented with the dialog to connect to a server, type "localhost" as the server name, and enter the name and password of a local admin for the local machine.
You'll see a warning that you are working in a directory node that is not visible to the network. Check Do not show this warning again if you wish, and click OK to dismiss the panel.
For purposes of this demo, we'll manage aspects of the local machine using the guest computer object. Settings for this object apply to all computers that don't have an explicit computer account record in the directory, which makes it work well for this demo. Choose Create Guest Computer from the Server menu in Workgroup Manager. You'll now have a guest object in the Computer view:
Select the guest computer, then click the Preferences icon in the toolbar. We're going to set some options for the Login Window, so click the Login icon in the Preferences overview.
Under the Window tab, click Manage: Always, then make some changes to the managed settings. Below, I've changed the Heading to display the serial number instead of the machine name, added a message to the Login Window, and changed the Style to show only name and password fields (instead of the default list of users).
Click Apply Now to save your changes.
Now log out and you should see the Login Window display the changes. If you don't, a restart should get them to kick in.
Even more interesting: log back in and open System Preferences, select the Accounts preference pane, and choose Login Options. If you followed my example and set the Login Window to show name and password text fields, you'll see that option set in the preference pane, and grayed out so you cannot change it.
This is a huge advantage of using MCX instead of scripts that write to various plists - in many cases, the OS updates the user interface to reflect your management settings.
We've used Workgroup Manager to manage certain preferences for this machine, and stored the MCX record in the local directory service. But what exactly does that mean? To find out, login as an admin and open the Terminal application. You'll need root privileges, so type sudo -s and press return, entering your own password when prompted (your account will typically need to be admin level to work. If not, login with an admin-level account).
Now change to the local directory service directory, and list its contents:
root# cd /private/var/db/dslocal/nodes/Default root# ls aliases computergroups config machines users computer_lists computers groups networks
The guest computer object we created, since it's a computer object, is stored in the "computers" directory:
root# cd computers root# ls guest.plist
Let's examine guest.plist:
root# cat guest.plist
And you'll see a standard OS X plist, which is too long and boring to list here. But you don't really need to deal with the internal structure at all - to replicate these MCX settings on another machine, you need only copy this file to the same location on another machine (and most likely restart the other machine, or restart DirectoryService to get it to notice your changes). If you have a way to push out files to your managed machines, you can now push out MCX settings the same way.
The demonstration isn't very flexible: since all the managed settings are stored in guest.plist, it's hard to mix and match settings. Next time, we'll look at some MCX management strategies using Leopard's new ComputerGroups that allow you to mix and match management policies.
Greg Neagle is a member of the steering committee of the Mac OS X Enterprise Project (macenterprise.org) and is a senior systems engineer at a large animation studio. Greg has been working with the Mac since 1984, and with OS X since its release. He can be reached at gregneagle@mac.com.
