Working with Domain Trust | Introducing Microsoft Windows Server(TM) 2003

All trusts within a Windows 2000 or Windows Server 2003 forest are transitive and two-way. Therefore, both domains in a trust relationship automatically trust each other. This means that if Domain A trusts Domain B and Domain B trusts Domain C, users from Domain C (when assigned the proper permissions) can access resources in Domain A.

Trust Protocols

A domain controller running Windows Server 2003 authenticates users and applications using one of two protocols: Kerberos V5 or NTLM. The Kerberos V5 protocol is the default protocol for computers running Windows 2000, Windows XP Professional, or Windows Server 2003. If any computer involved in a transaction does not support Kerberos V5, the NTLM protocol will be used.

With the Kerberos V5 protocol, the client requests a ticket from a domain controller in its account domain to the server in the trusting domain. This ticket is issued by an intermediary trusted by the client and the server. The client presents this trusted ticket to the server in the trusting domain for authentication.

When a client tries to access resources on a server in another domain using NTLM authentication, the server containing the resource must contact a domain controller in the client's account domain to verify the account credentials.

Trusted Domain Objects

Trusted domain objects (TDOs) are objects that represent each trust relationship within a particular domain. Each time a trust is established, a unique TDO is created and stored (in the System container) in its domain. Attributes such as a trust's transitivity, its type, and its partner domain name are represented in a TDO.

Forest trust TDOs store additional attributes in order to identify all of the trusted namespaces from its partner forest. These attributes include domain tree names , user principal name suffixes, service principal name suffixes, and security identifier namespaces.

Nontransitive Trust and Windows NT 4.0

A nontransitive trust is restricted by the two domains in the trust relationship and does not flow to any other domains in the forest. A nontransitive trust can be a two-way trust or a one-way trust.

Nontransitive trusts are one-way by default, although you can also create a two-way relationship by creating two one-way trusts. Nontransitive domain trusts are the only form of trust relationship possible between

A Windows Server 2003 domain and a Windows NT domain.
A Windows Server 2003 domain in one forest and a domain in another forest (when not joined by a forest trust).

Using the New Trust Wizard, you can manually create the following nontransitive trusts:

External trust.

A nontransitive trust created between a Windows Server 2003 domain and a Windows NT domain, a Windows 2000 domain, or a Windows Server 2003 domain in another forest. When you upgrade a Windows NT domain to a Windows Server 2003 domain, all existing Windows NT trusts are preserved intact. All trust relationships between Windows Server 2003 domains and Windows NT domains are nontransitive.
Realm trust.

A nontransitive trust between an Active Directory domain and a Kerberos V5 realm.

External Trust and Windows NT 4.0

You can create an external trust to form a one-way nontransitive relationship with domains outside your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust.

When a trust is established between a domain in a particular forest and a domain outside that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside the forest.

Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users And Computers by enabling Advanced Features.

More Information

For information about enabling Advanced Features, see "To View Advanced Features" in the Windows Server 2003 Help and Support Center.

To create an external trust, you must have Enterprise Admin or Domain Admin privileges for the domain in the Windows Server 2003 forest and Domain Admin privileges for the domain outside the forest. Each trust is assigned a password that must be known to the administrators of both domains in the relationship.

Note that in Windows 2000 mixed domains, external trusts should always be deleted from a Windows Server 2003 domain controller. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the Windows NT 4.0 or 3.51 domain controllers. However, only the trusted side of the relationship can be deleted on Windows NT 4.0 or 3.51 domain controllers. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to appear in Active Directory Domains And Trusts. To remove the trust completely, you will need to delete the trust from a Windows Server 2003 domain controller in the trusting domain. If an external trust is inadvertently deleted from a Windows NT 4.0 or 3.51 domain controller, you will need to re-create the trust from any Windows Server 2003 domain controller in the trusting domain.

How Some Windows NT Tasks Are Performed in Windows Server 2003

Table 16-3 lists common tasks for configuring Active Directory. The user interface for performing these tasks is different in this version of Windows from the way it was in Windows NT 4.0.

Table 16-3. Tasks Then and Now

Task	In Windows NT 4.0, Use	In Windows Server 2003, Use
Install a domain controller	Windows Setup	Active Directory Installation Wizard
Manage user accounts	User Manager	Active Directory Users And Computers
Manage groups	User Manager	Active Directory Users And Computers
Manage computer accounts	Server Manager	Active Directory Users And Computers
Add a computer to a domain	Server Manager	Active Directory Users And Computers
Create or manage trust relationships	User Manager	Active Directory Domains And Trusts
Manage account policy	User Manager	Active Directory Users And Computers
Manage user rights	User Manager	Active Directory Users And Computers
Manage audit policy	User Manager	Active Directory Users And Computers

Support for Existing Applications

On servers running Windows NT 4.0 and earlier, read access for user and group information is assigned to anonymous users so that existing applications, including Microsoft BackOffice, SQL Server, and some non-Microsoft applications, function correctly.

In Windows 2000 and Windows Server 2003, members of the Anonymous Logon group have read access to this information only when the group is added to the Pre-Windows 2000 Compatible Access group.

Using the Active Directory Installation Wizard, you can choose whether you want the Anonymous Logon group and the Everyone security groups to be added to the Pre-Windows 2000 Compatible Access group by choosing the Permissions Compatible With Pre-Windows 2000 Server Operating Systems option. To prevent members of the Anonymous Logon group from gaining read access to user and group information, choose the Permissions Compatible Only With Windows Server 2003 Operating Systems option.

When upgrading a domain controller from Windows 2000 to Windows Server 2003, if the Everyone security group is already a member of the Pre-Windows 2000 Compatible Access security group (indicating backward compatibility settings), the Anonymous Logon security group will be added as a member of the Pre-Windows 2000 Compatible Access security group during the upgrade.

You can manually switch between the backward-compatible and high-security settings on Active Directory objects by adding the Anonymous Logon security group to the Pre-Windows 2000 Compatible Access security group using Active Directory Users And Computers.

Note that if you select the Permissions Compatible Only With Windows Server 2003 Operating Systems option while promoting a domain controller, and you find that your applications are not functioning correctly, try resolving the problem by manually adding the special group Everyone to the Pre-Windows 2000 Compatible Access security group and then restarting the domain controllers in the domain. Once you have upgraded to applications compatible with Windows Server 2003, you should return to the more secure Windows Server 2003 configuration by removing the Everyone group from the Pre-Windows 2000 Compatible Access security group and restarting the domain controllers in the affected domain.

Top