Tài liệu Windows Server 2008 Inside Out- P22 ppt

Understanding Domain Functional Level
When you set a functional level for a domain, the level of functionality applies only to
that domain. This means that other domains in the forest can have a different func-
tional level.
As shown in Table 30-1, there are several domain functional levels. Changing a func-
tional level changes the operating systems that are supported for domain controllers.
For example, in Windows 2000 native functional level, the domain can have domain
controllers running Microsoft Windows 2000 Server, Microsoft Windows Server 2003,
or Windows Server 2008.
Note
You cannot use the Windows 2000 mixed domain functional level with Windows Server
2008 domain controllers. If your domain is operating at this level and you want to
install a domain controller running Windows Server 2008, you’ll fi rst need to raise the
domain functional level to Windows 2000 native or higher. Although you can raise the
domain functional level, you can never lower it. This means that if you raise the domain
functional level to Windows Server 2008, you can confi gure only Windows Server 2008
domain controllers in the domain.
Table 30-1
Domain Functional Levels
Domain Functional Level Supported Domain Controllers
Windows 2000 mixed Windows Server 2003
Windows 2000 Server
Windows NT 4.0 backup domain controller (BDC)
Windows 2000 native Windows Server 2008
Windows Server 2003
Windows 2000 Server
Windows Server 2003 Windows Server 2008
Windows Server 2003
Windows Server 2008 Windows Server 2008
Domains operating in Windows 2000 native mode can use group nesting, group type
conversion, universal groups, and migration of security principals. Domains operating

in this mode aren’t able to use easy domain controller renaming, update logon time
stamps, or Kerberos key distribution center (KDC) key version numbers.
Domains in Windows Server 2003 mode can use many improved Active Directory fea-
tures, including group nesting, group type conversion, universal groups, easy domain
controller renaming, update logon time stamps, migration of security principals, and
Kerberos KDC key version numbers. Applications can use constrained delegation
to take advantage of the secure delegation of user credentials through the Kerberos
Note
You cannot use the Windows 2000 mixed domain functional level with Windows Server
2008 domain controllers. If your domain is operating at this level and you want to
install a domain controller running Windows Server 2008, you’ll fi rst need to raise the
domain functional level to Windows 2000 native or higher. Although you can raise the
domain functional level, you can never lower it. This means that if you raise the domain
functional level to Windows Server 2008, you can confi gure only Windows Server 2008
domain controllers in the domain.
Design Considerations for Compatibility 1017
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
authentication protocol. You can also redirect the Users and Computers containers to
defi ne a new well-known location for user and computer accounts.
Windows 2008 domain functional level adds the following features above those avail-
able with Windows Server 2003:

Distributed File System Replication for Sysvol, which provides more robust and
granular replication of Sysvol.

Advanced Encryption Services (AES) support for the Kerberos protocol, allowing
user accounts to use AES 128-bit or AES 256-bit encryption.

Last interactive logon information, which displays the time of the last successful

interactive logon for a user, the number of failed logon attempts since last logon,
and the time of the last failed logon.

Fine-grained password policies, which make it possible for password and account
lockout policy to be specifi ed for user and global security groups in a domain.
Understanding Forest Functional Level
Forest functional level is a bit simpler, as shown in Table 30-2. When you raise the forest
functional level to Windows Server 2008, all domains using the Windows 2000 native
domain functional level or higher are automatically raised to the Windows Server 2008
domain functional level. As with the domain functional level, after you raise the forest
functional level, you cannot lower it.
Table 30-2 Forest Functional Levels
Forest Functional Level Supported Domain Controllers
Windows 2000 Windows Server 2008
Windows Server 2003
Windows 2000 Server
Windows Server 2003 Windows Server 2008
Windows Server 2003
Windows Server 2008 Windows Server 2008
Forests operating in Windows 2000 mode can’t use many Active Directory features,
including extended two-way trusts between forests, domain rename, domain restruc-
ture using renaming, and global catalog replication enhancements.
Windows Server 2003 forest functional level adds the following features:

Linked-value replication to improve the replication of changes to group
memberships

Extended two-way trusts between forests

Domain rename and domain restructure using renaming


