LDAPv3 Authenticating to Active Directory (Part II)

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
UserInfoMenu v1.02

Active Directory Integration in Three Hours or Less Article on AFP548.com
Mac OS X with Active Directory (Apple's PDF using LDAPv2)
Apple OIDs (For schema modifications)
NISSchema Attributes (Additional OIDs not covered by Apple)
University of Michigan LDAP info
Additional Docs on LDAP integration from JAMF Software
Mac OS X AD Integration Scripts (Shukwit.com)
Mac OS X Server: How to Avoid Sending Clear Passwords in a Kerberos Environment With LDAPv3

-- Where Has My GUI Gone? --

 

OS X is a bit particular about who can do what. Its Unix and that's just the way it is. Like Unix, OS X tracks people by using a uniqueID number. How unique this number is depends on what kind of environment you're using. If you plan on only logging into the OS X box and never interacting with a file server then the ID should be unique on the machine. (In fact, OS X manages this for you so you'll never see your uniqueID) If you plan on authenticating to an LDAP, Active Directory or OS X server, you should probably assign unique IDs for every person on the server using the supplied server administration tools. Now with Windows2000 this MAY not be so important since 2000 Server uses its own methods of tracking rights and ownership independent of the uniqueID. In fact, you could probably assign the same uniqueID to everyone and it wouldn't matter to OS X but I'd try to play it safe in case it does matter someday. One place where it will matter is if you setup local directories on someone's hard drive. To have rights to them, they must have the same uniqueID as that which is assigned to those directories.

So what does have to do with the missing GUI? Well, the reason the GUI is missing is because after OS X authenticates using LDAP its looking for a uniqueID. When it doesn't find one it assumes you enjoy "hell" and proceeds to dump you into one, namely the command line interface. To prevent this from happening, you need to give your ActiveDirectory account a uniqueID number.

-- Where Do I Put My UniqueID? --

 

As should be quickly apparent, Microsoft doesn't have a field in Active Directory for a uniqueID. This will leave you with two options: use an existing empty field to handle the uniqueID, or modify the schema and add the missing field to the user class. I'm going to describe option #1 since its easier. Modifying an Active Directory schema is tricky and permanent. Any additions made to the schema can be deactivated but they can NEVER be removed.

Hopefully, you have access to a Windows2000 and have logged in as the Administrator. Open the Active Directory Users and Computers administrative tool. Find a user account to play with and double-click to open its properties window. Pick a field and enter a uniqueID number. Since OS X Client starts around 100 and server seems to like 500 I'd suggest something higher like 1,000 or 10,000 to avoid conflicts (or security holes) with local accounts. For this example I'm using the telephone number field and I have entered 1005 as a uniqueID for the user Ricore.

Now, all we need to do is tell OS X to map the value uniqueID to the entry for telephone number in AD. Before we can do this we need to find out what the telephone number shows up as when browsing Active Directory via LDAP. You would probably guess that telephone number will show up as telephone number in LDAP. In this case you're right but sometimes its not that simple. In the user record above is a field called office. When viewing AD using LDAP it lists office as physicalOfficeLocation which is not particularly obvious at all.

NOTE: LDAP will only display fields that have data in them. If the field is emtpy in the user record it will not display when browsing via LDAP.

Warning: You could use a pre-existing field to simulate a UID provided it returns a number within the range of a normal UID. The uSNCreated field can be used to do this but I hesitate to suggest it since its a field used by AD internally and could be dangerous if you ever need to manually change its value.

Earlier I suggesting download a free java based LDAP browser. Open that up and connect to your Windows2000 server. Find the user account you modified and examine its properties. Hopefully, you'll find an entry like this:

If you decided to use some field other than telephone number just keep scanning the values column for whatever value you entered. You might even consider throwing a temp number in like 454545 so that it stands out better from the crowd. Now that we have a field name we have one last modification to make.

-- Making The Connection --

 

The Active Directory template supplied by Apple for LDAP authentication expects to find an entry named UniqueID. Since we haven't extended the schema (yet) we need to tell Apple's LDAP configuration to look for something else.

Open the Directory Access application located in Utilities inside the Applications folder. Click on the lock icon in the lower left corner and authenticate if everything is grayed out. Select LDAPv3 from the list (I'm assuming you've already configured it per part I.) and click Configure. Select your LDAPv3 server config and click Edit. Click the Search & Mappings tab. On the left click the triangle to open Users. Select UniqueID. On the right, click Add and enter telephoneNumber (or the name of the field you are using as it appeared in the ldapbrowser). If you wish you can delete the UniqueID entry leaving telephoneNumber as the only mapping to use. This isn't required since what you are modifying in the right column is a list of things OS X will look for to map to UniqueID in the OS X environment. If it can't find UniqueID in LDAP it will try the next entry, in this case telephone number, and so on.

Click OK for this and the previous window. Close Directory Access and logout. Now try logging in using the account you modified to have a uniqueID. The GUI should not disappear this time. All looks well except:

You can't modify any settings!!

Preferences won't save and the dock always defaults back to what it looked like the first time you login no matter how many times you remove items from it. This is to be expected. Without a homeDirectory OS X uses a set of non-modifiable defaults for any user that can authenticate to the system. This can be fixed by supplying a homeDirectory via LDAP but I'm still working this part out. I can describe how to modify your schema so that each user account can have a UniqueID field. This eliminates the need to use emtpy pre-existing fields, reduces the risk of picking a field that might be used later, and helps your server to better document itself rather than requiring a sticky note scrawled with "Yo, we're using the telephone number to store UIDs for those Mac users!".

Modifying The Schema -->

Email: Chuck Simciak