Manage the UPN Suffix
User principal names (UPNs) may be used to ease the process of console or network logon in cases where users provide their logon names in the username@dns-domain format. UPN logon names complement Windows NT 4.0-era logons, which used the NetBIOS domain\username format. UPN logon names resemble e-mail
FIGURE 6-7
Selecting an appropriate UPN logon suffix
addresses and consist of the logon name portion and the UPN suffix portion, separated by the @ sign.
To keep things simple, a logon name using the Windows 2000 format and a username in Windows NT 4.0 may be the same, provided that the name satisfies both syntax requirements. By default, the UPN logon name is constructed based on the DNS domain name of the user account, but this may or may not be desirable in cases of deeply nested domains; for example, you wouldn't want your UPN logon name to have a "research.ca.west.flexecom.local" UPN suffix. When you create a new user account, you can manually choose the UPN suffix of any existing domain for your user account—the box, as shown in Figure 6-7, is populated automatically. To make it easier for users to enter their logon credentials, you can add your own UPN suffixes, in which case they will also show up in the list when you create a new account.
To add (or remove) a custom UPN suffix, you use the Active Directory Domains and Trusts console, right-click the root container in the tree pane (Active Directory Domains and Trusts node), and choose Properties in the context menu. After creating your UPN suffixes on the property page shown in Figure 6-8, you will be able to add these suffixes instead of those generated automatically based on the current and parent DNS domain names.
FIGURE 6-8
Adding a custom UPN suffix
Let's go back to the research.ca.west.flexecom.local domain and take a look at the suffixes that are available to Research domain users by default. In this example, Flexecom Corp. has a DNS domain registered on the Internet: flexecom.com. But the forest root domain in Active Directory is flexecom.local. This is done to keep external and internal namespaces separate, as per our discussion in previous chapters. If we add the Flexecom UPN suffix in the Active Directory Domains and Trusts console, the full listing of all available suffixes will be as follows:
■ research.ca.west.flexecom.local Research domain default suffix
■ ca.west.flexecom.local Parent domain suffix
■ west.flexecom.local Parent's parent domain suffix
■ flexecom.local Forest root domain suffix
■ flexecom Custom UPN suffix added for user convenience
In addition to making things simple for users, UPN suffixes also fit into the Microsoft Exchange Server infrastructure and can be used to integrate it with the AD infrastructure if external e-mail addresses do not use the same DNS domain names as the AD infrastructure.
Forest trusts complicate UPN management a bit. Within the same domain forest, UPN conflicts are eliminated, because all domain names are unique by design. When you set up a forest trust, because each of the forests was constructed and developed on its own, several types of conflicts may arise:
■ Identical DNS names If DNS domains weren't registered with the Internet authorities to ensure their uniqueness, it would be possible, although unlikely, that two distinct forests would opt to use the same private namespace, such as domain.local, in which case UPN suffixes would no longer uniquely identify a domain.
■ Identical NetBIOS names Like DNS names, NetBIOS domain names used in Windows NT 4.0-style logons may no longer be unique, matching more than one domain name in several forests.
■ Identical custom UPN suffixes If user naming conventions were identical in both forests, and by pure coincidence administrators added the same custom UPN suffix, logon names would no longer be unique.
■ Domain SID conflicts When you have one forest, SID conflicts are eliminated thanks to the RID Master. In two separate forests, it is possible, although not very likely, that SID sequences used when creating new domains would no longer be unique.
In the context of a single forest, the RID Master makes sure that there are no SID sequence conflicts, the Domain Naming Master makes sure that domain names are unique, and global catalog servers redirect logon requests to domain controllers responsible for authentication of particular user accounts. When you have two separate forests, with two separate sets of masters and a separate global catalog, you lose track of what is happening in the other domain. There is no way to ensure uniqueness and collaboration between these elements when you have two distinct infrastructures that are growing and developing on their own, without being aware of each other.
A mechanism called name suffix routing can be used to avoid conflicts and configure UPN and SPN suffix routing if these conflicts are present. (SPN stands for service principal name.) You can access this mechanism using the Active Directory Domains and Trusts console, on the Trusts tab of your forest root domain node, and then on the Name Suffix Routing tab in the forest trust properties. (Figure 6-9 shows this tab.)
Using name suffix routing, you can specify which forest root domain default or custom UPN suffixes should be routed to the external forest over the trust link. This will effectively limit the scope of authentication, depending on which UPN suffix is
FIGURE 6-9
Managing UPN suffix routing for external domains
used to log on. If you need to control routing of default UPN suffixes belonging to child domains in your forest, you can do that on the tab shown in Figure 6-10, which can be accessed by clicking the respective forest root suffix and then clicking the Edit button.
A UPN suffix routing list is compiled when you set up a forest trust relationship, and it is not updated automatically. All conflicting UPN suffixes will be automatically configured not to be routed between forests during the setup. There is one way to avoid manual configuration: use trust validation. Every time a new domain is added to the forest, or a new UPN suffix is assigned, go to the General tab of forest trust relationship properties, and click the Validate button. This process will verify the state of the trust relationship and refresh the list of suffixes configured on the Name Suffix Routing tab.
You may have to disable suffix routing manually in cases where conflicts still exist after running through the validation process, where conflicts cannot be identified automatically. In addition, security concerns may also be a good reason to disable a suffix; this must be done manually.
FIGURE 6-10
Managing UPN suffix routing exclusions
Average user rating: 5 stars out of 3 votes
Post a comment