It wasn’t too long ago that using an Apple Macintosh computer in a Windows environment meant hassling with software integration and Active Directory (AD) schema changes. Within the past few years, however, this integration has become a lot easier and literally out of the box. This change didn’t occur because Microsoft and Apple suddenly had a kumbaya moment and started working together. It occurred because they both have done a great job of following the RFC 2703 and LDAP standards. As a result, if you’re using Windows Server 2003 R2 or later and Apple OS X Panther (version 10.3) or later and you just need your Mac clients to authenticate to AD, you don’t need any special software. You can simply specify the old “NT style” Home Folder path in the user’s AD object to have the user’s network drive show up on the desktop. If it’s a mobile account (what Microsoft calls "cached credentials and a Profile"), users can even log on when they aren’t connected to the domain—again all without any additional software. But if you want to manage your Mac clients like you manage your Windows clients, you’ll need a Mac-to-AD integration solution. I recently reviewed four products that do a great job.
Three of the products—Centrify’s DirectControl, Likewise Software’s Likewise Enterprise, and Quest Software’s Authentication Services—integrate Mac, UNIX, and Linux computers into your Windows world. The fourth product, Thursby’s ADmitMac, integrates Mac computers only.
I tested each product in a dedicated Windows Server 2008 AD environment hosted on a VMware ESXi server. I installed DirectControl and Authentication Services directly on the domain controller (DC). As recommended by the documentation, I installed Likewise Enterprise on a dedicated server. ADmitMac doesn’t require the installation of back-end software.
For the client, I used a MacBook Pro running OS X Snow Leopard (version 10.6.7). After installing and configuring each product, I ran it through the paces. The testing involved:
- Installing the client software
- Adding the Mac client to the domain
- Removing the Mac client from the domain
- Logging on to the domain
- Migrating a user
- Using the product’s management console (if applicable)
- Changing settings using a Group Policy Object (GPO)
- Adding a Global Group to a Local Group
- Deploying software to the Mac client
- Using cached credentials to log on when not connected to the domain
- Disabling automatic logons and logon messages using a GPO
For more information about the testing, see the web-exclusive sidebar “Criteria for Testing the Mac-to-AD Integration Solutions” (www.windowsitpro.com, InstantDoc ID 135957).
Installing DirectControl was a breeze. You simply double-click CentrifyDC_Console-4.4.3-win32 on a DC and follow the prompts. No database or other prerequisites are required, except to disable the .Net Publisher evidence verification option. Disabling this feature is easy, as the installation routine does it for you. However, finding out what the .Net Publisher evidence verification option does proved to be a bit more challenging. After numerous Internet searches and queries to my developer friends, I finally reached out to the folks at Centrify for an explanation. According to Centrify, “Disabling the ‘publisher evidence verification’ simply speeds up the launch of the console applications since it configures the app to launch without performing the time-consuming verification process, which can be problematic in isolated networks such as test labs that don't have Internet connectivity.”
After the setup routine finishes, you start the DirectControl console. The first time this program runs, a setup wizard walks you through setting up the default zone. Zones help you collect and identify collections of UNIX, Linux, and Mac computers. By grouping the client machines this way, you can easily enforce security or configuration policies. Zones are stored in the AD container domain.com/Program Data/Centrify/Zones.
The setup wizard also helps you install the required licenses, which are stored in the AD container domain.com/Program Data/Centrify/Licenses. In all of the products that I’ve reviewed, I’ve never seen licenses stored in AD. It’s unique, to say the least.
After the back-end support has been installed, the next step is to install the client software onto a Mac computer using a platform-specific package. For Mac OS X Snow Leopard, you use the CentrifyDC-4.4.3-mac10.6.dmg file. Double-clicking this file opens a menu that has a Prepare feature, which you use to ensure that DirectControl and AD are communicating properly and ready for integration. When prompted, you enter the name of your domain, and in a few seconds, a total of 20 tests are performed. These tests check to see whether there’s adequate disk space on the client, whether DNS is working properly, whether there’s a DC in the site, and much more. I failed the test that checked whether the DC’s and the client’s clocks were synchronized. After I fixed the problem, I was ready to install the client.
The installation itself takes only a few seconds, then DirectControl prompts you to join the domain. I like this feature, as it takes away any confusion on when you need to add the machine to the domain. From the configuration screen, you can set the user's home directory (/home/username), UNIX ID, and group ID, or you can let DirectControl’s Auto Zone mode configure them for you. Manually configuring the UNIX ID and group ID is important if you’re integrating a UNIX or Linux machine but since I was integrating a Mac machine, I chose the Auto Zone mode. It worked fine. (For more information about UNIX IDs and group IDs, see “Cross-Platform Identity Management Solutions for Single Sign-On.”)
The logging that’s produced from the configuration screen is extremely helpful. I accidentally misspelled the domain’s name and the log was very helpful in troubleshooting the problem. Rebooting is recommended after you join the computer to the domain.
After the MacBook Pro rebooted, I successfully logged on as a domain user. I didn’t have to add domain\ to the beginning of the username or add @domain to the end of the username. Because it was the first time I logged on with that account, I was prompted to change the password. After I did so, the logon process continued.
Credential caching worked right out of the box. To test this feature, I unplugged the network cable, disabled the AirPort network card, then logged off. When I attempted to log on, my cached credentials were used and I was soon looking at the desktop again.
Back on the DC, I found a new Centrify Profile tab on both the user object and computer object properties pages in the Active Directory Users and Computers snap-in. On the computer object properties page, this tab contained read-only information, such as the version of the client software, the type of zone being used (Auto Zone, in my case), and whether the client was using licensed or unlicensed features. On the user object properties page, this tab contained configurable information. Although not necessary for integrating Macs into an AD domain, you can configure some UNIX and Linux settings, such as the UNIX ID, logon name, Shell (/bin/bash), home directory, and primary group.
DirectControl is tightly integrated into the Group Policy Management Console (GPMC). As Figure 1 shows, you can easily manage your Mac clients. For example, I disabled automatic logons. Like a Windows machine, you can configure an OS X computer to log on automatically. However, unlike a Windows machine, this functionality isn’t disabled when the computer is joined to the domain. If a user knows the local machine’s administrator password, he or she can easily configure the machine to start up without a password credential. With just a few clicks, I was able to disable this feature.
Figure 1: DirectControl’s integration into GPMC
DirectControl offers a handy Mac utility named the DirectControl Widget. It displays information about AD’s status, Kerberos, AD accounts, and AD group membership. To install this widget on a Mac computer, click Go, select iDisk, click Other User’s Public Folder, enter Centrify, and double-click DirectControl Widget.
The installation guide makes it very clear that you shouldn’t install Likewise Enterprise directly on a DC. Instead, the guide recommends installing it on a dedicated server running Windows Server 2008. Alternatively, you can install it on a computer running Windows 7, Windows Vista, or Windows XP. Likewise Enterprise enhances the built-in AD administration tools (i.e., GPMC and Active Directory Users and Computers snap-in), so these tools must be already on the computer in which you install Likewise Enterprise. Microsoft Management Console (MMC) 3.0 is also required. Because you can’t install MMC 3.0 on Windows 2000, you can’t install Likewise Enterprise on Windows 2000 Server.
After Likewise Enterprise is installed, a wizard walks you through the setup process, including picking a mode and setting up a cell in AD. I found the wizard to be a bit confusing and had to read and reread the PDF manual to understand what it was trying to accomplish.
Picking a mode. Both my forest and domain were running at the Server 2008 functional level, yet the wizard was trying to steer me to use its Non-Schema Mode—the mode that supports Windows 2000 AD. (If you’re running Windows 2000 AD, you’d have to run Likewise Enterprise on XP or later and extend the schema.) In addition, the instructions in the wizard are incomplete, but I figured it out. To use Schema Mode—the mode in which Likewise Enterprise takes advantage of RFC 2307—you have to cancel the wizard and run a separate Schema Mode Wizard, which you’ll find by navigating to Console, Enterprise Console, Status. Even with the forest and domain running at the 2008 functional level, the wizard ensures that certain attributes (e.g., uid, uidNumber, gidNumber) are indexed and present in the AD Global Catalog (GC).
Whether you use Schema Mode versus Non-schema Mode depends on what OS your domain is running. If it’s running Windows 2003 R2 or later, no schema changes need be made to your domain so you should use the Schema Mode. If your domain is running an earlier OS, you have two options. You can use Non-Schema Mode and store the group or user information in the multivalued keywords and description attributes of the user and computer objects. Or, if you’re feeling especially brave, you can have Likewise Enterprise extend the schema for you.
Setting up a cell. Like DirectControl’s zones, Likewise Enterprise’s cells let you logically group non-Windows machines and control their information (e.g., UNIX ID, group ID). Also like zones, cells are logically connected to OUs. Using this structure, you can create a cell for each department or security boundary in your company and assign a user to one or more cells using the Likewise Settings tab in the Active Directory Users and Computers snap-in.
After the server software is installed and configured, it’s time to install the client software on each Mac computer. You can manually install it with the installation CD-ROM, or you can install it through an unattended installation that uses Secure Shell (SSH). (Apple’s name for SSH is Remote Login, which you can enable in System Preferences, Sharing.) The PDF manual gives a good step-by-step walkthrough on how to install the client software using SSH.
Next, you need to join the computer to the domain using the Likewise – Active Directory tool, which is in the Directory Utility. Just like the built-in Active Directory connector that comes with OS X, the Likewise – Active Directory tool lets you choose which container or organizational unit (OU) to create the computer object in.
I found Likewise Enterprise to be tightly integrated with Group Policy. Figure 2 shows how easy it is to configure local administration privileges for a domain user or group.
Figure 2: Likewise Enterprise’s integration into GPMC
If you already have an infrastructure in place for Mac authentication and you want to migrate everything to AD, Likewise Enterprise comes with a migration tool that can import Mac, UNIX, and Linux passwords and group files. These attributes are automatically mapped to users and groups in AD.
If your environment uses local authentication and has OS X user profiles already established, you might want to migrate them to the new domain authenticated account. For example, suppose that John has been using his MacBook Pro for a year and you now want him to authenticate to the domain. Just like a Windows machine, the OS X machine will create a new profile the first time he logs on. The Migrate User Profile tool moves the old local profile to the new domain-based profile. When John logs onto the domain with his new account, he’ll see the desktop that he’s used to.
Likewise Software Likewise Enterprise
Authentication Services requires that Microsoft .NET Framework 3.5 SP1 and Windows PowerShell be installed. Authentication Services’ installation process will install (and even help you download) all required components. The installation process will also verify that your AD schema will support the product. As with the other software discussed here, as long as you’re using Windows 2003 R2 or later, no schema extensions are required.
Unlike DirectControl and Likewise Enterprise, Authentication Services doesn’t use zones or cells. Thus, the product is very simple to set up. The Add and Join Host wizard walks you through the setup process, which involves:
- Adding and profiling hosts (aka clients). The server running Authentication Services must have name resolution to the Mac clients. The client should dynamically add itself to DNS, just like a Windows 2000 or later machine. However, I had mixed results. If you can’t resolve the OS X host name, make sure that there’s an A record for the client in DNS.
- Checking the clients for readiness to join AD. The AD Readiness check ensures that the client is ready to join the domain. In my case, I received an error message that noted the “time skew" (i.e., the difference between the DC’s time and the client’s time) was too great, so the client couldn’t be joined to the domain. I appreciated that the error message was clear and concise, unlike the built-in Active Directory connector, which provides cryptic messages.
- Installing the client software. When I attempted to install the client software, I received an error message that said Authentication Services couldn’t find the client for Mac OS X 10.6. I checked the path that was provided, and sure enough, the client file (VAS-188.8.131.52.dmg) was missing. After I downloaded VAS-184.108.40.206.dmg and manually copied it to the source directory, the installation finished without any further problems.
- Joining the clients to AD. Joining a client to a domain requires a root or administrator password.
I really liked the Add and Join Host wizard. As long as the Mac client is running SSH, you can add the client to the domain without ever leaving your desk.
After the client has been added and joined to AD, there isn't a whole lot to do with the Authentication Services-specific tools that are provided. The real meat is in the functionality that the product adds to GPMC, as Figure 3 shows. Adding printers is just one of the many features that you can manage within the Group Policy framework.
Figure 3: Authentication Services’ integration into GPMC
To log on to a non-Windows machine, the AD user account has to be “UNIX-enabled” through a Quest tab on the user object properties page in the Active Directory Users and Computers snap-in. This creates the needed UNIX ID and group ID.
Overall, I found the Quest product to be easy to setup and use. If you have a mix of UNIX, Linux, and Mac clients, put Quest at the top of your evaluation list.
Quest Software Authentication Services
ADmitMac has a much different architecture than the other three products, so I chose to review it last. According to the Thursby website, “ADmitMac is short for Active Directory admit Mac and pronounced ‘Admit Mac.’”
What quickly set this product apart is that it’s built solely for Mac integration into AD. The other products are UNIX- and Linux- centric, and the Mac support appears to be an afterthought. ADmitMac doesn’t try to be anything other than a Mac-based product. This doesn’t make ADmitMac any better or worse than the other three. If you’re integrating a mix of UNIX, Linux, and Mac clients into your Windows environment, you’d be better off with one of the other three products reviewed. If you’re integrating Mac clients only, you should first look at ADmitMac because its sole purpose is make Mac clients behave like Windows clients.
Instead of starting the installation on the server side like with the other products, ADmitMac installation starts on the client side. After you use the installation CD-ROM to install ADmitMac, the Setup Assistant (a wizard) walks you through configuring the ADmitMac networking software. The first screen is a bit of a surprise, as it asks for WINS information. You can either manually set the WINS information, or set it to DHCP.
The next screen sets the Security Policy Settings—whether the Mac client will use Kerberos, NTLMv2, NTLM, or LAN Manager to log on to the Windows domain. The default setting is to use NTLMv2 or Kerberos first, use NTLM next, and never use LM. You can set the ADmitMac client to send passwords in clear text, but you obviously must have another mechanism in place on the network to protect that information before you choose that option.
The next step is to add the Mac client to the domain. After you enter the domain’s name, you’re prompted for the network administrator username and password. You then specify where the machine account should be created in AD. The default location is the Computers container.
Finally, you set the type of Home Folder (i.e., Network, Local, or Mobile) that the user will use. You can also specify how many times a user can log on when not connected to the network.
That’s all that needs to be done to get the Mac client added and connected to the domain. The ADmitMac directory utility has more features, though. Like the other products, ADmitMac lets you map UNIX IDs and group IDs to AD accounts, but this is done from the client side. You can also put OU restrictions in place. For example, if you enter Sales in the Users OU, only those user accounts located in the Sales OU would be able to log on to the computer.
Although ADmitMac is managed from the server side, there’s no software to install. Instead, it uses Group Policy .adm files, as Figure 4 shows. Because the files don’t use the new .admx format, they’re buried a bit in the Server 2008 GPMC. However, this doesn’t take away from the fact that Group Policy support has been added to Mac clients with no additional software on the server—only .adm templates are added.
Figure 4: ADmitMac’s integration into GPMC
To add the templates, you run an executable (ThursbyADMInstaller.exe) that copies them from the installation CD-ROM to the DC. The default location is C:\Windows\inf. Once copied, you use these .adm templates just as you would any other template: Right-click Administrative Templates, select Add/Remove Templates, click Add again, and find the ADmitMac.adm template file.
Thursby Software ADmitMac
With DirectControl, Likewise Enterprise, Authentication Services, and ADmitMac, you can integrate and manage Mac clients in your AD domain. Each product provides easy domain logons, but so does the built-in Active Directory connector that comes with OS X. What sets these products apart is that they let you manage your Mac clients like you manage your Windows clients.
DirectControl and Likewise Enterprise are similar in how they work. Both let you logically group non-Windows objects together.
Quest stood out because it didn’t require this additional overhead. In addition, you can use a central console to install the client software and add the client to the domain. This could be very important if you have a lot of Mac computers to migrate to AD.
ADmitMac came away as the clear winner because this review focuses on Mac-to-AD integration solutions. For this task, it has a slight edge. ADmitMac doesn’t require any special software on the server side, and the client software is full of added features.