Thursday 22 March 2012

Complete Trust Relationships and Protocols


Trust Relationships
A trust relationship is a logical relationship established between domains to allow pass-through authentication, in which a trusting domain honors the logon authentications of a trusted domain. There are two domains in a trust relationship—the trusting and the trusted domain.
In Windows NT, trusts are one-way and non-transitive, and can require a great deal of administrator maintenance. Trusts were limited to the two domains involved in the trust and the trust relationship was one-way. In Windows Server 2003, trusts have three characteristics.
1.        Trusts can be created manually (explicitly) or automatically (implicitly).
2.        Trusts can be either transitive (not bound by the domains in the trust relationship) or non-transitive (bound by the domains in the trust relationship).
3.        Trusts can be one-way or two-way.

Trust Protocols
Windows Server 2003 authenticates users and applications using either the Kerberos version 5 or NTLM protocol.
·          The Kerberos version 5 protocol is the default protocol for computers running Windows Server 2003.
When using the Kerberos version 5 protocol, the client requests a ticket from a domain controller in its account domain for presentation 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

·          If any computer involved in a transaction does not support Kerberos version 5, the NTLM protocol is used. 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. A trust relationship can also be created with any MIT version 5 Kerberos realm

Trust Types
The following forms of trust relationships are supported by Windows Server 2003:
1.        Tree-root trust: Implicitly established when you add a new tree root domain to a forest. The trust is transitive and two-way.
2.        Parent-child trust: Implicitly established when you add a new child domain to a tree. The trust is transitive and two-way.
3.        Shortcut trust: Explicitly created by a systems administrator between two domains in a forest to improve user logon times. This is useful when two domains are separated by two domain trees. The trust is transitive and can be one- or two-way. A shortcut trust may also be referred to as a cross-link trust.
4.        Realm trust: Explicitly created by a systems administrator between a non– Windows Kerberos realm and a Windows Server 2003 domain. This trust provides interoperability between Windows Server 2003 and any realm used in Kerberos version 5 implementations. It can be transitive or non-transitive and one-or two-way.
5.        External trust: Explicitly created by a systems administrator between Windows Server 2003 domains that are in different forests or between a Windows Server 2003 domain and a domain whose domain controller is running Windows NT 4 or earlier. This trust provides backward compatibility with Windows NT environments and communications with domains located in other forests not joined by forest trusts. The trust is non-transitive and can be one- or two-way.
6.        Forest trust: Explicitly created by a systems administrator between two forest root domains. If a forest trust is two-way, it effectively allows all authentication requests made from one forest to reach another. The trust is transitive between two forests only and can be one- or two-way.

Understanding Forest Trusts
In Windows NT and Windows 2000, if users in one forest needed access to resources in a second forest, an administrator had to create an external trust relationship between the two domains. Because external trusts are one-way and non-transitive, they require administrator resources and limit the ability for trust paths to extend to other domains.
Forest trusts are a new feature in Windows Server 2003, extending transitivity beyond the scope of a single forest to a second Windows Server 2003 forest. Forest trusts pro-vide the following benefits:
1.        Simplified management. Forest trusts reduce the number of external trusts necessary to share resources with a second forest.
2.        Two-way trust relationships between all domains in two forests.
3.        UPN authentications can be used across two forests.
4.        Both the Kerberos and NTLM authentication protocols can be used to help improve the trustworthiness of authorization data transferred between forests.
5.        Administrative flexibility. Administrators can choose to split collaborative delegation efforts with other administrators into forest-wide administrative units.

Forest trusts can be created and are transitive between only two forests. Therefore, if a forest trust is created between Forest1 and Forest2, and a forest trust is also created between Forest2 and Forest3, Forest1 does not have an implicit trust with Forest3.

Planning Trust Relationships
When you add a Windows Server 2003 domain to an existing Windows Server 2003 forest, a tree-root or a parent-child trust is established automatically. Both of these trust relationships are two-way and transitive and are established at the time that the domain is created. Once established, these trust relationships do not need to be managed.

The four remaining types of trusts must be managed. They are
v  Shortcut trusts
v  Realm trusts
v  External trusts
v  Forest trusts

è A trust path is a series of trust relationships that must be traversed in order to pass authentication requests between any two domains.
è In a complex forest, following the trust path can take time and affect query response performance; each time clients are referred to another domain controller, the chances of a failure or of encountering a slow link are increased

When to Create a Shortcut Trust?
Windows Server 2003 provides a means for improving query response performance through shortcut trusts. Shortcut trusts help to shorten the path traveled for authentication requests made between domains located in two separate trees.
Shortcut trusts can be created only between Windows Server 2003 domains in the same forest.
Figure illustrates a shortcut trust created to shorten the trust path and improve query response performance between Domain M and Domain P. If the short-cut trust were not created, the client in Domain M would have to “walk” the trust path through domains L, K, J, N, and O before being able to communicate with the domain controller in Domain P to verify the authentication request.


