This should be well known at this point but doesn’t appear to be as I continue to see questions and problems around this….
There are multiple formats of a userid that can be used for authentication depending on the type of authentication.
For most authentications you can use either the NT format which is Domain\SAMAccountName or the user principal name which is somestring@someotherstring where it is usually userid@domain.com.
The NT ID or legacy format can omit the Domain component if the ID is local, for instance if you are connecting to a domain controller that has the ID joe then you can just say joe when connecting to it,. If you are connecting to a member server in the domain though, you need to specify domain\joe.
In AD the user principal name has to follow RFC822 formatting (i.e. email address) and the default is SAMAccountName@useraccountdomainDNSFormat so joe in the joeware.net domain would have a default UPN of joe@joeware.net, joe in the child.jake.com domain would be joe@child.jake.com. ADAM doesn’t require that formating and in fact it could just be somestring such as joe, the only requirement is that it is unique.
If you are using LDAP binding you have another format. The additional format is the distinguished name which is something like cn=joe,cn=coolusers,dc=joe,dc=com. This is the most familiar format for LDAP programs and directories. It is the format I don’t recommend most folks use because it assumes that your DN isn’t going to change. Possibly in older directories this isn’t going to happen, but moving IDs around is very common in Active Directory and you should account for it. This is EXTREMELY easy to do, use one of the other formats. I don’t know how many apps have broken because of some stupidity based on the bind ID being a DN. Either the app breaks when the ID is moved or the app owners know it is going to move and so they make a change in their app for the new DN and the app can’t handle the DN for some reason [1].
The UPN is the most flexible format because if you set arbitrary UPNs even a user changing domains won’t impact the userid. Just because your company AD is called widget.com doesn’t mean my UPN there has to be joe@widget.com, it could be joe@users. That way when widget.com spins up a new domain called skunkworks and my ID gets moved to that domain I don’t need to start type joe@skunkworks.widget.com instead, I can continuee typing joe@users. I mean you don’t have to change from joe@widget.com to joe@skunkworks.widget.com, a user in skunkworks could keep the ID joe@widget.com but it might be a little confusing.
  joeÂ
Â
[1] I once saw an app break because it assumed IDs would be no deeper than 3 levels deep in a container hierarchy below the domain components…
Â
