Special Reports

Do You Need Multiple Forests?

One forest is easier to manage than multiple forests, but it might not be secure enough.

• By Stephen Perry
• 02/01/2004

Common wisdom among those who use Active Directory (AD) holds that restricting yourself to one forest is the key to success. It is said that a single forest is the only way for you to get true collaboration, full use of group policy, a global address list, and a delegated administrative model.

Unfortunately, this clear view of AD designs is sometimes clouded in the event of a company spin-off or merger. Also, your company might have critical information or accounts that need protection from other users and other administrators. A single forest requires a level of trust on your part that the other administrators will do their jobs properly. You must have full confidence that the administrators in other domains are looking out for the organization's overall best interests. You must also be confident that the administrators in the other domains are using security practices that are equal to or stricter than your own. You must also be sure that other administrators are deploying domain controllers in locations that are physically and logically secure—computer rooms must be behind protective firewalls. Finally, your administrators must understand that the security and procedural guidelines are long lasting and cannot be changed without an overall consensus or approval process.

Total account security and partitioning requires a separate forest. Most companies can be configured in a single forest environment, but some agencies and companies require a higher level of security to protect from unauthorized and administrative attacks. This doesn't mean that every company should consider multiple forests; in fact, the opposite is true. But if you have a situation where there is sensitive data that you need to protect, it might be appropriate to build a separate forest for that data, leaving the user population in a separate forest. The same is true if you have resources that might need to be accessed from the DMZ. Instead of putting a domain controller of your production forest in the DMZ, you might consider a separate application domain and leave the sensitive data within the intranet on the production forest.

It's also important to recognize and secure the service admin accounts in your domain and forest to protect domain resources and objects from accidental or malicious attacks. There are key accounts in every domain that offer the greatest risk to security: <root>\Enterprise Admins, <root>\Schema Admins, <domain>\Domain Admins, <domain>\Administrators, <domain>\Server Operators, <domain>\Backup Operators, <domain>\Account Operators, and even <domain>\Print Operators. Some of these accounts have elevated permissions that can allow administrators to impersonate users; read, modify, or delete Windows-secured resource or configuration settings on machines joined to the domains in the forest; bypass, disable, or defeat system invariants such as ACLs, auditing, Flexible Single Master Operations (FSMOs), or read-only partitions; and cause changes to replicate to other DCs.

There are reasons apart from security to consider multiple forests in your organization. The nature of your business might require autonomy or isolation. Perhaps you need the ability to manage schemas differently within your organization. Strict legal requirements could also justify the use of a separate forest to ensure that some data is protected from other administrators. One of the most common reasons: a merger where a decentralized (and not fully trusted) administrative model is in place. You might also want to consider a multiple forest model if you're building an AD structure with the intent of separating it after a spin-off or sell-off.

Consider the Drawbacks
There are legitimate reasons to create multiple forests, but you shouldn't overlook the drawbacks. For example, incorporating multiple forests adds complexity to the AD. You must account for additional software and configuration settings to provide collaborative functionality between the forests. You can also hit limits with Exchange collaboration if you use more than one Exchange organization. It's also more expensive to support multiple forests—it can require additional labor and even additional software.

That's the bad news. The good news can offset this easily, assuming you use multiple forests correctly. For example, you can allow accounts to access resources in other forests. Windows 2003 domains can leverage both domain trusts and forests trusts. If the trust is established between Windows 2003 root domains, the trust can be made transitive and thus considered a forest trust. This transitive trust among domains in the two forests is managed and controlled by the root domains, but only works when the root domains can be contacted and communicate with each other over the network. If a full transitive trust is too much, you can still create external domain trusts from a domain in one forest to a domain in another forest. You can find this functionality in both Windows 2000 and Windows 2003 domains. Both operating systems let you add accounts to global or universal groups, which you can then nest inside local domain groups and assign to resource ACLs.