More effi cient generation of complex replication topologies by the KCC
Chapter 30
1018 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
With the original release of the operating system, Windows Server 2008 forest func-
tional level does not add any specifi c features.
Raising the Domain or Forest Functional Level
You can raise the domain or forest functional level using Active Directory Domains And
Trusts. To raise the domain functional level, follow these steps:
1. Click Start, choose Administrative Tools, and then select Active Directory
Domains And Trusts.
2. In the console tree, right-click the domain you want to work with, and then select
Raise Domain Functional Level. The current domain name and functional level
appear in the Raise Domain Functional Level dialog box.
3. To change the domain functionality, select the new domain functional level using
the selection list provided, and then click Raise.
CAUTION
!
You can’t reverse this action. After you raise the functional level, there’s no going back,
so you should consider the implications carefully before you do this.
4. When you click OK, the new domain functional level is replicated to each domain
controller in the domain. This operation can take some several minutes or longer
in a large organization.
You can raise the forest level functionality by completing the following steps:
1. Click Start, choose Administrative Tools, and then select Active Directory
Domains And Trusts.
2. Right-click the Active Directory Domains And Trusts node in the console tree,
and then select Raise Forest Functional Level. The current forest name and
functional level appear in the Raise Forest Functional Level dialog box.

3. To change the forest functionality, select the new forest functional level using the
selection list provided, and then click Raise.
CAUTION
!
You can’t reverse this action. After you raise the functional level, there’s no going back,
so you should consider the implications carefully before you do this.
CU O
!
CAUTION
!
Design Considerations for Compatibility 1019
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
4. When you click OK, the new forest functional level is replicated to each domain
controller in each domain in the forest. This operation can take several minutes
or longer in a large organization.
As a planning option, you can determine the steps you need to take to raise the forest
functional level by clicking Save As in the Raise Forest Functional Level dialog box.
When you click Save As, a Save As dialog box appears, allowing you to select a save
location for a log fi le. The log fi le details show the following information:

The forest root domain and the current forest functional level.

The domains and the domain controllers in those domains that are running ver-
sions of Windows earlier than Windows Server 2008. These are the servers that
need to be upgraded.

The domain functional level of each domain for which the functional level must
be raised. As long as the domain functional level of all domains is set to at least
Windows 2000 native, you can raise the forest functional level—doing so raises

the domain functional level in all the domains to Windows Server 2008 and sets
the forest functional level to Windows Server 2008 as well.
Design Considerations for Active Directory
Authentication and Trusts
Authentication and trusts are integral parts of Active Directory. Before you implement
any Active Directory design or try to modify your existing Active Directory infrastruc-
ture, you should have a fi rm understanding of how both authentication and trusts work
in an Active Directory environment.
Universal Groups and Authentication
When a user logs on to a domain, Active Directory looks up information about the
groups of which the user is a member to generate a security token for the user. The
security token is needed as part of the normal authentication process and is used when-
ever a user accesses resources on the network.
Understanding Security Tokens and Universal Group
Membership Caching
To generate the security token, Active Directory checks the domain local and global
group memberships for the user. All the supported domain functional levels in
Windows Server 2008 support a special type of group called a universal group. Uni-
versal groups can contain user and group accounts from any domain in the forest. As
global catalog servers are the only servers in a domain with forest-wide domain data,
the global catalog is essential for logon in any domain operating at the Windows 2000
native functional level or higher.
Chapter 30
1020 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Because of problems authenticating users when global catalog servers are not available,
Windows Server 2003 introduced a technique for caching universal group member-
ship. In a domain with domain controllers running either Windows Server 2003 or
Windows Server 2008, universal group membership caching can be enabled. After you
enable caching, the cache is where domain controllers store universal group member-

ship information that they have previously looked up. Domain controllers can then use
this cache for authentication the next time the user logs on to the domain. The cache is
maintained indefi nitely and updated periodically to ensure that it is current. By default,
domain controllers check the consistency of the cache every eight hours.
Thanks to universal group membership caching, remote sites running Windows Server
2003, Windows Server 2008, or both domain controllers don’t necessarily have to have
global catalog servers confi gured as well. This gives you additional options when con-
fi guring the Active Directory forest. The assignment of security tokens is only part of
the logon process. The logon process also includes authentication and the assignment
of a user principal name (UPN) to the user.

