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.

SAP TechEd 2012: Day 1

Day 1, all I can really say is Wow! I attended sessions on the latest addition to the SAP's Identity Management line up, some of it's oldest technology and the future of the NetWeaver IDM.  After today's session, my mind is completely blown away.

I started the day with two informative sessions on SAP's Single Sign-on Offering based on the technology asset acquisition from SECUDE about 18 months ago. SAP has clearly recognized that information security must begin at the login and proceed from there.  I'm looking forward to learning more about it over the next year or so.  It's a major technology on my radar and should be considered as a key strategic goal for all SAP implementations.

The next session was based on a favorite technology of mine, the Virtual Directory Server (VDS).  Virtual Directory technology has been the "next big thing" in Identity Management for many years now. It appears that SAP's use of Virtual Directory not only as an LDAP proxy, but also as a Web Services Proxy could very well make this the case, particularly in the SAP ecosystem. Miroslav Jokic, SAP's VDS expert, back to the MaXware days gave a great presentation. In an hour long session, Misa gave a thorough overview of VDS, explaining it's architecture, basic use cases and extended use cases when working with Web Services. Clearly this is a technology whose time has come.

The third session of the day dealt with best practices for implementing SAP IDM. While focused on consultants, Kåre Indrøy, presented a good 10 point plan that is applicable to any IDM implementation. In the second half of the presentation, we received an excellent briefing on the new SAP Rapid Deployment Framework for IDM developed by SAP Consulting. While somewhat limited in scope, it certainly does appear to be something that can be quickly implemented for most small to mid-sized clients if all of the pre-requisites are met.

All of these new features will be available in NetWeaver IDM SP 6 which should be available in 2-3 weeks.  Most are also available in SP 5, but not through the Web UI.

Now we come to the Crown Jewel of the day, which was a 2 hour presentation by Kåre and John Erik Setsaas showing the latest functionality to be released shortly in Service Pack 6 for NetWeaver IDM 7.2 and what we can expect to see in the next 6-9 months. Approvals are being enhanced again, making them more functional than ever, particularly where declines and assignments are involved.  Automatic Delegation is now available to designate temporary approvers when the primary approver will not be available.  

NOTE: Everything that follows is conceptual and is not guaranteed to be in any future version of NetWeaver Identity Management.

Trace functionality is also improved with additional control from the Web UI, which will be a boon to IDM developers. Also added to the Web UI is a new SQL Execution reporting interface that will report on database queries that last longer than a predefined limit.  This is a significant enhancement of the Configuration Analyzer's ability to detect inefficient queries and will be something that IDM Administrators will be very interested in.

The last part of the presentation was the really exciting part.  Kåre and John showed us some of the functions that we could be seeing beyond Service Pack 6. Access to the Administration Console looks like it will be getting some tightening along with some locking of objects being worked on in the Admin console. It's been a long standing issue that only one user should be accessing an IDM object in the MMC console at a time (Personally, I'm not found of two people looking at the same configuration at the same time) When the user is done editing and checks the object back in, it becomes available for editing by another IDM administrative user, Additional UME based security is being considered to restrict access to the IDM administrative objects as well.

Also it has been confirmed that DB2 will be supported by IDM in the near future.  The DB2 version will only work if the DB2 Database has been prepared to run in "Oracle Mode"  I'm sure we will be getting more information soon.

The Pièce de résistance of the afternoon was a brief overview of an early alpha version of a new Development UI. I'm not going into a lot of detail here since it was such an early release, but suffice it to say that a 21st century, eclipse based interface is on the horizon, and for those like me who have been working with this interface for the last 8+ years it appears that this will be the answer to our prayers.

I did not cover everything mentioned in these presentations for a couple of reasons.  One, I'd be writing for hours and I need to get some sleep tonight so I can be ready for tomorrow's sessions.  Two, this is SAP TechEd and you should be here.  If you're wondering is it worth it, I say YES! Hopefully this information will make you feel the same way!

The Stages of Identity

Recently I’ve been thinking about what happens to an identity through its life cycle and how the identity data is treated during this process.  I think you will also see that the Enterprise itself has differing methods of dealing with it as well. I am considering this to be the beginning of a framework and nomenclature that one can use for expressing how people relate to their Identity data on a number of different levels. I think we can pretty much consider this to be a “work in progress,” and I would greatly appreciate feedback.

So why do we need this, anyway? I have observed that organizations, consulting groups, and other industry experts relate to Identity based information. It seems that we all have our own set of assumptions about what is supposed to happen to this information based on our roles and responsibilities and that such a framework will help to organize our thinking a little better.

First off we have what I refer to as the Pre-Identity. During this time the data that will become the identity is in its most undefined form. Data in this stage might sit in a number of different silos or systems before moving on but is mostly used by Employment and HCM systems. Typically this data has some form in that it can identify and maybe even describe an individual in terms of the Enterprise, but it does not say anything about what it can actually do.  At this stage there are no entitlements that are associated with the user. The primary relationships held by this data are mostly legal ones as this data is used to connect with government and other systems to prove data on a legal / governmental level, such as the IRS, Department of Motor Vehicles, etc.