The majority of your cross-forest work is probably done if you're not using Exchange Server. You should probably focus on cross-certifying your certificate servers, establishing IPSEC, and working on logon scripts, if that's the case. You should also look at your DNS structure because you will need to bridge it. Users in one AD will need to be able to resolve names, and you might also want to experiment with using multiple DNS search suffixes on the client machines to help with NetBIOS name resolution cross-domain/forest.

Exchange 2000 and 2003 are a little trickier because they leverage the global catalog servers for the address list. There are only two options for a single Exchange Global Address List (GAL) in multiple forests. First, you can opt to use only one Exchange organization. The Exchange organization could "live" in one forest while the user accounts are located in others. This is the simplest design for Exchange and not too complicated to set up. The mailbox is associated with a disabled user account in the Exchange forest. The actual user has an account in another forest, and you grant permission to his or her mailbox in the Exchange organization.

The second option is to use multiple Exchange organizations. This would likely be your choice in the event of a merger or a situation where security dictates autonomous e-mail systems. Both solutions require some type of directory synchronization because Outlook users get the address list from their local GC server. Technically, you could synchronize the directories using an LDAP Data Interchange Format (LDIF) or custom ADSI script, then create contacts in each forest from mailbox information located in other forests. This strategy is cheap and you can control it easily, but it doesn't handle deletions well and it would be a little difficult to automate. You should also know that the Interorg Connection Agreement that comes with Exchange 2003 ADC can't help in this case because it's designed to replicate with Exchange 5.5 systems.

Install MIIS
Fortunately, Microsoft has evolved its Microsoft Metadirectory Services product into something that you can install and configure yourself. Microsoft Identity Integration Server (MIIS) is the new name for an older technology that is now ready for prime time. The idea behind MIIS is a metaverse that can contain entries from disparate directories. You can replicate items in the metaverse down to the individual directories through synchronization agents. AD, NDS, eDirectory, iPlanet, X.500, Exchange, Lotus Notes, PeopleSoft, SAP, ERP, telephone switches, Microsoft SQL Server, Oracle, Informix, dBase, and even flat text files can be integrated with MIIS. MIIS is a commercial product available from Microsoft, but Microsoft also offers a smaller version at no cost for those licensed to use Windows 2003 Enterprise Server.

Identity Integration Feature Pack for Microsoft Windows Server Active Directory is a free download that you can use to synchronize users and their information with contacts in another forest (see Figure 1). You can also synchronize local, global, and universal groups as well as Exchange 2000 and Exchange 2003 global address lists. Source forest objects become target forest contacts using this tool, so the Global Address List reflects that with the globe icons that are usually associated with external accounts. The specific configuration settings are too involved to include in this article, but you will need a SQL 2000 Server, SP3 for the metaverse database, and Windows 2003 Server Enterprise edition to install the Identity Integration Feature Pack.

You will also probably have to provide free/busy information to your user community. Microsoft has updated its Inter-Organizational Replication Tool to provide public folder synchronization between Exchange organizations. The benefit of this is that each administrator can control which data is exposed to other parts of the organization because the specified folders are replicated, but not the hierarchy itself. The free/busy data is contained inside a public folder, so you can replicate the contents of that folder to other Exchange organizations and share the availability information of your users. Remember that this information only specifies when a person is available, tentative, or not available. No details of the person's appointments are shared. This distinction is important because no security is implied, available, or (probably) needed with respect to free/busy information.

The Inter-Organizational Replication Tool consists of the Replication Configuration Program and Replication Service, and you configure it in Publisher and Subscriber modes. Windows 2000 SP3 is the minimum you need if you want support for both Exchange 2000 and Exchange 2003. The Publisher and Subscriber modes must have network connectivity, including RPC and MAPI access. Meeting requests are rich-text messages supported by Outlook, so invitations to meetings, including the scheduling of conference rooms, can continue to function across forest boundaries. The primary drawback to this configuration is the limitations of delegation. A person from one organization can't see the calendar information from someone in another Exchange organization. No delegation can occur between mailboxes in different organizations.