Every user account has a user principal name (UPN) which consists of the user logon
name combined with the at symbol (@) and a UPN suffi x. The names of the current
domain and the root domain are set as the default UPN suffi x. You can specify an alter-
nate UPN suffi x to use to simplify logon or provide additional logon security. This name
is used only within the forest and does not have to be a valid DNS name. For example,
if the UPN suffi x for a domain is it.seattle.cpandl.local, you could use an alternate UPN
suffi x to simplify this to cpandl.local. This would allow the user Williams to log on using
rather than
You can add or remove UPN suffi xes for an Active Directory forest and all domains within
that forest by completing the following steps:
1.
Start Active Directory Domains And Trusts from the Administrative Tools menu.
2.
Right-click the Active Directory Domains And Trusts node and then click
Properties.
3.
To add a UPN suffi x, type the alternate suffi x in the box provided and then click
Add.
4.

To remove a UPN suffi x, click the suffi x to remove in the list provided and then
click Remove.
5.
Click OK.
Enabling Universal Group Membership Caching
In a domain with domain controllers running Windows Server 2003, Windows
Server 2008, or both, you use the Active Directory Sites And Services tool to confi gure
universal group membership caching. You enable caching on a per-site basis. Start
SIDE OUT
The user principal name (UPN) suffi x can be changed
Every user account has a user principal name (UPN) which consists of the user logon
name combined with the at symbol (@) and a UPN suffi x. The names of the current
domain and the root domain are set as the default UPN suffi x. You can specify an alter-
nate UPN suffi x to use to simplify logon or provide additional logon security. This name
is used only within the forest and does not have to be a valid DNS name. For example,
if the UPN suffi x for a domain is it.seattle.cpandl.local, you could use an alternate UPN
suffi x to simplify this to cpandl.local. This would allow the user Williams to log on using
rather than
You can add or remove UPN suffi xes for an Active Directory forest and all domains within
that forest by completing the following steps:
1.
Start Active Directory Domains And Trusts from the Administrative Tools menu.
2.
Right-click the Active Directory Domains And Trusts node and then click
Properties.
3.
To add a UPN suffi x, type the alternate suffi x in the box provided and then click
Add.
4.
To remove a UPN suffi x, click the suffi x to remove in the list provided and then

click Remove.
5.
Click OK.
Design Considerations for Active Directory Authentication and Trusts 1021
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Active Directory Sites And Services by clicking Start, Programs or All Programs, Admin-
istrative Tools, and Active Directory Sites And Services. Expand and then select the site
in which you want to enable universal group membership caching, as shown in the fol-
lowing screen:
In the right pane, right-click NTDS Site Settings, and then select Properties. This dis-
plays the NTDS Site Settings Properties dialog box as shown in the following screen:
To enable universal group membership caching for the site, select the Enable Universal
Group Membership Caching check box and continue as follows:

If the directory has multiple sites, you can replicate existing universal group
membership information from a specifi c site’s cache by selecting the site in the
Refresh Cache From list. With this option, universal group membership informa-
tion doesn’t need to be generated and then replicated; it is simply replicated from
the other site’s cache.

If the directory has only one site or you’d rather get the information from a global
catalog server in the nearest site, accept the default setting <Default>. With
this option, universal group membership information is generated and then
replicated.
When you are fi nished confi guring universal group membership caching, click OK.
Chapter 30
1022 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
NTLM and Kerberos Authentication

Windows NT 4.0 uses a form of authentication known as NT LAN Manager (NTLM).
With NTLM, an encrypted challenge/response is used to authenticate a user without
sending the user’s password over the network. The system requesting authentication
must perform a calculation that proves it has access to the secured NTLM credentials. It
does this by sending a one-way hash of the user’s password that can be verifi ed.
NTLM authentication has interactive and non-interactive authentication processes.
Interactive NTLM authentication over a network typically involves a client system from
which a user is requesting authentication, and a domain controller on which the user’s
password is stored. As the user accesses other resources on the network, non- interactive
authentication may take place as well to permit an already logged-on user to access net-
work resources. Typically, non-interactive authentication involves a client, a server, and
a domain controller that manages the authentication.
To see how NTLM authentication works, consider the situation that occurs when a user
tries to access a resource on the network and she is prompted for her user name and
password. Assuming the resource is on a server that is not also a domain controller, the
authentication process would be similar to the following:
1. When prompted, the user provides a domain name, user name, and password.
The client computer generates a cryptographic hash of the user’s password,
discards the actual password, then sends the user name to the server as
unencrypted text.
2. The server generates a 16-byte random number, called a challenge, and sends it to
the client.
3. The client encrypts the challenge with the hash of the user’s password and
returns the result, called a response, to the server. The server then sends the
domain controller the user name, the challenge sent to the client, and the
response from the client.
4. The domain controller uses the user name to retrieve the hash of the user’s
password from the Security Account Manager (SAM) database. The domain
controller uses this password hash to encrypt the challenge then compares the
encrypted challenge it computed to the response computed by the client. If they

