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 Server 2003, the issues you face depend on what you re migrating from. As you might expect, updating from Exchange 2000 Server to Exchange Server 2003 is pretty simple (provided you know which default settings setup changes and which ones it leaves in place). If you re migrating straight to Exchange Server 2003 from Microsoft Exchange 5.5, you might face a more complex process, because you might have to use the Active Directory Connector (ADC) to synchronize your existing Exchange 5.5 directory with Active Directory. The migration process is covered in great detail in various places (including the excellent migration pages at http://www.microsoft.com/technet/prodtechnol/exchange/exchange2003/proddocs/library/depguide.asp ), 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 Server or Windows Server 2003 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 Exchange setup program with the /forestprep option before installing the ADC. This is a change from Exchange 2000 Server, in which you d run the ADC setup tool with the /schemaonly flag.

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 Server 2003 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. 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 Server 2003 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 Server 2003.

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 Server 2003; 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 or users.

The mechanics of setting up your organization by using the /forestprep and /domainprep switches are well-documented in most Exchange administration guides (as well as in the ExDeploy.chm file that ships with Exchange Server 2003), so there s no need to repeat them here. However, this is 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 more than 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 is MemberOfPartialAttributeSet 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, because the object you name here gets Exchange Full Administrator privileges on the entire Exchange organization. Later, you ll want to delegate access to other groups; you ll probably also want to delegate ownership of the security groups that Exchange creates to this group to prevent any accidental modifications by domain administrators.

If you re forestprepping an Active Directory forest so you can add an Exchange Server 2003 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 (this, of course, means that you have to get the ADC working so that the Active Directory account will be visible on the Exchange 5.5 server). 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 Server 2003 servers or Exchange Server 2003 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 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 in Exchange 2000 Server. In Exchange Server 2003, there s an explicit deny ACL on the Servers container that prevents this. 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 few permissions. In Exchange 2000 Server, you had to perform the installation using an account that had Exchange Full Administrator privileges on the Exchange organization object. That still works in Exchange Server 2003, but you can also use accounts or groups that have Exchange Full Administrator permission on the administrative group that you re installing into.

In a brand-new Exchange Server 2003 organization, the only accounts that have the Exchange Full Administrator role are the ones you specified during /forestprep; in an existing organization, some groups or accounts will already have it. If you like, you can install Exchange System Manager, log on with the privileged account, and use Exchange System Manager to delegate Exchange Full Administrator permissions on the administrative group before installing Exchange with the account or group that you delegated to. (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.) However, if you choose to install with an account that has permissions for the administrative group but not the organization, you ll need to be aware of some caveats. You must use an account with Exchange Full Administrator permissions on the organization when:

  • Installing the first Exchange Server 2003 server in an organization, an Active Directory domain, or an administrative group.

  • Upgrading the first Exchange Server 2003 server in an organization, an Active Directory domain, or an administrative group. This doesn t apply if you ve already done a clean install of Exchange Server 2003, but if you re doing in-place upgrades, the first server you upgrade will hit this restriction.

  • Upgrading Exchange 2000 servers that are acting as directory replication connector bridgeheads.

  • Installing or removing Exchange Server 2003 servers that are running the Site Replication Service (SRS).

When you install Exchange Server 2003 using an account that only has privileges on the administrative group, you ll have an additional step: before Exchange can be started, the installation account has to be added to the domain s Exchange Domain Servers group by a domain administrator. The installation account must also have administrator privileges on the target server. If your first Exchange Server 2003 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 Server 2003 installation domains. To install additional Exchange servers, the account you use must also have Exchange Full Administrator privileges on the administrative group where you re installing.

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 Server, and applying a service pack. You might wonder why there s no third case ”that of upgrading an Exchange 5.5 server directly to Exchange Server 2003. The answer is that you cannot directly upgrade from Exchange 5.5. To update your Exchange 5.5 servers, you have two choices: you can move their mailboxes to another server, then rebuild the Exchange 5.5 servers with Exchange Server 2003, or you can upgrade them in place to Exchange 2000 Server and then upgrade them again to Exchange Server 2003. However, the mailbox-moving option is vastly easier, and that s what Microsoft is recommending for all of their Exchange 5.5 customers.

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 Server 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, 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 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 Server 2003 servers

Same as above, plus Administrator on Exchange 5.5 site and configuration containers

Move mailbox between Exchange Server 2003 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




Secure Messaging with Microsoft Exchange Server 2003
Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)
ISBN: 0735619905
EAN: 2147483647
Year: 2004
Pages: 189

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