Installing Exchange

Exchange isn’t that hard to install; in fact, for single-server organizations, the hardest part of most installations is waiting for the installer to finish its work so you can start sending mail. However, because the Exchange installation process affects so many different parts of your network, from the Active Directory schema to the individual servers on which you install it, it’s important to understand the security and configuration changes that result from installing Exchange.

Preparing to Migrate

If you’re migrating to Exchange 2000 from Microsoft Exchange 5.5, you’ve already decided how you’re going to handle the migration; in particular, you’ve had to decide how to use the Active Directory Connector (ADC) to synchronize your existing Exchange 5.5 directory with Windows 2000’s Active Directory. The migration process is covered in great detail in various places (including the excellent migration pages at http://www.microsoft.com/technet/exchange/guide/), so I limit my comments here to the security requirements and implications of installing the ADC and creating connection agreements between your existing and new organizations.

First of all, when you install the ADC, remember what you’re doing: you are purposefully installing a piece of software that will mirror changes from one directory system to another. That means, naturally, that you should be careful about who has the ability to make changes to either of those systems. For example, accidentally deleting a set of accounts from the Exchange 5.5 directory might result in those accounts, and their mailboxes, being removed from Active Directory through a two- way ADC connection agreement.

Second, be aware that the first ADC you install in a Windows 2000 forest requires schema modifications, so the account used to install it must be a member of the Schema Admins group. You can work around this by allowing a member of Schema Admins (which should normally be empty, remember?) to run the ADC setup program with the /schemaonly option.

Third, whenever you install the ADC or any of its components (including the ADC management snap-in), the installation account must be a member of the Enterprise Admins group, and it must have administrator privileges on the target server.

Fourth, when you install the ADC, you’ll be prompted to specify a service account. This might seem odd, because Exchange 2000 doesn’t use service accounts. However, the ADC must account for the case when you’re installing the ADC to populate the directory in advance of installing Exchange 2000. In that case, a service account is needed to give the ADC a way to read and write configuration data. If you’re installing the ADC so you can add an Exchange 2000 server to an existing Exchange 5.5 setup, create a service account and add it to the Enterprise Admins group. Specify this service account during ADC installation, then remove it from the group (and from Active Directory, for that matter) once you’ve completed your migration to Exchange 2000.

When you want to create connection agreements, you’ll find that the required permissions differ slightly from those required for the ADC. The easiest way to get the right permissions is to log on with the ADC service account, then create connection agreements to your heart’s content (any account that has Exchange Full Administrator privileges on the Exchange organization can do the same trick). If you must set permissions manually, your account must be a member of the local Administrators group on the target ADC server. In addition, the account must have Read permission on the Exchange object (CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=yourDomain) and Full Control permission on the Active Directory Connections object beneath the Exchange object.

Preparing Your Organization and Domains

Before you can actually install Exchange, you have to complete two preparatory steps. The first step, started with the /forestprep switch, extends the Active Directory schema to support Exchange; forestprepping a forest roughly doubles the number of object classes and attributes in the schema. Forestprep also makes a number of other changes; you do one forestprep per Exchange organization. The second step, triggered by the /domainprep switch, creates domain-specific security groups and must be done in each individual domain that will host Exchange servers.

The mechanics of setting up your organization by using the /forestprep and /domainprep switches are well-documented in most Exchange administration guides, so there’s no need to repeat them here. However, this would be a good time to discuss what changes these switches make and what security issues might arise.

Understanding /forestprep

When you run Exchange Setup with the /forestprep switch (or when you install Exchange into a forest that hasn’t been prepped, in which case Setup does the forestprep for you), Setup imports the contents of 10 LDAP Data Interchange Format (LDIF) files from the product CD. These LDIF files make almost 1000 schema changes, adding, removing, and modifying object and attribute definitions to prepare your organizational Active Directory for Exchange. Because the schema definition itself is being changed, you should expect to see two waves of replication activity after this step finishes. The first wave pushes the schema changes from the schema master to all GC servers in the forest. Changing attribute definitions (in particular, modifying the isMemberOfPartialAttributeSet value of an attribute definition) causes the update sequence numbers (USNs) for all objects to be reset. That means that each domain has to re-replicate its local objects to a GC, and then all the GCs have to swap changes they’ve received. This can take a while. However, until it finishes, you won’t be able to continue your Exchange installation.

Note

I can’t overemphasize this point: if your Active Directory replication isn’t working properly, you might encounter all sorts of flaky and undesirable behavior when changing the schema, simply because schema changes trigger so much replication. Make sure that replication is working properly and that your network is passing replication traffic in a timely manner before you modify the schema.

Because /forestprep makes such sweeping changes, it requires elevated permissions. You can only run /forestprep with an account that is a member of the Enterprise Admins and Schema Admins group, and you must run it on a computer that is a member of the root domain of the Active Directory forest. For best performance, you should run setup /forestprep on the schema master itself (use Ntdsutil to find out which machine is the schema master, if necessary); you’ll also need local administrative privileges on the server you’re running on.

Do not use your regular account to perform these functions. First of all, your user account shouldn’t have elevated privileges; that’s what administrative accounts are for, after all. Second, when you run /forestprep, Exchange Setup prompts you for the identity of an administrative account or group to use as the first Exchange Full Administrator role holder. This is the time to specify the Exchange administrator group that you created earlier. Doing so ensures that the group is granted the correct privileges on the Exchange organization object, which you’ll need later when you delegate administration to other groups. Later on, you can delegate ownership of the security groups that Exchange creates to this group to prevent any “accidental” modifications by domain administrators.

If you’re forestprepping a Windows 2000 forest so you can add an Exchange 2000 server to an existing Exchange 5.5 organization, the account you use must have administrative privileges to the Exchange 5.5 site and configuration containers for the site that you’re joining. You will also need to know the site service account name and password; if your Exchange 5.5 servers are in a different domain, you’ll need to establish a two-way trust between the Exchange 5.5 servers’ domain and the forest root domain.

Understanding /domainprep

Once your forest is prepared, you still need to prepare individual domains. The root domain in the forest must be prepped so that it can accommodate public folder proxy objects; in addition, each domain that will host Exchange 2000 servers or Exchange 2000 users must be prepped. The /domainprep operation itself has several parts:

• Creating a new global security group named Exchange Domain Servers. Each time you install Exchange 2000 on a server, the computer account is added to this group. This group is security-critical: adding an ordinary user account to the group allows that account full access to servers and mailboxes. Adding an account that’s a member of Domain Admins or Enterprise Admins does not have the same effect, because there’s a deny access control entry (ACE) for those two groups on the mailbox store.

• Creating a new domain local security group named Exchange Enterprise Servers. The Exchange Domain Servers group from each domain is added as a member of this group. Exchange Enterprise Servers is given permission on a number of Active Directory objects; these permissions are inherited by the Recipient Update Service (RUS). The RUS requires these permissions so that it can update Exchange-related attributes (notably the proxy addresses that it’s responsible for maintaining) on user objects. Like Exchange Domain Servers, this group is security-sensitive; however, when the Exchange system attendant starts, it checks to ensure that no user accounts have been added to the group, removing any it finds.

• Creating the Microsoft Exchange System Objects container in the domain naming context. This container is used as the home location for a number of critical objects, including public folder objects and system mailboxes for Exchange servers.

• Changing the default domain controller policy for the domain to give the Exchange Enterprise Servers group the right to manage auditing and security logs. This is a little scary, but it’s required so that the Information Store service on each server can read system ACLs (SACLs) on objects within the domain. If this right is taken away, the Information Store won’t be able to mount any databases because it cannot read the SACLs.

To run /domainprep, you must be logged in with an account that has Domain Admin rights for the domain you’re in and local Administrator rights on the server you’re logged on to.

Tip

Rerunning /domainprep restores the default permissions that were originally granted on all the Exchange objects. You can almost always fix Exchange permissioning errors this way, although you’ll lose additional permission changes you might have made.

Performing the Actual Installation

Once you’ve completed the domain and forest preparation steps, the actual installation of Exchange requires relatively little permission. You must perform the installation using an account that has Exchange Full Administrator privileges on the Exchange organization object. In a newly minted Exchange organization, the only accounts with this role are the ones you specified during /forestprep. If you like, you can install the Exchange System Manager, log on with that account, and give other groups Exchange Full Administrator permissions before installing Exchange. (Of course, if you followed my recommendation earlier and created a security group for Exchange administrators, all you’d need to do is put the account you’re using into that group.)

The installation account must also have administrator privileges on the target server. If your first Exchange 2000 server is joining an existing Exchange 5.5 organization, the account must also have Admin permissions on the Exchange 5.5 site and configuration containers, and a two-way trust must exist between the Exchange 5.5 and Exchange 2000 installation domains. To install additional Exchange servers, the account you use must also have Exchange Full Administrator privileges.

Tip

If you create a new NTFS partition (or even a separate directory) before installing Exchange, then install Exchange into it, you’ll reduce the possibility of breaking any other programs by accidental ACL misbehavior. Of course, installing Exchange in a different location than the default of \Program files also makes it harder for an attacker to find and tamper with the Exchange binaries.

For clustered installations of Exchange, you should use the cluster service account to perform the Exchange installation. You’ll need to delegate that account Exchange Full Administrator permissions on the Exchange organization, and it will need local Administrator permissions on each of the cluster nodes.

Upgrading Servers

If you’re upgrading servers, a few special restrictions apply. There are two interesting cases: upgrading an Exchange 5.5 server to Exchange 2000, and applying a service pack.

If you’re upgrading an Exchange 5.5 computer, the account you use must already exist in Active Directory, and it must have Admin permissions on the Exchange 5.5 organization, site, and configuration containers. The installation account must also have Exchange Full Administrator permissions on the Exchange 2000 organization object and local Administrator privileges.

When installing a service pack, the account you use must have Exchange Administrator privileges on the administrative group that contains the target server, as well as local Administrator privileges on the target server itself. If you’re installing a service pack on a cluster node or a machine running the Exchange Key Management Service (KMS), the installation account must have Exchange Full Administrator privileges.

Other Installation-Related Tasks

Of course, installing Exchange is just the first step in the process of deploying an Exchange-based messaging infrastructure. There are a relatively large number of management tasks that require particular permissions, including mailbox-enabling users, creating administrative groups, managing storage groups and databases, and so on. Table 7-1 lists the most common operations and the privileges they require.

Table 7.1: Permissions Required for Various Exchange Management Tasks

Task	Required Privilege
Create or change global message formats	Exchange Administrator on Exchange organization
Create or configure connectors	Exchange Administrator on the administrative group that contains connector server
Create/delete administrative group	Exchange Administrator on the Exchange organization
Create/delete mailbox or public folder store	Exchange Administrator on the administrative group that contains target server
Create/delete routing groups	Exchange Administrator on the administrative group that contains target routing group
Create/delete storage group	Exchange Administrator on the administrative group that contains target server
Enable or disable instant messaging (IM) for a user	Mailbox-enabling permissions, plus Exchange View Only Administrator on administrative group that contains IM server
Enable or disable mailbox for user	Active Directory permissions for user account, plus Exchange View Only Administrator on administrative group of target server
Move mailbox between Exchange 5.5 and Exchange 2000 servers	Same as above, plus Administrator on Exchange 5.5 site and configuration containers
Move mailbox between Exchange 2000 mailbox stores	Active Directory permissions for user account, plus Exchange Administrator on server administrative group and local Administrator on workstation used to start move
Run Active Directory Cleanup Wizard	On the source object’s container: Read and Delete. On the target object’s container: Write and Modify