are identical, the authentication is successful.
Starting with Windows 2000, Active Directory uses Kerberos as the default authentica-
tion protocol, and NTLM authentication is maintained only for backward compatibility
with older clients. Whenever a client running Windows 2000 or later tries to authen-
ticate with Active Directory, the client tries to use Kerberos. Kerberos has a number
of advantages over NTLM authentication, including the use of mutual authentication.
Mutual authentication in Kerberos allows for two-way authentication, so that not only
can a server authenticate a client, but a client can also authenticate a server. Thus,
mutual authentication ensures that not only is an authorized client trying to access the
network, but also that an authorized server is the one responding to the client request.
Design Considerations for Active Directory Authentication and Trusts 1023
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Kerberos uses the following three main components:

A client that needs access to resources

A server that manages access to resources and ensures that only authenticated
users can gain access to resources

A Key Distribution Center (KDC) that acts as a central clearinghouse
Establishing the Initial Authentication
All domain controllers run the Kerberos Key Distribution Center service to act as
KDCs. With Kerberos authentication, a user password is never sent over the network.
Instead, Kerberos authentication uses a shared secret authentication model. In most
cases, the client and the server use the user’s password as the shared secret. With this
technique, authentication works as shown in Figure 30-4.
Kerberos
Client
Kerberos

Server
Validates by
successful
decryption then
checks time stamp.
Sends a session key
and service ticket.
Sends authentication message.
1
2
4
Validates by
successful decryption
then checks time
stamp. Caches key
and ticket.
3
Figure 30-4 The Kerberos authentication process.
The details of the initial authentication of a user in the domain are as follows:
1. When a user logs on to the network, the client sends the KDC server a message
containing the user name, domain name, and a request for access to the network.
In the message is a packet of information that has been encrypted using the
shared secret information (the user’s password), which includes a time stamp.
2. When the KDC server receives the message, the server reads the user name, and
then checks the directory database for its copy of the shared secret information
(the user’s password). The KDC server then decrypts the secret part of the
message and checks the message time stamp. As long as the message time stamp
is within fi ve minutes of the current time on the server, the server can then
authenticate the user. If the decryption fails or the message time stamp is more
than fi ve minutes off the current time, the authentication fails. Five minutes is the

default value; the allowable time difference can be confi gured through domain
security policy, using the Kerberos policy Maximum Tolerance For Computer
Clock Synchronization.
Chapter 30
1024 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3. After the user is authenticated, the KDC server sends the client a message that is
encrypted with the shared secret information (the user’s password). The message
includes a session key that the client will use when communicating with the KDC
server from now on and a session ticket that grants the user access to the domain
controller. The ticket is encrypted with the KDC server’s key, which makes it valid
only for that domain controller.
4. When the client receives the message, the client decrypts the message and checks
the message time stamp. As long as the message time stamp is within fi ve minutes
of the current time on the server, the client can then authenticate the server and
assume that the server is valid. The client then caches the session key so it can
be used for all future connections with the KDC server. The session key is valid
until it expires or the user logs off. The session ticket is cached as well, but it isn’t
decrypted.
Accessing Resources After Authentication
After initial authentication, the user is granted access to the domain. The only resource
to which the user has been granted access is the domain controller. When the user
wants to access another resource on the network, the client must request access
through the KDC. An overview of the process for authenticating access to network
resources is shown in Figure 30-5.
The details of an access request for a network resource are as follows:
1. When a user tries to access a resource on the network, the client sends the KDC
server a session ticket request. The message contains the user’s name, the session
ticket the client was previously granted, the name of the network resource the
client is trying to access, and a time stamp that is encrypted with the session key.

