Active Directory Sites and Services Snap-in

Raising Functional Level

Using the Active Directory Domains and Trusts snap-in, you can raise the domain as well as the forest functional level. In Windows 2000, a similar operation is called changing mode (mixed mode or native mode). Right click a domain in the domain tree and select the Raise Domain Functional Level command on the context menu (see Fig. 7.19). You will see a window (Fig. 7.20) that informs you about the current domain level and possible levels (if available).

Fig. 7.20: Selecting functional level of a domain

If the domain consists of Windows .NET-based domain controllers only, you can raise the domain level to Windows .NET (version 2002) right away. Select a level and click Raise . If there are domain controllers on other platforms (Windows NT 4.0 or Windows 2000), then the operation will fail. The system will report the controllers that prevent raising the functional level. Such a report will contain lines similar to the following:

The following domains include domain controllers that are running earlier versions of windows: Domain NameDomain Controller Version of Windows subdom.net.dom w2kdc3.subdom.net.dom Windows 2000 Server 5.0 (2195)

Otherwise, the operation will be replicated over other controllers in the same domain. Wait until replication has been completed. Then, you can verify functional levels by querying the RootDSE object on domain controllers (see Chapter 1, "LDAP Basics").

To raise the forest level, point to the root in the tree pane (Fig. 7.21) and select the Raise Forest Functional Level command on the context menu. Again, all errors that have occurred will be reported .

Fig. 7.21: Raising forest functional level

If two domain forests have the Windows .NET (version 2002) functional level, then the Active Directory Domains and Trusts snap-in will allow you to establish forest trusts between root domains of those forests.

Using User Principal Names (UPN)

The concept of user principal names can considerably simplify the logon process in large domain trees. While logging on, the domain users can use one of two methods for specifying their names. They can:

• Enter a UPN name , such as user@DNSdomainName (in this case, the domain list becomes unavailable).

• Enter a pre-Windows 2000 (SAM account) user name (without the "@" symbol) and then select a domain from the list.

Each method has certain advantages. It may be inconvenient to enter long domain names, such as dom1.comp1.ent1.com. The first method is, in fact, just a particular instance of a general format: userName@UPNSuffix. The default UPN suffix is the DNS name of that domain where a user account is located. It is possible to add alternative suffixes that can be used by all users of a domain forest .

To add a UPN suffix, open the Active Directory Domain and Trusts snap-in, point to the root in the tree pane, and select Properties from the context menu. Enter a suffix in the Alternative UPN suffixes field and click Add and Apply . The entered suffix (net in Fig. 7.22) will appear in the dialog box during new user creation.

Fig. 7.22: Adding an alternative UPN suffix

Now you can choose any UPN suffix for a new user (the current domain, parent domain and alternative UPN suffixes) or change the UPN name for an existing user. Let us create, for example, a user with the logon parameters shown in Fig. 7.23. Initially, the logon name and the pre-Windows 2000 name are the same, but you can specify any name you like.

Fig. 7.23: Choosing UPN suffixes during new user creation

The created user will be able to log onto the domain tree with the following names (the password will be the same for both logon names):

• EntAdmin@net — UPN name

• EAdmin (and a domain name selected from the list) — SAM account name

You can also check these names using the ADSI Edit snap-in ( sAMAccountName is a mandatory attribute, and userPrincipalName is an optional attribute).

Understandably, all account names must be unique. SAM account (pre-Windows 2000) names in the same domain cannot be repeated. A full name must not be used more than once in an OU. However, the same full name can be used for accounts in different OUs (because the canonical names of objects will differ , e.g., domain.com/OU1/John Smith and domain.com/OU2/John Smith ), provided that the UPN and SAM account names are different (e.g., jsmith@domain.com and johnSmith@domain.com ; JSMITH and JOHNS ).

Verifying Trusts

A domain administrator can use the Active Directory Domains and Trusts snap-in for verifying trusts between domains and for creating new trusts. This process primarily concerns trusts with Windows NT 4.0 domains. Such trusts must be manually created (see Chapter 5, "Installing Active Directory").

However, you may also want to create explicit, unidirectional trusts between AD-based domains that belong to different domain trees (or forests — if the forest trusts are established) or even to the same tree. This, for instance, may be required in order to reduce logon time into a "remote" domain. Here, "remote" is related to the "distance" between domains in a tree structure. (All considerations stated are even applicable to transitive Kerberos trusts.)

For example, the dom1.comp1.ent1.com and dom2.comp2.ent2.com domains (Fig. 7.24) can be regarded as "remote", because trusts between trees in a forest are established through the root domains.

Fig. 7.24: A shortcut trust between two "remote" domains