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.

Using VDS to Promote Efficiency

Hi there.  I know it's been a while since I posted here, but it's not because I'm not working on NetWeaver IDM or writing.  I've been doing a lot of the former and a bit of the latter.  In order to help promote the growth of a NW IDM technical knowledge base, I've been posting most of my IDM specific things on the SAP Community Network Blog.  I'll still be posting here from time to time, but it will more likely be architectural or opinion related pieces about IDM.

To that point I'd like to talk about the seldom discussed Virtual Directory Server.  I've always loved VDS and it's MaXware predecessor, MVD. There's just so much this product can do. While most of the SAP world is familiar with the Virtual Directory as a Web Services proxy for GRC or use with HCM, it is so powerful and flexible that it can do everything from provisioning to authorization and authentication management, to representing data sources in all kinds of different ways.

That's one of the things I'd like to talk about today.  Ask most Directory Services administrators about a recommended architecture and they will tell you straight out, "flat, as flat as possible."  However there are a number of reasons that this tends not to happen.

So how do we deal with this.  Simple, via the Virtual Directory Server.  Set up the flat structures that the administrators want, then use VDS to  represent the directory with different views, deep organized by geography  department, types of equipment, whatever.  Present the displayname and other attributes as the different divisions request.  Create separate customer facing views of your Identity Data.

Also don't be limited by only using Directory Services information for your Virtual View of data, use the Identity Store, UME and other sources separately or joined together to create your new interface.  Information on this can be found here. The advantage here is that you can create a virtually (if you'll pardon the pun) unlimited number of data representations. Now go forth and create Virtual Directories make your Identity Management group, the "Can do!" group that provides everyone the flexibility that your external customers need while providing the optimal efficiency that the back office wants to deliver.