Lesson 4:Creating Trusts in Windows Server 2003 | MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)

< Day Day Up >

You should already be familiar with the role Active Directory fulfills for authenticating users on a domain. Briefly, Active Directory stores and organizes a list of users that have access to network resources. Network resources that participate in an Active Directory domain rely on the Active Directory domain controllers to authenticate a user’s credentials before the network resource determines whether the user is authorized to access the resource. Active Directory enables administrators to organize these users in a variety of ways to delegate administrative responsibilities, simplify administration, and improve security.

Many smaller organizations are able to manage their network resources by using a single Active Directory domain. In the single domain model, all user and computer accounts are contained within a single domain. Users must have an account in that domain to access network resources. While the simplicity of a single domain makes it ideal, there are many circumstances that require multiple domains that must interact with each other.

Windows Server 2003 requires that enterprises create multiple domains to apply different security policies to users or resources. Some aspects of an enterprise’s security policy, such as minimum password length, can only be defined once for an entire Active Directory domain. Therefore, if an organization within the enterprise requires higher security than the rest of the enterprise, that organization might require its own domain. For more information about security policies, refer to Chapter 3, “Deploying and Troubleshooting Security Templates.”

Many enterprises are using multiple domains to enable compatibility with earlier operating systems. It was common practice to create separate Windows NT 4 domains for each geographic location or to separate users from resources. While those are not valid reasons to create separate Windows 2000 Server or Windows Server 2003 domains, enterprises might choose to maintain an existing, if outdated, domain model.

Managing trusts between large numbers of domains is complicated and laborious. To simplify this task, Active Directory domains can be organized into forests. A forest is a hierarchical structure that begins with a forest root domain. When domains are added to a forest, they inherit the root domain name, schema, and other characteristics from the forest root domain. Figure 1.8 shows an example of a forest.

click to expand
Figure 1.8: A forest

Enterprises that have multiple domains often need to allow users in one domain to access resources in another domain. Active Directory provides security across multiple domains and forests by using domain and forest trusts. Trusts are a critical part of a networking infrastructure and one of the concepts that seem to be misunderstood quite frequently.

Trusts in Windows Server 2003

A trust is a relationship that is established between domains or forests that enables users and other security principals from one domain to be authenticated by domain controllers in another domain. Configuring a trust enables a domain to authenticate users and other security principals that exist in a remote domain. A trust does not authorize users to access resources in the remote domain, however. Network resources authorize trusted users just as they would authorize a user in the local domain: through the use of security descriptors on the resources that need to be accessed.

For example, if John has an account in domain A and attempts to print to a printer in domain B immediately after the trust has been created, he will be denied access. However, because the trust is in place, an administrator will be able to grant John’s account access to print to the printer. Without the trust in place, the administrator would not be able to select John’s user account when authorizing users to print.

Types of trusts

Table 1.7 describes the types of trusts supported in Windows Server 2003.

Table 1.7: Windows Server 2003 Trusts
Trust type	Description
Parent/child trust	In Windows Server 2003, this is a default trust between all domains in the forest. This two-way transitive trust allows security principals to be authenticated in any domain in the forest. These trusts are created by default and cannot be removed.
Tree/root trust	In Windows Server 2003, this is a default trust between all domain trees in the forest. This two-way transitive trust allows security principals to be authenticated in any domain in the forest. These trusts are created by default and cannot be removed.
External	This trust type is created manually between domains that are not part of the forest. These trusts can be one-way or two-way and are not transitive.
Realm	This trust type is created manually between a non-Windows-brand operating system domain (referred to as a Kerberos realm) and a Windows Server 2003 domain. These trusts can be one-way or two-way and can be transitive or non-transitive.
Forest	This trust type is created manually between forests that use the Windows Server 2003 domain functional level. These trusts can be one-way or two-way and can be transitive or non-transitive.
Shortcut	This trust type is created manually within a Windows Server 2003 forest to reduce logon times between domains in a forest. This one-way or two-way trust is particularly useful when traversing tree-root trusts, because the trust path to a destination domain is potentially reduced.

