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

func-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

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 tional level changes the operating systems that are supported for domain controllers

func-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 ServerWindows NT 4.0 backup domain controller (BDC)Windows 2000 native Windows Server 2008

Windows Server 2003Windows 2000 ServerWindows Server 2003 Windows Server 2008

Windows Server 2003Windows 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 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

fea-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.

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 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 2003Windows 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

With the original release of the operating system, Windows Server 2008 forest tional level does not add any specifi c features

func-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

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

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 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 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

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 williams@cpandl.local rather than williams@it.seattle.cpandl.local

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

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 williams@cpandl.local rather than williams@it.seattle.cpandl.local

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.

Active Directory Sites And Services by clicking Start, Programs or All Programs, istrative Tools, and Active Directory Sites And Services Expand and then select the site

Admin-in which you want to enable universal group membership cachAdmin-ing, as shown Admin-in the lowing screen:

In the right pane, right-click NTDS Site Settings, and then select Properties This 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

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 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

authentica-of advantages over NTLM authentication, including the use authentica-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 Ch ap

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

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

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

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.

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

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

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 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

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

Authentication and Trusts Across Forest Boundaries

You can establish authentication and trusts across forest boundaries as well As cussed in Chapter 29, “Active Directory Architecture,” while you are upgrading your network to implement Active Directory, you can establish external trusts to Windows

dis-NT domains to ensure that Windows dis-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

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 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

authen-2003 or higher, and the forest must be running at the Windows Server authen-2003 or higher functional level

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

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 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

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

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 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

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)

To view the details of a particular trust, select it, and then click Properties The 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

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 way incoming,

one-way outgoing, or two-one-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

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

One-Way: Outgoing—Users in the designated domain will be able to access resources in the domain initially selected Users in the domain initially selected will not be able to access resources in the designated domain

Figure 30-13 Choose the direction of trust

7 For shortcut or forest trusts, the next page you see is the Sides Of Trust page To

begin using a trust, you must create both sides of the trust You have the option of setting the sides of the trust for This Domain Only or for Both This Domain And The Specifi ed Domain

If you are creating only one side of the trust, select This Domain Only, and then click Next

If you are setting both sides of the trust or the administrator from the other domain is at your desk, select Both This Domain And The Specifi ed Domain, and then click Next When prompted, type, or let the other admin-istrator type, the name and password of an appropriate account in the other domain or forest, and then click OK

8 On the Trust Password page, shown in Figure 30-14, type and then confi rm the

initial password you want to use for the trust The password is arbitrary but must follow the strong security rules, meaning that it must have at least eight characters, contain a combination of uppercase and lowercase characters, and contain either numerals or special characters

Figure 30-14 Set the initial password for the trust

The trust password you use must be the same for both the domain initially selected and the specifi ed domain, so be sure to securely store the password so that you can use it when confi guring the other side of the trust After you create the trust, Active Directory periodically updates the password, using an automatic password reset This helps safe- guard the integrity of the trust

9 For domain or realm trusts, click Next twice to begin the trust creation process

10 For forest trusts, you can set the outgoing trust authentication level as either

Domain-Wide Authentication or Selective Authentication With domain-wide authentication, users in the trusted domain can be authenticated to use all the resources in the trusting domain (and any trusted domains) This means that authentication is automatic for all users With Selective Authentication, only the users or groups to which you explicitly grant permission can access resources in the trusting domain This means that authentication is not automatic and you will need to grant individual access to each server that you want to make available to users in the trusting domain Click Next twice

11 After the trust is created, you are given the opportunity to verify the trust

SIDE OUT You may need the password

The trust password you use must be the same for both the domain initially selected and the specifi ed domain, so be sure to securely store the password so that you can use it when confi guring the other side of the trust After you create the trust, Active Directory periodically updates the password, using an automatic password reset This helps safe- guard the integrity of the trust.

Verifying and Troubleshooting Trusts

By default, Windows validates all incoming trusts automatically If the credentials used

to establish the trust are no longer valid, the trust fails verifi cation If you want to date a trust by providing new credentials or to specify that incoming trusts should not

revali-be validated, 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 trusted domain for which you want to verify the incoming trust,

and then select Properties

3 In the domain’s Properties dialog box, click the Trusts tab, and then click Validate

and select one of the following options:

