Leopard Server Part 2 - Local Directory Services

Good-bye NetInfo, don't let the door hit you in the ass on the way out. 

Continuing on our review of Leopard Server we turn to something not truly server specific, but one that will have a significant impact on your environments. Many of the tools you might have been using are now dead and gone, but you should get over that pretty quickly as their replacements have been greatly enhanced.

Read on for more...

Overhauled for Speed

In Mac OS X 10.4 and earlier there was a collection of daemons that did all of the directory service work. DirectoryService itself was the daemon pulling most of the strings, but it many times had to call out to helpers. The venerable lookupd did local NetInfo lookups in addition to DNS resolution and provided an entry point for things using libc. In 10.4 memberd came along and theoretically allowed for a much more robust group experience including nested groups and support for more than 16 groups per user.

This worked, but it was at best an interim solution. There was a significant amount of interprocess communication between the three. Lookups had to go through unnecessary round trips as well. For example, using the Apple Directory Service APIs to lookup a local user would first hit DirectoryService which would then farm out the request to lookupd, since it's a local user. When lookupd responded, DirectoryService could then respond back to the requesting application.

Things got even worse when you wanted to lookup a remote user. Every single lookup would first be handed off to lookupd to ensure it wasn't a local user. Only then could DirectoryService hand off the lookup to one of it's own plugins to query the LDAP or AD directory.

In Leopard all three of these daemons have been combined into just one, DirectoryService. The reduction in unnecessary lookups and interprocess communication in general should greatly enhance directory services in general. In addition a lot of cruft code was removed and some things like NIS, of all things, got some extra love and attention.

All in all, Leopard should present a much more streamlined and functional directory service infrastructure.

Die NetInfo Die!

NetInfo is dead, long live the default local node!

The NetInfo database that held all of the local users has been replaced with a brand spanking new collection of flat files. Don't let the name fool you, this isn't your bearded Unix grandfather's flat files, which are still useable if you want, but a collection of individual xml files that describe every entry that used to be in NetInfo. Imagine if you will, that NetInfo barfed it's entire contents into plists and you'd have a close approximation of what now runs your system.  This isn't one of those cases of XML for the sake of it. Local Directory Service records are a prime case for being stored in a self-describing, plain text editable format, and you can now manipulate that database in just about any scripting language.

You'll find this new local database in /var/db/dslocal/nodes/Default/. There's a folder for every "container" that you used to have in NetInfo. In each folder are individual flat flies that represent each item like a user or a group record. The information contained in the files is essentially what you would have been able to see with niutil or NetInfo Manager, just in a plist form here.

This is an important point to notice here, while the underlying technology serving up the records have changed, the records themselves and the data that they contain have not. The passwords are still stored in shadow hashes in /var/db/shadow/hash. MCX is still attached to the user record as an attribute in the flat file. And you can still create any arbitrary data that you want. Go ahead and add a custom attribute to a local user if you want.

I'm still not real keen on the name, or lack thereof, for the new database. I guess all the good names have been taken so the local database, local node or default local node will have to suffice.

I think you dropped a nicl?

The biggest change for day-to-day admin work is going to be the tools that you use. Gone is any tool that starts with "ni" or has NetInfo in the name.

For years, literally, now you've been told on various mailing lists, at WWDC and hopefully whenever you talked to someone knowledgeable from Apple that niutil and friends were going away. Now that time has come. Get to know dscl, your new best friend.

Since dscl can't do everything there are some new, and greatly enhanced tools to help you:

• dsenableroot - just like it sounds. This has been on OS X for a while now, but it may be more useful now that NetInfo Manager is gone.
• dseditgroup - also present in 10.4, but will get more usage now. Good for manipulating group memberships.
• dscacheutil - brand new in Leopard. This tools allows you to peek into the Directory Service cache and flush it if necessary. Semi-analogous to lookupd -d.
• dserr - a curious tool. Lives only to lookup DS error codes for you and return the text equivalent of the error. I half expected to find a quick shell script here just grepping the man page for DirectoryService.
• dsmemberutil - now this is a command you can sink your teeth into! Allows you to check group membership and do some debugging on what groups the system thinks a user is in.

