Identifying Trust Relationship Considerations
Trust relationships are used when connecting forests, domains, and remote UNIX Kerberos realms. Once trust relationships are created between structures, the accounts within those structures can be granted access to resources. You need to take some considerations into account when you are determining whether or not a trust should be put into place. The primary question is: Do users need to access resources within the domain/forest from the remote domain/forest? If the answer to this question is yes, you need to determine how you are going to create the trust relationship. Depending on the trust type being created, you will have options to control the level of access accounts will have within the organization.
The following sections cover the differences in the types of trust relationships that you can create within a Windows Server 2003 Active Directory environment.
 |
Montgomery Printing has decided to build an Active Directory forest for their printing operations in Boston, Calgary, New Orleans, and Des Moines. Administrators from each of the operation centers are responsible for their own resources, but no administrative responsibilities are shared between operations centers. Users from each of the operations centers are allowed to access files at each of the other locations so that they do not have to duplicate work.
Each of the operations centers were originally individual companies until Montgomery Printing took them over. Even after the take-over, they retained their own staff at each location and controlled their own resources including account policies.
To retain autonomy over their own systems, a root domain was created and each operations center was made a domain beneath the root domain. Administrative staff from Montgomery Printing were identified as the Enterprise Admins group that would have the final say over how the corporate standards were enforced, and these staff could manage the forest when necessary. The four domains ”one for each of the operations centers ”were then managed by each of the administrative staff from the four locations.
The root domain was identified as MP.local. Each domain was then created based upon the location of the operations center: Calgary.MP.local, Boston.MP.local, NewOrleans.MP.local, and DesMoines.MP.local. Administrative staff were assigned to manage each of the domains.
Because Calgary was identified as still having Windows NT 4 BDCs that needed to be migrated , Calgary.MP.local was set to the Windows Server 2003 Interim functional level, but the other domains were set to Windows Server 2003 because all of their domain controllers were running Windows Server 2003.
| |
Using the Forest Trust
When you are using multiple forests and your users need access to resources in remote forests, you should create a forest trust . A forest trust can only be created between Windows Server 2003 Active Directory forests that are running in the Windows Server 2003 functional level. By using a forest trust, you will be able to take advantage of new features available with forest and external trusts: security identifier (SID) filtering and trust authentication mechanisms (discussed later in this chapter in the sections titled Using SID Filtering and Identifying Trust Authentication Allowances ).
Using Trusts between Domains
When the forest is not at the Windows Server 2003 functional level, you will have to determine where you need to build trust relationships. These trust relationships are built to allow users from one domain to access resources in another domain. Three domain-based trust types exist: shortcut trusts, external trusts, and realm trusts.
Shortcut Trusts
You can create shortcut trusts between domains within a forest if you need to have more efficient authentication processing. Active Directory takes advantage of the shortest trust path. In Figure 4.8, users in DomainB use resources within DomainE. In this example, the shortest trust path uses DomainA, the forest root domain, and DomainD. When a user needs access to the resource within DomainE, domain controllers within each of the domains in the trust path are contacted so that the user can be granted Kerberos tickets in order to continue accessing domain controllers along the trust path, and finally, the resource.
Figure 4.8: Trust path within a forest
In Figure 4.9, a shortcut trust has been created between DomainB and DomainE. Once created, the shortcut trust is the shortest trust path to the resource. Domain controllers from DomainB and DomainE are the only ones responsible for delivering Kerberos tickets to the client, making the resource access faster and more efficient. Because these trusts are transitive, the shortest trust will be used to access the objects if the object is located within a domain that has a shorter trust path when the shortcut trust is being used instead of the parent/child trusts.
Figure 4.9: Shortcut trust path
External and Realm Trusts
Two other trust types exist: external trusts and realm trusts . External trusts are used to connect two domains that reside in different forests or an Active Directory domain to a Windows NT 4 domain. A realm trust allows an Active Directory domain to have a trust relationship with a UNIX Kerberos realm.
| |
Trish is responsible for maintaining two forests. Users in both forests need to access resources in each forest. Currently no trust relationships exist between the forests. Trish is reviewing the configuration of the forests and domains so that she can decide on a trust type. She wants to use the easiest method to create the trusts.
Within each forest, one domain is in the Windows 2000 Native Mode. The rest of the domains are at the Windows Server 2003 level. Users from all domains need to access resources within each forest.
-
Question: What type of trust can Trish create and why? Answer: Trish can create an external trust. Because the forest is not at the Windows Server 2003 functional level, the forest trust cannot be used. The only other option for tying the domains together is to use an external trust between every domain. If the forest functional levels for the forests were set at the Windows Server 2003 level, a forest trust could be created that would allow access to all domains through a transitive trust.
| |
Using these trust relationships, you can allow users from separate domains or UNIX Kerberos realms to have access to resources within your domain. The disadvantage to these trust relationships is that they are one-way non-transitive relationships. Using external trusts also allows you to take advantage of SID filtering. When planning the trust relationships you are going to use, you should understand the authentication protocols that will be used. Whenever two Windows Server 2003 domains are tied together through a trust relationship, or a UNIX realm and a Windows Server 2003 domain are tied together, the Kerberos protocol will be used to authenticate. However, any time a Windows NT 4 domain is connected through an external trust, the NT LanManager (NTLM) authentication protocol will be used.
Using SID Filtering
SID filtering is a tool that will allow you to restrict access across trust relationships. Accounts within Active Directory domains that have been put into the Windows 2000 Native Mode functional level have an attribute available known as SIDHistory . SIDHistory retains the security identifiers (SIDs) for any account that has been moved from one domain to another. Because an account obtains a new SID whenever it is moved to another domain, if SIDHistory did not keep track of the account s previous SID, the account would not be able to access the resources it had been assigned when it existed in the original domain. This could be an administrative nightmare because the administrator would have to reassign the account permissions and rights whenever a move was performed.
The SIDHistory attribute is seen as a possible security problem. A rogue administrator could modify the SIDHistory on an account to reflect another account s SID, thus gaining access to objects and resources that the rogue administrator would normally not have access to. In order to stop this SID spoofing, SID filtering can be enabled on the trust relationship, eliminating the use of the SIDHistory attribute on objects from other domains. With SID filtering in place, the account s actual SID would be the only security descriptor that could be used across the trust relationship in the target domain.
Identifying Trust Authentication Allowances
When creating the forest trust, you will have the option of selecting whether you want forestwide access, or if you want to specify selected accounts that will have access. If you select forest-wide authentication, as long as the user account is in the trusted forest, the account will be able to access resources within the other domain, given that the account has been granted permissions to do so. If selective authentication is chosen , the administrator will have to decide which accounts will be allowed across the trust and which resources the accounts will be allowed to access. Using selective authentication will increase the administrative overhead because the administrator will need to modify the access control every time a new user needs access to the resources.
EAN: 2147483647
Pages: 159