Windows 2000 enables companies to integrate different commercial units into a unified structure, this structure is an activity directory forest, which is impossible in Windows NT 4.0. Many business units that cannot coexisted in the NT 4.0 domain can now be peacefully coexist in an organizational unit (OUS) or domain of the active directory. However, as someone who uses a single forest structure, there are also situations where some commercial units cannot be co-all. Sometimes business needs or political reasons require you to achieve separate forests. In many cases, users in the forest still need to access resources in the central forest. Therefore, you need to establish trust relationships between central forests and other forests. The method of establishing a trust relationship between different forest domains is consistent with NT 4.0. But Windows Server 2003 new forest trust function makes it simpler.
Multi-forest example
From the perspective of information security, the domain is not only a security boundary, but also the boundaries of replication and management. Members of the root domain administrator group, domain administrator group and enterprise administrator group can easily access any of the machines in the forest. The only way to truly isolate resources is to place them into separate forests.
We don't need to give up the idea of establishing a single forest, but we need to change it, ie: controlling the number of forests smallest and only increases the forest when necessary. For how to determine if you have created a forest, see Microsoft White Paper "Design Considerations for Delegation of Administration In Active Directory" (http://www.microsoft.com/activedows2000/techinfo/planning/activedirectory/addeLadmin.asp). This white paper clearly illustrates the security boundaries between the OU, the domain, and the forests, indicating how to determine if the business unit is placed in the process of separating the forest.
When do you need to separate the forest? This requires in several cases. The most common situation is to ensure manor authority (equivalent to "I don't trust you"). Another situation is the main business unit running Windows 2000 forest and cannot be updated immediately. Since this forest still takes a while, you need to find ways to coexist with it. Another situation is related to the forest architecture, please remember the architecture (such as the AD structure definition) sharing throughout the forest, if you want to change the architecture frequently, you should do these things in the separated forest, so just change the center when you need it. Forest architecture.
Resource separation is another important reason for establishing separation forests. For example, the information of the legal agency department needs to be separated, and the protected contract also needs to be separated. Some industries like banks will be punished if customer information sharing will be punished.
Trust within the forest of Windows 2000
In one forest in Windows 2000, the Kerberos security protocol automatically establishes a domain trust relationship. An important function of Kerberos is to support trust delivery. If the A domain trust the B domain, the B domain trust the C domain, then the A domain is automatically trust the C domain. The simple way to remember "your friend is my friend". This feature makes the concept of the domain tree possible, and the Kerberos bills are automatically transferred to automatically trust other domains in a field in the forest. The two-way trust in the forest in the forest is also called "internal trust". To learn more about the Kerberos technology of Windows 2000, see Microsoft White Paper "Windows 2000 Kerberos Authentication" (http://www.microsoft.com/windows/security/kerberos.asp).
Windows 2000 Trust Trust
The trust relationship outside the forest is more primitive. In Windows 2000, Kerberos cannot establish trust across the forest. NT LAN Manager (NTLM) will establish a trust relationship between NT 4.0 domains and Windows 2000 domains. These trusts are called "external trust" (the third trust, "quick trust", using Kerberos directly connects the subdomains of the two domain trees to improve performance). External Trust has the same restrictions as NT 4.0 trust: external trust is not as trusted by Kerberos and cannot be delivered. Therefore, you will soon fall into NT 4.0, you must maintain trust in every field of each forest.
Woods Trust in Windows 2003
Forest trust is a trust in connecting two forest roots. Forest trust allows you to bring your friendly forest together with a simple and easy way, faster than NTLM trust. Because forest trust uses Kerberos replaces NTLM, trust between two forests is deliverable. For example, if forest A trusts forest B, all domains in forest A trust all domains in forest B. However, this trust is not passed between forests. If forest A trusts forest B, forest B trusted forest C, forest A does not automatically trust the forest C. This is the same as NTLM trust, but it is amplified to the domain forest, like NTLM trust, you can establish one-way or two-way trust.
The advantages of forest trust
The two advantages of forest trust are cross-forest certification and authorization. Cross forest certification enables users in trusted forests to log in to the machine of trusted forests without having to create an account repeatedly. Cross-forest authorization also allows you to assign permissions to users who are trusted forests so that they can access the resources of the trusted forests without repeating accounts. This behavior will not endanger the forest security boundaries.
Although you can build external trusts between forests, but use Kerberos-based forest trust greatly reduced the number of trust in the forest. If you establish a trust relationship between all domains of the two forests, you can calculate the number of external trusts required by the following formula. The total number of external trust = (1 One-way Trust or 2 Bidirectional Trust) × (Domains in Forest A) × (Domain Number in Forest B).
For example, suppose you have a development forest (DEV) containing three domains and a production forest (PROD) containing four domains, you want the bidirectional relationship between the domains to establish all domains. You need to build 24 trust, both 2 × 3 × 4. Although this quantity can be endured, if you decide to join an integrated forest (int) containing four domains, the trust topology will be more complicated. You now have three sets of trust relationships: DEV to Prod, dev to int, prod to INT. The total number of trusts to be maintained will reach 80.
Forest trust allows you to achieve an important policy that is the account forest configuration. An account forest is essentially an enlarged amplification of the NT 4.0 account or resource domain configuration. To establish an account forest, you must first ensure that all accounts are in the main forest and then establish one-way trust from other resource forests to major forests. Users can log in to any league forest using the major forest account. You can even send the administrative power committee of the establishment of trust to users who are not belong to the enterprise management group.
You may be strange, why Windows 2003's forest trust can contain other forests, and the external trust of Windows 2000 cannot be. In Windows 2003, the Trust Domain Object (TDO) describes the basic information of external trust and forest trust. In the forest trust, TDO contains an additional attribute called "Forest Trust Information". This property contains information, tree names, and optional name suffixes in remote forests. This information is necessary for routing authentication and query remote forests. The global directory stores this information, so all domain controllers can query this information.
Configuring a forest trust with Windows 2003
To build a forest trust, you must ensure that both forests are in the forest functional level of Windows 2003. Each DC in the two forests must run Windows 2003, each domain must be upgraded to the Windows 2003 domain function level, and two forests must be upgraded to the WINDOWS 2003 forest functional level. To learn more about the functional level, see "What's new and what's improved in windows.net server?" (Http://www.winnetmag.com ,.tantdoc ID 24316). Next, the root field of the two forests must be able to find each other through DNS. If you are integrated with the company's DNS in the enterprise intranet environment, the root domain of the forest may have been able to find each other. To check, open the command prompt window on a forest server and run NSlookup. Type:
SET TYPE = NS
Then type the domain name of other forest roots (such as Test.Test.com). If the server can resolve this FQDN, NSLookup returns the authorization DC list of the domain.
If your existing DNS configuration cannot resolve other forests, you need to configure forwarding conditions for the DNS server of each forest. Add one or more forwarders to other forests to other forests. The forwarding server tells the local DNS that forwards the request to the specified IP address when receiving a request for a particular domain. For example, you have to establish forest trust between TEST1.com and Test2.com. In the Microsoft Management Console (MMC) DNS management unit, right-click on the DNS server of the forest A and select "Properties". Select "Forwarder" and enter the DNS server IP address to be forwarded, which will process the request to forest B. Repeat this process in forest B to resolve the request of forest a.
Remember that the forwarding server you use is based on manual input IP address. If these addresses change, the forwarder list must be updated, otherwise trust may fail.
After the forest, the Trust Wizard of the MMC's Active Directory and Trust Management Unit is used to establish the type of trust you expect. Let us set a two-way trust in one step in two forests.
Select "Active Directory Domains and Trusts" from the Administrative Tools menu, or type: "Run" or command line:
Domain.msc
Right-click on the root field, select "Properties", then select Trust Properties, and then select "New Trust" launch trust wizard.
This new trust wizard is new in Windows 2003. This wizard guides you to create a variety of trusts, have four target types: a Windows 2003 or Windows 2000 domain, a NT 4.0 domain, a Kerberos 5.0 area, and other forests. The help function of this wizard provides additional information on trust, functional level, and user preferences (UPNS).
Although you use the wizard to set trust operation, you should pay attention to how to set trust and review the confirmation screen before building trust. Setting trust has a variety of possibilities, and the wizard does not recommend some type. If you can't make mistakes, you may get an external trust type rather than the forest trust. For example, if you choose a sub-domain instead of the root domain, establish a forest trust will not be an option.
The first step of the wizard is to enter the DNS or NetBIOS name trusted forest. Once properly, the next dialog will ask you to choose external trust or forest trust. If the forest trust does not appear, return to the first step and use the help button to determine what is not set correctly.
Our example is to set two-way trust. When you have another forest management, the New Trust Wizard enables you to create two one-way trust to form two-way trust.
Next two dialogs allow you to allow all users of the target forest to automatically authenticate when accessing local forests. If you select "Allow Authentication Only for Selected Resources in the local forest", Windows 2003 does not automatically add trust forest authentication users SID to the token of trusted forest users; you must authorize the access resource. This feature is called "selective authentication". Selective authentication is safer, but the management workload is also larger because you must configure permissions for each domain and server to enable users of other forests to access. Trust Choose The Complete dialog box allows you to review your choice before execution. You will see this dialog after building trust. The final step of the wizard provides another useful feature. Since you have provided remote vouchers of another forest, you can confirm the trust of both parties without additional steps. After the forest trust is successfully established, the wizard will be closed, and the property book will display "Forest" under the trust type, not "Child" or "External".
Despite the straightforward trust is straightforward, a mistake will result in serious consequences in a multi-forest environment. Therefore, test exercises should be conducted before implementing forest trust.
Forest trust limit
Forest trust is not completely transparent to users. If a forest does not contain a user's account, the user does not see his account domain list in the login dialog in this forest, and he needs to enter his UPN (such as Test @ Test. COM). Microsoft uses this design because there may be a NetBIOS name conflict between domains in a multi-forest environment. For example, assuming Test1.Test1.com and Test2.Test2.com in the same geographical domain, although the FQDN is unique, if the forest does not use the same WINS namespace, they may have a NetBIOS named Namerica domain. Similarly, if your forest users are not logged in to Windows 2003 Server or Windows XP Service Pack 2 (SP2), the user or group list will be seen when the user adds a cross-forest user or group to the local forest resource. Alternatively, the UPN of the resource must be entered. Access Control Inlet (ACE) uses UPN instead of a traditional domain / account format.
Another important consideration related to UPN is the forest namespace conflict. By default, the user's UPN format is Account @ FQDN. For example, Henry has an account in the subdomain test2.test2.com, which default UPN is Henry@test2.test2.com. You can use the root domain UPN, ie Henry@test2.com. Many companies use the root domain UPN so that UPN is consistent with the user's Email address. This can work when this account exists in a forest, but what if you have the same account in two forests? Every member of the company has a Test2.com mail address, but after using this UPN suffix in a forest, other forests cannot be used again. For internal, you must choose a unique UPN suffix for users. For external, you can use Test2.com for emails.
Forest trust is an important new feature of Windows 2003, which removes many of Windows 2000. For companies that need to be collected together with the Separation Forest, forest trust function can reduce the cost of upgrading from Windows 2000 to Windows 2003.
Easily create one-way trust