Once we have connected the data and accepted it into the Enterprise, the Identity information moves out of Pre-Identity systems into what I refer to as Dynamic Identity. This is the phase of Identity Management that most of us work with full time.  We will analyze this data, transform, populate (and de-populate) it in our Enterprise systems. This is also the time that we will grant, modify and revoke entitlements and apply that extra “dimension” that did not exist in the Pre-Identity stage. As the relationship between people, their Enterprise Identity and their organization(s) change, so will the Dynamic Identity. Systems and Processes will constantly be changing based on the need for access based on geography, roles, titles, responsibilities and other enterprise requirements.

Happening mostly at the same time as Dynamic Identity is that of Interrogative Identity. This stage of Identity encompasses some of the latest trends in the field of Identity Management. As there is an increasing need to clarify, document and ultimately define what an Identity has access to and ensure that the Identity is compliant with internal enterprise rules (governance) and governmental rules (compliance) it is essential that there is a defined set of processes that enable this to occur. There are now several sets of guidance on these practices established by governments and standards bodies and a growing set of application vendors to help navigate their processes.

As another dimension of Interrogative Identity, there is the constant need by the Enterprise to understand its own data. Access to data through Enterprise Systems and linking the elements of Pre-, Dynamic and even Interrogative Identities is increasingly being managed by Business Intelligence (BI) systems.  Our understanding of how the Identity and Enterprise are connected is being enhanced as BI is extended into Identity models. This trend will only continue to grow; however its management through will need to be maintained and monitored by Dynamic and Interrogative systems to ensure that Identity and Access data is properly protected.

Finally, we must define what happens when an Identity is no longer associated with the Enterprise. The Post Identity phase is one that is often overlooked, and is the cause of many exploits and Identity Management related crises. Ensuring that there are ways to properly separate the user from the Enterprise systems while maintaining their existence for ongoing Interrogative Identity practices is required properly complete Dynamic Identity operations.

Throughout this article I have made references to “the Identity” without going into much detail.  This is done this on purpose so that there are no preconceptions as to what can be managed by this model. Any type of Enterprise object could be managed in this framework, whether it is people, groups, roles, privileges or other objects such as systems, phones and other hardware, and the relationships therein.

I have also been somewhat vague about what constitutes the Enterprise.  For far too long, the field of Identity Management has been confined to the Corporate Enterprise. However with ongoing initiatives to “Cloud” and “Service” based systems, there is a greater need to manage and monitor these relationships as one would in a Corporation or Government system. Our increasing reliance on systems such as Google, Facebook, LinkedIn, Yahoo!, etc. to store our data and provide next generation service such as Federated access makes this all the more essential.

This does not mean that non-cloud methods and repositories do not benefit from this type of organization. These relationships are just as important when considering ERP, LDAP and other "classic" Enterprise systems as I have referenced earlier in this article.  The organization of this data is still among the leading determinants in the choice of both ERP and Identity Management systems. It is my hope that in defining and expanding this framework in terms of Pre-, Dynamic, Interrogative and Post Identity stages (PDIP) that we can find a way to address all types of Identities in all possible systems.

The Real Time Myth

I was talking to a colleague last week and the topic of real time provisioning came up.  This has always been a bit of an issue with me due to the use of the term "real time"  I've almost always found that by the time we discuss what is involved in the act of provisioning and what the requirements really are, it is impossible to have this happen in "real time".  The fact is provisioning takes time.  Always has, always will.  Writing the information to your authoritative store takes a certain amount of time.  As does provisioning to LDAP.  We know it takes at least 15 minutes for AD to begin replication, and regardless of type of Directory Service used, it takes time to replicate in an international setting.

In my experience most organizations are more concerned with improving performance over the old methodology and getting initial provisioning to happen in less that a day.  There's nothing that irritates a manager more than having to sit around and wait for the new person's accounts to be created.  If we can get that time period down to a reasonable wait, hopefully to about the time it takes to fill out the remaining new hire paperwork, tour the facility, get the briefing from HR and have that welcoming cup of coffee, we will have made progress.

In the best of all possible worlds, provisioning should have already been started as soon as HR receives a signed offer letter.  Creating essential accounts in a a disabled state gets a lot of the heavy lifting done and front loads the whole process. This way all that has to be done is wait for the start date to occur and then enable accounts via a regularly scheduled work flow. However, I recognize that even creating disabled, locked accounts poses something of a risk so it will not be for all organizations. 

In the end careful analysis of current state, target state environments is called for along with a thorough examination of compliance, legal and best practices as they relate to the organization's needs.

SELECTing from the Identity Store

