Steffo's Echolot : Weblog

Saturday Apr 14, 2007

Weird modeling in X.500/LDAP and ActiveDirectory: cn in distinguished names

Over the last years I came across some common issues on the modeling in LDAP and ActiveDirectory, well, more on AD than LDAP. The first issue is on distinguished names.

I never understood why so many AD implementation use the cn rather than uid or employeeNumber as part of the distinguished name. The problem is that if there are employees with common common names like 'John Smith' the dn's look like

dn: cn=John Smith,ou=People,dc=company,dc=com
dn: cn=John J Smith,ou=People,dc=company,dc=com
dn: cn=John Smith 1,ou=People,dc=company,dc=com
dn: cn=John Smith 2,ou=People,dc=company,dc=com

This might not appear to be a problem from an LDAP perspective, but it is a problem from an identity management perspective. If John Smith gets married to Jane Miller and changes his name the key (dn) must be changed as well. Employee numbers don't change. Moreover, if the entries do not contain a company wide unique attribute at all it is difficult to tell whether 'jsmith5' on UNIX belongs to the same person as 'cn=John Smith 3' on LDAP/AD.

When an IDM is deployed, no enterprise infomation system can be anyl longer regarded as an island. Data quality is one major issue in identity management projects and improper naming convention do contribute this this issue.

Posted at 12:00AM Apr 14, 2007 by steffo in Identity Systems | Comments[4]

Comments:

Oh, you're a 404? The "whoami" in the upper left quadrant leads to a 404 page. Not good for someone writing about name services, is it? Anyway, thanks for your interesting blog. R.

Posted by Rainer on April 14, 2007 at 10:23 PM CEST #

While I agree with you that the naming convention chosen for LDAP entries is an important part of Identity Management, it is a common mistake to consider CN as being unique, as it's not a single valued attribute. DNs are not names that should be for human consumption. Since the raise of the Internet over ISO communications systems (x.400, x.500), I haven't seen a single business card with a DN on it (more than 12 years ago, I used to have my DN like x.400 address on my card : /C=FR/O=SUN/OU=PEOPLE/CN=LUDOVIC POITOU/). And should John Smith name change because he get married, its DN should not change, but the CN attribute part of its entry can have several values. cn=John Smith,ou-people,dc=company,dc=com objectclass: person cn: John Smith cn: John Smith-Miller ... Regards, Ludo.

Posted by Ludo on April 16, 2007 at 09:57 AM CEST #

Thanks for pointing out the 404. Apparantly it was caused by some relative link. Should work now.

Posted by 84.142.211.114 on April 16, 2007 at 11:00 AM CEST #

Hi Ludo, so if the cn changes after marriage, and the dn is not supposed to change, should cn be a part of dn?

Posted by Steffo on April 16, 2007 at 11:02 AM CEST #