v  One-Way Shortcut Trusts:
A one-way shortcut trust established between two domains located in separate domain trees can reduce the time needed to fulfill authentication requests, but from only one direction. If a one-way shortcut trust is established between Domain M and Domain P, authentication requests made in Domain M to Domain P can take full advantage of the new one-way trust path. However, when authentication requests from Domain P to Domain M are made, they cannot utilize the shortcut trust path that was created between Domain M and Domain P, and default to walking up the trust path hierarchy in order to find Domain M
v  Two-Way Shortcut Trusts:
 A two-way shortcut trust directly established between two domains located in separate domain trees can help optimize authentication requests made from users located in either domain. Therefore, authentication requests made from either Domain M to Domain P or from Domain P to Domain M can utilize the shortened shortcut trust path.

Accessing Resources Across Domains Joined by Shortcut Trust:
You can set selective authentication differently for out-going and incoming shortcut trusts, which allows you to make flexible access control decisions between domains. You set selective authentication on the Outgoing Trust Authentication Level page when you set up a shortcut trust using the New Trust Wizard.
v  If you use domain-wide authentication on the incoming shortcut trust, users in the second domain have the same level of access to resources in the local domain as users who belong to the local domain. For example, if Domain A has an incoming shortcut trust from Domain B and domain-wide authentication is used, any user from Domain B can access any resource in Domain A (assuming the user has the required permissions).

v  If you set selective authentication on an incoming shortcut trust, you need to manually assign permissions on each resource to which you want users in the second domain to have access. To do this, set an access control right ALLOWED TO AUTHENTICATE on an object for that particular user or group from the second domain.

When a user authenticates across a trust with the Selective authentication option enabled, an Other Organization security ID (SID) is added to the user’s authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, if the Other Organization SID is not already present, the server to which the user authenticates adds the This Organization SID. Only one of these special SIDs can be present in an authenticated user’s context.
Requirements:
 To create a shortcut trust, you must have Enterprise Admin or Domain Admin privileges in both domains within the forest. Each trust is assigned a password that must be known to the administrators of both domains in the relationship.


When to Create a Realm Trust?
A realm trust can be established between any non–Windows Kerberos version 5 realm and a Windows Server 2003 domain to allow cross-platform interoperability with security services based on other Kerberos version 5 implementations, such as UNIX or MIT. Realm trusts can be switched from non-transitive to transitive and back and can be either one- or two-way.
Requirements:
 To create a realm trust, you must have Enterprise Admin or Domain Admin privileges for the domain in the Windows Server 2003 forest and the appropriate administrative privileges in the target Kerberos realm.

When to Create an External Trust?
You can create an external trust to form a one-or two-way nontransitive relationship with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4 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 forest and a domain outside of 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. You can view foreign security principals in the Active Directory Users And Computers console when Advanced Features are enabled. To enable Advanced Features, select Advanced Features from the View menu on the Active Directory Users And Computers console.

When to Create a Forest Trust?
Creating a trust between two forest root domains provides a transitive relationship between every domain residing within each forest, and can be one- or two-way. Forest trusts are useful for application service providers, organizations undergoing mergers or acquisitions, collaborative business extranets, and organizations seeking solutions for administrative autonomy.


One-Way Forest Trusts:
 In a one-way forest trust, all domains in the trusted forest can utilize resources in the trusting forest, although members in the trusting forest cannot access resources in the trusted forest. For example, if you create a one-way forest trust between Forest1 (the trusted forest) and Forest2 (the trusting forest), then users in Forest1 can access resources in Forest2 (assuming the users have permissions on resources). However, users in Forest2 will not be able to access resources in Forest1 until a second forest trust is established.
Two-Way Forest Trusts:
 In a two-way forest trust, every domain in one forest trusts every domain in its partner forest implicitly. Users in either forest can access any resource located anywhere in either forest (assuming the users have permissions to the resource).
Accessing Resources Across Domains Joined by External Trust
Using Active Directory Domains and Trusts, you can determine the scope of authentication between two forests that are joined by a forest trust. You can set selective authentication differently for outgoing and incoming forest trusts, which allows you to make flexible access control decisions between forests. You set selective authentication on the Outgoing Trust Authentication Level page when you set up a forest trust using the New Trust Wizard.
v  If you use forest-wide authentication on the incoming external trust, users from the outside forest have the same level of access to resources in the local forest as users who belong to the local forest. For example, if ForestA has an incoming forest trust from ForestB and forest-wide authentication is used, any user from ForestB can access any resource in ForestA (assuming the user has the required permissions).
v  If you set selective authentication on an incoming forest trust, you must manually assign permissions on each domain and resource to which you want users in the second forest to have access. To do this, set the access control right Allowed To Authenticate on an object for that particular user or group from the second forest.
When a user authenticates across a trust with the Selective Authentication option enabled, an Other Organization security ID (SID) is added to the user’s authorization data. The presence of this SID prompts a check on the resource domain to ensure that the user is allowed to authenticate to the particular service. Once the user is authenticated, if the Other Organization SID is not already present, the server to which the user authenticates adds the This Organization SID. Only one of these special SIDs can be present in an authenticated user’s context.

No comments:

Post a Comment