How to Authenticate Mac OSX Against Active Directory

This Paper will explain how to authenticate a Mac OS X 10.2 computer against Active Directory via LDAP without modifying any schema.

Part I: Getting your Schema Attributes

As a MCSE, the thought of making irreversible schema changes to our Active Directory to authenticate our Macs ranks up there with intentionally contracting scurvy. To make matters worse, all of the documentation available for OSX authentication either called for massive schema changes, buying expensive third-party software, or buying OSX servers, none of which were an acceptable solution. Another option which was reported to work was to statically map and script some of the settings. The only problem with this is that nobody actually had complete documentation on the process, which is the scope of this paper.

The first step in authenticating against Active Directory (AD for short) is to be able to actually see the directory. For testing purposes, it is much easier to use a LDAP viewer to hone in your settings than to try to authenticate against AD without knowing the exact settings you need.
Get a LDAP Viewer:
Download the Java-based LDAP browser from here:
Now unzip and open the lbe.jar file inside the “ldapbrowser” folder.
Once the program has finished loading, select “New” and enter a name for this connection. Click on the Connection tab and enter the Fully Qualified Domain Name (FQDN for short. ex, or the IP address of one of your Active Directory domain controllers into the host field. Port should be set to 389, and version should be set to 3.
Enter your network’s Base Suffix into the Base DN field. (A Base suffix is a collection of domain component (dc for short) items in your domain separated by commas. For example, for the domain “”, the Base suffix will be “dc=store,dc=apple,dc=com” Note the lack of spaces between the dc’s.) Initially you should be able to connect anonymously and atleast see the base DSE, although some admins have locked this down. To be able to connect and browse the directory you’ll have to supply credentials of a user that has been granted this permission. By default, all users have this permission unless your admin has changed something. If you’re the only user of a machine you can use your own account, but if you’re setting up a lab you should setup a user specifically for this purpose and deny this user any rights to anything important because this user will be going on every OSX box as part of the setup. Let’s create this user and we’ll call him macviewer.
Uncheck the Anonymous bind checkbox.
Enter “cn=yourusername,ou=yourou” into the User DN field, where yourusername is a username of any user in the domain (like the “macviewer” account), and yourou is the ou to which the user belongs (in a standard configuration, the OU is Users).
Enter the password for that user, and check the “append base DN” check box.

Click Save, and then click Connect.
If everything that you entered was correct, then a list of items should appear on the left of the window. Select the OU that you entered, and select one user in that OU. On the right side of the window the Attributes belonging to that user will appear.
From that list of attributes you should choose one of these attributes to be the user ID for all your users. It could be something like uid, userID, or uSNCreated (We used uSNCreated in our network). You will also need to choose a Record Name for your users. Acceptable options would be sAMAccountName, or cn (We used sAMAccountName in our Network).
Write these names somewhere, as you will need them later in the setup.
Part II: Configuring Directory Access

Open the “Directory Access” application (located in /Applications/Utilities/).
Authenticate by clicking on the lock in the lower left corner of the screen if you have to.
Uncheck all boxes except AppleTalk, LDAPv3, and SMB (That’s what we had, although only LDAPv3 should be enough).
Click on LDAPv3, and click on the “Configure” button.
Uncheck the “User DHCP-supplied LDAP Server” box
Click on show Options.
Click on the New… button.
Enter a configuration name of your choice, the FQDN or IP of your Windows domain controller, uncheck the SSL check box, and select “Active Directory” from the LDAP Mappings pop-up menu.

Enter your Search Base Suffix (see above) into the dialog that will pop-up, and press “OK”.
Click the Edit… button.
Set “Open/close times out” and “Connection times out” fields to 10 seconds.
Check the “User authentication when connecting” box.
Enter the following into the Distinguished Name field:
“cn=yourusername, ou=yourou, yourbasesuffix” (See the top of this paper if you don’t know what these are.)
Enter the password for that user.
Make sure that “Encrypt using SSL” and “User custom port” are not checked

Click on the “Search & Mappings” tab.
Click on “Users”. The Search base field of the window should get automatically filled in. The OU will be automatically set to Users. If your OU is not Users, then type in your OU instead of Users. Make sure that the all subtrees radio button is selected.
Click on the triangle to the left of “Users”.
You will have to click on each attribute under the User type, and map it to something using the box on the right.
Map RecordName to the record name that you wrote down earlier (in our case it was sAMAccountName).
Map UniqueID to the unique ID that you wrote down earlier (in our case it was uSNCreated).
Map RealName to “cn” (without the quotes).
Don’t map the Password to anything.
Map the PrimaryGroupID to “#20” (without quotes). This will make any network user that logs on to your Mac have the same privileges as the local non-administrator users. You may change this if you know what you’re doing.
Don’t map the HomeDirectory to anything (delete the item that it was mapped to by default).
Map NFSHomeDirectory to “#/Users/localUser/” without quotes, where localUser is the name of a local user on the machine whose home directory you want the network users to use when they log on to your Mac.
Delete the following attributes (unless you really need them and know how to map them:
EMailAddress, PhoneNumber, Comment.

Press the “OK” button.
Press “OK” again (you might have to enter your local admin password).
Click on the Authentication tab.
Choose custom path from the Search pop-up menu, then click on the Add… button, and click add in the dialog box that pops up. Do the same for the Contacts tab, and press Apply.

Part III: Using lookupd to view all of the users
Now you need to check if your Mac can receive the user information from the active directory server by using the lookupd program:

Open the Terminal, and type in “lookupd -d” (without quotes of course), and press enter.
At the prompt type in allUsers and press enter.

Information for all the users should appear, with the number of users on the bottom.
If the number of users is between 18 and about 25 (number of local users on your machine + system users), then it didn’t work. Try to figure out what you have done wrong. If the number of users is much higher, congratulations! You have done most of the work!

Part IV: Testing the Setup
Now you are ready to test to see if everything works.

Restart the computer, and try to log in as a network user.

NOTE: If your Mac freezes up after you made some changes in Directory Access, or it stalls on boot up before the login screen comes up, then you will have to boot up in single-user mode (hold Command-S during startup), and type in the following at the prompt: “mount -uw / [enter] rm -r /Library/Preferences/DirectoryService [enter] exit” Once the Mac has finished booting, login, and configure Directory Access all over again.

If the login screen appears and you can’t log in as a network user, then login as a local user, and open Terminal, and enter lookupd -d [enter] userWithName yourusername [enter] to see if the Mac even gets the logon information for that user. If so, then there is a problem with password encryption incapability. You’ll need to troubleshoot it a bit.

Part V: Setting up unique user directories (optional)
This part will explain how to make it so that each user has their own home directory (locally).

You will need to write a login hook (a script that runs on login) that does all of this, and install it by using a utility called “LoginWindow Manager” which can be downloaded from

Here is the script that I used:

##### Script Begins Here (you don’t need this line) #####

#! /usr/bin/perl -w
if($ARGV[0] ne “admin”) {
if(-e “/Users/NetworkUsers/$ARGV[0]”) {
# a home folder already exists for this user – do nothing.
mkdir “/Users/NetworkUsers/$ARGV[0]”;
`ditto -rsrcFork ‘/System/Library/User Template/Non_localized/’ ‘/Users/NetworkUsers/$ARGV[0]/’`;
unlink “/Users/networkUser”;
symlink “/Users/NetworkUsers/$ARGV[0]/”, “/Users/networkUser”;

`/usr/sbin/chown -R $ARGV[0]:staff /Users/NetworkUsers/$ARGV[0]/`;

##### Script Ends Here (you don’t need this line) #####

Just put it in a text file using TextEdit, and save the file somewhere safe, like somewhere in the /Library directory.
Then Open LoginWindow Manager, and set this script to run on startup as a login hook. Make sure that you test the script by pressing the Test button in LoginWindow Manager before you press Apply.

What this script does is it first checks if the user logging in named “admin” (local user), in which case it does nothing.
It the user is not admin, then it checks if a home directory already exists for that user in /Users/NetworkUsers/.
If it doesn’t exist, then it creates a new home directory from the template. Then it sets privileges for the user’s home directory, and makes an alias to that directory in /Users/ and names it networkUser. This networkUser alias is what the Directory Setup will be configured to use as a home directory for every network user logging in on this machine. You can do this by mapping the Users > NFSHomeDirectory in Directory Access to “#/Users/networkUser/” (without quotes).

Logout and log back in as a network use to make sure that everything works well.

Part VI: Making it secure

Now that you’ve got it working, it is time to make it secure. We’ll be doing this via Secure Socket Layer (SSL) so our credentials don’t go across the network unencrypted. We need to get a certificate from our network’s Certificate Authority (CA) so we can use SSL.