Posted by BPuhl on March 16, 2008
Active Directory can provide unique identity information within it’s scope. But sometimes, usually when applications are being developed, the identity requirements are a little bit more than what AD can provide.
For example, in your environment, do you have any identifier for a user, which you can guarantee is unique, and never reused throughout the lifetime of the enterprise?
This can be a hard question, because AD doesn’t (and arguably, shouldn’t) provide this kind of uniqueness in a way which is easily consumable by applications. Internally at Microsoft, quite a while ago, it was determined that a persons employeeID number was going to be the piece of identity information which is guaranteed to be unique at any given point in time, and never reused over any span of time.
Interestingly, I recently had to write an Identity FAQ type of document for our application team explaining this little bit of trivia. It seems that in the absence of this knowledge, they had simply assumed that a persons user name (samAccountName) was guaranteed to be unique, and hadn’t considered the impact of whether it could be reused. This has led to some interesting help desk calls, for example:
User Robert (call me Bob) Puhl works for Microsoft from 1995-1999 – user name, BPuhl
User Brian Puhl (me), gets hired into Microsoft in 2001 – user name BPuhl
When Brian goes to access several web applications, guess who’s information and history in that application context are already there? Yup, Brian meet Bob.
Much of the time, we’ll think about the need for uniqueness within the environment “now”. If you’ve only got a single domain, then you might get away with samAccountName. But if you fail to consider the time factor, then reusing common attributes like user name, can become nearly equivalent to reusing SIDs.