Working with Active Directory Trusts One of the many issues that need to be dealt with in any computer organization is how to protect resources.The main difficulty that administrators face is the dilemma of how to ensure that the resources of the company are not accessible by those who do not need access.The other side of that coin, equally important, is how to ensure that people who do need access are granted access with the least amount of hassle. In small companies, the issues are simpler, because multiple domains rarely exist. In today’s larger corporations and conglomerates, the issues of security are compounded. What admin- istrators need is an easy tool to manage access across multiple domains and, often, across forests. The tool is Active Directory Domains and Trusts. With Active Directory Domains and Trusts, an administrator can establish relationships between domains that will allow users in one domain to access the resources in another.This way, the administrator can ensure that all users who need access can have it without the hassles involved in having user accounts in multiple domains. Types of Trust Relationships Two or more Active Directory domains are implicitly or explicitly connected using trust relation- ships.The authentication requests made from one domain to the other domains use these relation- ships.The trusts provide a seamless coexistence of resources within the forest structure. Users are granted access to the resources in the other domain(s) after being authenticated in their own domain first. Once authenticated in their own domain, they can traverse the other domains to gain access to their resources. The primary advantage of these relationships is that administrators no longer need to create multiple user accounts for each user who needs access to resources within each domain. Administrators can now add the users of the other domains to their access control lists (ACLs) to control access to a resource.To take full advantage of these relationships, the administrator must know about the various types of trust that exist, and when to use them. Default Trusts When the Active Directory Installation Wizard is used to create a new domain within an existing forest, two default trusts are created: a parent and child trust, and the tree-root trust. Four additional types of trusts can be created using the New Trust Wizard or the command-line utility netdom. The default trust relationships inside a Windows 2000 and Windows Server 2003 forest are transi- tive, two-way trusts. A parent and child trust is a transitive, two-way trust relationship. It allows authentication requests made in the child domain to be validated in the parent domain. Because the trusts are tran- sitive, these requests pass upwards from child to parent until they reach the root of the domain namespace.This relationship will allow any user in the domain to have access to any resource in the domain if the user has the proper permissions granted. An additional transitive, two-way trust is created to simplify the navigation, the tree-root trust. This is especially needed in large organizations that might have multiple levels of child domains.The tree-root trust is a trust that is created between any child domain and the root domain.This provides a shortcut to the root.This trust relationship is also automatically created when a new domain is created. 496 Chapter 13 • Working with Trusts and Organizational Units 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 496 Shortcut Trust Shortcut trusts are transitive in nature and can either be one-way or two-way.These are explicit trusts that you create when the need exists to optimize (“shortcut”) the authentication process. Without shortcut trusts in place, authentication travels up and down the domain tree using the default parent and child trusts, or by using the tree-root trusts. In large complex organizations that use multiple trees, this path can become a bottleneck when authenticating users.To optimize access, the network administrator can create an explicit shortcut trust directly to the target domain (see Figure 13.1). These trusts are used when user accounts in one domain need regular access to the resources in another domain. Shortcut trusts can be either one- or two-way. One way shortcut trusts should be established when the users in one domain need access to resources in the other domain, but those in the second domain do not need access to resources in the first domain. Two-way trusts should be created when the users in both domains need access to the resources in the other domain.The shortcut trust will effectively shorten the authentication path, especially if the domains belong to two separate trees in the forest. Realm Trust Realm trusts are explicit trusts that are created to join a Windows Server 2003 domain to a non- Windows Kerberos v5 realm.This allows you the flexibility of creating a trust for your non- Windows networks to interoperate with the security services based on other Kerberos v5 implementations, such as with UNIX.This extension of security can be switched from one-way or two-way trusts and from transitive to non-transitive. External Trust An external trust is used when you need to create a trust between domains outside of your forest. These trusts can be one- or two-way trusts.They are always non-transitive in nature.This means that you have created an explicit trust between the two domains, and domains outside this trust are not affected.You can create an external trust to access resources in a domain in a different forest that is not already covered by a forest trust (see Figure 13.2). Working with Trusts and Organizational Units • Chapter 13 497 Figure 13.1 Shortcut Trust Forest 1 Shortcut Trust 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 497 After the trust has been established between a domain in a forest and a domain outside the forest, the security principals from the domain outside the forests will be able to access the resources in the domain inside the forest. Security principals can be the users, groups, computers, or services from the external domain.They are account holders that are each assigned a security identifier (SID) automatically to control access to the resources in the domain. The Active Directory in the domain inside the forest will then create foreign security principal objects representing each security principal from the trusted external domain.You can use these for- eign security principals in the domain local groups.This means that the domain local groups can have members from the trusted external domain.You use these groups to control access to the resources of the domain. The foreign security principals are seen in Active Directory Users and Computers. Since the Active Directory automatically creates them, you should not attempt to modify them. Forest Trust A forest trust can only be created between the root domains in two forests. Both forests must be Windows Server 2003 forests.These trusts can be one- or two-way trusts.They are considered tran- sitive trusts because the child domains inside the forest can authenticate themselves across the forest to access resources in the other forest. Forest trusts help manage the Active Directory infrastructure.They do this by simplifying the management of resources between two forests by reducing the required number of external trusts. Instead of needing multiple external trusts, a two-way forest trust between the two root domains will allow full access between all the affected domains. Additionally, the administrator can take advantage of both the Kerberos and NTLM authentication protocols to transfer authorization data between forests. 498 Chapter 13 • Working with Trusts and Organizational Units Figure 13.2 External Trust Transitive Two-Way Trust External Trust External Trust Forest 1 Forest 3 Forest 2 Windows NT 4.0 Domain 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 498 Forest trusts can provide complete two-way trusts with every domain within the two forests. This is useful if you have created multiple forests to secure data within the forest or to help isolate directory replication within each forest. Creating, Verifying, and Removing Trusts Trust relationships are created and managed using the Active Directory Domains and Trusts utility in the Administrative Tools menu.To create or manage trusts, you must be a member of the Domain Admins group or the Enterprise Admins group in the Active Directory, or have the appropriate authority delegated to you. Most administrators will use the RunAs command to manage trusts.This is generally accepted as a security best practice. Use the following steps to create a transitive, one-way incoming realm trust. Create a transitive, one-way incoming realm trust 1. Open Active Directory Domains and Trusts by clicking Start | Programs | Administrative Tools, and then selecting Active Directory Domains and Trusts. 2. In the console tree, right-click the domain node. Select Properties in the context menu. 3. On the Trusts tab, click the New Trust button. 4. When the New Trust Wizard opens, click Next. 5. On the Trust Name page, enter the target realm’s name and click Next. 6. On the Trust Type page, select Realm Trust and click Next. 7. On the Transitivity of the Trust page, click Transitive, and then click Next. 8. On the Direction of Trust page, click One-way: incoming, and then click Next. 9. On the Summary page, review the information, and then click Finish. This wizard will allow you to also create non-transitive trusts and two-way and one-way out- going realm trusts. Alternatively, you can use the netdom command to create a realm trust. Securing Trusts Using SID Filtering One security concern when using trusts is a malicious user who has administrative credentials in the trusted domain sniffing the trusting domain to obtain the credentials of an administrator account. With the credentials of the trusting domain administrator, the malicious user could add his SID to allow full access to the trusting domain’s resources.This type of threat is called an elevation of privilege attack. The security mechanism used by Windows Server 2003 to counter an elevation of privilege attack is SID filtering. SID filtering is used to verify that an authentication request coming in from the trusted domain only contains the domain SIDs of the trusted domain. It does this by using the SIDHistory attribute on a security principal. SID filtering uses the domain SID to verify each security principal. If a security principal includes a domain SID other than one from trusted domains, the SID filtering process removes the SID in question.This is done to protect the integrity of the trusting domain.This will prevent the malicious user from being able to elevate his or her own privileges or those of other users. Working with Trusts and Organizational Units • Chapter 13 499 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 499 There are some potential problems associated with SID filtering. It is possible for a user whose SID contains SID information from a domain that is not trusted to be denied access to the resources in the trusting domain.This is can be a problem when universal groups are used. Universal groups should be verified to contain only users that belong to the trusted domain. SID filtering can be disabled if there is a high level of trust for all administrators in the affected domains, there are strict requirements to verify all universal group memberships, and any migrated users have their SIDHistories preserved.To disable SID filtering, use the netdom command. Working with Organizational Units Creating OUs inside a domain allows for two different types of hierarchies. One hierarchy is the structure of the domain and child domains; the other hierarchy is the structure of the OU and its child OUs.The two hierarchies give you flexibility in how to manage the organization.The concept of placing one OU inside another is called nesting. Although there are no limits to the number of nested OUs, Microsoft recommends that you not exceed 10 levels of nesting. Understanding the Role of Container Objects OUs are not security principals. Security principals are user accounts, group accounts, and computer accounts. OUs are containers that are used to organize the Active Directory. The purpose of creating OUs is to allow the administrator to create a container that can be used to implement security policies, run scripts, deploy applications, and delegate authority for granular administrative control. Creating and Managing Organizational Units OUs are created and managed in the Active Directory Users and Computers tool in the Administrative Tools.This tool allows you to add OUs to the domain. After adding an OU, you have the ability to delegate control, add members, and move the OU.All of these activities can be accomplished by right-clicking on the OU that you want to manage and selecting the appropriate action from the context menu.The context menu will give you options to delete, rename, and enter the properties of the OU as well. The Properties window of an OU has three tabs: ■ General ■ Managed By ■ Group Policy The General tab allows you to enter a description of the OU, street, city, state/providence, zip/postal code, and country/region information. The Managed By tab allows you to change the user account that manages the OU. When a user account has been selected, the tab will display information about the account, such as office, address, and telephone numbers.This is read for the corresponding section of the user information stored about that user account.The Managed By tab has three buttons to manage this section of the OU Properties: Change,View, and Clear.The Change button opens a user window so you can select the account that will be used to manage the OU.The View button lets you see the user’s 500 Chapter 13 • Working with Trusts and Organizational Units 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 500 account Properties window.You have the opportunity of making any necessary changes to the user’s account.The Clear button removes the user account from the Managed By tab. The Group Policy tab is discussed in the next section. Create an Organizational Unit 1. Open Active Directory Users and Groups by clicking Start | Control Panel | Performance and Maintenance | Administrative Tools, and then double-click Active Directory Users and Groups. 2. In the console tree, right-click on the domain node. Select New in the context menu, and then select Organizational Unit. 3. In the New Organizational Unit window, type the name of the OU. 4. Click OK to create the OU. 5. Right-click on the new OU and select Properties from the menu. 6. On the General tab, enter a description to explain the purpose of the OU 7. Click on the Managed By tab. Click the Change button. Select a user account to manage the OU from the Users and Groups window. 8. Click the Group Policy tab. Click the New button to create a new GPO. 9. Rename the GPO by typing the new name. 10. Right-click on the GPO, and select No Override from the menu. Notice the check mark by the GPO in the No Override column (see Figure 13.3). Working with Trusts and Organizational Units • Chapter 13 501 Figure 13.3 No Override Option 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 501 11. Click the Edit button. From the GPO window, double-click User Configuration | Administrative Templates | Start Menu & Taskbar. Double-click Remove Favorites menu from Start Menu. In the window that opens, click Enable to remove favorites from the Start menu. 12. Click the Explain tab.This defines what the impact of your actions will be. 13. Click OK to close the Remove Favorites menu from Start Menu window. 14. Close the GPO window. 15. Check the Block Inheritance option. 16. Right-click on the GPO and select Disable from the menu. 17. Close all windows. Applying Group Policy to OUs One of the fundamental reasons for creating an OU is to apply a GPO to it. After creating the OU, you can then create a new GPO or apply an existing GPO.The Group Policy tab found in the OU Properties window is the most important tab of the OU properties.This is where you create, associate, and edit the GPOs that will affect the OU.This tab has the following buttons: ■ New ■ Add ■ Edit ■ Options ■ Delete ■ Properties The permissions that are set via the Security tab control the level of access that a user or group of users has over the GPO.The levels of permissions are: ■ Full Control ■ Read ■ Write ■ Create Child Objects ■ Delete Child Objects ■ Apply Group Policy At the bottom of the Group Policy tab is the option to Block Inheritance. Block Inheritance will block settings from the GPOs that would otherwise be inherited from a parent OU.This gives the child OU the ability to control which settings to accept from the parent OUs. However, if the parent has set the No Override and the child sets Block Inheritance, the No Override setting takes precedence. 502 Chapter 13 • Working with Trusts and Organizational Units 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 502 Delegating Control of OUs Delegation of control over an OU is done to alleviate the tasks of the network administrators from performing the routine functions of an OU. Often, a manager or supervisor whose account is in the OU will have a better understanding of the daily tasks associated with the users and computers that belong to the OU, and is thus well positioned to take care of the OU. Delegation is a simple pro- cess. A wizard will walk you through the process.The Delegation of Control Wizard is discussed later in the chapter. After you have decided to whom you want to delegate control, decide on which tasks to delegate. You have the ability to delegate management control over users and groups as well as the Group Policy Links.You can pass control of different activities to different people in the organization. Specifically, the levels of delegations are: ■ Create, delete, and manage user accounts ■ Reset passwords on user accounts ■ Read all user information ■ Create, delete, and manage groups ■ Modify the membership of a group ■ Manage Group Policy Links As you can see, delegation can reduce the amount of daily management tasks required by the network administrator. Planning an OU Structure and Strategy for Your Organization The OU structure can make your life easier—or it can do the opposite. If you spent time planning the structure and the implementation, the chances improve that your life will become easier and that you will be able to focus on the many facets of network administration without having to per- form daily maintenance on the OUs and user issues such as resetting passwords.Your strategy should include the following: ■ What OUs to create ■ What policies need to be applied to cover the security requirements of the OU ■ Who needs to be in charge of the OU (so you can delegate control to that user) As with any structure, you will be faced with many decisions that need to be addressed; for example, whether a domain or OU is more appropriate for a given scenario. When making these decisions, remember to factor in the ease with which growth and changes can be accommodated. Working with Trusts and Organizational Units • Chapter 13 503 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 503 Delegation Requirements Delegation of control over an OU is frequently a necessity for many organizations.The delegation allows a local manager or IT staff member to control the OU.To delegate the control, you must be a member of the Enterprise Admins or Domain Admins global groups, or you must have been granted the privilege of delegating control. From a security standpoint, when you delegate control, you should first determine the level of control that you want to grant. Just because you delegate basic administrative control over the OU does not mean that you fully relinquish control of the OU.The following procedure steps through how to delegate authority for an OU. Delegate authority for an OU 1. Click Start | Programs | Administrative Tools | Active Directory Users and Computers. 2. In the console tree, right-click the OU to be delegated. Select Delegate Control in the context menu.This invokes the Delegation of Control Wizard. 3. In the Delegation of Control Wizard, click Next to continue. 4. In the User or Groups window, click Add and then select the user who will receive the delegated control. Click Add and then click OK. Click Next to continue. 5. In the Tasks to Delegate window, select the tasks that you want to delegate. Click Next to continue. 6. In the Completing Delegation of Control window, review the information and click Finish. Security Group Hierarchy One of the issues that will need to be evaluated as you deploy Active Directory is the answer to this question: What is the effective policy that will be applied to a specific user? Because it is possible for a user to have several layers of GPOs applied, it is very possible to have conflicting policies.This sec- tion discusses how to evaluate which policy will ultimately apply. The first concept that needs to be covered is the order in which policies are applied.The first rule to remember is that a policy always overrides a profile setting.This becomes a factor as users might be moved from one OU where they use roaming profiles that allow the user a lot of liberty to configure their own settings. As these users are moved to another OU where the users’ privileges are more con- trolled, they might notice that the user profile settings are overwritten by the OU policies. 504 Chapter 13 • Working with Trusts and Organizational Units 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 504 The next concept is the order of the application of polices. Group policy is applied in this order: ■ Local computer policy ■ Site policy ■ Domain policy ■ OU policies, starting with the parent OU and working inward toward the security object through the child OUs As an administrator, you still have further control over the application of policies. Windows Server 2003 Active Directory has two settings that help you with this control: No Override and Block Inheritance.The No Override setting is set to prevent a child OU policy setting from overwriting the policy setting of the parent. It does not apply if the policy setting is not set in the parent GPO. The Block Inheritance setting allows you to control the inheritance of a policy setting in the parent by blocking it from being applied to the child. Even though you can set Block Inheritance, if the No Override option is set, No Override will be the setting that takes effect. Working with Trusts and Organizational Units • Chapter 13 505 301_BD_W2k3_13.qxd 5/12/04 12:42 PM Page 505 . access to the resources in the other domain(s) after being authenticated in their own domain first. Once authenticated in their own domain, they can traverse the other domains to gain access to their. because the child domains inside the forest can authenticate themselves across the forest to access resources in the other forest. Forest trusts help manage the Active Directory infrastructure.They. domains; the other hierarchy is the structure of the OU and its child OUs .The two hierarchies give you flexibility in how to manage the organization .The concept of placing one OU inside another is