Tip

You can create trusts by using the Active Directory Domains And Trusts console or the Netdom.exe command-line tool. Microsoft Windows Small Business Server 2003 does not support the creation of trusts.

Authentication methods used with trusts in Windows Server 2003

Because trusts allow you to facilitate access to resources in a multidomain environment, it is important that you use the most secure authentication protocol whenever possible when creating trusts between domains and realms. You also need to understand the various authentication types associated with each trust type. For example, if you have secured your authentication in your organization to accept only Kerberos authentication, an external trust to a Windows NT 4.0 domain will fail because a Windows NT 4.0 domain cannot use Kerberos.

Table 1.8 lists the various authentication protocols that can be used with specific trust types.

Table 1.8: Authentication Protocols Used with Trusts
Trust type	Authentication protocol
Parent/child trusts	Kerberos, NTLM
Tree/root trusts	Kerberos, NTLM
External	NTLM
Realm	Kerberos
Forest	Kerberos, NTLM
Shortcut	Kerberos, NTLM

The attributes of each authentication protocol will be discussed later in this chapter.

Note

By default, new external and forest trusts in Windows Server 2003 Active Directory enforce SID filtering.

Trust authentication protocols

The version of the server operating system you are running will determine which authentication protocols you can use across a trust. Additionally, certain operating systems have the capability to use only certain authentication protocols. For example, Windows 95 can use only the LanMan authentication protocol. Therefore, the types of trusts that you create between domains and forests depends on the operating systems used in each domain or forest. For example, if your security policy requires Kerberos authentication but you need to establish a trust to a Windows NT 4.0 domain, you will need to relax your authentication policy to allow for the NTLM protocol.

Authentication between Windows Server 2003 forests

Forest trusts provide features that other trust types cannot support, such as Kerberos authentication, user principal name (UPN) logon, and security policy support. If a forest trust feature or forest-wide authentication is needed, you must use a forest trust. Before establishing a trust between two Windows Server 2003 forests, determine if all domains will need to authenticate users from all other domains. For example, if the trust is required only to allow users from only one domain in a forest to authenticate to a single domain in a remote forest, a forest trust would be excessive. When authentication is required between a limited number of domains, establish one-way or two-way external trusts between the domains that require authentication instead of forest trusts.

Authentication between Windows Server 2003 and Windows 2000 forests

Kerberos trusts only work between Windows Server 2003 forests. You cannot create transitive Kerberos trusts between Windows Server 2003 forests and Windows 2000 forests because Windows 2000 is not able to find Kerberos Key Distribution Centers (KDCs) in other domains. To establish trusts between Windows Server 2003 and Windows 2000 forests, create one-way or two-way external trusts between forests.

Authentication between Windows Server 2003 forests and Windows NT 4.0 forests

As with Windows 2000 and Windows Server 2003, you cannot create transitive Kerberos trusts between Windows Server 2003 and Windows NT 4.0 forests. To establish trusts between Windows Server 2003 and Windows NT 4.0 domains, establish one-way or two- way external trusts between domains that need access to resources.

Authentication with servers running other operating systems

Unlike Windows 2000 and Windows NT 4.0, you can create trusts between Windows 2003 domains and domains that use UNIX or other operating systems that support MIT-compliant Kerberos versions. This type of trust is known as a realm trust. Like external trusts, realm trusts can be one-way or two-way. However, user and service accounts in the Kerberos realm do not contain group associations that are used for access control in the Windows Server 2003 environment. To make the Kerberos realm security principals aware of Active Directory, you can use account mappings in Windows Server 2003 to map accounts from the Kerberos realm to the Windows Server 2003 accounts.

Securing trusts with SID filtering

Windows grants or denies users access to resources by using access control lists (ACLs). ACLs use security identifiers (SIDs) to uniquely identify principals and their group membership. Every SID is made up of two parts: a domain SID that is shared by all principals for that domain, and a relative ID (RID) that is unique to the principal within the domain.