2. When the KDC server receives the message, the server decrypts the session ticket
using its key. Afterward, it extracts the original session key from the session ticket
and uses it to decrypt the time stamp, which is then validated. The validation
process is designed to ensure that the client is using the correct session key and
that the time stamp is valid.
3. If all is acceptable, the KDC server sends a session ticket to the client. The session
ticket includes two copies of a session key that the client will use to access the
requested resource. The fi rst copy of the session key is encrypted using the
client’s session key. The second copy of the session key contains the user’s access
information and is encrypted with the resource’s secret key known only by the
KDC server and the network resource.
4. The client caches the session ticket, and then sends the session ticket to the
network resource to gain access. This request also contains an encrypted time
stamp.
Design Considerations for Active Directory Authentication and Trusts 1025
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Kerberos
Client
Kerberos
Server
Validates by
successful
decryption then
checks time stamp.
Sends a session ticket with
two session keys.
Sends session ticket request.
2
4a

Caches both keys.
The next time the
user needs to access
the resource, the
session ticket in
cache can be used.
3
Grants or denies access.
Sends session ticket to
the network resource.
6
5
Print Server
(network resource)
Validates by successful
decryption of its key,
then decrypts user access
token with session key.
Checks level of access.
4b
1
Figure 30-5 The Kerberos authentication process.
5. The network resource decrypts the second session key in the session ticket, using
the secret key it shares with the KDC server. If this is successful, the network
resource has validated that the session ticket came from a trusted KDC. It then
decrypts the user’s access information, using the session key, and checks the
user’s access permissions. The time stamp sent from the client is also decrypted
and validated by the network resource.
6. If the authentication and authorization are successful (meaning that the client
has the appropriate access permissions), the user is granted the type of access

to the network resource that the particular permissions allow. The next time the
user needs to access the resource, the session ticket in cache is used, as long as it
hasn’t expired. Using a cached session ticket allows the client to send a request
directly to the network resource. If the ticket has expired, however, the client
must start over and get a new ticket.
Authentication and Trusts Across Domain Boundaries
Active Directory uses Kerberos security for server-to-server authentication and the
establishment of trusts, while allowing older clients and servers on the network to
use NTLM if necessary. Figure 30-6 shows a one-way trust in which one domain is the
Chapter 30
1026 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
trusted domain and the other domain is the trusting domain. In Windows NT 4.0, you
typically implemented one-way trusts when you had separate account and resource
domains. The establishment of the trust allowed users in the account domain to access
resources in the resource domain.
Direction of trust
Trusted domain
(account domain)
Domain A
Direction of access
Trusting domain
(resource domain)
Domain B
Figure 30-6 One-way trust with a trusted domain and a trusting domain.
Two-Way Transitive Trusts
With Active Directory, trusts are automatically confi gured between all the domains in
a forest and are implemented as two-way, transitive trusts. As a result, if the domains
shown in Figure 30-6 were Windows domains, users in domain A can automatically
access resources in domain B and users in domain B can automatically access resources

in domain A. Because the trusts are automatically established between all domains in
the forest, no setup is involved and there are many more design options for implement-
ing Active Directory domains.
Note
The physical limitation on the number of objects that necessitated having separate
account and resource domains in Windows NT 4.0 no longer applies. Active Directory
domains can have millions of objects, a fact that changes the fundamental reason for
creating additional domains.
As trusts join parent and child domains in the same domain tree and join the roots of
domain trees, the structure of trusts in a forest can be referred to as a trust tree. When a
user tries to access a resource in another domain, the trust tree is used, and the user’s
request has to pass through one domain controller for each domain between the user
Note
The physical limitation on the number of objects that necessitated having separate
account and resource domains in Windows NT 4.0 no longer applies. Active Directory
domains can have millions of objects, a fact that changes the fundamental reason for
creating additional domains.
Design Considerations for Active Directory Authentication and Trusts 1027
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
and the resource. This type of authentication takes place across domain boundaries.
Authentication across domain boundaries also applies when a user with an account in
one domain visits another domain in the forest and tries to log on to the network from
that domain.
Consider the example shown in Figure 30-7. If a user from domain G visits domain
K and tries to log on to the network, the user’s computer must be able to connect to
a domain controller in domain K. Here, the user’s computer sends the initial logon
request to the domain K domain controller. When the domain controller receives the
logon request, it determines that the user is located in domain G. The domain control-
ler refers the request to a domain controller in the next domain in its trust tree, which