GUI too!

And for those of you that are CLI-averse there seems to be a GUI equivalent for everything that was in the GUI in 10.4.

Start off with the Accounts preference pane. You can now right click on a user to get the advanced options. From here you can screw your user record up in at least as many ways as you could in NetInfo Manager. You can even <shudder> change the users GUID here. Although it's somewhat relevant to note here that the Loginwindow in 10.5 will attempt to rectify home directory permission errors if the ownership of a home directory gets out of whack.

Also from the Accounts pref pane you're able to create and manage group membership. Try to do that easily with NetInfo Manager! Look at the "New Account" pull-down when you hit the plus button under the user list. You'll find a group entry. Like a child-like WGM you can now add and remove users to groups from the GUI here.

For those that insist on enabling the root user, you can do this graphically in the strangely renamed Directory Utility. Authenticate and then look under the "Edit" menu.

Why You Care

So beyond faster, easier to use and new fun CLI utilities, why should an admin care about the death of NetInfo?

Local account creation was one of the last few actions in OS X that you couldn't easily script. It required a lot of dscl one liners and maybe even using expect. You were also pretty much locked out of doing this unless you were actually booted from the volume that had the NetInfo database in question, either. Not to mention radmind getting angry about the same database being different on every machine.

With the local database pretty much all of these issues are gone.

• You can now deploy users onto a disk image without booting that image. A simple package installer to insert a user record in the right place and a pre-created hash file in the right place and you're done. When the system boots it will read in all of the plist files. This GREATLY enhances the InstaDMG methodology that Josh has been working on.
• Single User Mode becomes almost stupidly easy. Editing a borked account or a database is a simple matter of using vi or copying over files in target disk mode. No need to learn the arcane usage of nicl.
• While not entirely sanctioned, for reasons explained later, you may even be able to push out a new user to all of your systems via a package with ARD, or other file distribution utility. It's just a matter of using the same package you would have created to install a user into a disk image.

Where This Breaks

Pushing out a file is not the same as using dscl. Pushing out a file does not alert the system to any changes. DirectoryService caches a lot of the information as it goes along and by changing the flat files from underneath it you have a distinct possibility of getting your system confused.

On a test system play around with manipulating a user record from both the CLI using a text editor or the advanced section of the Accounts pref pane. You'll notice that you'll usually have to kick DirectoryService with a HUP for the changes to take effect. Sometimes you have to do it a few times and flush the cache. Because of this your advised not to make live changes using direct manipulation of the files.

However, it's quite possible that you could create a new user, or change a user that's not currently logged in, and then HUP DirectoryServices with no problems. If this goes wrong though... it's not my fault. Test this thoroughly before doing it.

The Local KDC

Yes, you read that right, the local KDC. All Leopard client systems will now create a Local KDC for use with peer to peer file sharing.

While this isn't even as close to as scary as it seems, it is a topic worthy of at least a separate article, if not a whole series. I put on my thinking toque and sat in my thinking corner for a while on this, and I've not yet been able to come up with a reason for why having a KDC on every machine is less secure than how 10.4 did things. Having said that, though, I fully understand how this can seriously freak out your network security team as they don't quite grasp all the ins and the outs of this. Combine this with Back to My Mac, another article that's forthcoming, and you have a very interesting collection of some "sleeper" features in Leopard.

So, in a nutshell, a Local KDC, the LKDC, is created when 10.5 is installed. Local users will get LKDC authentication authorities allowing them to get Kerberos tickets and use that for single sign on to all the services hosted on that client system. Kerberos is supposed to be only used when you use Bonjour to discover the other machine. So primarily in peer to peer on the same LAN cases.

It works, you can see this for yourself. Screen share to another machine as a local user by picking the machine out of the sidebar in the Finder. You'll have to enter in your password the first time, but after that you can close out of that screen sharing session and restart it without having to re-enter your password. You can also see the ticket in the Kerberos.app, still buried in /System/Library/CoreServices.

More on this in a followup article.