When a principal’s credentials are verified during authentication, a process known as the local security authority subsystem (lsass.exe) retrieves the principal’s SID, in addition to SIDs for all the groups to which the principal belongs. For example, when a user Joe, who belongs to the Administrator group, is authenticated, the local security authority subsystem retrieves Joe’s user SID and the SID for the Administrator group. When Joe requests access to a resource, his SIDs are checked by the local security authority subsystem against the ACL to determine if he is allowed to perform the action.

SID spoofing

Users with the proper privileges, such as domain administrators, can manipulate the SIDs that are associated with specific accounts. SID spoofing occurs when a domain administrator from a trusted domain attaches a well-known security principal onto the SID of a normal user account from the trusted domain. In the SID spoofing process, a rogue or coerced administrator sniffs packets from the trusted domain to find the SID of a security principal that has full access to resources in the trusted domain. Using a variety of programs, an administrator can attach the sniffed SID to the SIDHistory attribute of a user. By doing this, administrators from trusted domains can escalate their privileges in the trusted domain to access resources that they are not authorized to access.

Therefore, if you do not have confidence in other domain administrators, do not establish trust relationships with them. However, in the real world, this is not always possible. By understanding the threat, we can mitigate the vulnerability.

Real World

A recent client of mine was creating an Active Directory structure that would incorporate five Windows NT domains from four different companies into one Windows Server 2003 forest owned by the holding company. This design was chosen to support a unified mail structure between the companies. None of the domains had previously had trusts established, and the domain administrators were apprehensive about other domains having the ability to authenticate against resources in their domains. Although the decision was not the choice of the administrators, they felt better knowing that the default SID filtering and proper resource management would minimize security vulnerabilities.

Using SID filtering to secure trusts

You can use SID filtering to prevent SID spoofing. SID filtering enables administrators to discard credentials that use SIDs that are likely candidates for spoofing.

When security principals are created in a domain, the domain SID is included in the security principal’s SID to identify the domain in which it was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal’s authenticity.

Similarly, outgoing external trusts created from the trusting domain use SID filtering to verify that incoming authentication requests made from security principals in the trusted domain contain only SIDs of security principals in the trusted domain. This is done by comparing the SIDs of the incoming security principal with the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID.

You can use Netdom.exe to enable or disable SID filtering on any trust relationship between domains or forests.

Tip

If you have domains running Windows 2000 Service Pack 3 or earlier, you can use Netdom.exe to enable SID filtering on external trusts.

Disabling SID filtering

Even though it is not generally recommended, in some instances you might need to turn off SID filtering by using the Netdom.exe tool. SID filtering should be disabled only in the following situations:

You have the same level of confidence for all administrators who have physical access to domain controllers in the trusted domain as you have for the administrators in the trusting domain.
You have a strict written security policy requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.
Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on the SIDHistory attribute. For example, user accounts are migrated from domain A to domain B, but there are still resources that have not yet been migrated from domain A to domain B. To allow the migrated users in domain A to be able to access resources in domain B, you turn off SID filtering so the users can still use the old SID from domain B to access resources in domain B.

Creating trusts

You can use Active Directory Domains And Trusts to create trust relationships between forests or between domains in the same forest. You can also use it to create shortcut trusts.

Before you create a forest trust, you must ensure that the Domain Name System (DNS) name resolution is working between the two forests. You can use stub zones, conditional forwarding, secondary zones, or a shared root hints server between the two forests with proper delegation. You also need to make sure that the forest functionality level between the two forests is set to Windows Server 2003.

To create a trust, perform the following steps:

