Which field to use when authenticating against Active Directory?

Active Directory user objects include a number of fields that can be considered an identifier. The following lists some of these with their label in ADUC and their attribute name:

• Full Name - cn
• ? - name
• User sAMAccountName logon - sAMAccountName
• User UPN Logon: userPrincipalName
• ? - distinguishedName

I'm trying to get our developers to standardise on using only one of these when writing custom code that authenticates against AD - trouble is I'm not sure which is the "right" one, or if different ones are the right one in different circumstances. I'm not even sure any of the above fields should be used!

Has anyone else picked one to use consistanly, and what influenced you in that decision? Any documentation that clarifies the issue?

Solution 1:

A CN (common name) is no good for logging in, because a CN alone does not uniquely identify a user. I could have a

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

and I could also have a

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

A user's CN is also an RDN (relative distinguished name.) They have the same CN, but different DNs. You might notice that you run into problems if you have two people in your organization named Ryan Ries, and you'll have to make the SamAccountName for the second one something like rries2.

A DN (distinguished name) isn't good to log in with, because who wants to log in to a system with a username like CN=ryan,OU=Texas,DC=brazzers,DC=com ? While using a DN does uniquely and definitively identify a user, it's annoying to have to type out. It's the same kind of concept between relative paths and absolute paths on a file system. It also implies that you know exactly where in the directory structure the object is located without having to search for it. Which you often do not.

This is called Ambiguous Name Resolution (ANR) - searching the directory for a user when you do not have his or her distinguished name.

UPN (User principal name) is pretty good because they look like email addresses, they can be the same as the user's corporate email address, they're easy to remember, and they are preferred to log in with because the name will be searched for in the local domain first, before searching for it in the forest.

Microsoft says: The point of the UPN is to consolidate the email and logon namespaces so that the user need only remember a single name. The UPN is the preferred logon name for Windows users. Users should be using their UPNs to log on to the domain. At logon time, a UPN is validated first by searching the local domain, then the global catalog. Failure to find the UPN in the local domain or the GC results in rejection of the UPN. The UPN can be assigned, but is not required, when the user account is created.

Keep in mind that "not required" bit at the end when designing your applications.

SamAccountName is also good because SamAccountName needs to be unique for everyone in the domain (but not the forest.) In addition, SamAccountNames are short. Most people log in with SamAccountNames, even though they do not uniquely identify you in an AD forest, which is why you have to specify a domain name to go along with your SamAccountName so that the system knows what domain you are trying to log in to.

Here's some great documentation on the issue for further reading:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx

Solution 2:

If you are referring to username as something someone would type to login, I would recommend either sAMAccountName, which would be unique in combination with a domain name, or the userPrincipalName, which would be unique within a forest.

As far as username as unique identifier, Windows uses the SID for all access control entries, and provides a full set of methods for translating to SIDs from user names. SIDs match the user metaphor for the lifetime of an account, as renames and moves within a domain have no effect, but deleting and re-creating results in a new SID.

To that end, I would call LookupAccountName, which takes a string representing the username, and returns the sAMAccountName, the SID and the domain name of the domain the user was found in.

The user can then use any syntax supported by windows to log in, and no additional training is required.