This basic article is intended to provide a background in different Active Directory user name and domain name formats and how they are used by applications for basic and integrated authentication process within Windows Server.

The guidance provided throughout is targeted towards working with Microsoft Lync, Exchange, and third-party solutions or applications which support direct registration and authentication to these Microsoft UC platforms.

In most environments registration is as simple as typing in a SIP Address, username, and password which is the same information that native Lync and Outlook clients will leverage for connectivity and authentication. But in some more complex environments it may be necessary to known more specific information about the user accounts used to authenticate clients as these Active Directory deployments can often times use a variety of mismatched user name and domain name formats.

Thus it is beneficial to understand the following concepts in order to identify what is often simply a failure to register due to incorrect entering account credential information.  The specifications and limitations of these formats are detailed in this TechNet article.

Domain Names

Active Directory supports two separate types of domain name formats since it’s introduction into Windows Server 2000.

Legacy Domain Name

The Legacy Domain Name parameter, which is also commonly referred to as the NetBIOS Domain Name, is a carryover from Windows NT and is limited to 15-characters. (NetBIOS names are 16-characters in length but the last character is hidden and is used to identify the name record type.) This is the value commonly used with the DOMAIN\username format when signing into various Microsoft applications and even though it is not case-sensitive this string is traditionally shown all in uppercase as a matter of good practice.  Although it is considered a legacy format it is still the most prevalently used format today for user authentication.

DNS Domain Name

The DNS Domain Name parameter was added in Active Directory with the release of Windows 2000 and supports up to 24-characters for the hostname portion, but the Fully Qualified Domain Name can be much longer (e.g. subdomain1.subdomain2.domain.com).

As indicated in the screenshots above the sample environment is using a legacy domain name that is shorter than 15 characters so the same string can be used for both formats. This is ideal and is the general best practice used in the field; to select shorter domain names when designing an Active Directory forest so that authentication can be simplified across Microsoft and third-party applications which may use one or both formats. Unfortunately this is not always the case as mergers and divestitures over time can lead to more complicated Active Directory environments. Although newer versions of Windows Server does allow for these domain names to be changed post-deployment this is almost never actually attempted in the field due to the massive impact on the entire environment.

Alternatively the following screenshot shows an AD domain in which the two type use entirely different values (verylongdnsdomainname.com vs. SHORTNAME).

User Names

Just as with domain names there are two different formats in Active Directory for storing user names:

Legacy User Logon Name

The User Logon Name (Pre-Windows 2000) is the legacy format from Windows NT and is often referred to using the raw attribute name of sAMAccountName. This field is limited to a maximum of 20 characters and is used in conjunction with the legacy (or NetBIOS) domain name.

User Logon Name

The User Logon Name is a the newer username format which is often mistakenly referred to as the User Principal Name (UPN).  That term is used to indicate the entire user name and domain name format.comprised of the User Logon Name and the UPN Suffix which is shown in the drop-down menu in the screenshot below.

Just as with domain name formats the user names can also be unique. Depending on the naming conventions used in the directory it is more common to have long user names truncated to 20 characters in the legacy user name field. In the complex example shown below a user name of 36 characters (e.g. abcdefghijklmnopqrstuvwxyz0123456789) is automatically truncated to only 20 characters in the legacy field.

Authentication Formats

Once the user name and domain name formats are clearly identified then they are assembled into pairs in specific formats to be used for authentication. The ubiquitous NTLM authentication used in Windows Server can support two different formats.

Legacy

The legacy format requires that the Legacy (NetBIOS) Domain Name value is used with the legacy User Logon Name (sAMAccountName).

Simple Example: SCHERTZ\jeff

Complex Example: SHORTNAME\abcdefghijklmnopqrst

User Principal Name

The newer User Principal Name format is comprised of the User Logon Name (not the legacy sAMAccountName) and the UPN Suffix assigned to the specific user account.

Simple Example: jeff@schertz.local

Complex Example: abcdefghijklmnopqrstuvwxyz0123456789@verylongdnsdomainname.com

It is important to understand that although the DNS Domain Name is the default assigned UPN Suffix for all user accounts created in the domain this value can be changed and customized in Active Directory. So in the event that the Active Directory namespace (e.g. schertz.local) does not match the Lync SIP Domain namespace (e.g. mslync.net) it is still possible to provide a simplified user sign-in experience by defining an additional UPN suffix which matches the SIP domain and then assigning that suffix to all desired user accounts.

• The following screenshot shows how an additional UPN suffix (e.g. mslync.net) can be added to the forest using the Active Directory Domains and Trusts application.

• Once this is defined then it will appear as a choice for all user accounts in the domain and can be selected in the Active Directory Users and Computer utility.

In the example above it would be possible to provide the same ‘string’ to users as both their SIP Address and User Principal Name even when separate namespaces are used between AD and Lync.  This approach allows Lync users to enter the same information for both their Sign-In Address and their User Name.  In fact in a recent Cumulative Update for the Lync client the sign-in behavior was changed to actually assume that the AD user name is the same as the SIP address during the first authentication attempt, and then if that fails (due to unique values being used for both) then the User Name field will be presented to the user to fill-out for a second attempt.  This change in behavior makes the client more ‘cloud’ friendly as the default configuration for Office 365 and most hosted deployments of Lync will set these fields to the same values.

Hopefully this post has provided some clarity between the different user name formats and in turn help reduce confusion when signing.  When the credentials are known to be accurate and in the proper format this make issues much easier to troubleshoot as it takes the uncertainty of out of equation.