Schemas and Some Elements of LDAP History

Note: all trademarks mentioned in this blog are the property of respective owners.

I've been meaning to write this entry in one form or another for over 20 years. Glad I finally got around to it.

LDAP has been around since 1993, while Microsoft's Active Directory was introduced in 2000. During this time, Active Directory has become a virtually universal constant in organizations worldwide. Approximately 90% of the Fortune 1000 use it. It's hard to escape from it. But there is a definite appeal to setting up additional Directory Service instances from Microsoft or other providers. Setting up these additional instances helps to properly segregate different user types (employees, customers, vendors, etc.) and, particularly in the Active Directory use case, helps manage licenses and keep all OS and Application infrastructure accessible by Active Directory out of prying hands.

Herein lies the issue at hand. For its own reasons, Microsoft does not use the same object classes as standard LDAP. For those unfamiliar with LDAP, an object class is a grouping of attributes. Object classes facilitate the definition of users, groups, and other components of the LDAP structure, thereby introducing some organization to the overall schema.

Standard LDAP uses the inetOrgPerson as the basic definition of a user, while Active Directory uses the user. Most of this grew from the basic organization of Active Directory, along with the additional information required by integrating Microsoft Exchange back when it was an on-premises application. Of course, as the two concepts evolved, differences cropped up that I need to reference from time to time. To make this easier, I'm listing the most important differences here. I've listed the standard LDAP attribute first, followed by the Active Directory attribute.

• jpegPhoto -- thumbnailPhoto
• secretary -- assistant
• street    -- streetAddress
• uid       -- typically not used

I'm sure there are a few others, and I can see updating this list as things change in the future. Also, the uid attribute is typically used in Active Directory when it is being synchronized with a more standards-based LDAP, as it usually uses uid as the primary identifier as opposed to cn when building the entry's distinguishedName. It's also important to remember that the value stored in userPassword is not encrypted, but rather it is a hashed representation of the password. (This article provides a nice description of the process) This means that there is no way to decode this value and setting it typically requires an SSL connection.

One final note here, I've pointed out some differences between Active Directory and LDAP. This is not necessarily a criticism of Active Directory. Active Directory is a proprietary evolution of the original LDAP standard for some of the reasons I mentioned above and more. Standard LDAP is just that, LDAP based applications more closely adhering to RFC2798 and typically being a "descendent" of the original AOL-Netscape-Sun Directory Server code.

Let me know if you have other attributes that should be added to this list.