1dent1ty cHa0s

For Active Directory and Exchange environments, this unassuming attribute can be the source of many headaches and without proper planning can cause the downfall of any IdM implementation.  I'm talking about the displayName attribute in Active Directory which is used by Exchange's Global Address List.  It's how you're known by others through email (and possibly IM) and few stop to consider the implications of implementing an Identity Management system on something both so critical and so trivial.  To make matters worse, AD does not enforce uniqueness on this attribute like it does the sAMAccountName (so AD doesn't care that there are twenty John Smith's)

Pre-IdM displayName

Prior to implementing any Identity Management, the displayName attribute lives it's lifecycle as a freeform text field.  While it's true that at the time of an object's creation it's inherited from the full name (cn, name or RDN), that is no longer the case afterwards.  Modifying someone's first name (givenName), last name (sn), or changing their Relative Distinguished Name (RDN) does not update or affect the displayName in any way [renaming through the UI will ask you to change the displayName, but that's a UI thing and doesn't happen automatically].  But, this is the guy that is seen in the GAL which is published across your entire enterprise!

In AD, it is entirely legal for the following User object to exist:

distinguishedName: CN=Sally Smith,OU=
cn|name: CN=Sally Smith (also the RDN)
givenName: Joe
sn: Smith
displayName: Mouse, Mickey

So, an AD Admin would see Sally Smith in ADUC, would find Joe Smith after looking at the object itself, and everyone else would know this person in the GAL as Mickey Mouse.  Any change to this identity is going to cause an impact to either the AD Admins or the people normally used to corresponding with Joe/Sally as Mickey.  So, you can imagine that by introducing an authoritative source from HR you can really cause some serious impacts.

IdM Impacts to displayName

As part of an MIIS implementation you could end up with any of the following variations.

• JOE SMITH - simple but HR always has all caps, annoying
• JOSEPH SMITH - legal name is Joseph, not "Joe"
• ALAN "JOE" SMITH - legal name is totally different than the nickname and few HR departments bother to capture nickname
• ALAN SMITHE - alternate spelling of the legal surname and no nickname present (my favorite)
• FRANCIS JOSEPH SMITH - person is only known as their middle name
• JOSEPH VON SMITH - nickname, middlename or multi-part last name?  Von Smith, or von Smith?
• MARY ANN SMITH - middlename or multi-part first name?

In all but the first case you can seriously impact GAL browsing by imposing data from an authoritative source.  Assuming you can join these objects correctly you're faced with what to do with the data you have from HR.

Legal Names

In most cases it should be safe to map the first and last names to the givenName and sn attributes respectively; that is, unless you have an application that relies on the data in these two attributes to uniquely identify you.  Since the displayName will not be automatically updated through this method it limits the impact to only these attributes.  However, in doing so what value have you brought to AD if the RDN and displayName are not derived from this information?  From this perspective, the only risk is manipulating the case of the names and not coming up with something entirely wrong.  Something so inconsequential as the case of a last name can be big coding obstacle trying to deal with "MCMAHN", "MACMAHON" and "MACKENZIE".  You try and explain to a senior exec why the spelling of their name has changed!

To Rename or Not Rename

Renaming the object, or changing it's RDN, is the next step.  If you want the object to be easily located in a group membership, or in an object listing from ADUC then it's a simple matter to have MIIS rename the object during provisioning; however, someone has to generate the name used in the RDN.  You must choose how to derive the RDN.  Impact wise, this mostly only impacts the AD Admins so there is less of an issue tying this directly to the legal names.

Changing the displayName

The last thing to consider is whether or not you will affect the displayName.   Just like the RDN, you need a method to generate or modify the attribute that will impact existing GAL users the least.  Here are some options to consider:

• No Change - you can decide to leave it alone and allow Exchange to "own" this attribute entirely
• Update on Legal Name Change - you may decide to leave it as is until a legal name change occurs (marriage, divorce, or witness protection); however once you've decided to change it you now have to generate it from data that is available to you
• Update All - you could decide to force an update of all displayNames to their legal versions.  This is much easier if you already have a nickname or preferred name stored for everyone and can use this value in your algorithms but it will have far reaching implications for the GAL

I find that in many cases it's prudent to flow whatever the existing value of givenName is from AD into the metaverse as a preferred name and use that in the calculations if it should differ from the legal first name.  If at all possible, getting a preferred name (should your organization allow for them) from HR or Exchange is preferable to overwriting everyone with their legal names.

GALSync

I recently implemented a custom GALSync solution where the displayName formats were different between forests (givenName sn, vs sn, givenName).  The process had to translate between the two formats which exposed the same issues we've been talking about.  The biggest issue here is knowing where to break multi-part names (two component names are easy) and at some point you just have to make an arbitrary decision as to which side to err on.  Generating a new displayName from data present was out of the question!

Recommendations

My recommendation is to approach this issue head-on and very early in your project.  You need to make everyone extra sure that very small issues like this one can kill an IdM project through unfavorable popular opinion.  No one will care what cool extensions you wrote or how many data sources you had to aggregate if no one can find recipients in the GAL any longer.  Ensure that someone will own the displayName attribute, be that HR through a formalized "preferred name" process, or Exchange whereby it's hands off for MIIS.

I tend to force the issue by requiring unique displayNames in all of my implementations.  This is because I derive the RDN/DN directly from the displayName; by enforcing uniqueness here I never have to worry about collisions when objects move between containers and there is no confusion in the GAL.  Remember, however, that neither AD or MIIS will enforce uniqueness on this value for you, you must do it through rules extensions.

In a bold move by Microsoft the retail pricing for the newly announced Identity Lifecycle Manager 2007 will be reduced from $25,000 per processor to $15,000 per server* further increasing the value proposition for both system integrators and companies looking for an Identity Management solution.

Licensing for the certificate and smart card mangement functionality added in ILM 2007 will be licensed separately using a per user CAL model with retail pricing at $25 per CAL. It is important to note that the purchasing of CAL's for ILM 2007 is only required if it is used to generate digital certificates and are not required for basic product functionality.

Microsoft has offered to extend a one-time license update to existing owners of MIIS 2003 - for details, visit the "How to Buy" page:



To bring this into perspective, an organization with 10,000 identities who had to purchase new hardware and software licensing to implement an entry level Identity Management solution based on ILM 2007, the estimated cost per user is less than $3 US (not including labor costs or certificate management). Adding digitial certificate management for all 10,000 identities would raise the cost per user to $28. For many organizations which already own licensing for SQL and Windows Server 2003 Enterprise, the cost drops to about $2 per user for the same sized company.

In a market where popular IdM solutions cost hundreds of thousands of dollars purchase, Microsoft is poised once again to provide a competitive product for an extremely attractive price tag. That means you can afford to send your staff to training!
* [edited on 2/19/07]

At the RSA 2007 keynote today titled "Anywhere Access", by Bill Gates and Craig Mundie it was announced that the successor to Microsoft's Identity Integration Server 2003 will be the new Identity Lifecycle Manager 2007 (ILM 2007). Look for ILM 2007 to replace MIIS 2003 in the May 2007 timeframe.

ILM 2007 builds on the successful MIIS 2003 platform and adds support for certificate and smart card management. For more information on ILM 2007, visit the product page here:

http://www.microsoft.com/ilm2007