LDAPv3 Authenticating to Active Directory (Intro)

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

-- News And What Not --

 

April 15th, 2005
     Added some information I got in an email regarding the use of Classic with machines joined to AD. Apparently there is a way to make it work. I also recall reading that the true issue with Classic had to do with the preference file it needs to create not being created due to something involing file name length limits.

May 9th, 2003
     Now that the ADmitMac (formerly Goliath) beta is drawing to a close its looking like my company will probably use this piece of software instead of attempting to modify our AD schema. As such, I won't be doing any more LDAP research for now though some projects related to ADmitMac may get documented here. I've added a link to Thursby's ADmitMac web site which also links to the documentation I've written during the beta period. Well, it use to. Now that the beta is over the link is gone but still there is plenty of good stuff to read out there.

     I've also added a link to my first OS X software project. UserInfoMenu is a small app I wrote using an article on Cocoa/Applescript integration. It simply creates a menu item which contains vital info like user name, home directory, uid, account type, host name, and ip address. Once Thursby gets ADmitMac and its support tools out the door I'm also hoping to add support for domain and domain controller as well.

April 7th, 2002
     Just a warning to everyone. The OIDs supplied by Apple are NOT final. Use them at your own risk. If you must deploy your schema changes do so by registering for your own Enterprise ID and developing your own OID space independent of Apple.

February 28th, 2003
     I haven't had much time to update this. I'm currently working on a project to migrate a Novell Netware server over to Windows2000 and Active Directory. I have updated the current OIDs used by Apple. Currently its unlikely my organization will allow schema changes so I've abandoned any further research into this matter. The approach I'm moving towards involves using an OS X server "connected" to AD. Mac OS X clients will connect to OS X server via OpenDirectory and hopefully the OS X server will reference AD for passwords so I don't have to deal with the multiple password problem.

     A new Misc section has been added to collect interesting pieces of information until I can find time to write a full article about them.

     Finally, Thursby Software announced they are working on a product codenamed Goliath. Goliath will allow a Mac OS X client to connect to an AD resource with kerberized LDAP authentication. This is a major plus as this tool doesn't require schema changes and provides the all important encryption to the LDAP connection (something I haven't figured out yet).

December 17th, 2002
     Part III and Part V have been updated. Finally got all the OIDs and kinks worked out so I feel these docs are about as accurate as they can get. I won't have much time over the next month or so to do any more updates. My services are needed on a few other projects so the LDAP stuff will have to hold until they are finished.

December 12th, 2002
     Part III of my series has been updated with the proper OIDs as well as the proper use of an Auxiliary Class for the addition of new attributes. Check it out.

December 11th, 2002
     Finally got time to do some updates. I'm working on re-writing the documentation a bit now that I have the official GIDs used by Apple for schema modifications. I'm also told that one should not add attributes directly to the user class but should instead create an auxiliary class, add atrributes to it, and then attach the auxliary class to the user class. When I get the documentation updated it will reflect this. For now, I'm trying to get caught up on everything since I was out for Thanksgiving week and then had to attend an Active Directory class all last week.

November 20th, 2002
     Oops, I've just discovered recently that all my schema entries in Part V are backwards. Where I say LDAP Display Name I meant Common Name and vice versa. I've corrected this now but if you were having problems getting LDAP and autoMounts to work this might be why. I'll have more information posted soon as I catch up on all my emails.

November 11th, 2002
     Finally got the homeDirectory information posted. Noticed in Apple's MacOS X with Active Directory documentation they used "Case Sensitive String" instead of IA5-String when making schema additions. Not sure how important that is but I've had no problems using IA5-Strings so far. On my next test setup I'll try Apple's recommendation and see if there's a difference.

November 4th, 2002
     Since I'm pretty much posting as I'm learning I thought I should have a new page to point out any changes I make as I understand things better. One such thing is warning in Part2 of this document. The OID (Object Identifiers) that I'm using are from a reference document published by University of Iowa. These numbers are fine for a test setup but you should NOT use them when you go live. I don't completely understand the process but I'm pretty sure that OIDs are unique to each business and organization. So, even if you are registering an OID for a pre-existing data type, it still has to be registered to your organization. The good news that I think you only need an organization level OID and whatever you add to it is up to you to administer, not unlike a block of IP addresses. If anyone has additional insights on OIDs please email me.

Oh, and if you should be in error on something ABSOLUTELY email me. I'm learning this as I go and this site is as much to help others out as its to document what I'm doing so I don't forget.

Getting Started -->

Email: Chuck Simciak