Access Denied: Creating New UPN Suffixes

Following prevailing style, we gave our primary domain the same name as our DNS name on the Internet (e.g., acme.com). Does this approach expose our user accounts to greater risk because attackers can easily guess the domain name for user accounts (e.g., acme.com in [email protected])?

Risk is subjective. The security through obscurity approach can make life a little more difficult not only for an attacker but also for administrators and users. Using hard-to-remember names and nonstandard configurations to confuse an attacker can backfire and cause legitimate users to practice bad security, such as writing down usernames and passwords. Therefore, I support the general consensus of the security community that security through obscurity is a bad approach. Usernames and user principal name (UPN) suffixes aren't supposed to be secret. The password is the secret. Obfuscating usernames and UPN suffixes doesn't adequately compensate for weak passwords. You need to base your security on real controls, such as password requirements and an account-lockout policy.

That said, you can create different UPN suffixes for users to log on with. First, open the Microsoft Management Console (MMC) Active Directory Domains and Trusts snap-in. Alternative UPN suffixes are available to the entire forest, so right-click the root node (Active Directory Domains and Trusts) in the treeview pane, then select Properties to open the forest's Properties window. Select the UPN Suffixes tab as Figure 2 shows, enter your new suffix (e.g., jupiter) in the Alternative UPN suffixes field, then click Add. Close the Properties window. Open the MMC Active Directory Users and Computers snap-in, and open the Properties window of a user to whom you want to assign the new suffix. Select the Account tab, then select the new suffix from the drop-down list. User@acme.com becomes user@jupiter. The user's pre­Windows 2000 domain name, which you specified when you created the domain, remains acmeusername.