Active Directory Integration in Three Hours or Less

—by Joel Rennich, mactroll@afp548.com

8 May 2003

If you aren’t fortunate enough to have a Mac OS X Server running your directory services for your organization, you stand a good chance of having a Windows 2000 Server running Active Directory for your needs.

We can take this AD (Active Directory) server and have it provide directory services to all of your Mac OS X clients and servers. There are a number of different ways of doing this. The most thorough calls for all of the information stored in NetInfo to be completely replicated inside AD. Certainly this makes for a more unified approach. However, you will also need to seriously overhaul your AD database—which will make even seasoned Windows administrators cringe.

Instead, we will take another path in this article: more of a guerilla approach. This is not a perfect solution by any means. Administrators looking for perfection who have the luxury of controlling both the Mac OS X and the AD side of things will come up with a much more unified approach. Additionally, the steps that we will take in this article may cause problems down the line if they are not considered carefully before starting out.

Take all of these considerations into mind before engaging in this course of action. We will try to point out wherever you may wish to deviate from our course of action and list the reasons why. At the end of the day, however, the method we will describe will work and for many situations can work very well.

Alright, enough of the danger text.

(1) Know thine enemy

The first step to AD integration is to better understand your AD server and what it contains. AD is just a modified version of LDAP, and as such we can immediately bend it to our will without changing much of anything on the server.

There are two ways to do this. If you have admin access to the Windows server, you can add the ADSI snap-in to the management console. You’ll find the snap-in in the support folder of a Windows 2000 server installer CD. The other way is to hack your way through the AD forest using an LDAP browser.

Before we start: a brief primer on LDAP terminology. All LDAP databases are referenced by their DN, or distinguished name. This is supposed to be a globally unique name. To keep things simple this is usually based on the DNS name of the LDAP server. The top-level DN of the server is made up of DC, or domain components. This allows the DNS name to be broken up into different parts. This should make more sense when we go through an example. Once we get past the top level the LDAP database is usually comprised of OU, organizational units, and CN, common name, components. These are just ways of addressing individual parts, or directories, of the database.

In our example the server the AD, or LDAP, server that we will be using has a DNS name of afp548.rennich.com. The base DN of the LDAP database is “DC=rennich,DC=com". Here you see the top-level DN of the server is made up of DCs that are based off of the DNS name. When we get further into the database we run into the other components. For example, to reference the user record of the admin user we could say “UID=admin,CN=users,DC=rennich,DC=com". When we use this full DN we can only be talking about one piece of information in the database.

Now back to getting this set up.

We’ll cover the Windows way first. After adding the snap-in to the console, you can use it to view the schema of the AD database. What you are looking for specifically is the CN or OU where all of your user records are kept. By default AD will only let authenticated users browse the directory store. This is usually a good thing, since it keeps things more secure, but it does make your job harder the first time out.

You need to find a user with very minimal rights. Preferably a non-admin user. You will be using this user to bind, the LDAP term for authenticating and connecting to the directory store, to the AD server so that everyone else can log in. This user is very similar to a machine account in Windows and will be saved in the configuration files on the Mac OS X client. This is one of the reasons why you want this to be an account with minimal access rights since it has a higher chance of being compromised.

You’ll need to know the user’s password and the distinguished name of the user. The ADSI snap-in makes this easy since it will list it the DN on the right-hand side of the screen. Copy the DN down since we will use it in the next step. You’ll also get the base DN here. This is the name of the top folder in the ADSI module. This is usually the domain name of the AD server, not the full DNS name just the domain. In our example it is DC=rennich,DC=com.

Click the image to see the full picture.

If you don’t have the ADSI snap-in installed you can sometimes get away with just the AD Users and Computers snap-in. However, I would suggest you test the DN that you get with an LDAP browser, which will we talk about next, to make sure that you have the right setup.

If you don’t have access to the AD server directly you can root around in the directory store a little bit by using an LDAP browser. My personal fave is a java-based application called “LDAP Browser” by Jarek Gawor. You can find it here.

Launch this and create a new connection to the IP address of the AD server. Now comes the hard part. You are going to need to guess at the full DN for a user before you will be able to browse the directory store. This means that through trial and error you need to plug away at the DN path to the user. For a vanilla AD server this will be CN=<user name>,CN=users,DC=<domain>,DC=<tld>. However, there is a very good chance, especially if you are in a larger organization, that this has been changed. Now it might be time to ply your AD admin with beer and cookies to get the information out of them.

