MG

With the advent of Active Directory, the old school Security Accounts Manager (SAM) account names are almost a thing of the past, not that anyone got the memo. Most people still authenticate to their domain using their SAM account name, which is usually DOMAIN\username; with DOMAIN being the NETBIOS name for the AD domain.

While this is still (as previously mentioned) widely used and acceptable, in my opinion there is a more appealing method for having users log into their accounts on Active Directory networks, and that is using the User Principal Name (or UPN) suffix. A UPN will allow a user to specify their username@upnsuffix to log into their account, and you can now see why this is appealing for some users. If your domain name does not live in the global DNS namespace, you probably have an Active Directory domain utilizing a .local suffix, or a sub-domain of a domain that does live in the global DNS namespace like corp.mydomain.com. By default, the UPN that is added (and thus shows up in the Account tab of an Active Directory user’s properties) is the fully qualified domain name (FQDN) of your Active Directory domain. This can be quite a task to type, if, for instance your FQDN is corp.mydomain.com. In my opinion this is one of the main reasons that a down-level SAM account name is still used to log into AD domains most of the time today. But what if you could add the UPN suffix of your internet facing domain name, the domain name that your users are assigned for their e-mail addresses to the list of UPN suffixes that they can use to log into the network?

As an administrator, you will know that each user will at least remember their e-mail address, so they can share it with co-workers or colleagues outside the company (and the GAL). Allowing a user to log on with their e-mail address gives your users less to remember and in the end can even save you a support call if they need to log in to OWA or Outlook on their laptop configured with Outlook Anywhere. The reason for this is that they are logging into their domain and will sooner remember to type in their e-mail address than remember the NETBIOS name of the domain they use to log into the corporate network.

Now to answer your question before you ask it, you can add any UPN suffix you want inside your Active Directory forest, you will naturally want to choose something your users can relate to, but you don’t necessarily need to follow that advice either. Once you add a UPN suffix to your forest, you simply need to navigate to the Account tab on a user’s properties in AD and change the drop down in the User logon name: section to the UPN suffix that you’ve just added to the forest. You will recognize the UPN suffix because it looks like the end of an e-mail address. This can also be scripted using the DS commands (more on those in later posts), in case you want to change the UPN suffixes for accounts already present in Active Directory to allow log on with your newly created UPN suffix.

So now, I’m sure you are asking yourself “Where is it that I add these UPN suffixes? Tell me already!”

You can add a UPN suffix to your forest by opening the Active Directory Domains and Trusts snap-in, right clicking the root of the snap-in which is Active Directory Domains and Trusts and clicking on Properties. From there you will see a UPN Suffixes tab, and it is here where you can add the new UPN suffix to be used in your forest (and domains within the forest).

If you only have one domain controller (shame on you, there should be at least two DCs in each AD domain), but if you do only have the one, you should be able to make the change instantaneously to your accounts. Otherwise, you will need to either force replication using the repadmin utility, or wait long enough for the DCs to replicate between each other.

Now your users will be able to log into the domain using username@mycompany.com instead of username@corp.mycompany.com or username@mycompany.local or MYCOMPANY\username, and you want this because a user will sooner remember his e-mail address than any of the latter example account names. However, just because they can log in with one does not mean they can’t log in with the others, as long as the UPN suffixes are there and/or the NETBIOS name is correct, the user should be able to log into the network using any of the previous account names. Correction: Once the UPN suffix for an account has been set, the user will only be able to authenticate using that UPN suffix, the domain NETBIOS name followed by a backslash and the username will also continue to work (since that will provide the server with the old SAM account name).