If you want to stop validation of the incoming trust, select No, Do Not date The Incoming Trust

If you want to revalidate the incoming trust, select Yes, Validate The ing Trust, and then type the user account and password for an administra-tor account in the other (trusting) domain

4 Click OK For a two-way trust, repeat this procedure for the other (trusting)

If clients cannot connect to a domain controller running Windows 2000, check the service pack level on the domain controller The Windows 2000 domain con-troller should be running Service Pack 3 or later If it isn’t, upgrade it

If clients or servers get trust errors within an Active Directory forest, there could

be several causes The time on the clients or servers trying to authenticate may be more than fi ve minutes off, which is the default maximum time difference allowed for Kerberos authentication In this case, synchronize the time on the clients and servers The problem could also be that the domain controller may be down or the trust relationship could be broken For the latter case, you can run NETDOM

to verify or reset the trust

If clients are experiencing trust errors connecting to a Windows NT 4.0 domain, the automatic password reset for the trust may not have reached the PDC emula-tor You can run NETDOM to verify or reset the trust If this doesn’t resolve the problem, see Knowledge Base article 317178 for more information

After upgrading a Windows NT 4.0 domain that has existing trusts with one or more Active Directory domains, you need to delete and re-create all the previ-ously existing trusts These trusts are not automatically upgraded from Windows

NT 4.0 trusts If this doesn’t resolve the problem, see Knowledge Base article

275221 for more information

Delegating Authentication

The delegation of authentication is often a requirement when a network service is distributed across several servers, such as when the organization uses Web-based application services with front-end and back-end servers In this environment, a client connects to the front-end servers and the user’s credentials may need to be passed to back-end servers to ensure that the user only gets access to information to which she has been granted access

Delegated Authentication Essentials

In Windows 2000, this functionality is provided using Kerberos authentication, either using proxy tickets or using forwarded tickets:

With proxy tickets, the client sends a session ticket request to a domain ler acting as a KDC, asking for access to the back-end server The KDC grants the session ticket request and sends the client a session ticket with a PROXI-ABLE fl ag set The client can then send this ticket to the front-end server, and the front-end server in turn uses this ticket to access information on the back-end server In this confi guration, the client needs to know the name of the back-end server, which in some cases is problematic, particularly if you need to maintain strict security for the back-end databases and don’t want their integrity to be compromised

control-With forwarding tickets, the client sends an initial authorization request to the KDC, requesting a session ticket that the front-end server will be able to use to access the back-end servers The KDC grants the session ticket request, and sends

it to the client The client can then send the ticket to the front-end server, which then uses the session ticket to make a network resource request on behalf of the client The front-end server then gets a session ticket to access the back-end server using the client’s credentials

Note

In the Windows 2000 model, the front-end server is not constrained in terms of the network resources it can request on the client’s behalf That means the front-end server could try to access any network resource using the client’s credentials

Note

In the Windows 2000 model, the front-end server is not constrained in terms of the network resources it can request on the client’s behalf That means the front-end server could try to access any network resource using the client’s credentials.

Although both techniques are effective, the requirement to use Kerberos in Windows

2000 limits the types of clients that can be used In this scenario, only clients running Windows 2000 or later can be used With Windows Server 2003 and Windows Server

2008, you can use both NTLM and Kerberos for authentication, which allows older clients to be used, as well as clients running Windows 2000 or later In addition, with Windows Server 2003 and Windows Server 2008, you can use constrained delegation

Constrained delegation allows you to confi gure accounts so that they are delegated only for specifi c purposes This kind of delegation is based on service principal names Thus, unlike Windows 2000, in which the front-end server can access any network service on the client’s behalf, with Windows Server 2003 and Windows Server 2008, a front-end server can only access network resources for which delegation has been granted

Confi guring Delegated Authentication

To use delegated authentication, the user account, as well as the service or puter account acting on the user’s behalf, must be confi gured to support delegated authentication

com-Confi guring the Delegated User Account

For the user account, you must ensure that the account option Account Is Sensitive And Cannot Be Delegated is not selected, which by default it isn’t If you want to check this option, use Active Directory Users And Computers, as shown in the following screen

Double-click the user’s account entry in Active Directory Users And Computers, and then click the Account tab You’ll fi nd the Account Is Sensitive And Cannot Be Del-egated check box under Account Options Scroll through the list until you fi nd it