Click the image to see the full picture.

At this point, either through using the Windows 2000 tools or an LDAP browser you should have the full DN of a user on the AD server and the corresponding password. Now you can move on to setting up the Mac OS X client.

(2) Bound and gagged

Now that you know more information about the AD server, you can begin the process of establishing a connection for authentication purposes.

Open up Directory Access, which you will find in the Utilities folder on the Mac OS X machine, and double-click on the LDAPv3 entry. A sheet will come down that will allow you to create a new LDAP connection. Give the new connection a name, and specify an IP address or DNS name of the AD server. Select Active Directory for an LDAP mapping. This will bring up a window asking you for the Search Base Suffix, which is what we figured out using the ADSI plug-in or an LDAP browser in the previous step. In our example this is “DC=rennich,DC=com".

Click the image to see the full picture.

Now select the LDAP mapping and click on the “Edit...” button. A new window will come up with a lot of options. The one that we care about is “Use authentication when connecting.” Here we will supply a user name and password that will allow us to browse the LDAP store. The user name will be the full DN of the user that we selected earlier. In our example this is “UID=Administrator,CN=Users,DC=rennich,DC=com.” You’ll need to put in the whole thing and not leave any part of it out or else this won’t work. Next, fill in the password for this user.

Click the image to see the full picture.

Now on to the “Search & Mappings” tab. Here is where you will need to make sure that Mac OS X can find all of your user information inside AD. If you select the “Users” entry on the left side, you will see the search base field at the bottom of the screen filled in with “CN=Users” and then the search base for the AD server that you just entered. If your user records are not stored in the Users container, and you’ll know this from the full DN of the user that you have already determined in step one, you need to make the changes here.

Click the image to see the full picture.

If you hit the disclosure triangle on the Users entry you’ll see all of the attributes that can be associated with a user. Since AD only has two or three of the half-dozen attributes that we need already created you’ll need to make a decision here.

  1. You can add the missing attributes to the AD store by editing the schema. This is not for the faint of heart, since you are unable to revert back to the original schema after making changes. Also, you will need to edit the top AD server in a forest which will then propagate the changes down to all of the other servers. This is the method described in detail in Apple’s PDF on AD integration and other sources on the web. This does not allow you to integrate with AD in 3 hours or less, so we won’t cover it here. In large-scale environments, with enough forethought and planning, this is a very attractive solution.
  2. You can commander an unused AD attribute and use it for Mac OS X clients. When doing this you need to consider the ramifications of using an attribute that may be needed later as this will cause significant problems. However, there are some fields that you should be able to use with a reasonable degree of certainty that they will not be needed elsewhere. The “ipphone” attribute is a popular one. You can pick out a few of these to do your dirty work if you want. However, you will need to be able to edit these entries in the AD server. Also, it’s best to coordinate with your AD admin on these so that your rear isn’t the only one on the line if things go bad later on.
  3. Finally, you can use static mappings to permanently associate a value to every record. This does not require any modifications to the AD store but does limit your flexibility since every user in the AD store will get this value for the associated attribute. For example: instead of adding a field to AD for the user ID you can static map the UID to a number; for example, 505. Now every user logging into the Mac OS X machine and authenticating against AD will become user 505. I’ll give you some examples later of how this may be of immense use in some situations.

Again, keep in mind that you can use a combination of these three methods to get all of your user information. For example: you could map the UID to a certain field in AD but then have a secondary static map, such that your admin users you would actually edit their AD entries and fill in the UID number. However, for your users you wouldn't. They would get the statically mapped number since there was no value in the first field. All of these mappings are done in Directory Access. Select the fields on the left that Mac OS X is looking for and then associate them with AD fields, either new or commandeered, on the right. To make a static map enter the value on the right preceded by pound sign.

Now that you know how to map, what should you map?

In the back of the Mac OS X Server Admin Guide there is a much more in-depth discussion of all of these fields and the format of the data.

(3) Test twice, login once

Once you have the fields mapped, you need to add the LDAP server to your authentication path. Go to the Authentication tab of Directory Access and select a custom path. Then hit the add button at the bottom and select entry for the LDAP server that you just added. Hit the apply button and you are ready to test the setup.

Click the image to see the full picture.

Go to the command line and use lookupd in the interactive mode to test if everything is working out.

lookupd -d

Once in interactive mode, query lookupd for all users that it can find.

allUsers

