Volume Number: 25 (2009)
Issue Number: 02
Column Tag: MacEnterprise
by Greg Neagle
In the November issue, we looked at getting started with MCX by using MCX records in the local directory service. We set some policies for the loginwindow using the Guest Computer object, verified they worked, and noted that the Accounts preference pane had certain controls grayed out to match our management settings.
Since local directory service entries in Leopard are simply plist files stored in /var/db/dslocal/nodes/Default, replicating MCX settings to multiple machines can be as simple as copying a few files.
LodIf you are going to use the local directory service to store MCX data, you'll quickly discover that putting all your management settings into the Guest Computer object doesn't give you very much flexibility. If you want different groups of machines to have different management settings, you'll have to maintain multiple versions of /var/db/dslocalnodes/Default/computers/guest.plist, and mixing and matching management settings becomes tedious, as you'd have to create a version of the guest.plist for every needed combination of management settings.
A new feature of MCX in Leopard can help: Computer Groups. Prior to Leopard, MCX supported "Computer Lists", which were, unsurprisingly, lists of computers. Management settings could be applied to Computer Lists, which would then apply those settings to all computers in the list. The downside is that a given computer could be a member of only a single computer list at a time.
Leopard's new Computer Groups behave more like groups of users: a computer can be a member of multiple Computer Groups. This allows you to modularize your management settings. Create a Computer Group called "loginwindow" and apply all the loginwindow management to that Computer Group. Create another Computer Group called "screensaver" and apply your screensaver policies. If you want a machine to have both the "loginwindow" and "screensaver" policies, just add it to both Computer Groups. In this way, you can modularize your policy settings and mix and match them among machines. This approach even works if you are implementing MCX management in a traditional network directory environment.
Perhaps now you're thinking, "Great! I'll create Computer Groups with my desired management settings, add the Guest Computer to each of those Computer Groups, and I'm all set!" Not so fast. There's a complication: even though Workgroup Manager allows you to add the Guest Computer account to a Computer Group, the MCX settings for the Computer Group are not applied to guest computers. So we'll need to use another way to take advantage of Computer Groups.
Use Workgroup Manager to connect to the local directory service as we did last time:
We will create a computer record that will represent the current local computer. Make sure you are working in the /Local/Default directory. Select the Computer accounts icon in the left pane, and click New Computer. Set the Name and Short Name to "local_machine", and click Save. You can leave all other fields empty.
You can now add this computer record to your Computer Groups:
We're not done yet - MCX still has no way to know that by "local_machine" you mean the current machine that this is running on. To do this, we have to add some data to the local_machine record.
MCX identifies machines by the MAC layer address of their en0 interface - this is usually the built-in Ethernet port, but in the case of a MacBook Air, this is the AirPort interface. Here's a way in the command-line to get this info:
root# ifconfig en0 | awk ' /ether/ {print $2}'
00:1b:63:93:8b:ac
So the MAC layer address for this machine is 00:1b:63:93:8b:ac. We can add that to the local_machine record like this:
root# dscl . -create /Computers/local_machine \ ENetAddress 00:1b:63:93:8b:ac
Checking our work:
root# dscl . read /Computers/local_machine AppleMetaNodeLocation: /Local/Default ENetAddress: 00:1b:63:93:8b:ac GeneratedUID: 15BEE70A-A32D-4A33-B740-93CBE95F75A4 RecordName: local_machine RecordType: dsRecTypeStandard:Computers
Note that the GeneratedUID will vary, as it is created when you create the computer record in Workgroup Manager.
To actually take advantage of this, we'll need to write a script that runs on each machine that modifies the local_machine record with the MAC layer address of the current machine. Here's a very simple version:
#!/bin/sh
MAC=`ifconfig en0 | awk ' /ether/ {print $2}'`
dscl . -create /Computers/local_machine ENetAddress $MAC
This script gets the current MAC layer address and updates the local_machine record accordingly. You'd want to implement this script as one that ran during startup. You could do this as part of a StartupItem, or use launchd.
Now you have a computer object that corresponds to the local machine, and management settings attached to Computer Groups. To implement these management settings on another machine or machines, you need to copy to each machine:
While testing your new MCX settings, you'll want to be aware of tools available to you so you can see which MCX settings have been applied to your machines. The easiest tool to use in Leopard is System Profiler. Under the Software section is a new Managed Client category. You can use this to see what preferences are being managed, and their source.
In the illustration, we can see that com.apple.TimeMachine's preference "DoNotOfferNew-DisksForBackUp" is set to "1", that this is applied "often", and these settings come from membership in the "timemachine" Computer Group.
Another tool is available at the command line: mcxquery. Prior to 10.5.3, mcxquery did not display proper results when MCX records were in the local directory service, but it now behaves as expected.
mcxquery -user shortname
will show you the effective MCX settings for the user on the current machine.
In this series of articles, we've looked at ways of using the local directory service to implement MCX settings. This would be useful for environments that don't have Open Directory, and cannot or will not do schema extension for Active Directory or third-party LDAP directory services. Mac administrators can also use these techniques as a proof-of-concept for MCX client management, using the local directory service implementation as a prototype for what benefits your organization would realize by extending the schema on its existing directory services.
There are certainly applications of this concept outside the management of enterprise workstations. Parents could use Workgroup Manager to manage their children's user account and capabilities - a sort of Parental Controls on steroids. In another application, the author used MCX records in the local directory service to lock down a Mac used as an iTunes jukebox. Since you are using local records, you can experiment with various settings and not worry that what you try will affect other machines on your network.
If nothing else, taking advantage of local MCX records should lower the entry bar to using Apple's client management system. If you haven't been using MCX in the past, there is no excuse not to at least try it now, and see how it can help you better manage Macs in your organization and give your users a consistent user experience.
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.
