Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)

Before you start installing Exchange, it s worth examining your existing Active Directory structure, with an eye toward how you might improve its design for Exchange. Exchange is perfectly happy to reside in the typical single-domain, single-tree Active Directory forest; in fact, the majority of Exchange deployments are in just such environments. In more complex environments, though, questions often arise about where to put the Exchange servers: In a root domain? In their own child domain? In their own organizational unit (OU)? It s not strictly necessary to put the Exchange servers in any particular location; as long as each domain that will contain an Exchange server has been domain-prepped (more on that in a bit), Exchange will be happy.

Having said that, though, there are some good security reasons to segregate your Exchange servers into their own domain or OU:

• You can apply Group Policy settings to your Exchange servers only. This holds true whether you put the servers in their own OU or in a domain. If you re going to use the security templates discussed in Chapter 6, Windows Server Security Basics, remember that some of them must be applied to domain controllers used by Exchange ”an argument for putting Exchange and its global catalog (GC) and domain controller resources into their own separate domain.

• Centralizing Exchange into its own domain allows you to better separate Exchange administration from ordinary domain management tasks . Depending on your political and organizational environment, it might be very useful indeed to have an Active Directory structure that keeps Exchange administrators walled off in their own little preserve. Remember, however, that the domain is not the security boundary in Active Directory, so this segregation is not absolute.

• Putting Exchange servers in a domain separate from ordinary users reduces the risk that a user who successfully elevates his or her privileges will be able to do something nefarious to the messaging system. It also raises the difficulty bar for a rogue administrator, because he or she would have to first gain access to the Exchange domain (leaving an audit trail) before compromising accounts within it.

  Tip

  If you put your Exchange servers in their own domain, users in other domains might attempt to elevate their privileges in the Exchange servers domain by falsifying their account s SIDHistory attribute. To protect against this, you can use the netdom tool s /filtersids switch. See Microsoft Knowledge Base article 289243 or the Using SID Filtering to Prevent Elevation of Privilege Attacks white paper located at http://www.microsoft.com/windows2000/docs/SIDHist.doc .

The decision to add a new domain is not one made lightly, especially in organizations with large infrastructures or vigorous internal politics. In those cases, it might be easier to create a separate OU for the Exchange servers; that still preserves the benefits of policy application without as much administrative overhead.

Designing a Group Structure

Irrespective of the domain or OU structure that you choose, there are some other Active Directory “ related changes you should consider. First, make sure that the Schema Admins group is empty. Membership in this group is required to make changes to the schema; because schema changes are irreversible, and because they might trigger re-replication of the contents of all GC servers, it is wise to be extremely cautious about which accounts have that privilege. Keeping the Schema Admins group empty by default means that you ll have forewarning of schema changes ”watch the event log for group changes on that group and you ll know who s been added and when.

As a next step, you should probably create a security group for your Exchange administrators. When setting permissions for Exchange management (including permissions on file system objects like the Exchange binaries and message tracking directories), you should assign them to this group, not to the ordinary Domain Admins group. In fact, you should probably plan on keeping your Exchange administrators out of the Domain Admins and Enterprise Admins groups altogether. You might also find it worthwhile to set up another group for mailbox management; at many sites, the help desk or desktop support group has permission to create and manage mailboxes for end users, but no permission to manage Exchange itself.

As with prior versions of Exchange, Exchange Server 2003 can only be installed on a server that belongs to a domain. The argument about whether it s a good idea to install Exchange on a domain controller has been going on for many years . In this book, I resolve it in favor of security: my recommendation is that you install Exchange on member servers only, not domain controllers. Why?

There are four primary reasons:

• Separation of privileges Your Active Directory and Exchange administrators are probably separate groups of people. Exchange administrators don t need to physically log on to the console of domain controllers, and Active Directory administrators normally don t need to log on to Exchange servers. In fact, allowing domain administrators to log on to the console of your Exchange server can cause a security risk because they might be able to grant themselves mailbox permissions.

• Disaster recovery If your Exchange server is located on a domain controller and the computer fails, the recovery process is much more complicated because before you can restore Exchange you ll have to reboot in directory services restore mode and restore the Active Directory databases.

• Availability When Exchange is installed on a GC, the DSAccess process automatically uses the local machine s GC service, and if it fails for some reason DSAccess won t search for another one on the network. This can cause your Exchange server to behave in unexpected ways.

• Performance In a typical Exchange architecture, Microsoft recommends a rough ratio of about one GC CPU for every four Exchange CPUs ( assuming that the CPUs are of equivalent speed). Although some deployments might benefit from collocating Exchange and the GC/domain controller role, in general you ll benefit from keeping Exchange on its own servers.

  Of course, if you have a small user base, it sometimes isn t possible to purchase an additional server for messaging alone. In that case, you might have to install Exchange on a domain controller.