In a non-homogenous network environment, you frequently have to deal with many different kinds of workstations running different hardware and software. This includes the Apple Macintosh. Popular among some users, the Macintosh presents special challenges for a Windows 2000 administrator who has deployed Active Directory.

Because Mac OS X doesn’t include an Active Directory client, you have to jump through some hoops to make it connect to your Windows 2000 server. This includes modifying Active Directory’s schema, which is no small task. In this Daily Drill Down, I’ll explain how to connect your Macintosh workstations running OS X to your Active Directory environment.

Old Macs need not apply

For the purposes of this Daily Drill Down, I’ll discuss only what you must do to connect a Mac OS X workstation to your Active Directory environment. Based on UNIX, Mac OS X connects to Active Directory more easily than earlier versions of the Mac OS.

What makes the Mac so difficult?
The Mac OS doesn’t have any type of Active Directory interface built in. Normally, when Windows clients access Active Directory, they do so using Active Directory Service Interface (ADSI). ADSI isn’t present in the Mac OS, so it’s impossible for the Mac OS to use it to connect to your Active Directory.

Mac OS doesn’t support ADSI, however, it does support LDAP, and Active Directory is LDAP based. So by making LDAP calls, Mac OS can access Active Directory. Unfortunately, the process isn’t as simple as just making LDAP calls to a Windows 2000 server.

Not only does the Mac OS not support Active Directory, Active Directory doesn’t support the Mac OS either. So the process of connecting your Macs to Active Directory involves creating custom Active Directory objects and attributes especially for the Mac workstations. You must then configure the Mac OS to associate LDAP functionality with common commands, and map those LDAP functions to the custom Active Directory objects you’ve created.

As you can probably guess, this is a tedious process. You shouldn’t attempt this process unless you’re very familiar with both Active Directory and Mac OS X. Performing the process incorrectly can cause some major problems for both operating systems.

There are many ways to set up a network, but for the purposes of this article, I’ll assume that you have two separate, but interconnected TCP/IP networks. The first network is the Windows network, which consists of Windows-based workstations and Windows 2000 Servers. The other network is a Macintosh network, which consists of Macintosh workstations and Mac OS X servers. I’ll also assume that the Windows users access resources from the Windows servers and the Mac users access resources from the Mac Servers, and will continue to do so.

The purpose behind setting up the Macs to use Active Directory is to centralize network management and authentication. The Mac users will still have home directories on the Mac servers, but Active Directory will specify the location of those home directories.

The madness behind the method
Let me illustrate how Active Directory will fit in with the Macintosh networking environment. Suppose for a moment that a Macintosh user needs to access some file from a share point on a Mac OS X server. The process begins when the user selects the server either through the Chooser or through the Connect To Server command on the Go menu, depending on which version of the Mac OS the user is using.

When the user connects to the server, the server prompts the user for his or her username and password. At this point, the Macintosh server contacts a Windows 2000 domain controller and requests the user’s Active Directory record. The Active Directory record is then compared to the credentials supplied by the user and the user is authenticated. The Macintosh server also validates the user’s rights to the data within the requested share point with the user’s user ID and group ID.

Now suppose that the user also has a home directory on the Macintosh server. During the authentication process, the Macintosh server retrieves the user’s Active Directory record from the Windows 2000 domain controller. The user’s record contains the location of the home directory, the type of file system that the home directory exists on, and the protocol necessary to access the home directory. If the home directory exists on a Macintosh server, this will usually be the Apple Filtering Protocol (AFP). Once this information has been retrieved, the information is passed back to the Macintosh client computer. The client computer then uses the information to connect to the home directory on the Macintosh server.

Configuring Active Directory
The first task that you must complete to achieve Macintosh/Active Directory integration is to prepare Active Directory. To do this, you will need to modify Active Directory schema. Because modifying Active Directory schema isn’t something that you’d normally do, the tools for doing so aren’t installed by default. So you must install the Windows 2000 Administration Tools.

To do so, verify that Service Pack 2 or higher is installed, and then open Control Panel and double-click on the Add/Remove Programs icon. You’ll see the Add/Remove Programs dialog box. Go through the list of currently installed programs and select the Windows 2000 Administration Tools. Click the Change button to launch the Windows 2000 Administration Tools Setup Wizard. Follow the wizard’s prompts to install all the Administrative Tools.

When you’ve finished, you must also install the Windows 2000 Support Tools. Insert your Windows 2000 Server installation CD. From the splash screen, select the option to explore the CD’s contents. Next, navigate to the \SUPPORT\TOOLS folder and double-click the Setup icon. You’ll then see a wizard for installing the Windows 2000 Support Tools. The wizard is pretty much self-explanatory. Once you’ve completed the wizard and installed the Windows 2000 Support Tools, reboot your server.

After you’ve installed the necessary tools, enter the SCHMMGMT.MSC command at the Windows 2000 Server Run prompt. Doing so will open the Schema Manager console. When the console opens, right-click on Active Directory Schema in the column on the left, and select the Operations Master command from the resulting menu. This will reveal the Change Schema Master dialog box. Select the check box for the option The Schema May Be Modified On This Domain Controller, as shown in Figure A, and click OK.

Figure A

