Exchange Server 2003 Deployment

 

The permissions specified in this topic also apply to Exchange 2000 Server deployments.

What permissions do I need to run ForestPrep for Exchange Server 2003 Setup?

ForestPrep updates the Active Directory® directory service schema and creates the Exchange organization object. Additionally, you will be able to specify the first Exchange Server 2003 administrator account. This account can be a user or group object. For simplicity, it is recommended that you use a group object. You will need to be logged on as a user who has the following permissions:

• Schema Admins

• Enterprise Admins

ForestPrep must be run in the domain that contains the Active Directory schema master. By default, this domain is the root domain in the forest. You do not necessarily have to run ForestPrep on the schema master; any Windows® 2000 or Windows Server™ 2003 computer in the domain is satisfactory. That said, it is a best practice to run ForestPrep on the schema master so that network interruptions and latency do not affect the schema update.

Why do some of my third-party applications stop working after I run Exchange Server 2003 ForestPrep?

After you run Exchange Server 2003 ForestPrep, some third-party applications may log error events because of a permissions error when you access mailboxes.

It is likely that these applications rely on gaining access to mailboxes through membership of the Exchange Domain Servers group. However, on each Exchange Server 2003 ForestPrep and server installation, a 'Deny ACE' is now placed on this group on the 'Servers' container.  This change was made to decrease a potential point of access for attack and to help increase the overall security of the messaging system.

To continue to allow your applications to access mailbox data, create a group and place the application's service accounts within this group. Grant this group "Send As" and "Receive As" permissions on the appropriate Exchange configuration container such as the Organization object. To help enhance security additionally, configure permissions on only those mailbox stores to which the application requires access.

What does DomainPrep for Exchange Server 2003 Setup do?

DomainPrep allows Microsoft Active Directory® directory service domain administrators to prepare their domains for Exchange 2000 Server or Exchange Server 2003 users and/or servers. DomainPrep performs the following actions when it runs:

• Creates within the domain's Users container 'Exchange Enterprise Servers' domain local group.

  • This group will contain each domain's 'Exchange Domain Servers' group that has a Recipient Update Service.

  • This group's membership is managed by a process within the Exchange System Attendant service.

  • Grants 'Exchange Enterprise Servers' group and Org Exchange Full Administrators 'Full Control' permission on this object (Recipient Update Service will add Org Exchange Full Administrators as they are delegated).

• Creates within the domain's Users container 'Exchange Domain Servers' global group.

  • This group will contain all the Exchange 2000 Server and Exchange Server 2003 servers within the domain.

  • This group's membership is managed by a process within the System Attendant (though Setup will add the server to this group).

  • Grants 'Exchange Enterprise Servers' group and Org Exchange Full Administrators 'Full Control' permission on this object (Recipient Update Service will add Org Exchange Full Administrators as they are delegated).