in this case is domain J. A domain controller in domain J refers the request to domain I.
A domain controller in domain I refers the request to domain H. This process continues
through domains A, E, and F until the request fi nally gets to domain G.
Two-way
transitive trust
A
B
E
C
F
D
G
H
I
J
K
Figure 30-7 A forest with many domains.
Shortcut Trusts
This rather lengthy referral process could be avoided if you established an explicit
trust between domain G and domain K as shown in Figure 30-8. Technically, explicit
trusts are one-way transitive trusts, but you can establish a two-way explicit trust by
creating two one-way trusts. Thus unlike standard trusts within the trust tree, which
are inherently two-way and transitive, explicit trusts can be made to be two-way if
desired. As they can be used to establish authentication shortcuts between domains,
they are also referred to as shortcut trusts. In this example, it was decided to create two
one-way trusts: one from domain G to domain K and one from domain K to domain
G. With these shortcut trusts in place, users in domain G could visit domain K and
Chapter 30
1028 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

be rapidly authenticated and users in domain K could visit domain G and be rapidly
authenticated.
If you examine the fi gure closely, you’ll see that several other shortcut trusts were
add to the forest as well. Shortcut trusts have been established between B and E and
between E and I. Establishing the shortcut trusts in both directions allows for easy
access to resources and rapid authentication in several combinations, such as the
following:

Using the B to E shortcut trust, users in domain B can rapidly access resources in
domain E.

Using the B to E and E to I shortcut trusts, users in domain B can also rapidly
access resources in domain I.

Using the B to E shortcut trust, users in domain B can visit domain E and be rap-
idly authenticated.

Using the B to E and E to I shortcut trusts, users in domain B can visit domain I
and be rapidly authenticated.
Two-way
transitive trust
A
B
E
C
F
D
G
H
I

J
K
One-way
shortcut trust
Figure 30-8 A forest with several shortcut trusts.
The trusts work similarly for users in domain E. Users in domain E have direct access
to both domain B and domain I. Imagine that domain B is sales.cohovineyard.com,
domain E is mf.cohovineyard.com, and domain I is cs.cohowinery.com, and you may
be able to better picture how the shortcut trusts allow users to cut across trees in the
Active Directory forest. Hopefully, you can also imagine how much planning should go
into deciding your domain structure, especially when it comes to access to resources
and authentication.
Design Considerations for Active Directory Authentication and Trusts 1029
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Authentication and Trusts Across Forest Boundaries
You can establish authentication and trusts across forest boundaries as well. As dis-
cussed in Chapter 29, “Active Directory Architecture,” while you are upgrading your
network to implement Active Directory, you can establish external trusts to Windows
NT domains to ensure that Windows NT domains continue to be available to users.
One-way external trusts, such as the one depicted in Figure 30-9, are nontransitive.
This means that if, as in the example, a trust is established between domain H and
domain L only, a user in any domain in forest 1 could access a resource in domain L
but not in any other domain in forest 2. The reason for this limitation is that the trust
doesn’t continue past domain L and it does not matter that a two-way transitive trust
does exist between domain L and domain M or that a two-way trust also exists between
domain L and domain O.
Two-way
transitive trust
A

B
E
C
F
D
G
H
I
J
K
One-way
shortcut trust
L
M
O
N
Forest 1 Forest 2
One-way
external trust
Nontransitive
Figure 30-9 A one-way external trust that crosses forest boundaries but is nontransitive.
Like Windows Server 2003, Windows Server 2008 supports cross-forest transitive
trusts also referred to simply as forest trusts. With this type of trust, you can establish a
one-way or two-way transitive trust between forests to share resources and to authen-
ticate users. With a two-way trust, as shown Figure 30-10, you enable cross-forest
authentication and cross-forest authorization. Before you can use cross-forest trusts, all
domain controllers in all domains of both forests must be upgraded to Windows Server
2003 or higher, and the forest must be running at the Windows Server 2003 or higher
functional level.
Chapter 30