Open Active Directory Domains And Trusts.
In the console tree, right-click the domain node for the forest root domain, and then click Properties.
On the Trusts tab, click New Trust, and then click Next.
On the Welcome page of the New Trust Wizard, click Next.
On the Trust Name page, perform one of the following steps:
- If you are creating a forest trust, type the DNS name of the second forest, and then click Next.
- If you are creating a shortcut trust, type the DNS name of the domain, type and confirm the trust password, and then click Next.
- If you are creating an external trust, type the DNS name of the domain, and then click Next.
- If you are creating a realm trust, type the realm name for the target realm, and then click Next.
On the Direction Of Trust page, perform one of the following steps:
- To create a two-way trust, click Two-way, and then click Next.
- To create a one-way incoming trust, click One-way: Incoming, and then click Next.
- To create a one-way outgoing trust, click One-way: Outgoing, and then click Next.
On the Sides Of Trust page, perform one of the following steps:
- To create a trust in only the local domain, click This Domain Only, and then click Next.
- To create a trust in both the local domain and the remote domain, click Both This Domain And The Specified Domain, and then click Next. On the User Name And Password page, provide Domain Admin authentication for the remote domain, and click Next.
The remaining pages vary depending on your previous choices. Follow the instructions in the wizard to create, and optionally verify, the trust.

Practice: Creating Trusts

In this practice, you will create a cross-forest trust. You must be logged on with an account that has permission to create a cross-forest trust.

Your company, Coho Winery, needs to create a trust with your primary partner, Coho Vineyards, to share information between your organizations. You will create a cross- forest trust between the two companies by using Active Directory Domains And Trusts.

Exercise 1: Raising the Functional Level of the Windows Server 2003 Domains

When all domain controllers in a forest are using Windows Server 2003, you can raise the domain functional level to take advantage of new features that are not available in Windows 2000 Server domains. Both of the domain controllers used in the exercises in this chapter run Windows Server 2003. Therefore, in this exercise, we will raise the domain functional level to Windows Server 2003 from the default Windows 2000 Server domain functional level.

Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Click Start, click Administrative Tools, and then click Active Directory Domains And Trusts.
In the console tree, right-click cohowinery.com, and then click Raise Domain Functional Level.
Select Windows Server 2003, as shown in Figure 1.9.

Figure 1.9: Raising the domain functional level
Click Raise.
When warned that the change cannot be reversed, click OK.
Click OK again when notified that the upgrade was successful.
Repeat steps 1 through 7 on Computer2 for the cohovineyards.com domain.

Exercise 2: Creating a Cross-Forest Trust

Complete the following procedure to create a trust between cohowinery.com and cohovineyard.com.

Log on to the cohowinery.com domain on Computer1 using the Administrator account.
Click Start, click Administrative Tools, and then click Active Directory Domains And Trusts.
In the console tree, right-click cohowinery.com, and then click Properties.
Click the Trusts tab, and then click New Trust.
The New Trust Wizard appears. On the Welcome To The New Trust Wizard page, click Next.
On the Trust Name page, type cohovinyard.com as shown in Figure 1.10, and then click Next.

Figure 1.10: The Trust Name page of the New Trust Wizard
On the Direction Of Trust page, click Two-way, as shown in Figure 1.11.

Figure 1.11: The Direction Of Trust page of the New Trust Wizard
On the Sides Of Trust page, select Both This Domain And The Specified Domain, and then click Next.
On the User Name And Password page, provide the Computer2 Administrator user name and password, as shown in Figure 1.12, and then click Next.

Figure 1.12: The User Name And Password page of the New Trust Wizard
On the Outgoing Trust Authentication Level—Local Domain page, select Domain- Wide Authentication, and then click Next.
On the Outgoing Trust Authentication Level—Specified Domain page, select Domain-Wide Authentication, and then click Next.

Review the results shown in the Trust Selections Complete page, which will resemble the following:

This domain: cohowinery.com Specified domain: cohovineyard.com Direction: Two-way: Users in the local domain can authenticate in the specified  domain and users in the specified domain can authenticate in the local d main. Trust type: External Transitive: No Outgoing trust authentication level:  Domain-wide authentication in local and  specified forests. Sides of trust: Create the trust for both this domain and the specified  domain.

After reviewing the results, click Next.
On the Trust Creation Complete page, review the results to verify that the trust was created successfully. Click Next.
On the Confirm Outgoing Trust page, click No, and then click Next.
On the Confirm Incoming Trust page, click No, and then click Next.