• Creates the 'Microsoft Exchange System Objects' container at the root of the domain.

  • This container is used to store public folder proxy objects and Exchange-related system objects (for example, the mailbox store's mailbox).

  • Assigns specific permissions on this folder. For more information about the specific permissions granted, see "Permissions Granted During Exchange Setup."

• Assigns permissions at the domain level for the 'Exchange Enterprise Servers' group. For more information about the specific permissions granted, see "Permissions Granted During Exchange Setup."

• Assigns the 'Exchange Enterprise Servers' group the user right 'Manage Auditing & Security Logs' on the Default Domain Controller Policy (Group Policy object on the Domain Controllers organizational unit).

• Assigns specific permissions on the domain's adminSDHolder container for the 'Exchange Enterprise Servers' group. For more information about the specific permissions granted, see "Permissions Granted During Exchange Setup."

• Assigns 'Exchange Enterprise Servers' group specific permissions on the domain's Pre-Windows 2000 Server Compatible Access domain local group so that the Recipient Update Service can add each domain's 'Exchange Domain Servers' group to the membership of this group. For more information about the specific permissions granted, see "Permissions Granted During Exchange Setup.

When do I need to run DomainPrep for Exchange Server 2003 Setup?

DomainPrep allows Active Directory domain administrators to prepare their domains for Exchange 2000 Server or Exchange Server 2003 users and/or servers. You should run DomainPrep in each domain that will contain:

• either Exchange 2000 Server or Exchange Server 2003 servers

• mail-enabled objects

• global catalog servers that Exchange Directory Access components could potentially use.

Additionally, you must also run DomainPrep on the root domain in the forest to ensure that Public Folder proxy objects are created successfully.

DomainPrep will create an Exchange Domain Servers global security group, an Exchange Enterprise Servers local security group, and configure the permissions so that the Exchange server can access the Active Directory database. To run DomainPrep, you must be logged on as a user who is a member of the Domain Admin group in the domain where DomainPrep is to be run.

I have noticed that DomainPrep changes the domain controller policy. The Exchange Enterprise Servers group is granted the permission to 'Manage the auditing and security logs'. Why is this required?

For the store process to support mailbox auditing, this permission is required because it allows the Exchange server to read System Access Control Lists (SACLs) within the domain. If this permission is removed, Exchange server databases will not mount. This is the only adjustment that DomainPrep makes to the domain controller policy. This policy is replicated to other domain controllers through a combination of Active Directory replication and the File Replication service. You can use the policytest.exe tool, which is provided in the Support\ExDeploy folder on the Exchange Server 2003 media, to check the replication state of the adjusted policy.

What function do the Exchange Domain Servers and Exchange Enterprise Servers groups perform?

Both these groups are created through DomainPrep. They reside in the Users container in the domain and must not be moved or renamed (otherwise, computers that are running Exchange 2000 Server or Exchange Server 2003 in the domain will shut down). Every time Exchange is installed on a computer, the computer account is added to the local Exchange Domain Servers global security group. In turn, this group is a member of the Exchange Enterprise Servers local security group in each domain. The Recipient Update Service is responsible for making sure that all Exchange group nestings are complete in the forest. The Exchange Enterprise Servers group is given various permissions on the domain naming context in Active Directory. Through these inherited permissions, the Recipient Update Service can modify Exchange-specific attributes on user accounts in each domain.

Why does the Pre-Windows 2000 Compatible Access group contain the Exchange Domain Servers group?

In the Exchange security model, every domain contains two groups: a domain global group named Exchange Domain Servers and a domain local group named Exchange Enterprise Servers. The Exchange Domain Servers group contains all the Exchange servers in that domain. The Exchange Enterprise Servers group contains the Exchange Domain Servers groups from all domains in the forest in which you have run DomainPrep. DomainPrep grants the Exchange Enterprise Servers group read and write permissions on a variety of mail-related attributes on domain partition objects. After you run DomainPrep, all Exchange servers should have these read and write permissions through the two levels of group membership.

In Exchange 2000 Server, all Exchange servers do not always have the necessary read and write permissions after you run DomainPrep. Specifically, if an Exchange server attempts to read attributes on a domain partition mailbox-enabled user object and is connected to a global catalog server in a different domain than that in which the user resides, the Exchange Enterprise Servers group is not present in the Exchange server's security token; therefore, the read and write permissions from the Exchange Enterprise Servers group do not take effect. In this case, the Exchange server acts as an authenticated user.

This is not an issue when the domain is enabled with “Permissions compatible for pre-Windows 2000 applications" because the Everyone security principal (and in Windows Server™ 2003, the Anonymous Logon security principal) has read permissions against all attributes on all objects in the domain. Therefore the Exchange server has access to the necessary data.

To help protect against cases where the domain may not have been prepared for pre-Windows 2000 applications, Exchange Server 2003 DomainPrep adds the Exchange Domain Servers group to the BUILTIN\Pre-Windows 2000 Compatible Access group within the domain. In addition, DomainPrep adds an access control entry to the Pre-Windows 2000 Compatible Access group to allow the Exchange Enterprise Servers group to modify the membership of the Pre-Windows 2000 Compatible Access group.

The policy in my company is not to allow inherited permissions from the Active Directory domain level to child containers and organization units. Is this going to cause a problem?

DomainPrep only places access control entries (ACE) for the Exchange Enterprise Servers group at the domain level; therefore, if you block inheritance, the Recipient Update Service will not be able to process user objects. The result is that new users will not be able to log on to Exchange, and policy modifications to existing users will not be applied.

Upon blocking inheritance, you have the option to either 'Remove' or 'Copy' the permissions on the selected container/organizational unit. If you choose to 'Copy' the permissions, the Recipient Update Service continues to process objects. If you choose to 'Remove' the permissions, the Recipient Update Service is unable to function in that container.

If you want to set permissions manually on an organization unit so that the Recipient Update Service can process objects, assign the Exchange Enterprise Servers group the following permissions to all user objects in the organizational unit:

• List Contents

• Read All Properties

• Read Permissions

• Write Public Information

• Write Personal Information

• Write Group Type

• Write Display Name

Additionally, the Exchange Enterprise Servers group must have the 'modify-permissions' permission on group objects. This permission is necessary to support hidden group membership.

All these permissions can be set using the ADSI Edit MMC snap-in. For more information about setting permissions at the organizational unit level, see "Implementing a Split Permissions Model."

When reviewing the Advanced Permissions tab on the domain object, I see that the 'Enterprise Exchange Servers' group appears multiple times. However, why do most of the permissions appear blank?

The Enterprise Exchange Servers group requires permissions at the domain level so that computers running Exchange 2000 Server can process new mail and mailbox-enabled users. For example, when a new mailbox-enabled user is created, the Recipient Update Service writes a set of e-mail addresses on the object and places the user in the correct address lists. The Recipient Update Service runs as part of the Exchange System Attendant process on an Exchange server. Because the computer object of the Exchange server is a member of the Exchange Domain Servers group (which in turn is a member of the Exchange Enterprise Servers group), the Recipient Update Service can successfully process updates on objects in the domain.

The permissions may appear blank in the Active Directory Users and Computers snap-in because the interface does not show all of the granular permissions that can be granted in Active Directory. Therefore, the permissions have been granted, but they are not viewable from the interface. To view all of the granular permissions, use the Dsalcs.exe tool as described in "Implementing a Split Permissions Model."

What permissions do I need to install the first Exchange server?

Assuming that ForestPrep and DomainPrep have been run, to install the first Exchange server, you must be logged on to Active Directory with the following permissions:

• Exchange Full Administrator role (which was defined during ForestPrep)

• Member of the local Administrators group on the target Exchange server

Additionally, if you are joining an existing Exchange Server 5.5 site, the logged-on account must have the following permissions to access the Exchange Server 5.5 directory, and the person installing Exchange must know the site services account name and password:

• Admin role on the Exchange Server 5.5 site naming context (for the Exchange site you want to join)

• Admin role on the Exchange Server 5.5 configuration naming context (for the Exchange site you want to join)

A two-way trust will be required between the domain where you are installing Exchange 2000 Server or Exchange Server 2003 and the domain where the server running Exchange Server 5.5 exists.

There are two independent requirements that necessitate a two-way trust between the Windows NT® domain and Active Directory. The trust from Active Directory to Windows NT is necessary because the Exchange Server 2003 message transfer agent (MTA) and Site Replication Service must use the Exchange Server 5.5 site service account, which exists in the Windows NT domain. The second one-way trust, from Windows NT to Active Directory, is required to provide appropriate rights for Exchange Server 2003 (the account specified when you install into an Exchange Server 5.5 site) to read and write to the Exchange Server 5.5 organization, site, and configuration naming contexts.

How do I delegate permissions to other administrators so that they can manage various Exchange Server 2003 services?

To delegate permissions to other users, use the Exchange Delegation Wizard that is part of the Exchange System Manager console.

You must be logged on as a user with the Exchange Full Administrator role to the organization to use the Exchange Delegation Wizard. For this reason, and for performance reasons, it is recommended that you delegate control to group objects instead of directly to users. For example, you may want to create an Active Directory group called "Seattle Exchange Admins". You can use the Exchange Delegation Wizard to allow members of this group to administer the "Seattle" admin group. A domain administrator or equivalent can change the membership of the group object to include the relevant administrator accounts.

If I move the Exchange computer accounts to a different organizational unit in Active Directory, will this affect my Exchange permissions and delegation?

No, the Exchange Administration Delegation Wizard assigns permissions in the configuration naming context of Active Directory, not the domain naming context (which is where the computer accounts reside). However, you will need to restart the System Attendant on the Exchange server after the computer account object has been moved. For more information about why you need to restart the Exchange server, see Microsoft Knowledge Base article 271335, "XADM: System Attendant Generates 9186 and 9187 Event ID Messages."

What is the difference between the Exchange Full Administrator and the Exchange Administrator role?

An Exchange Full Administrator is able to manipulate any Exchange object in the configuration naming context. Additionally, full administrators have permissions to modify the following settings on the Security tab of the following objects:

• Exchange databases

• MAPI and application public folder hierarchies

• Address lists

An Exchange Administrator can manipulate any Exchange object, but does not have the ability to delegate permissions or change the settings on the Security tab on the Exchange objects listed above. However, an Exchange Administrator can change the permissions (Security tab) on public folders.

If I grant a user or group permissions at the Exchange organization level, do these automatically flow down to all administrative groups?

Yes. Unlike Exchange Server 5.5, Exchange Server 2003 permissions are inherited.

What permissions do I need to install subsequent servers that are running Exchange Server 2003 into my organization?

In Exchange 2000 Server, administrators must be assigned the Exchange Full Administrator administrative role at the organization level to install and to remove Exchange 2000 Server, to upgrade servers, and to perform disaster recovery on servers. This requirement changed in Exchange Server 2003 to permit administrators who are assigned the Exchange Full Administrator administrative role at the administrative group level to install and to remove Exchange Server 2003, to upgrade servers, and to perform disaster recovery on servers that are in that administrative group.

The following considerations apply when you install Exchange Server 2003 on servers as an administrator who has Exchange Full Administrator permissions at the administrative group level only:

• A domain administrator must manually add the computer account of the server to the Exchange Domain Servers group.

• An administrator who has Exchange Full Administrator permissions at the organization level must perform the first installation of Exchange Server 2003 on a computer that is in an organization.

• An administrator who has Exchange Full Administrator permissions at the organization level must perform the first installation of Exchange Server 2003 in an Active Directory domain.

• An administrator who has Exchange Full Administrator permissions at the organization level must perform the first installation of Exchange Server 2003 on a computer that is in an administrative group.

• Only an administrator who has Exchange Full Administrator permissions at the organization level can upgrade computers running Exchange 2000 Server that are configured as bridgehead servers for directory replication connectors to Exchange Server 2003.

• Only an administrator who has Exchange Full Administrator permissions at the organization level can install or remove Exchange Server 2003 on servers where Site Replication Services (SRS) is installed.

If you are an administrator who is an Exchange Full Administrator in the administrative group, and you run Exchange Server 2003 Setup on a server that is not clustered, only the administrative groups that you have permissions to access appear. However, on a clustered server, Exchange Server 2003 Setup displays all administrative groups. If you select an administrative group that you do not have permissions to access, you receive an "Access Denied" message.

If you are installing subsequent servers into a mixed Exchange 2000 Server or Exchange Server 2003 and Exchange Server 5.5 site, a two-way trust is required between the domain where you are installing Exchange 2000 Server or Exchange Server 2003 and the domain where the server running Exchange Server 5.5 exists.

What permissions do I need to install Exchange Server 2003 in a cluster configuration?

For an Exchange 2000 Server cluster administrator to create, delete, or modify an Exchange Virtual Server, the cluster administrator's account and the Cluster service account require the following permissions:

• If the Exchange Virtual Server is the first Exchange Virtual Server in the Exchange organization, the cluster administrator's account and the Cluster service account must each be a member of a group that has the Exchange Full Administrator role applied at the organization level.

• If the Exchange Virtual Server is not the first Exchange Virtual Server in the organization, the cluster administrator's account and the Cluster service account must each be a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

In Exchange Server 2003, the permissions model has changed. The Windows Cluster service account no longer requires Exchange-specific permissions. Specifically, the Windows Cluster service account no longer requires that the Exchange Full Administrator role be applied to it, neither at the Exchange organization level nor at the administrative group level. Its default permissions in the forest are sufficient for it to function in Exchange Server 2003.

As with Exchange 2000 Server, the cluster administrator requires the following permissions:

• If the Exchange Virtual Server is the first Exchange Virtual Server in the organization, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at the organization level.

• If the Exchange Virtual Server is not the first Exchange Virtual Server in the organization, you must use an account that is a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

However, depending on the mode in which your Exchange organization is running (native mode or mixed mode), and depending on your topology configuration, your cluster administrators must have the following additional permissions:

• When your Exchange organization is in native mode, if the Exchange Virtual Server is in a routing group that spans multiple administrative groups, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at all the administrative group levels that the routing group spans. For example, if the Exchange Virtual Server is in a routing group that spans the First Administrative Group and Second Administrative Group, the cluster administrator must use an account that is a member of a group that has the Exchange Full Administrator role applied at First Administrative Group and must also be a member of a group that has the Exchange Full Administrator role applied at Second Administrative Group.

  Note

  Routing groups in Exchange native-mode organizations can span multiple administrative groups. Routing groups in Exchange mixed-mode organizations cannot span multiple administrative groups.

• In topologies such as parent/child domains where the cluster server is the first Exchange server in the child domain, the cluster administrator must be a member of a group that has the Exchange Administrator role or greater applied at the organization level to be able to specify the server responsible for Recipient Update Service in the child domain.

What permissions do I need to install service packs for Exchange Server 2003?

Service packs for Exchange must be installed after Exchange Server 2003. There is no integrated setup of Exchange that includes service packs. You need the following permissions to apply service packs:

• Exchange Administrator role on the administration group where the Exchange Server 2003 server exists.

• Member of the local Administrators group on the target Exchange Server 2003 server.

I have a third-party messaging application that requires full access to each user's mailbox. With Exchange Server 5.5, we grant a special account the 'Service Account Admin' permissions, and then tell the application to use this account. How can I achieve similar functionality in Exchange Server 2003?

Exchange Server 2003 security works differently from that of Exchange Server 5.5. In fact, Exchange Server 2003 does not use a site service account; instead, all services start as the local computer account.

The recommended methods of achieving the effect that you want are described in the following Microsoft Knowledge Base articles:

• 821897: "How to assign service account access to all mailboxes in Exchange Server 2003"

• 262054: "XADM: How to Get Service Account Access to All Mailboxes in Exchange 2000"

Why can domain administrators spoof mailbox-enabled user accounts in their domain?

Active Directory includes a base set of permissions that can be applied against objects within the directory. In particular, Active Directory includes the Send As extended permission. By default, the Administrators group, the Domain Admins group, the Enterprise Admins group, and the Account Operators group have Send As permissions for all users. The Administrators group permissions and the Enterprise Admins group permissions are inherited from the domain level. The Account Operators group and the Domain Admins group receive explicit permissions that are based on the definition of the user object that is in the Active Directory schema.

You may consider implementing a Deny "Send As" access control entry (ACE) against administrators for user objects in the domain. If you decide to implement a Deny "Send As" ACE against administrators for user objects in the domain, consider the following:

• An explicit Allow ACE will override an inherited Deny (in other words, explicit ACEs are applied before inherited ACEs).

• Members of the Domain Admins group are able to remove the Deny ACE and/or add an explicit Allow ACE.

• The addition of a Deny ACE may have additional consequences in your environment. For more information, see Where to Apply Permissions.

If implementing a Deny "Send As" ACE against administrators for user objects in the domain puts your messaging environment at risk, you should implement one or more of the following:

• Limit the number of domain administrators in the domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (https://go.microsoft.com/fwlink/?LinkId=31309).

• Use auditing to monitor the account logon events for those accounts that are members of the Domain Admins group.

Why do members of the Enterprise Admins group and root Domain Admins group have full control in the Exchange organization?

In Exchange 2000 Server and later versions, data about the Exchange organization is not stored in a separate directory. Exchange stores organizational data in Active Directory in the Configuration naming context. The forest administrators (members of either Enterprise Admins group or root Domain Admins group) control all aspects of the directory, and, in essence, own the data stored in the directory. Forest administrators must control the directory because a single configuration change could adversely affect the entire forest. The Configuration naming context, and, by inheritance, the Exchange organization stored within the Configuration naming context, have the following permissions:

• Enterprise Admins – Full Control

• Root Domain Admins – Read, Write, Create All Child Objects, Special Permissions

In addition to the inherited permissions, Exchange Setup adds a Deny ACE for “Send As” and “Receive As” against the Enterprise Admins group and root Domain Admins group; this prevents those administrators from accessing and spoofing mailboxes within the forest. For more information, see Permissions Granted During Exchange Setup.

You cannot remove inheritance from the Exchange organization node within the configuration naming context. If the messaging administrators do not trust the forest administrators, the messaging team should consider isolating Exchange within its own forest. For more information about deployment options, see the Exchange Server 2003 Deployment Guide (https://go.microsoft.com/fwlink/?LinkId=47569).

If you cannot put the Exchange organization in a separate forest, it is recommended that you perform one or more of the following tasks:

• Limit the number of enterprise administrators and domain administrators in the root domain by delegating specific tasks. For more information, see “Best Practices for Delegating Active Directory Administration” (https://go.microsoft.com/fwlink/?LinkId=31309).

• Use auditing to monitor the account logon events for those accounts that are members of any privileged groups, including the Enterprise Admins group and the root Domain Admins group.

• Use auditing to monitor changes that occur within the CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<root domain> portion of the directory.

Why is there a special service account in Exchange Server 5.5, when Exchange Server 2003 services can start as the LocalSystem (built-in computer account)?

Exchange Server 5.5 required a special logon account for its services because of a limitation with Windows NT Server 4.0. Although local computer accounts in Windows NT 4.0 had tokens, they did not have credentials; therefore, one computer account could not authenticate to another. Kerberos authentication is used in Windows 2000 or Windows Server 2003, and computer accounts have both tokens and credentials.

It is more secure to use the local computer account than an administrator-specified account for the following reasons:

• The local computer password is a random hexadecimal number, instead of a human-readable string.

• The local computer password changes automatically every seven days.

• The Exchange Server 5.5 service account has to be excluded from lockout policies because a brute-force attempt to log on could disable the account and shut down the Exchange services.

The computer account for my Exchange Server 2003 server was accidentally deleted from Active Directory. Although I can re-create it, will the Exchange Server 2003 services work correctly?

If you just re-add the computer account, the Exchange services will start, although you might encounter some issues such as DSAccess errors in the event log. The computer account is assigned various permissions in Active Directory during Exchange Server 2003 Setup. Therefore, run Exchange Server 2003 Setup again and select the Reinstall option; the correct permissions will be granted for your new computer account.

Alternatively, you can grant the computer account the appropriate permissions with ADSI Edit as specified in Microsoft Knowledge Base article 297295, "The Computer Account for Exchange Server Is Absent."

After you have re-created the computer account, you can grant the new account necessary permissions. To assign the appropriate permissions to the Exchange computer account, see "How to Use ADSI Edit to Add Full Control Permissions to the Exchange Computer Account."