Designing an Active Directory Structure for Exchange


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 2000 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 domainprepped (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 2000 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.

  • 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 Q289243 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 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.

start sidebar
Domain Controller or Member Server?

As with prior versions of Exchange, Exchange 2000 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 2000 on member servers only, not domain controllers. Why? There are three 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 into 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.

  • Performance In a typical Exchange architecture, you’ll need about one GC CPU for every four Exchange CPUs. 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.

end sidebar




Secure Messaging with Microsoft Exchange Server 2000
Secure Messaging with Microsoft Exchange Server 2000
ISBN: 735618763
EAN: N/A
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net