| There is not a lot to secure with the forest, but what there is to secure is extremely important. Remember from our earlier discussion, a forest is a logical structural component of Active Directory. So, there won't be any setting that you make to the forest, although with Windows Server 2003 you can make a forest trust, which does deal with the forest itself. 13.6.1 Forestwide Components Three areas of Active Directory are forestwide: the global catalog, configuration context, and schema context. Every domain controller contains a copy of the configuration and schema contexts. By default, there is only one global catalog server, the first domain controller in the forest. It is typical to configure multiple global catalog servers, which can be any domain controller. A global catalog server can become a security issue if the administrator configures security- related information to be stored in the global catalog. If this secure information is located in the global catalog server, anyone who has Read access to this portion of the Active Directory database could obtain the secure information using a tool such as LDP or ADSIEdit. This is not the case by default, but caution needs to be upheld as novice administrators and applications are installed. If a green administrator starts to configure the attributes that are stored in the global catalog, it is very easy to make an attribute a part of the global catalog. Also, applications that modify the schema can also modify which attributes are included in the global catalog. If an attacker were to get into the configuration or schema context, she could glean only a few bits of information. For example, she could obtain information about the site topology and replication structure and get a listing of all domains in the forest. Although this information is not enough to gain access to Active Directory, it does provide some information that an intruder would need. In addition to the problems that could ensue from information obtained from these contexts, any changes made to them would be widespread and damage could be catastrophic since these contexts are stored on every domain controller in the entire forest. Incorrect configurations in the configuration context could render sites unrecognizable and replication could stop completely. A change to the schema can modify which attributes are associated with certain objects. The loss of these attributes can break applications, cause email to malfunction, and stop production for days. 13.6.2 Forestwide Groups The best way to ensure that forestwide functions are secure is to manage the groups that are forestwide. These groups include the Schema Admins and Enterprise Admins. There is no reason to have members in these groups as a standard practice. Instead, just place the domain administrators in the Domain Admins group , where they can manage the domain but not the IT infrastructure. Then, when a task needs to be performed by the privileges that are granted to members of the Schema and Enterprise Admins groups, an administrator can be manually placed into these groups to complete the task. The reasons for having membership in these groups are very simple. If a change needs to occur to the schema, which is rare, a user account needs to be in the Schema Admins group to perform this activity. This could include maintenance on the schema or the installation of an application that needs to modify the schema.  | Some applications modify the schema but don't explicitly instruct you that they do. If you attempt to install an application that requires schema access, but you are installing the application with a user account that is not in the Schema Admins group, you will receive an error message. This is a good way to tell if applications update or access the schema in any way during installation. | |
For the Enterprise Admins group, management of sites and creation of new domains are examples of tasks that require membership in this group. Like the Schema Admins group membership, not having a user account in the group will quickly indicate a problem if the privilege that the group provides is required for the activity. 13.6.3 Forest Trusts With Windows Server 2003 Active Directory, the limitation of not having two forests joined by a trust has been eliminated. Although many prefer the separation of two different forests for security purposes, many companies had a need to connect different companies that were in different forests. These companies usually had merged or had acquired another company. It is unreasonable in most instances to have these companies combine the domains in each forest to a single forest, so the forest trust was created. To take advantage of the forest trust, some upgrades and configurations must first be made to the domain controllers, domains, and forest. The domain controllers must all be running Windows Server 2003. Any Windows NT or Windows 2000 Server domain controllers need to be decommissioned or upgraded, since they cannot function in a forest that is trusted by another forest. Every domain in both forests that will be trusted need to be upgraded to the Windows Server 2003 domain functional level. Finally, both forests need to be upgraded to the Windows Server 2003 forest functional level. After these steps have been accomplished, the two forests can establish a trust, so that users in one forest can have the ability to access resources in the other forest. The forest trust is established between the root domains of each forest. The trust that you create can either be a one-way or two-way trust, allowing for more granular control of which users can access resources. The trusts are Kerberos-based and transitive, but are transitive only for the domains that are in the trusted forest, not additional domains or forests that are outside of the trusted forest. Providing forestwide access to your resources might make you feel a bit nervous. During the creation of the forest trust, you can control whether the trust allows the entire trusted forest to access resources or only certain accounts from the trusted forest. You will have two: -
- Forestwide authentication
-
Windows will allow all users from the trusted forest to be authenticated for all resources in the trusting forest. -
- Selective authentication
-
This restricts which users from the trusted forest will be authenticated for access to resources in the trusting forest. This will require that individual access be specified to each resource that you want to make available to users in the trusted forest. By default, no user from the trusted domain has access to any resource in the trusting forest. The Allowed to Authenticate permission on the user account properties will provide the means for the account to be authenticated by the trusting forest. 13.6.4 SID Filtering A key feature that is now turned on by default with domain controllers running Windows Server 2003 and Windows 2000 Server with Service Pack 4 (or higher) is SID filtering. This is a very important feature that protects the trusts that are created to other forests, as well as to external domains. The concept of SID filtering protects against someone modifying the SIDHistory attribute for a user account in the trusted domain to include SIDs for the trusting domain. SID filtering works by checking the SIDs for all authenticating requests from trusted domains. The incoming security principal SIDs are checked to ensure that they are all related to the trusted domain, not the trusting domain. The trust removes any SIDs associated with the trusting domain. SID filtering can be disabled, although it is not a good security practice to do so. Also, old SIDs from a migrated Windows NT domain that are in the SIDHistory attribute are to be removed by the trust. This will not allow the user to access resources that are still associated to the old Windows NT SID. Another problem that might occur from SID filtering relates to universal groups. If a user is a member of a universal group that was not created in the trusted domain, this group SID will be removed by the trust too. | 