Next, you will create some new Active Directory attributes. Keep in mind that you can name the attributes anything that you like, as long as you’re consistent with your naming scheme. Whatever Active Directory attribute names you use, you must use duplicate names in the Macintosh directory. So I strongly recommend documenting the names that you use.

Author’s warning

Creating an Active Directory attribute is not a reversible process. Once an attribute has been created, it can’t be deleted. Additionally, the attribute will be propagated to every other domain controller in your entire organization. So it’s extremely important not to make a mistake when creating attributes.

The trickiest part of creating attributes is that you must assign each attribute a unique X.500 object ID number. What makes this so tricky is that you can’t just make a number up. If you do, you risk overlapping with an existing number or a number reserved for use with future software installations. Fortunately, Microsoft makes a utility called OIDGEN, which can generate these object identifiers for you. You can find OIDGEN in the Windows 2000 Server Resource Kit.

Running OIDGEN is a matter of simply opening a command prompt window and entering the OIDGEN command. Upon doing so, the utility will generate two numbers; an Attribute Base OID and a Class Base OID, as shown in Figure B.

Figure B
OIDGEN produces a unique Attribute Base OID and Class Base OID.

Write these numbers down! All future OIDs that you create will be based on one of these two numbers. These numbers are actually a series of numbers separated by decimal points. The first several numbers are known as the OID prefix. All attributes that you create must have a common prefix. If you happen to lose your OIDGEN information, you can run OIDGEN again to get a new set of numbers, but using a new set of numbers increases the size of the OID prefix table within Active Directory and dramatically decreases performance.

To create a unique X.500 OID, simply look at the Attribute Base OID and take the set of numbers furthest to the right and increment it by one. The number that you produce (including the prefix) will be a unique OID. Record the number and the attribute that you’re associating with it. The next time that you need to create an attribute, take the highest number on your list of unique OIDs and increment it by one. You must always work with only the last set of numbers.

The next step is to create attributes. To do so, return to the Active Directory Schema Attributes console, right-click on the Attributes object and select Create Attribute from the resulting menu. You’ll see a warning explaining that the process is irreversible. Click the Continue button and you’ll see a screen similar to the one shown in Figure C.

Figure C
You must create a series of new attributes.

As you can see in the figure, the information that the Create New Attribute dialog box asks for is fairly simple to fill in. The trick is knowing which attributes to create. Begin the process by creating some attributes for the Mount class. You must create the class’ attributes before creating the class itself.

Begin the process by creating an attribute called vfsdir. Both the common name and the LDAP display name should be vfsdir. The syntax parameter should be set to Case Sensitive String. Finally, enter a unique X.500 object ID for the new attribute.

Next, create another attribute for the Mount class. This new attribute will be called vfstype. The main difference between the vfstype and the vfsdir attributes is that the vfstype attribute is multivalued, so you must select the Multi-Valued check box. You can see an example of the correct settings for this attribute in Figure D.

Figure D
You must also create a multivalued vfstype attribute.

You must create one more attribute before creating the mounts class, the vfsopts attribute. Again, this will be a multivalued, case-sensitive string.

After you’ve created the vfsdir, vfstype, and vfsopts attributes, you need to create the mounts class and assign the attributes you’ve just created to the new class. To create the mounts class, right-click on the Classes container in the Active Directory Schema Attributes console, and select Create Class from the resulting menu. You’ll see the same warning message as you did previously. Clear the message and you’ll see the Create New Schema Class dialog box.

Initially, creating the new class will be almost identical to the process for creating a new attribute. As you can see in Figure E, the process requires you to enter a common name, an LDAP display name, and a unique X.500 OID. On this screen, you must also enter a Parent Class and a Class Type. For this particular class, set the Parent Class to Top and set the Class Type to Structural.

Figure E
You must create a mounts class that will be associated with the attributes you’ve already created.

Once you’ve entered the information, click Next to begin the next phase of the configuration process. In this step, you can add attributes to the class that make the attributes either mandatory or optional. All attributes for the mounts class should be optional. You can see an example of this in Figure F.

Figure F
Add the attributes you created as optional attributes to the mounts class.

Once you’ve created the mounts class, locate it in the list of classes, right-click on the class and select the Properties command from the resulting menu. This will allow you to view the class to make sure that you entered the information correctly. Pay close attention to the Relationship tab to make sure that the only possible superior is organizationalUnit.

Next, create a search base for mount records. To do so, you must use one of the support tools that you installed. Select Start | Programs | Windows 2000 Support Tools | Tools | ADSI Edit.

When you open ADSI Edit, navigate through the column on the right to ADSI Edit | Domain NC | DC=your domain. Right-click on your domain and select the New | Object commands from the context menu. You’ll then see the Create Object dialog box, which contains a long list of classes. Select the organizationalUnit class and click Next. You’ll see a screen that asks for a value. Enter mounts into the space provided and click Next. Finally, click Finish to complete the creation of the object. When you return to the main ADSI Edit screen, you’ll see the object that you just created in the column to the right, as shown in Figure G.

Figure G
You should see the mounts object appear in ADSI Edit.

How painful was that?
With these changes, your Mac OS X server is ready to make the connection. All you have to do is create mount objects that correspond to various network locations, such as home directories, and link some user objects to the mount objects.