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