I was having a conversation the other day with an IT security team member at a friend's company. He was talking about some IdM processes and how it was odd that an error occured in the provisioning system. He and I have had a few conversations about the consistency of the directories in use and how that could be a problem in his environment. In addition, there have been reports of tools in use that cannot understand organizational unit structure. That's why the current implementation of Active Directory is using such a flat model for the users even though the single domain design/multiple line of business business model (distributed IT aligned with line of business) they have just screams that it should be a more delegated model.
Because the current policies and processes in use have no provision for the removal of accounts, the current lifecycle includes a disabling process (I mean that figuratively as well as literally) where the electronic identity is disabled vs. being removed from the directory store. Presumably, this is because of some legal requirement, but he has not been able to confirm that yet. The company currently employs a system where every consumer of the electronic systems are represented by a unique identity number. This is still fairly new to the company, but every warm body that has access to a corporate computer asset has been issued one and uses it for one access or another. Most users are forced to use at least two identities but thankfully there is a password synchronization mechanism in use that at least helps reduce some of the help desk calls.
The issue he was describing was that of a user, Jane Smythe that had worked at the company as a full time employee. She left and came back as a contractor. She left again. Then another Jane Smythe came to work in that same department for the same manager. Then the original Jane Smythe came back to work as a contractor again (really, HR should get a handle on retention!) When the original Jane Smythe left and came back, the same unique numerical id was assigned. Well, not each time, only when in the same role (contractor vs. FTE.) What's wrong with that, you ask?
Perfectly normal account lifecycle scenario from what I can see too. However, because this company provisions the accounts in Active Directory using a distinguished name that includes the user's first name and last name, there was a collision when the administrator tried to re-animate the original Jane Smythe account. That's because ADUC and the way our MIIS system is configured, builds the distinguished name using the displayname value. That makes the (R)DN look like this:
cn=Smythe\, Jane,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com
The problem of course is that there can be only one cn=Smythe\, Jane in that relative path. You could have additional cn=Smythe\, Jane 's but they'd have to be in some other cn or ou. In this organization, you would also have a problem if you tried to disable the electronic identity because the user id's are put in the same container for neatness. Distinguished names would collide if that happened.
What's the solution? Remember how I told you that every person with computer resource access is given a unique electronic identity that they use to logon to the network? The solution is to create the electronic identities with the cn equal to 'uniqueElectronicIdentity'. For example, instead of using
cn=Smythe\, Jane,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com
you would use
cn=12345678,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com
If you use this system, then when a user is moved between containers and organizational units, there won't be any collisions as long as you follow that formula. But as a best practice, let's not stop there. Ever been tasked to integrate an application that uses LDAP calls to identify and authenticate users? Ever want to use Active Directory for that task? If so, then setting the cn this way is almost a requirement.
In most environments I've seen, the distinguished name of the users follows no particular scheme. Often this is just because Windows administrators historically have not had to worry about that value. That was the domain of LDAP administrators. Instead, users are only concerned about their "pre-Windows 2000 logon name" a.k.a samaccountname. When LDAP and Windows collided in Active Directory, administrators typically weren't interested. Over time, this becomes more of an issue.
The problem is that if you don't make these consistent, then unless the application was written to search for user information in an Active Directory you'll have to instruct the user to logon with a credential like this
cn=Smythe\, Jane
and as an added inconvenience, you won't be able to move the user objects around in the directory for management purposes. That's very restrictive in my opinion!
Since the user is already conditioned to know themselves as "1234562" when they logon to Windows, it makes sense to make their LDAP logon name the same right? Right. If you make the cn the same as the samaccountname then by default the distinguishedname will be the same as well.
But wait there's more....
What about their user principal name? Should the user have a different value for that as well? I don't think so. In fact, in older versions of Exchange, you would have issues with Outlook Web Access if the samaccountname and upn value left hand side were different. If you also didn't have the mailnickname match one of the proxy addresses, then you had problems.
The easiest solution to the problem my friend sees is to provision your security principals so that the samaccountname, mailnickname, cn, and left hand side of the user principal name are the same value. Making these four attributes the same unique id will result in no collisions, easier integration with LDAP applications, less confusion for users, and a more consistent directory for your developers. I didn't mention that earlier, but you'll have a much easier time programatically managing and reporting on your Active Directory if you make your directory consistent.
If anyone's interested, I'm sure I can blog something about how to go about making an existing directory consistent along these lines. I'm interested if anyone sees anything different than I've written about. But I'm sure I'll see this same behavior many more times in my career. History does repeat itself.