1030 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
As discussed in “NTLM and Kerberos Authentication” on page 1023, Kerberos is the
default authentication protocol, but NTLM can also be used. This allows current clients
and servers as well as older clients and servers to be authenticated. After you establish
a two-way cross-forest trust, users get all the benefi ts of Active Directory regardless of
where they sign on to the network. With cross-forest authentication, you ensure secure
access to resources when the user account is in one forest and the computer account is
in another forest, and when the user in one forest needs access to network resources in
another trusted forest. As part of cross-forest authorization, administrators can select
users and global groups from trusted forests for inclusion in local groups. This ensures
the integrity of the forest security boundary while allowing trust between forests.
Two-way
transitive trust
A
B
E
C
F
D
G
H
I
J
K
One-way
shortcut trust
L
M
O

N
Forest 1 Forest 2
Two-way trust
Cross-forest,
transitive
Figure 30-10 A two-way transitive trust between forests.
When you connect two or more forests using cross-forest trusts, the implementation is
referred to as a federated forest design. The federated forest design is most useful when
you need to join two separate Active Directory structures, for example, when two com-
panies merge, when one company acquires another, or when an organization has a
major restructuring. Consider the case in which two companies merge, and, rather than
migrate their separate Active Directory structures into a single directory tree, the staff
decides to link the two forests using cross-forest trusts. As long as the trusts are two-
way, users in forest 1 can access resources in forest 2 and users in forest 2 can access
resources in forest 1.
Having separate forests with cross-forest trusts between them is also useful when you
want a division or group within the organization to have more autonomy but still have
Design Considerations for Active Directory Authentication and Trusts 1031
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
a link to the other divisions or groups. By placing the division or group in a separate
forest, you ensure strict security and give that division or group ownership of the Active
Directory structure. If users in the forest needed access to resources in another forest,
you could establish a one-way cross-forest trust between the forests. This would allow
users in the secured forest to gain access to resources in the second forest, but would
not allow users in the second forest to gain access to the secure forest.
Organizations that contain groups or divisions with high security requirements could
use this approach. For example, consider Figure 30-11.
Two-way
transitive trust

A
B
E
C
F
D
G
H
I
J
K
One-way
shortcut trust
L
M
O
N
Main Organizational Forest Engineering Forest
One-way trust
Cross-forest, transitive
Figure 30-11 A one-way transitive trust between forests.
In this situation, the users in the organization’s Engineering department need access
to resources in other departments, but for security reasons they should be isolated
from the rest of the organization. Here the organization has implemented two forests:
a main organizational forest and a separate Engineering forest. Using a one-way cross-
forest trust from the main forest to the Engineering department forest, the organization
allows Engineering users to access other resources, but ensures that the Engineering
department is secure and isolated.
Chapter 30
1032 Chapter 30 Designing and Managing the Domain Environment

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Examining Domain and Forest Trusts
You can examine existing trusts using Active Directory Domains And Trusts. Click
Start, choose Programs or All Programs as appropriate, choose Administrative Tools,
and then select Active Directory Domains And Trusts. As shown in the following
screen, you see a list of available domains:
To examine the existing trusts for a domain, right-click the domain entry, and then
select Properties. Then, in the domain’s Properties dialog box, click the Trusts tab as
shown in the following screen. The Trust tab is organized into two panels:

Domains Trusted By This Domain (Outgoing Trusts)
Lists the domains that this
domain trusts (the trusted domains).

Domains That Trust This Domain (Incoming Trusts)
Lists the domains that trust
this domain (the trusting domains).
Design Considerations for Active Directory Authentication and Trusts 1033
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
To view the details of a particular trust, select it, and then click Properties. The follow-
ing screen shows the trust’s Properties dialog box:
The Properties dialog box contains the following information:

This Domain
The domain you are working with.

Other Domain
The domain with which the trust is established.