Note
You will manually verify the trusts after completing the wizard.
On the Completing The New Trust Wizard page, click Finish.
A dialog box will notify you that SID filtering is enabled by default, as shown in Figure 1.13. Click OK.

Figure 1.13: Dialog box notifying you that SID filtering is enabled by default

Exercise 3: Verifying the Outgoing and Incoming Trusts

After creating a trust, you are returned to the Cohowinery.com Properties dialog box. Now that a trust has been created, you can use this dialog box to verify that the incoming and outgoing trusts were created successfully. To verify trusts, complete the following steps:

In the Cohowinery.com Properties dialog box, select Cohovineyard.com in the Domains Trusted By This Domain list, and then click Properties.
Click Validate.
Because this is a two-way trust, you will be automatically prompted to validate the incoming trust as well. As shown in Figure 1.14, click Yes and provide the Computer2 Administrator user name and password. Click OK.

Figure 1.14: Verifying an incoming trust
If both directions of the trust were successfully validated, a dialog box will appear explaining that the trust is in place and active.

If you experience a problem verifying the trust, test connectivity and name resolution between the domain controllers. On Computer1, open a command prompt and issue the command ping computer2.cohovineyard.com. If the ping fails, verify that Computer1 has the IP address of Computer2 configured as a secondary DNS server. Next, on Computer2, ping computer1.cohowinery.com. If the ping fails, verify that Computer2 has the IP address of Computer1 configured as a secondary DNS server.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the “Questions and Answers” section at the end of this chapter.

In which of the following situations should you use trusts? (Choose all that apply.)
1. To enable access to an external Web site by customers from dozens of different companies.
2. To enable access to shared folders by employees of a recently acquired company who have accounts in a different domain.
3. To enable all employees within an enterprise that uses multiple domains to print to a printer.
4. To enable employees of a consulting firm to send e-mail messages to internal employees with whom they are working closely.
In which of the following scenarios should you raise the domain functional level to Windows Server 2003? (Choose all that apply.)
1. An environment with domain controllers running Windows NT, Windows 2000, and Windows Server 2003 that has only client computers that run Windows XP.
2. An environment with domain controllers running Windows 2000 and Windows Server 2003 that has only client computers that run Windows NT and Windows 98.
3. An environment with only domain controllers that run Windows Server 2003 and with only client computers that run Windows 98 and Windows XP.
4. An environment with only domain controllers that run Windows Server 2003 and with only client computers that run Windows XP and Windows Server 2003.
Which type of trust should you create to enable users from a UNIX-based Kerberos realm to access resources in a Windows Server 2003 domain?
1. Parent/child trust
2. Tree/root trust
3. External
4. Realm
5. Forest
6. Shortcut
Which type of trust is automatically created when a new domain joins an existing forest?
1. Parent/child trust
2. Tree/root trust
3. External
4. Realm
5. Forest
6. Shortcut
Creating a two-way trust between DomainA and DomainB will have which of the following effects? (Choose all that apply.)
1. Enable all users in DomainA to access all shared folders in DomainB.
2. Enable members of the Domain Admins group in DomainA to access all shared folders in DomainB.
3. Enable administrators of DomainA to grant access to shared folders to users in DomainB.
4. Enable administrators of DomainA to view a list of users and groups in DomainB.

Lesson Summary

A trust is a relationship that is established between domains that enables security principals from one domain to be authenticated by domain controllers in another domain.
Use Active Directory Domains And Trusts to create trust relationships between forests or between domains in the same forest.
When all domain controllers within a domain are running Windows Server 2003, raise the domain functional level to Windows Server 2003.
The following are valid types of trusts:
- Parent/child
- Tree/root
- External
- Realm
- Forest
- Shortcut
The following are valid authentication protocols that can be used between trusts:
- NTLM
- Kerberos
You can use SID filtering to prevent SID spoofing. SID filtering enables adminis- trators to discard credentials that use SIDs that are likely candidates for spoofing.

< Day Day Up >