Now I don't know about you, but I've always had some issues with looking up entries in the NetWeaver Identity Management Identity Store. I know there are built in scripting functions like uIS_Get, uIS_GetValue, uIS_sGet, uIS_sGetValue, etc, but they've just never worked well for me. So to compensate, I've developed my own methodology for searching and retrieving items from the Identity Store.

The basic use case is this: The Identity Management solution needs to do a look up between an incoming data feed and the Identity store. The basic idea is that if the value from the feed and the value from the Identity Store match then the entries match and updating/provisioning can proceed as directed by workflow. I'm sure you can imagine other use cases, looking up managers, phone numbers, and other frequently used attributes.

The feed processing job will use a script to evaluate the match. Most likely it will pass MSKEYVALUE but could also use some other unique attribute in the feed.

The first thing that is needed is to determine the MSKEY, if any, for the entry to be worked with. To this end, I created the following query which will be implemented by NW IDM's uSelect function, which can be used in a Provisioning Job or Reconciliation task. Following best practices for NetWeaver Identity Manager, I am using the JAVA engine and therefore JavaScript in this example.

//Create an uppercase version of Par for checking against the SEARCHVALUE
uPar = Par.toUpperCase();

MSKEYQuery = "select mskey from mxiv_sentries where (searchvalue = '" + uPar + "')";
MSKEYResult = UserFunc.uSelect(MSKEYQuery);

You'll notice one of the first things we need to do is make sure we access the searchvalue correctly. Elements in this column always have their text elements stored in Uppercase, so we need to make sure that for the purposes of searching, we have an uppercase value handy. The results of this query are stored in a variable called MSKEYResult. Now that this information is available, we can now search for needed values related to this entry.

EmployeeNumQuery = "select avalue from mxiv_sentries where (mskey=" + MSKEYResult + ") and (AttrName='HR_EMPNUM)";
EmployeeNumResult = UserFunc.uSelect(EmployeeNumQuery );

With this query I can now look for a specific attribute value for a specific user and store it in a variable. At this point we should plan on returning a more nicely formatted version of the attribute so we will return aValue rather than SearchValue which is the value for the attribute as it entered into and subsequently processed by NW IDM for use in screen output, reports, emails, etc. In this example we are returning the user's Employee number.

This process might also include another query to do a count of returned Employee Numbers to protect against potential "dirty data" entries (multiple identities for the user or to many users with the same name.) If this scenario occurs more detailed searching, involving more attributes might be needed.

Note: I don't necessarily claim that this is the best or most efficient methodology for accessing this information. All I know is that it works for me and the way that I think / process information. If anyone has ideas on making this better or properly using the embedded functions listed above, I'd love to hear about it.

A New Whitepaper is born

I'm pleased to announce that Business Trends Quarterly has just published SECUDE Global Consulting's latest white paper! The white paper is called Strategies for Creating an Authoritative Store. I think you'll find that it meshes with several topics I've discussed in this blog and on SECUDE's IdM Blog as well.

To Virtual Directory or not To Virtual Directory, that is the question.

James McGovern was kind enough to cue me into this posting from Jackson Shaw. Jackson certainly knows his way around the Metadirectory space and is one of the smarter people I've encountered in the IdM space.

I'm a big fan of Virtual Directories from my days at MaXware and I absolutely believe that under the correct circumstances, they are a tool without equal for real time data consolidation and search, particularly when there are multiple data formats involved.

Which brings me to my point... Jackson states:

"Yes, absolutely. I think the industry will move away from a technology solution to a product solution over time. Given the "buzz" about this I am sure we will see this happen in the near-term. I certainly do not want to sell a virtual directory "product" but I do see how adding that capability to various Quest products would solve some very interesting business problems that our customers have."

I'm not sure what we'd want to move away from here. I've noticed over the years that most of the big players in IdM have had something very close to a Virtual Directory or something with lite Virtual Directory functionality and these companies have recently gone out of their way to go full steam ahead (SUN, Oracle) with this functionality. I seem to recall looking at some of the high level architectures for Access Management products and saying to myself, "gee this look like a Virtual Directory..." Given this I've also seen examples in my time where adding a Virtual Directory to an established product has solved problems of look-up, authentication and access, so I wonder why this would not be a good tool.

I've said it before and I'm sure I'll say it again, Virtual Directories, Metadirectories and even Identity Stores are merely tools. I don't think that anyone should say a tool is not fit for the job until requirements have been gathered and a competent architect had started the design process. Even then, good arguments can be made for all schools of thought. At MaXware, we commonly took turns coming up with pro and con Metadirectory and Virtual Directory arguments for all of our customers so that we could be ready for anything. These discussions always benefited our engineers and even the sales team as we looked at solutions to customer's problems.

One of the great things about this field is that there are so many great tools and people using them that there's never an end to the discussion, which I'm sure we'll have again, and again, and again and...