Volume Number: 19 (2003)
Issue Number: 12
Column Tag: Programming

Patch Panel

New Networking Tricks in Panther

by John C. Welch

So, once again, we have a major release of Mac OS X upon us, and while everyone else is ooh-ing and ah-ing things like Expose and vertical toolbars, I, MacTech's intrepid IT Geek, am plumbing the networking changes to Panther. Well, okay, so most of the UI stuff is not that exciting to me. Expose is cool I suppose, but I had my own methods of dealing with this that don't require Quartz Extreme, or yet another set of key equivalents. (Lately I've been having flashbacks to WordPerfect 5.1, and the dorky key-command templates we all needed with it.)

But Panther is a big change, and I daresay that if you're a networking type, (I'll assume you are, since you're reading a column called "Patch Panel"), Panther has a lot of stuff for you. Now, I'm not going to be able to look at everything in this column. To do so would mean the "John C. Welch" issue of MacTech, and while that's a great ego stroke, there's a hard limit to how much of me anyone should have to take in a month. Instead, I'll take a look at a key element of Panther's networking subsystem.

This is one of the most improved areas of Panther, and the changes are a long time in coming. Personal opinions of Microsoft not withstanding, it's just sensible for Mac OS X to play nice with Active Directory. In this area, the biggest new toy is the Active Directory, (AD) plugin for Directory Services. This allows you to make your Mac a member of an Active Directory domain, and be able to play almost as nicely as a Windows box. (I say "almost" because there's a huge part of AD that requires windows, such as MSI, certain group policies, ACLs, etc.) This is quite different from the way you did this in Jaguar, which used the LDAP connector to talk to AD, and could sometimes require modifying the AD schema to work right. (To be fair, there's nothing wrong with using LDAP. It's how AD does a lot of its work, and even with the plugin, if you want certain things stored in AD, you're still going to need to modify the schema. But the plugin minimizes some of this.) As well, enabling automatic Kerberos authentication at login with Jaguar was somewhat tricky, and not for the faint of heart. You could use ADmitMac, from Thursby Systems with Jaguar, and get the same level of integration as the Panther plugin enables, along with some extras, such as better use of Windows shares, (no .DS_Store booger files littered everywhere), and support for NT 4 Domains, (Panther's plugin is AD only.) So, if you need to deal with NT 4 domains, or need to integrate Jaguar with AD, ADmitMac is a great solution, albeit not free. But then again, neither is Panther. In any case, with Panther, AD just got a lot easier.

So, as we see above in the Directory Access application, AD now has its own entry. Click on Active Directory, hit "Configure..." and you get the following screen:

To add, or bind a computer to an Active Directory domain, you enter in the forest name, the domain name, and the computer name. If you don't have a separate domain, then use the forest name. Click on the "Bind..." button, (It says "Unbind..." here because my laptop is already bound to a domain.), enter in your Mac OS X admin password, and the userid and password of a user that is able to add machines to an AD domain, and you're set. Note that the userid and password for the AD domain does not have to be the logins for local users on that machine. In my case, they're completely different. If there are no errors, then your machine is now a part of an AD domain. There are a few options that can make your life easier here. "Cache last user logon for offline operations" is very handy for laptops, so that you can log onto your machine and get work done, even when you're off the network. If you have a large AD forest, the "Authenticate in multiple domains" can make your life easier. "Prefer this domain server:" allows you to specify what domain server to authenticate to when available. Unless you have a specific need for this, leave it unchecked. (If you have to ask if you need this, the answer is probably "no".) "Map UID to attribute:" allows you to map the unique User ID to a specific AD attribute instead of letting AD handle this. Again, if you aren't sure you need to do this, leave it alone. "Allow administration by:" lets you give admin rights to users in certain domain groups. By default, the domain admins and enterprise admins groups are used if this option is enabled, and you can add others if you like. This allows AD administrators to have administrator rights on a Mac OS X machine without having to create local accounts for them.

However, if you have to set up the plugin on multiple machines, using the UI tools can get a bit tedious. They still work, but automating the Directory Access application is fairly tedious. Luckily, you can completely set up the AD plugin via the command line, and the dsconfigad application. The man page for dsconfigad is pretty complete, and has some nice examples. So, to add a machine to a domain, the command line would look like the example in the man page:

dsconfigad -a ThisComputer -u "administrator" -ou 
"CN=Computers,OU=Engineering,DC=ads,DC=demo,DC=com" -forest ads.demo.com -domain 
domain.ads.apple.com

The man page gives clear examples of using dsconfigad to set up all the different features of the plugin. Including a command line configuration option makes the plugin much easier to use with other management tools, even if your management console is running a different flavor of Unix, or even Windows. Cross-platform automation in the IT space is a good thing.

By default, Mac OS X will search through the local authentication domains first, then any external directories. If you have multiple authentication directories, or you want to force a specific order, then you can create custom authentication paths as in the image below:

This tells Directory Services where to look, and in what order when performing authentication operations on a given machine. Now, there's another thing that we use directories for, namely as distributed address books. If we take a look at the "Contacts" tab in directory services, we see that it looks much the same as the Authentication tab, and you can set up custom search paths there as well, like in this image:

If you do this in Panther with Active Directory, you get one immediate bonus. Address Book, and therefore Mail can now use Active Directory's Global Address List, or GAL, to look for email addresses when sending mail.

Once you have this set up, how's it work? Well, pretty darn well so far. I can log into my laptop using my AD login identity, with no local account creation. My home directory is created, and I have access to all my Mac applications. When I connect to shares on the Windows network that I have access to, I don't have to supply additional credentials for them, they just work. So the single signon aspects of Active Directory work with Panther as well. This is due to the other part of the AD plugin's magic, namely it's Kerberos support. When I log into my AD domain, since AD and Panther both heavily use Kerberos, I automatically get my Kerberos tickets. So when I attempt to use AD services, like access to network file shares, I don't have to re-enter my user information. One signon does it all, thanks to Kerberos.

The only real problem I ran into was a momentary problem with DNS. Like a lot of network services in Mac OS X, the AD plugin makes heavy use of reverse DNS lookups to get information on the AD domain so that it can interoperate correctly. When I first tried to bind to the domain, I kept getting reverse DNS errors. Nothing seemed to be wrong, and by the next morning everything was working fine, and I could bind with the domain, so I'm not really sure what went wrong there, or what got fixed, since nothing was changed on the AD side.

This is a major benefit to Apple and Mac OS X in almost every market they compete in. Regardless of your opinion of Microsoft, Active Directory is one of the most popular directory systems on the market, and with good reason. It's flexible, fairly secure, (As a product. While Windows tends to have a lot of security holes, AD has been pretty clean here.), and had excellent management tools. It's very dominant in the enterprise, and is gaining ground in both the higher ed and k-12 markets. Integrating well with AD is critical for Apple to go from a reluctantly accepted platform to an accepted alternative to Windows on the desktop and Linux in the server room.

I know that in my case, the ease of setup of the plugin, and the functionality it provides is going to make my Macs a much more accepted part of the network. This doesn't mean that we automatically start buying Macs by the truckload, but in the future, if I bring up Mac OS X as a solution to a problem, there won't be the automatic "Macs can't integrate with AD" dismissal.

There are still a few things that need to be done on the integration side, such as creating a Microsoft Maintenance Console, (MMC) snap-in for Mac OS X, so that you can properly manage Macs with the Windows AD administration tools. Giving Windows administrators a way to use Group Policies with Macs would be another good idea too. Since most Mac OS X applications don't use a resource fork, it has more flexibility with installation sources than Mac OS 9 did, so there is at least a theoretical potential for MSI integration that I would like to see explored a little more. However, for a first implementation, the plugin works quite well.

Obviously Panther contains far more networking improvements than just an Active Directory plugin, but the plugin is a major new feature that will help Apple be thought of as a much better player in the enterprise space. No matter how you look at it, this can only be thought of as good for Apple and the Mac community.

John Welch <jwelch@provar.com> is a Technical Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt, (http://www.tackyshirt.com/). He has over fifteen years of experience at making Macs, and other computers work. John specializes in figuring out ways to make the Mac do what nobody thinks it can, showing that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computers on occasion, or at least that's the rumor.