| Intro | LDAP to AD Part I |
| LDAP to AD Part II | LDAP to AD Part III |
| LDAP to AD Part IV | LDAP to AD Part V |
| Misc | ADmitMac |
| -- Modifying the Schema -- |
Its pretty much a given that you will have to add information to a user account in AD in order to make OS X authenticate correctly. You can use pre-existing fields but its better in larger environments to modify the schema. By modifying the schema you can add additional fields to a user record allowing it to store the extra values needed by OS X to authenticate properly. Modifying the schema should not be taken lightly. All schema modifications are permanent. Although you can deactive a schema modification you will never be able to delete it.
| -- Preparation -- |
On the Windows2000 server select Run from the Start menu. Type in:
regsvr32 c:\winnt\system32\schmmgmt.dll
You should get a message that schmmgmt.dll has been registered. Load up the Microsoft Management Console by selecting Run again and typing MMC. Click Ok.

In the console window, select the Add/Remove Snap-In from the Console menu. Click the Add button and select Active Directory Schema. Click Ok then click Ok again. Open the Active Directory Schema object in the tree view on the left side. Click on the attributes folder. In the right column you will get a list of the all the ActiveDirectory attributes that are available. These attributes can apply to anything from user accounts to computer objects.
| -- Adding A New Attribute -- |
To create a new attribute we must first enable modifications. Right click on the Active Directory Schema object at the top of the tree. From the popup menu select Operations Master. Check the box for "The schema may be modified on this Domain Controller". You can only do this if the machine you are working on is a domain controller. Click Ok to enable modifications.

Right click on the attributes folder and select Create Attribute. Click Continue after reading the warning. For the Common Name enter uidNumber and for the Display Name field enter UniqueID. You can name it anything you want but calling it UniqueID will save you a step later on. Now, the next field, Unique X.500 ObjectID is important. This field is how X.500 tracks things and it has to be unique. Apple and various other companies have already registered OIDs for the things we need. For UniqueID use this one (see the NISSchema Attributes for a complete list):
1.3.6.1.1.1.1.0
The next section covers Syntax and Range. Set Syntax to integer and enter 0 for a minimum value.
Though 0 is the lowest UID you can use you might consider setting the minimum value to something like 1000 or 10000. This way, you don't have to worry about local accounts every recieving a UID that matches an account in AD. Remember, OS X uses UIDs to handle security so it doesn't matter if the local account is JoeBlow and the AD account is JessicaAlba. If the UIDs match OS X will consider Joe and Jessica to be the same person.
For a maximum value I'm not entirely sure how high OS X can go. Based on what I've gotten out of OS X 10.1 Server, I know you can use a value as high as 999,999,999 so go ahead and enter that as a maximum value without the commas. Later, if we decided we want to raise or lower the maximum it can always be changed. Click Ok.

Go back and scroll through the attribute list. If all is well your entry should now be there. Click on the UniqueID entry and select properties. Type in a comment and click Ok. Don't worry about the other options we don't need them to make this work.
| -- Create an Auxliary User Class -- |
A new attribute is great but until we associate it with the user class OS X will never see it (nor will anyone else for that matter). Now, you could just add the new attribute to the existing User class but I've received information from various sources that this is a "bad thing". I don't why but its just not how things are done. Instead what we will do is create an Auxliary class, add the attribute to it, and then append the class to the standard User class. To get things started right click on the Classes folder and select Create New Class from the popup menu. Click Ok again to acknowledge that we know what we are doing.

Enter the following information as seen above:
Common name: aplUsers
LDAP Display Name: Users
Unique X500 Object ID: 1.3.6.1.4.1.63.1000.1.1.2.1
Class Type: Auxiliary
Click the Next button. Here we add attributes to our class. Since we've only created one there is only one to add. Click add in the Optional section and add the UniqueID attribute created earlier.

Finish the auxliary class, then go back into the Classes folder and get properties on it to set the comment field. One final step must be done. In the Classes folder find the user class and right click it. Select properties from the popup menu. Click the Relationship tab and click add for the Auxiliary Classes section. Add the Users auxiliary class you created and click Ok.

By doing this we've added the UniqueID attribute to the User class via the auxliary class. Now whenever a new user account is created there will be an additional field called UniqueID into which we can store our UID number. The problem is standard MMC tools like "Active Directory Users and Groups" will never display this field. Why? Because if Microsoft didn't create the field they are not supporting it. However, there are ways around this.
| -- Modifying Our New Attribute -- |
On your Windows 2000 Server cd is a directory called SUPPORT. Open it up and run the installation program found inside. Accept the default settings and let it do its work. Run MMC and add the snap-in for "ADSIEdit". (For some reason, many websites including Microsoft's will tell you this tool is in the Windows 2000 Resource Kit. Wasn't there when I looked so perhaps these were earlier editions of the Resource Kit CDs that had it.)
In the MMC you should have a ADSI Edit object. Right click it and select Connect To. As long you are running this where you are making the schema changes you should be able to click Ok with the default values used in the Connection dialog. Open the server object under ADSI Edit and start opening DCs until you find CN=Users. Open this and look for your user account. Right click on it and select properties.

"Select Which Properties To View" should be set to Optional as a default. In the next drop down select your custom field, UniqueID (or whatever you entered) or simply highlight the dropdown and start typing in UniqueID until its highlighted. Enter a value in the Edit Attribute field and click the Set button. Click Ok.
If the UniqueID attribute is not visible there are two things to try (and I'm still not sure which of them matters or if both do). First, back in the Active Directory Schema snap-in you can right click on the Active Directory Schema icon in the tree view and select Reload the Schema. The other option is to right click on your domain tree object directly under the ADSI Edit tree entry and select Update Schema Now from the popup menu.
| -- Modifying OS X LDAP Mapping -- |
Now if you created your schema addition as UniqueID you can skip this step and proceed with testing your LDAP autheticated login. If you did use something different open the DirectoryAccess application on your OS X client. Click on the lock icon in the lower left to authenticate if you haven't already. Click on LDAPv3 and click the Configure button. Click on your LDAP server entry and click Edit. Click the Search & Mappings tab.

Click the arrow by Users to expand and select UniqueID. Remove telephoneNumber if you have it left over from Part II and also remove UniqueID. Click the Add button and enter the field name you created in the schema for storing your UniqueID. Click Ok twice and close the application.
Test your LDAP login. If you followed along in part II you shouldn't see any difference which is good since that means the schema changes have worked. Next up I need to figure out home directory mounting which will complete the LDAP setup for AD directory. In the meantime, I may document a few more things like a better way to administrate your custom schema. Yes, you could use ASDIEdit for this but it doesn't scale. Wouldn't you rather administrate your server with a web browser?
Email: Chuck Simciak