Trust Type
The type of trust. By default, two-way transitive trusts are created
automatically when a new domain is added to a new domain tree within the for-
est or a subdomain of a root domain. There are two default trust types: Tree Root
and Parent And Child. When a new domain tree is added to the forest, the default
trust that is established automatically is a tree-root trust. When a new domain is a
subdomain of a root domain, the default trust that is established automatically is
a parent and child trust. Other trust types that may appear include the following:

External, which is a one-way or two-way nontransitive trust used to provide
access to resources in a Windows NT 4.0 domain or to a domain in a sepa-
rate forest that is not joined by a forest trust

Forest, which is a one-way or two-way transitive trust used to share
resources between forests

Realm, which is a transitive or nontransitive trust that can be established
as one way or two way between a non-Windows Kerberos realm and a
Windows Server 2008 domain

Shortcut, which is a one-way or two-way transitive trust used to speed up
authentication and resource access between domain trees
Chapter 30
1034 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Direction Of Trust
The direction of the trust. All default trusts are established as
two-way trusts. This means that users in the domain you are working with can
authenticate in the other domain and users from the other domain can authenti-

cate in the domain you are working with.

Transitivity Of Trust
The transitivity of the trust. All default trusts are transitive,
which means that users from indirectly trusted domains can authenticate in the
other domain.
Establishing External, Shortcut, Realm, and
Cross-Forest Trusts
All trusts, regardless of type, are established in the same way. For all trusts there are
two sides: an incoming trust and an outgoing trust. To confi gure both sides of the trust,
keep the following in mind:

For domain trusts, you need to use two accounts: one that is a member of the
Domain Admins group in the fi rst domain and one that is a member of the
Domain Admins group in the second domain. If you don’t have appropriate
accounts in both domains, you can establish one side of the trust and allow
another administrator in the other domain to establish the other side of the trust.

For forest trusts, you will need to use two accounts: one that is a member of the
Enterprise Admins group in the fi rst forest and one that is a member of the Enter-
prise Admins group in the second forest. If you don’t have appropriate accounts
in both forests, you can establish one side of the two-way trust and allow another
administrator in the other forest to establish the other side of the trust.

For realm trusts, you will need to establish the trust separately for the Windows
domain and for the Kerberos realm. If you don’t have appropriate administrative
access to both the Windows domain and the Kerberos realm, you can establish
one side of the trust and allow another administrator to establish the other side of
the trust.
To establish a trust, follow these steps:

1. Click Start, choose Programs or All Programs as appropriate, choose
Administrative Tools, and then select Active Directory Domains And Trusts.
2. Right-click the domain for which you want to establish a one-way incoming, one-
way outgoing, or two-way trust and then choose Properties. For a cross-forest
trust, this must be the forest root domain in one of the participating forests.
3. In the domain Properties dialog box, click the Trusts tab, and then click the New
Trust button. This starts the New Trust Wizard. Click Next to skip the welcome
page.
4. On the Trust Name page, specify the domain name of the other domain, as shown
in Figure 30-12. For a cross-forest trust, this must be the name of the forest root
domain in the other forest.
Design Considerations for Active Directory Authentication and Trusts 1035
Chapter 30
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Figure 30-12 Specify the name of the other domain.
5. When you click Next, the wizard tries to establish a connection to the other
domain. The options on the next page depend on whether you are connecting to a
Windows domain, a Windows forest, or a non-Windows forest.

If the domain is determined to be a Windows forest, you have the option of
creating an external trust that is nontransitive or a forest trust that is transi-
tive. Choose either External Trust or Forest Trust, and then click Next.

If the domain is determined to be a Windows domain, it is assumed that
you are creating a shortcut trust, and the wizard goes directly to the Direc-
tion Of Trust page.

If the domain is determined to be a non-Windows domain, you have the
option of creating a realm trust with a Kerberos version 5 realm. Select
Realm Trust, and then, on the Transitivity Of Trust page, select either Non-

transitive or Transitive, and then click Next.
6. On the Direction Of Trust page, shown in Figure 30-13, choose the direction of
trust and then click Next. The following options are available:

Two-Way—Users in the domain initially selected and in the designated
domain can access resources in either domain or realm.

One-Way: Incoming—Users in the domain initially selected will be able to
access resources in the designated domain. Users in the designated domain
will not be able to access resources in the domain initially selected.
Chapter 30
1036 Chapter 30 Designing and Managing the Domain Environment
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.