60

I'm trying to troubleshoot an obscure authentication error and need some background information.

  • Is there any difference between how Windows (and programs like Outlook) process DOMAIN\username and username@domain.local?

  • What are the proper terms for these two username formats?

  • Edit: In particular, are there any differences in how Windows authenticates the two username formats?

StackzOfZtuff
  • 1,754
  • 12
  • 21
Josh Kelley
  • 963
  • 1
  • 7
  • 17

4 Answers4

48

Assuming you have an Active Directory environment:

I believe the backslash format DOMAIN\USERNAME will search domain DOMAIN for a user object whose SAM Account Name is USERNAME.

The UPN format username@domain will search the forest for a user object whose User Principle Name is username@domain.

Now, normally a user account with a SAM Account Name of USERNAME has a UPN of USERNAME@DOMAIN, so either format should locate the same account, at least provided the AD is fully functional. If there are replication issues or you can't reach a global catalog, the backslash format might work in cases where the UPN format will fail. There may also be (abnormal) conditions under which the reverse applies - perhaps if no domain controllers can be reached for the target domain, for example.

However: you can also explicitly configure a user account to have a UPN whose username component is different from the SAM Account Name and whose domain component is different from the name of the domain.

The Account tab in Active Directory Users and Computers shows the UPN under the heading "User logon name" and the SAM Account Name under the heading "User logon name (pre-Windows 2000)". So if you are having trouble with particular users I would check that there aren't any discrepancies between these two values.

Note: it is possible that additional searches are done if the search I describe above doesn't find the user account. For example, perhaps the specified username is converted into the other format (in the obvious way) to see if that produces a match. There must also be some procedure for finding accounts in trusted domains that are not in the forest. I don't know where/whether the exact behaviour is documented.

Just to further complicate troubleshooting, Windows clients will by default cache information about successful interactive logons, so that you may be able to log into the same client even if your user account information in the Active Directory is inaccessible.

Harry Johnston
  • 5,875
  • 4
  • 35
  • 52
  • 2
    I like this answer better than mine. Nicely done. – Ryan Ries Mar 20 '12 at 12:33
  • If you're querying AD with ldapsearch you'll find the down-level login name in the msDS-PrincipalName attribute, which you need to request explicitly since it's an "operational attribute". – Eric Feb 14 '17 at 18:35
27

I may get corrected on this, but there's not really much of a difference.

Domain\User is the "old" logon format, called down-level logon name. Also known by the names SAMAccountName and pre-Windows 2000 logon name.

User@Domain.com is a UPN - User Principal Name. It's the "preferred", newer logon format. It's an Internet-style login name, that should map to the user email name. (Ref. at MSDN)

The reasons for logging in with UPNs I think are mostly cosmetic - they hypothetically give your users in your company a single name with which to log on to their workstations which can also act as their corporate email address.

edit: More elaboration - another advantage of UPNs is that you can setup more than one valid UPN for your users to logon with. Again, largely cosmetic. But the important thing is that not all applications are compatible with UPNs, and that might be what you're experiencing.

edit #2: I like Harry Johnston's answer below about the two slightly different search formats performed. It makes sense, and most importantly it might actually explain your problem. :)

PatrikN
  • 155
  • 6
Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 3
    There is no mention of UPNs in RFC 822, "Standard for the format of ARPA Internet text messages". UPNs are an Active Directory "invention" that binds together Kerberos and LDAP information in order to provide Single-Sign-On services (SSO) across a domain (or "realm") of associated computer systems. – adaptr Mar 19 '12 at 14:46
  • Ah, sorry -- I was getting my info from http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx ... I'll edit my answer if I find the right one. – Ryan Ries Mar 19 '12 at 16:28
  • 1
    @adaptr RFC 822 was obsoleted 10 years ago - see rfc 2822. – Jim B Mar 19 '12 at 16:55
  • @Ryan, I think the Active Directory is searched in different ways for the two different formats - see my answer. – Harry Johnston Mar 20 '12 at 03:29
  • @JimB I think you'll find that no, RFC822 is NOT obsolete; both RFC2822 and the current RFC 5322 refer to it, as well as a multitude of other mail- and content-related RFCs (5321 for starters). – adaptr Mar 20 '12 at 09:11
  • 1
    perhaps you have a different definition of "obsolete" then the rest of the world, both 2822 and 5322 refer to 822 as obsolete, from 5322: "This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs" – Jim B Mar 20 '12 at 16:05
  • The "old logon format" is also called a "Down-level logon name" – Eric Feb 10 '17 at 16:28
5

The slashed format (DOMAIN\username) is actually the NetBIOS equivalent of the domain's DNS name (domain.mycompany.local).
The NetBIOS name is limited to 15 characters and cannot contain dots, underscores etc.

This page explains in more detail:

As mentioned by @harry-johnston above, its really just the old NT4 and Windows 2000 compatible format but it seems to have stuck as a favorite format (its less to type!). Eventually, support for the legacy format may go from Windows.

It's probably a good idea to get users into the habit of using the UPN format as it also avoids issues where they are having problems to log in to a PC with their username and don't realise that the Windows login box has defaulted to the local PC domain (eg. pc01\fred) or when they connect to different remote desktop hosts and have to remember to include the domain as well as their username because the Remote Desktop Client may cache another previously used domain name. Sticking to the UPN format every time just makes for less support calls in the end.

Daniel
  • 6,780
  • 5
  • 31
  • 60
Trichromic
  • 89
  • 1
  • 2
  • 6
  • It's unlikely that the "old format" would go away, as that's still in use for non-AD environments. (As `Host\username` of course, no domains without AD) – MSalters Jul 31 '18 at 08:56
0

There is definelty a difference between those two only 99% of the users won't have a problem with it. I will try to explain the difference and when such a problem may occure.

If you use domain\username when you try to access a fileshare then DNS will first resolve the domain and then check the username. If you use username@domain then it will directly check if the user is on the ACL (access control list ) and has access. So what does it matter you might think... well, picture this:

1 domain controller with name DC01 and all the clients get dns and are in this domain. You want to migrate and someone added another server with the same name. The latter server will also become a DC so the local SAM won't be used anymore and also has a file share.

When the users will connect to the server they are prompted for credentials. If you use domain\username it will first check the current domain instead of using the new domain and we used accounts from the new domain on the file share. So once it has found the current dc and checks the username it can't be found. ( even if the username and password are found and are exact the same it won't work as it won't use the username to verify if it is allowed in the ACL but it will use the SID. The sid will be created at the user creation time in AD and you have a change of 1 in a trillion that it is the same, great huh:-P ).

Nanne
  • 602
  • 2
  • 8
  • 26
Andre Boom
  • 17
  • 2
  • -1. I really can't follow what you're saying here. Where you say "When the users will connect to the server" which server do you mean, the old DC01, or the new DC01? What happened to the old DC01 anyway, was it decommissioned, renamed, removed from the domain, or what? Was it properly demoted first? What do you mean by "new domain", since you didn't describe the creation of a new domain at any point? If you use "domain\username" it *should* always search the domain you explicitly specified, are you describing a case where it doesn't? – Harry Johnston Jul 15 '13 at 22:07
  • Also, "it won't use the username to verify if it is allowed in the ACL but it will use the SID" is the expected behaviour - it should always do that, regardless of whether you use domain\username or username@domain. Are you talking about a case where there are two domains with the same name, or something similarly pathological? – Harry Johnston Jul 15 '13 at 22:08
  • **DNS will first resolve the domain and then check the username**. DNS will check the username? What? – bahrep Jun 25 '15 at 13:18