Which, if you have done everything right, will return all users that exist both on your local machine and on the AD server. You should now be able to log out and log back in as one of the AD users. Exciting stuff, eh?

If this doesn’t work you need to double-check everything that you entered into Directory Access. There is a lot of different fields that need cryptic information put into them. A small typo in any of them can cause the whole chain to break. To help you troubleshoot the connection I suggest you use an LDAP browser to make sure that the information that you have is correct.

If that doesn’t help you and you can’t find anything bunged up in the configuration, you are probably better off deleting the entry in Directory Access and starting over. Don’t be discouraged if this is hard. You aren’t the only one that feels that way.

(4) Lighting the bulbs

If you have followed along so far and everything seems to be working well, great! You can now log into your Mac OS X machines as a user stored in the AD directory store and get a local home folder. The problems come when you want your users to use network home folders. Even though you have specified the right syntax in the “HomeDirectory” attribute, the sharepoint isn’t being automounted at boot. To get this to happen you need to create Mount entries on the AD server and then map those using Directory Access. Boy is that a real pain in the rear, though! To do this you really need to edit the AD store, which would make this process much more than 3 hours, so there must be a better way!

There is.

If you have a Mac OS X Server running on your network, you can use it to provide the missing information over NetInfo or LDAP to the client machines, thus eliminating major changes to AD. Your clients can bind to the AD server over LDAP and the OS X Server over NetInfo at the same time. The client will get all automounts, group information and the MCX, or managed permission cache, from the Mac OS X Server but get the user and password information from AD. Now you can setup the automounting home folders on the Mac OS X Server and point the users home folder there in AD.

This hybrid setup will minimize the amount of intrusion in the AD store while maximizing the amount of control that you have over your Mac OS X clients.

To achieve this you need to set up Directory Access on the server in the same way that you did on the client. This will allow the server to bind to AD and get the user information. Now create a parent NetInfo domain on the server, making sure that the local, network NetInfo database, and the LDAP server are in the custom authentication path that you have set up in Directory Access.

Now open up Workgroup Manager and log into your server. You’ll get a window that comes up showing all of your NetInfo users and groups. Open up a new window by hitting Command-N. In the new window go down to the “At:” pull down menu in the lower left hand corner and select “other.” This will bring up a sheet showing all available directory services that you have specified in Directory Access. One of these will be the LDAP connection to the AD server. Select this.

You will now have a window showing all of your AD users. You won’t be able to edit them, but have no fear, you can do something even cooler. Go back to the window showing your network NetInfo database and create a group. Instead of adding users to that group by using the drawer that comes out on the side, drag users from the AD window into the group. While you can’t edit the AD user information you now have full control over the NetInfo group that contains all of the AD users. Using this method you can now enforce preferences, file permissions, and workgroup management on the AD users without further changing the AD directory store.

Again, since your clients will be bound to both the AD server and the Mac OS X Server all of this information will be picked up by the client.

You’ve just integrated your machines with Active Directory in an afternoon. And maybe your Windows admins don’t even know about it.

(5) Concerns

Using LDAP to connect to the AD server will NOT allow your users to change their passwords from the Mac OS X machine. This is function of AD not really being an LDAP server but an Active Directory server. For most people this isn’t an issue since you can still change your password using Terminal Services, Citrix, or by logging into a Windows machine.

In addition, you also need to be concerned with sending your passwords across the network. The method I have outlined above uses only the normal LDAP connection protocol and not LDAPS—which wraps the whole connection in SSL. We’ll cover adding SSL to the AD server and the Mac OS X client in the next installment; however, there are other resources on the web which outline this, so please look carefully at those before implementing this.

Also you should consider Kerberos connections for your Mac OS X machines. This is even more secure than SSL and will also solve the problem of not being able to change passwords. Oh, happy day! More on this later, too.

(6) Example implementation

This is a common setup for schools and other lab situations. All users are stored in AD, but no attributes are added or modified. All users get the same UID, home directory, etc. since these are all statically mapped. When a user logs in they get put into a generic, statically mapped, home folder. When the user logs out you engage a logout hook and delete the used home directory and recreate it with a skeleton version.

All of your admin users you created yourself in NetInfo. This allows you to log into every machine as an admin without having to add extra attributes to the users in AD. Just set up the users as you normally would on the Mac OS X Server.

You can further enhance this setup by placing all of the users from AD into a NetInfo group and then managing preferences on that group.