E2 K 3 ADPerm

Working with Active Directory Permissions
in Microsoft Exchange Server 2003
Microsoft Corporation
Published: December 12, 2006
Author: Exchange Server Documentation Team
Abstract
This guide discusses the necessary minimum rights needed for Exchange administrators to
manage Exchange-related data in Active Directory as it pertains to user, inetOrgPerson,
group, and contact objects so that separation of administrative tasks can be implemented.
Comments? Send feedback to exchdocs@microsoft.com.

Contents
Working with Active Directory Permissions in Microsoft Exchange Server 2003......................1
Contents...................................................................................................................................3
Working with Active Directory Permissions in Exchange Server...............................................7
Introduction to the Working with Active Directory Permissions in Exchange Server 2003........7
What Will You Learn from This Guide?..................................................................................8
Who Should Read this Guide?..............................................................................................8
Exchange Server 2003 Data and Active Directory....................................................................9
Schema Naming Context..........................................................................................................9
Configuration Naming Context................................................................................................10
Domain Naming Context.........................................................................................................10
Exchange Server 2003 Delegation and Roles........................................................................11
Exchange Full Administrator...................................................................................................11
Exchange Administrator..........................................................................................................12
Exchange View Only Administrator.........................................................................................13
Effective Permissions Granted by the Exchange Administration Delegation Wizard..............13
Exchange Server 2003 Permissions FAQ...............................................................................15
Active Directory Connector.....................................................................................................15
How to Change the Password for the Active Directory Connector Service Account...............19
Before You Begin................................................................................................................19
Procedure............................................................................................................................19
Exchange Server 2003 Deployment.......................................................................................20
How to Use ADSI Edit to Add Full Control Permissions to the Exchange Computer Account. 32
Before You Begin................................................................................................................32
Procedure............................................................................................................................32
For More Information...........................................................................................................33
Exchange Server 2003 Management.....................................................................................33

How to Grant WMI Permissions for Message Tracking..........................................................38
Procedure............................................................................................................................38
For More Information...........................................................................................................39
Planning a Split Permissions Model.......................................................................................39
Implementing a Split Permissions Model................................................................................40
Access Control.......................................................................................................................40
Where to Apply Permissions...................................................................................................40
Applying Permissions at the Domain Level.............................................................................41
Applying Permissions at the Organizational Unit Level..........................................................41
How to Apply Permissions......................................................................................................42
Using DSACLS to Apply Permissions.....................................................................................43
How to Use DSACLS to Apply Permissions............................................................................43

Before You Begin................................................................................................................43
Procedure............................................................................................................................43
Using ADSI Edit to Apply Permissions....................................................................................44
How to Use ADSI Edit to Apply Permissions...........................................................................44

Before You Begin................................................................................................................44
Procedure............................................................................................................................45
Prerequisites to Implementing Permissions Changes............................................................46

Exchange Server 2003........................................................................................................46
Exchange 2000 Server........................................................................................................46
Permissions Granted During Exchange Setup.......................................................................47
Permissions on Objects in the Exchange Configuration Tree.................................................49

Microsoft Exchange Container............................................................................................49
ADC Connection Agreement Container...............................................................................51
Organization Container.......................................................................................................51
Address Lists Container......................................................................................................59
Addressing Container..........................................................................................................60
Recipient Update Services Container..................................................................................60
Administrative Group...........................................................................................................61
Default Top Level Hierarchy................................................................................................61
Connections Container........................................................................................................62
Servers Container...............................................................................................................62
Server Object......................................................................................................................63
Protocols Container.............................................................................................................67
System Attendant Object.....................................................................................................68
MTA Object..........................................................................................................................69
Permissions on Other Objects in the Configuration Naming Context.....................................70

Deleted Items Container......................................................................................................70
Active Directory Connector Object......................................................................................71
Permissions on Objects in the Domain Naming Context........................................................72

Domain Container...............................................................................................................72
Domain Proxy Container.....................................................................................................75
AdminSDHolder Container..................................................................................................78
Pre-Windows 2000 Server Compatible Access Group........................................................78
Exchange Enterprise Servers Group...................................................................................79
Exchange Domain Servers Group.......................................................................................80
Exchange 2000 Server Permissions FAQ...............................................................................81
General Questions..................................................................................................................81
Exchange Instant Messaging..................................................................................................84
Exchange Conferencing Server..............................................................................................84
Split Permissions Model Reference........................................................................................86
Exchange-Related Attributes on User, Group, and Contact Objects.......................................87
Exchange General Tab...........................................................................................................87
Exchange Features Tab..........................................................................................................90
E-Mail Addresses Tab.............................................................................................................90
Exchange Advanced Tab........................................................................................................91
User-Related Tasks................................................................................................................95
Mailbox-Enabling User Objects..............................................................................................96
Moving Mailboxes...................................................................................................................97
Mixed Mode Move Mailbox Permissions.............................................................................97
Permissions for Native Mode Mailbox Move Operations.....................................................99
Mailbox-Disabling User Objects..............................................................................................99
Mail-Enabling User Objects..................................................................................................102
Mail-Disabling User Objects.................................................................................................103

Removing Exchange Attributes on User Objects..................................................................105
Mail-Enabled Group Related Tasks......................................................................................109
Mail-Enabling Group Objects................................................................................................109
Mail-Disabling Group Objects...............................................................................................110
Hiding Group Membership....................................................................................................112
Removing Exchange Attributes on Group Objects................................................................113
Contact Related Tasks..........................................................................................................116
Mail-Enabling Contact Objects..............................................................................................116
Mail-Disabling Contact Objects.............................................................................................117
Removing Exchange Attributes on Contact Objects.............................................................119
Query-Based Distribution Groups.........................................................................................122
Exchange-Related Attributes of Query-Based Distribution Group Objects...........................123
Other GAL-Related User, Group, and Contact Attributes.....................................................126
DSACLS Command Syntax Snippets...................................................................................127
Copyright..............................................................................................................................130
7
Working with Active Directory Permissions

in Exchange Server
This guide discusses the necessary minimum rights needed for Exchange administrators to
manage Exchange-related data in Active Directory as it pertains to user, inetOrgPerson,
group, and contact objects so that separation of administrative tasks can be implemented.
Further, this document is a reference guide for administrators implementing a split
permissions model.
Note:
The downloadable version of this guide includes the following additional files: DSACL
Snippets. Download Working with Active Directory Permissions in Microsoft
Exchange Server 2003 to print or read offline.
Introduction to the Working with Active

Directory Permissions in Exchange
Server 2003
Working with Active Directory® directory service permissions related to Microsoft® Exchange
can be a complex task. This document has been written to aid Exchange architects in their
understanding of how Exchange uses Active Directory in the context of permissions. Further,
this document is a reference guide for administrators implementing a split permissions model.
In many organizations, there are separate administrators for Exchange and Active Directory,
which means that there is a need to delegate administrative functions, so that distinct
boundaries of administrative rights are maintained. This is known as a split permissions
model. In this type of model, operations are decentralized in that two or more operation teams
manage aspects of Exchange and Active Directory. For example, one operations team might
manage domain and forest functions (creating DNS zones, establishing new domains, and
creating user accounts), while another operations team manages Exchange-related functions
(installing Exchange servers, mailbox management, and e-mail routing). In these situations,
certain rights must be delegated to all parties so that they may complete their prescribed job
functions without compromising the operational and security boundaries.
Organizations that implement a split permissions model typically want to restrict permissions
granted to administrative personnel to the extent possible, thereby ensuring accountability
and increasing security.
8
While the majority of this guide focuses on understanding and configuring a split permissions
model, several other permission-related topics are also covered, including:
• Explanation of the schema, domain, and configuration Active Directory naming

contexts.
• Frequently asked questions (FAQ) regarding the "how" and "why" of permissions
around the Active Directory Connector, Exchange Server 2003 deployment, and
Exchange Server 2003 management.
• Specific rights granted by the Exchange Administration Delegation Wizard; specific

rights granted during Exchange ForestPrep.
• How to set permissions on Active Directory objects and classes at the domain and
organizational unit levels.
What Will You Learn from This Guide?

This guide will answer the following questions:
• How does Active Directory store and manage permissions for Exchange user and
configuration data?
• What permissions are set by the Exchange Administration Delegation Wizard, and
what are "effective" rights or permissions?
• What permissions are set during Exchange Setup?
• What permissions do I need to perform various Exchange and Exchange service

installations?
• What permissions do I need to manage the various Exchange features?
• How can I customize Exchange-related permissions in Active Directory to fit my

organization's administrative model?
• What tools are available to modify Exchange permissions in Active Directory, and
how do I use them?
Who Should Read this Guide?

This guide has been written for Exchange architects and Active Directory deployment
planners. The goal of this guide is to provide these administrators with the information that
they need to understand the level of permissions required in installing and managing
Exchange. In addition, architects and planners can use the split permissions information to
provide a detailed permissions strategy that fits the administration model of their organization.
By using the DSACLS snippets discussed in Planning a Split Permissions Model, you can
then implement the permissions strategy.
9
Because all organizations are different and determining Active Directory permissions is so
flexible, it is not possible to recommend a permissions strategy that works for all
organizations. Therefore, this guide is not prescriptive; it does not provide suggestions
around a permissions model. Use the information presented in this guide to implement the
appropriate permissions model for your organization.
Exchange Server 2003 Data and Active

Directory
Before you review the detail of Exchange-related permissions in Active Directory® directory
service, it is important that you understand the general relationship between Microsoft®
Exchange data and Active Directory.
In Active Directory, data storage is partitioned into three logical segments called naming
contexts. Each naming context replicates its changes separately among those domain
controllers in the forest that store copies (replicas) of the same naming contexts:
• Schema naming context
• Configuration naming context
• Domain naming context
You can view these naming contexts and their contents with the ADSI Edit MMC snap-in. The
ADSI Edit MMC snap-in is installed with the Windows Support Tools. You can launch the
Windows Support Tools Setup by double-clicking the Suptools.msi file in the \Support\Tools
directory on the Windows Server™ 2003 CD.
Schema Naming Context

There is only one schema naming context per forest. The schema naming context contains
the definitions of all objects that can be instantiated in Active Directory. It also stores the
definitions of all attributes that can be a part of objects in Active Directory. Every domain
controller has one fully writeable copy of the schema directory partition, although schema
updates are allowed only on the domain controller that is the schema operations master.
The schema naming context root object contains one child object for each class of objects
that can be instantiated in the Active Directory forest and contains one object for each
attribute that can be part of an object in the Active Directory forest.
Exchange 2000 Server and Exchange Server 2003 extend the schema so that Exchange
objects (for example, mail-enabled recipients, Exchange databases) can be instantiated in
10
the organization. There are no Exchange-related permissions required to extend the schema;
this function is reserved for the Schema Administrators in the forest.
Configuration Naming Context

There is only one configuration naming context per forest, and it stores forest-wide
configuration data that is required for the proper functioning of Active Directory as a directory
service. For example, all information required to ensure the proper functioning of replication is
stored in the configuration partition, which also houses information pertaining to the site
topology. Information that Active Directory uses to construct the directory tree hierarchy is
also stored in the configuration directory partition, as is network-wide, service-specific
information that applications use to connect to instances of services in the forest. Every
domain controller has one fully writeable copy of the configuration directory partition.
Exchange 2000 Server and Exchange Server 2003 store their configuration within this
naming context, specifically within cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<root domain>. Data stored by Exchange within
the Configuration naming context is protected from unauthorized access by the security
permissions configured within the Exchange System Manager using the Exchange
Delegation Wizard.
Important:
Enterprise Administrators and root domain Domain Administrators can perform
Exchange-related functions without being granted rights using the Exchange
Delegation Wizard. Although these administrators do not have Full Control, they do
have many rights. The only permissions that they do not have are Full Control, Delete
Children, Delete Tree, and No Special Permissions. So, for example, Domain
Administrators from the root domain and Enterprise Administrators can dismount and
mount Exchange stores.
Domain Naming Context

Every domain is represented by a domain naming context. The domain naming context stores
users, computers, groups, and other objects for that domain. All domain controllers that are
joined to the domain share a full writeable copy of the domain directory partition. Additionally,
all domain controllers in the forest that host the global catalog also host a partial read-only
copy of every other domain naming context in the forest. For the most part, domain naming
contexts store domain content—that is, user, group, and computer information. However,
some domain-specific configuration data is also stored in the System container of the domain
directory partition.
11
For Exchange 2000 Server and Exchange Server 2003, the domain naming context is where
mail-enabled recipients are stored. To manipulate mail-enabled recipients, permissions may
be required both on the object and within the Exchange organization.
Exchange Server 2003 Delegation and

Roles
By using the Exchange System Manager, you can delegate permissions. You can use the
Exchange Administration Delegation Wizard to delegate permissions through roles. Roles are
scenario-based. Therefore, the organization administrator can make a user or group the sub-
administrator of the Exchange organization, thus granting limited access to certain objects.
Selecting the role in the Exchange delegation wizard sets a number of granular permissions
in Active Directory® directory service.
Enterprise administrators may want to have more granular details on the exact changes that
the Delegation Wizard makes to Active Directory. This chapter explains those changes.
By using the Exchange Administration Delegation Wizard, permissions are applied at the
Microsoft® Exchange container level in the Active Directory configuration naming context and
inherited throughout the organization. These permissions do not grant any access to objects
stored within the domain naming contexts of the forest (that is, where user, group, and
contact objects are stored), allowing for higher levels of security and separation.
Exchange Full Administrator

When you assign a user or a group Exchange Full Administrator permissions, the user or the
group can fully administer Exchange Server computer information and modify permissions. A
user who has Exchange Full Administrator permissions has the following rights:
Organization Rights:
• Full Control permissions on the MsExchConfiguration container (this object and its
subcontainers).
• Deny Receive-As permissions and Send-As permissions on the Organization

container (this object and its subcontainers).
• Read permissions and Change permissions on the Deleted Objects container in the
Configuration naming context (Config NC) (this object and its subcontainers).
Administrative Group Rights:
• Read, List object, and List contents permissions on the MsExchConfiguration

container (this object only).
12
• Read, List object, and List contents permissions on the Organization container (this
object and its subcontainers).
• Full Control, Deny Send-As, and Deny Receive-As permissions on the Administrator
Groups container (this object and its subcontainers).
• Full Control permissions (except for Change) on the Connections container (this
object and its sub-containers).
• Read, List object, List contents, and Write properties permissions on the Offline
Address Lists container (this object and its subcontainers).
Exchange Administrator
When you assign a user or a group Exchange Administrator permissions, the user or the
group can fully administer Exchange Server computer information. A user who has Exchange
Administrator permissions has the following rights:
• All permissions (except for Change permissions) on the MsExchConfiguration

• Deny Receive-As permissions and Send-As permissions on the Organization


• All permissions (except for Change, Deny Send-As, and Deny Receive-As
permissions) on the Administrator Group container (this object and its sub-containers).
• All permissions (except for Change permissions) on the Connections container (this
• Read, List object, List contents, and Write properties permissions on the Offline
Address Lists container (this object and its subcontainers).
13
Exchange View Only Administrator

When you assign a user or a group Exchange View Only Administrator permissions, the user
or the group can view Exchange Server configuration information. A user who has Exchange
View Only Administrator permissions has the following rights:

container (this object and its sub-containers).
• View Information Store Status permissions on the Organization container (this object
and its sub-containers).

object only).
• Read, List object, and List contents permissions on the Administrator Groups
• Read, List object, List contents, and View Information Store Status permissions on
the Administrator Groups container (this object and its sub-containers).
• Read, List object, and List contents permissions on the MsExchRecipientsPolicy

container, the Address Lists container, Addressing, Global Settings, System Policies (this
object and its sub-containers).
Effective Permissions Granted by the

Exchange Administration Delegation
Wizard
The Exchange Administration Delegation Wizards allows you to define roles at the
organization level, or at the administrative group level. Where you define a role, combined
with the role that you grant may create "effective" permissions. Effective permissions are
permissions granted as a side-effect of a granted permission. For example, when you assign
a group view-only permissions at the Organization level, the group will also have view-only
permissions at the Administrative Group level. Thus, the effective, or actual, permissions of
the group are view-only at both the Organization and Administrative Group levels.
More specifically, at the administrative group level:

14
• Exchange Administrator includes Exchange View Only Administrator at the

organization level.
• Exchange Full Administrator includes both Exchange Administrator at the

administrative group level and Exchange View Only Administrator at the organization
level.
• Exchange View Only Administrator at the organizational level.
Additionally, at the organization level:
• Exchange View Only Administrator includes Exchange View Only Administrator at the
administrative group level.
• Exchange Administrator includes Exchange View Only Administrator at the

organization level, which gives Exchange Administrator Exchange View Only
Administrator at the administrative group level.
• Exchange Full Administrator includes all other permissions at both the organization
and administrative group levels.
The following table provides a summary of the effective permissions versus the granted
permissions.
Effective permissions versus granted permissions
Granted AG: View AG: Admin AG: Full ORG: ORG: ORG: Full
Permissio Admin View Admin Admin
ns
AG: Yes None None Yes None None

Exchange
View Only
Administra
tor
AG: Yes Yes* None Yes None None

Exchange
Administra
tor
AG: Yes Yes* Yes* Yes None None

Exchange
Full
Administra
tor
15
Granted AG: View AG: Admin AG: Full ORG: ORG: ORG: Full
Permissio Admin View Admin Admin
ns
ORG: Yes None None Yes None None

Exchange
View Only
Administra
tor
ORG: Yes Yes None Yes Yes None

Exchange
Administra
tor
ORG: Yes Yes Yes Yes Yes Yes

Exchange
Full
Administra
tor
* = Local administrative group only AG = Administrative group level ORG = Organization

level
Exchange Server 2003 Permissions FAQ

This section provides answers to frequently asked questions (FAQ) about permissions that
have been collected since Microsoft® Exchange 2000 Server was introduced. The majority of
these FAQs apply to both Exchange 2000 Server and Microsoft Exchange Server 2003.
Sometimes the FAQ only applies to Exchange Server 2003, and that fact is noted. For more
information about permissions specific to Exchange 2000 Server features, see Exchange
2000 Server Permissions FAQ.
Many answers in this section describe specific permission changes that you can make to
allow or disable access. If you are not familiar with the tools you can use to make permission
changes, see Implementing a Split Permissions Model.
Active Directory Connector

What permissions do I need to install the first Active Directory Connector (ADC) in my
Microsoft Windows® 2000 or Windows Server 2003™ Active Directory forest?
16
To install the first Active Directory Connector (ADC), you must update the schema of
Active Directory and copy the binary files to the local computer. Therefore, you must be
logged on as a user with the following permissions:
• Schema Admins
• Enterprise Admins
• Member of the local Administrators group on the target ADC server
As an alternative, an administrator in the Schema Admins group can use the /SchemaOnly
command-line switch with Active Directory Connector Setup to extend the Active Directory
schema. In this scenario, the person who actually installs the ADC service does not need to
be a member of the Schema Admins group. An advantage to this method is that, if a company
has very strict control over the schema, personnel who have the responsibility of monitoring
the schema can make the schema adjustments required, and the ADC/Exchange
administrator can perform his or her job independently.
It is recommended that you follow the best practices defined in the Exchange Server 2003
Deployment Guide when deploying the ADC Service. The best practice recommendation is to
run ForestPrep, run DomainPrep, and then install the ADC service.
What permissions do I need to install subsequent Active Directory Connector servers

into my Active Directory forest?
Because the schema has already been updated, you need the following Active Directory
permissions to install additional connectors:
• Domain Administrator
• Member of the local Administrators group on the target ADC server
The ADC setup program has a hard-coded prerequisite where you must belong to the
Domain Admins group in Active Directory. You must belong to this group even if you only want
to install the ADC Management snap-ins on a computer.
When installing the Active Directory Connector service, I need to enter a service
account. Why is this required when Exchange services start as LocalSystem? What
permissions will the service account require?
The ADC requires a service account because a subset of the ADC technology is shipped with
the Windows Server operating system. Exchange has features to prepare the Active Directory
forest and domains for installation of the server (with the use of ForestPrep and
DomainPrep). Part of this preparation involves setting permissions for LocalSystem services
to Active Directory. Because the ADC can be used without Microsoft Exchange 2000 Server
or Exchange Server 2003 installed, a separate service account is used to achieve the same
functionality.
The ADC service account requires the following permissions:

17
• Member of the local Administrators group on the target ADC server (to write local
security authority, or LSA, Global Secrets).
• Member of the Enterprise Admins group if the ADC is used in a Windows 2000 or
Windows Server 2003–based environment without Exchange 2000 Server or
Exchange Server 2003.
• Either a member of the Enterprise Admins group or the role of Exchange Full
Administrator at the Organization level if the ADC is used with Exchange 2000 Server or
Exchange Server 2003 and not just Windows 2000 or Windows Server 2003.
For more information about how the ADC writes to LSA Global Secrets, see Microsoft
Knowledge Base article 253830, "XADM: How the Active Directory Connector Stores
Passwords."
The ADC service account requires permissions to modify the Exchange configuration
information in the Active Directory database because configuration connection agreements
(CCAs) do not have credentials set on them by default. Therefore, the ADC must assume that
the service account has all the necessary permissions to make the Active Directory changes.
If you are going to deploy Exchange Server 2003 by joining an existing Exchange Server
version 5.5 organization, you may install the ADC first. If you want, you can put the ADC
service account into the Enterprise Admins group for the initial installation, and subsequently
delegate the correct Exchange role after the first server running Exchange Server 2003 has
been installed. You can then remove the ADC service account from the Enterprise Admins
group.
As mentioned above, however, if you follow the best practices in the Exchange Server 2003
Deployment Guide, you can grant the ADC service account Exchange Full Admin permissions
by means of the Exchange System Manager Administration Delegation Wizard.
What user rights does the ADC service account require?
On member servers, ADC configures the ADC service account to have the following user
rights in the member server’s local security policy:
• Act as Part of the Operating System
• Log on as a Service
• Generate Security Audits
• Restore Files and Directories
If ADC is installed on a server running Active Directory, then these user rights are configured
on the Default Domain Controller group policy.
Note:
If you have implemented other policies on your domain controller organizational units,
you must add these rights to the highest applicable policy.
18
Is it possible to change the password for the ADC service account after installation?
Yes. To change the password, see "How to Change the Password for the Active Directory
Connector Service Account."
What permissions do I need to create connection agreements?
You need to have the following permissions:
• Read on the "CN=Microsoft Exchange,CN=Services,CN=Configuration, DC=your-

domain-here" object
• Full Control on the "CN=Active Directory Connections,CN=Microsoft

Exchange,CN=Services,CN=Configuration, DC=your-domain-here" object
• Membership of the local Administrators group on the ADC server where the
connection agreement is to be executed. You need this permission so that passwords
can be securely transmitted to the ADC server.
The above permissions can be manually granted using the ADSI Edit (AdsiEdit.msc) MMC
snap-in. If you do not want to manually grant permissions, either of the following user roles
can be used to manage the ADC:
• The ADC service account
• A Full Exchange Administrator at the Organization level
When I create a connection agreement in the Active Directory Connector, I need to

specify the credentials for accessing the Active Directory and Exchange Server 5.5
Directory Service. What permissions does this account need?
The permissions that you need are:
• Exchange Server 5.5
• Admin role on the Exchange Server 5.5 site naming context
• Admin role on the Exchange Server 5.5 organization naming context
• Active Directory
• Domain Admins (of the local domain)
• Exchange View Only Administrator role on the Exchange 2000 Server

organization (so that the homeMDB and homeMTA attributes can be properly
expanded)
• Account Operator (of the local domain) if there are any Exchange Server 5.5
distribution lists with hidden membership. For more information about hidden
membership, see Microsoft Knowledge Base article 321205 "XADM: Hidden Group
Membership Does Not Replicate to Exchange Server 5.5."
19
How to Change the Password for the Active

Directory Connector Service Account
The Active Directory Connector (ADC) requires a service account because a subset of the
ADC technology is included with the Microsoft® Windows Server operating system.
Exchange uses ForestPrep and DomainPrep to prepare the Active Directory forest and
domains for installation of the server. Part of this preparation involves setting permissions for
LocalSystem services to Active Directory. Because the ADC can be used without Microsoft
Exchange 2000 Server or Exchange Server 2003 installed, a separate service account is
used to achieve the same functionality.
It is recommended that you change the ADC service account password periodically.
Before You Begin

To change the ADC service account password, you must be logged on to an account that is a
member of the Domain Administrators security group in the domain where the ADC service
account resides.
Procedure
To change the password for the ADC service account
1. Change the password for the ADC service account using the Active Directory
Users and Computers snap-in.
2. Wait a few minutes for the new password to replicate through Active Directory.
3. On each server running Active Directory Connector, in the Services Microsoft

Management Console (MMC) snap-in, locate the Microsoft Active Directory
Connector service. Change the logon password for the service account on the Log
On tab of the Microsoft Active Directory Connector properties page.
4. If the ADC service account is being used on any connection agreements, use the
Active Directory Connector MMC snap-in to locate any one of these agreements
and re-type the password on the Connections tab. It is only necessary to change the
password on one connection agreement because the password is stored in the LSA
Global Secrets database.
5. Restart the ADC service, and monitor the event log to make sure that replication
is occurring successfully.
20
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.
21
• 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?

22
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.
Note:
If you have implemented other policies on your domain controller organizational units,
you must add this right to the highest applicable 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
23
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
24
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
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)

25
• 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."
26
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.

organization level must perform the first installation of Exchange Server 2003 in an
Active Directory domain.
27

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:
28
• 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.
Important:
Starting with Exchange Server 2003 Service Pack 2 (SP2), you will need the
Exchange Administrator role at the organization to upgrade the first server to the
29
latest service pack. This is so that setup can create the UCE Content Filter container
in the Exchange organization container within the Configuration partition. After the
first server is upgraded and this container gets created, you will only need the
Exchange Administrator role on the destination administrative group to upgrade
additional servers.
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"
Note:
If you are running Exchange 2000 Server, and the EDSLock script has been used to
secure access to Exchange mailboxes, members of the "Exchange Domain Servers"
group will not have permissions to open mailboxes on remote Exchange servers.
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).
30
• 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”
(http://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
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” (http://go.microsoft.com/fwlink/?
LinkId=31309).
31
• 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."
32
How to Use ADSI Edit to Add Full Control

Permissions to the Exchange Computer
Account
This topic explains how to manually apply permissions to a Microsoft® Exchange Server
2003 computer account. These permissions are applied automatically when you run
Exchange Server 2003 Setup. If you accidentally delete an Exchange Server 2003 computer
account from Active Directory, you must either run Setup in "Reinstall" mode on the Exchange
server (recommended) or re-create the computer account and apply the appropriate
permissions to that account.
Before You Begin

Before you assign permissions, you must create a computer account for the computer
running Exchange Server 2003.
After you create the computer account, you can grant the new account the required
permissions.
Caution:
If you use the ADSI Edit snap-in and you incorrectly modify the attributes of Active
Directory objects, you can cause serious problems. These problems may require that
you to reinstall Microsoft Windows Server™ 2003, Microsoft Exchange Server 2003,
or both. Serious problems may occur if you incorrectly modify Active Directory object
attributes. Modify these attributes at your own risk.
Procedure
To use ADSI Edit to add Full Control permissions to the Exchange computer
account
1. Start ADSI Edit, and then browse to the following location:
Domain.com/Configuration/Services/Microsoft Exchange/Org/Administrative
Groups/AdminGroup/Servers/Server Name
2. Right-click the server name, and then click Properties.
3. Click the Security tab, and then click Add.
4. Locate the computer account for the Exchange Server computer.
5. Click Add, and then verify that the account is added to the Permissions window
with full control.
33
6. Click OK, and then close ADSI Edit.
7. Add the Exchange Server computer account to Exchange Domain Servers

group.
8. Restart the Exchange Server computer.
You should also examine the local Exchange Domain Servers group within the domain to
make sure that your new computer account is a member. The System Attendant will try to add
the computer account to this group when it starts; however, if this process is unsuccessful,
you will have to add the account manually by using the Active Directory Users and Computers
snap-in.
For More Information

For more information, see the Microsoft Knowledge Base article 297295, "The computer
account for Exchange Server is absent."
For more information about working with ADSI Edit, see the topic "Adsiedit.msc: ADSI Edit" in
the Windows Server Help.
Exchange Server 2003 Management

What permissions do I need to be able to create and delete Exchange Server 2003
users?
If you are responsible for both user and mailbox management, you need to have permissions
to create a user object in Active Directory. For example, you could be a Domain Admin,
Account Operator, or you might have delegated access to a specific organization unit. In
addition, you need the following Exchange permission:
• The Exchange View Only Administrator role to the administrative group where the
target Exchange Server 2003 server exists.
If you are responsible for mailbox-enabling users post-account creation, you can use a
reduced set of permissions (in addition to the Exchange View Only Administrator).
Additionally, if you manage public folder objects, it is recommended that the administration
account (that is, the account that you log on as when you manipulate objects in the Exchange
System Manager) is mail-enabled or mailbox-enabled. In some cases, odd behavior in the
permissioning user interface, as well as display name resolution errors may occur if the
account administering public folder objects is not mailbox or mail-enabled.
For more information, see "Other Problems" under the topic "Troubleshooting and Repairing
Exchange Server 2003 Store Problems" in Working with Exchange Server 2003 Stores
34
What permissions do I need to be able to modify a user object's mailbox rights?
For an Exchange Administrator to properly modify a user or inetOrgPerson object's mailbox

rights by means of the Mailbox Rights button on the Exchange Advanced tab of the
Active Directory Users and Computers snap-in, you must have the following rights:
• Exchange View-Only Administrator role delegated on the target administrative group
• Administer Information Store right granted on the mailbox store where the mailbox
resides
• Write right granted on the mailbox store where the mailbox resides
For more information about modifying mailbox rights, see Microsoft Knowledge Base article
330475 "You need full mailbox access to change mailbox rights after you install
Exchange 2000 SP3." This behavior was changed in Service Pack 2 for Exchange 2000
Server. However, an issue arose in Service Pack 3; therefore, to fully administer mailbox
rights, you should install at least the Exchange 2000 Server Post-SP3 Rollup. For more
information about the Post-SP3 release, see Microsoft Knowledge Base article 836488, "April
2004 Exchange 2000 Server post-Service Pack 3 update rollup."
What permissions do I need to be able to move a mailbox between Exchange mailbox

stores?
The move mailbox functionality accessible from the Active Directory Users and Computers
snap-in logs onto the source mailbox and moves the folders and messages to the destination
mailbox. You can move mailboxes between mailbox stores in the same storage group, across
different storage groups on the same server, between Exchange servers in the same
administration group, or between Exchange servers in different administrative groups
(Exchange Organization must be at Native Mode). You will need to have permissions on the
user object in Active Directory to modify its Exchange mailbox attributes; a user who is an
Account Operator will have these permissions. Additionally, you will require:
• Exchange Administrator role on the administrative group where the source and
destination server running Exchange Server 2003 exists.
• Member of the Administrators group on the local workstation/server (to create a

dynamic MAPI profile).
Why does Exchange View Only Administrator require the right to create objects in the
global namespace for Exchange Server 2003 Service Pack 1?
When Service Pack 1 (SP1) for Exchange Server 2003 is running on Windows 2000 Server
SP4 (or later) or Windows Server 2003, Exchange System Manager creates objects in the
computer's global namespace. As a result, any administrator who is using Exchange System
Manager must have the Create Global Objects right (SE_CREATE_GLOBAL_NAME) on the
server. By default, local administrator accounts have this right. However, if the user's account
has Exchange View Only Administrator rights but does not have local administrator rights on
the computer, the user receives an error. This situation typically occurs when a user uses
35
Terminal Services to access Exchange System Manager on another server for which the user
is not a local administrator.
To avoid this error, you can either add the user to the local administrators group, or you can
grant the Create Global Objects right to the user. To grant this right, log on to the local
computer using an account that is a member of the Administrator's group, and then grant this
right to the user account in Local Security Settings.
The Create Global Objects right does not exist in Windows 2000 Server SP3 (or earlier) or
Windows XP. For these operating systems, no action is necessary.
What permissions do I need to be able to move a mailbox from Exchange Server 5.5 to
Exchange 2000 Server or Exchange Server 2003 in the same site or administrative
group?
When you use Active Directory Users and Computers, the mailbox is transferred between the
two servers, and then the current credentials are used to update the Home-MTA and Home-
MDB attributes on the user and mailbox object.
You need the following permissions:
• Admin on the Site naming context
• Admin on the Configuration naming context
• Either a member of the Domain Admins or the Account Operators group in the
local domain, or the appropriate attribute-level permissions.
• Exchange Administrator role on the administrative group where the target

Exchange Server 2003 server exists
What permissions do I need to create a new administrative group?
To create a new administrative group, you need to be logged on to Active Directory as a user
with the following permission:
• Exchange Administrator role at the Exchange organization level
What permissions do I need to run the Active Directory Account Cleanup Wizard
(ADclean.exe)?
The administrator who uses ADclean.exe needs the following permissions in Active Directory:
• On the source object
• Read and delete permissions in the organizational unit or container
• On the target object
• Write and modify permissions in the organizational unit or container

36
ADclean.exe modifies almost all of the attributes on the target object; therefore, it is
recommended that the administrator who runs the tool be a member of the Domain Admins
group of the target domain.
What permissions do I need to be able to create a new Mailbox/Public Folder Store

and/or Storage Group?
You need to be logged on with the following permissions:
• Exchange Administrator to the administrative group where the Exchange server

resides.
What permissions do I need to be able to look at the Status node in the Exchange
System Manager and perform Message Tracking?
You need at least the Exchange View Only Administrator role to the Administrative Group(s)
where tracking will take place. In large, multi-Administrative Group installations, it is
recommended to give message tracking staff the Exchange View Only Administrator role at
the Organization level because a single message track may include servers from any
Administrative Group.
Be aware that in Exchange 2000 Server 'Everyone' has read permissions to the message
tracking log share on each Exchange server. If the administrator enables subject line logging,
user data may be exposed. However, in Exchange Server 2003, the permissions on the
message tracking log share have been restricted to the local Administrators group by default.
For an added layer of security, you should further restrict the message tracking log by
creating a security group of authorized personnel and allowing only that security group read
access to the logs.
If a user wants to perform message tracking on an Exchange server that is running Windows
Server 2003, but the user does not have administrative permissions, you must grant the
following WMI permissions to the account:
• Execute Methods
• Provider Write
• Enable Account
• Remote Enable
Note:
You must apply these permissions to each Exchange server where you want to track
a message.
For more information about how to grant WMI permissions to user accounts or groups that
will perform message tracking, see How to Grant WMI Permissions for Message Tracking.
What permissions do I need to be able to configure routing groups and connectors?

37
When you configure routing groups and connectors, you are not directly affecting user
account objects; therefore, you only need the following permission:
• Exchange Administrator role to the administrative group where the new routing group
or connector will exist.
Note:
Routing group connectors are unidirectional. To create a bidirectional routing
group connector to a routing group that is outside of the local administrative
group, you also need to have Exchange Administrator permissions to the remote
administrative group.
If you need to define the global message formats for specific outbound domains or need to
specify global message thresholds, you need the following permission:
• Exchange Administrator role on the Exchange organization
What permissions do I need to start and stop an Internet Protocol virtual server (for
example, Simple Mail Transfer Protocol)?
You need either of the following permissions:
• If you are starting or stopping the service from Exchange System Manager, you need
Exchange Administrator role on the administrative group where the virtual server exists.
• For stand-alone Exchange Servers: If you are starting or stopping the service from
the Services MMC snap-in, you need to be a member of the local Administrators group
on the stand-alone Exchange server.
• For Exchange Virtual Servers: If you are starting or stopping the service from the
Cluster Administrator, you need to be a member of the local Administrators group (or
have been delegated permissions to the cluster) on the Exchange Virtual Server.
What permissions do I need to view the Current Sessions on an SMTP virtual server?
To view the current SMTP sessions you need the following permissions:
• Member of the local Administrators group on the Exchange server
What permissions do I need to be able to manipulate message queues?
To view the message queues in the Exchange System Manager, you need the following
permissions:
• Exchange View Only Administrator role on the administrative group where the virtual
server exists
• Exchange View Only Administrator role on the administrative group where the routing
group for the virtual server exists.
To remove messages from queues, you need eitherof the following permissions:
38
• Exchange Administrator role on the administrative group where the virtual server
exists
What permissions do I need to create, manage, and delete content indices?
To manage content indices, you need the following permissions:
• Exchange Administrator role on the administrative group where the server exists.
What permissions do I need to apply a system policy?
To apply system policies, you need the following permissions:

• Exchange Administrator role on the administrative group where the system policy
exists
• Exchange Administrator role on the administrative group where the server or store
exists
How to Grant WMI Permissions for

Message Tracking
This topic explains how to grant Windows Management Instrumentation (WMI) permissions
on an Exchange server for the user account or group that will perform message tracking.
Procedure
To grant WMI permissions for message tracking
1. On the Exchange server on which you will track messages, click Start, point to
All Programs, point to Administrative Tools, and then click Computer
Management.
2. Expand Services and Applications.
3. Click WMI Control.
4. Right-click WMI Control and then select Properties.
5. Click the Security tab.
6. Expand Root.
7. Select MicrosoftExchangeV2 and then click Security.

39
8. Click Add to add the user accounts or groups that will be responsible for
message tracking in the organization.
9. For each group or user name that will be responsible for message tracking in the
organization, select the Allow check box for the following permissions:
• Execute Methods
• Provider Write
• Enable Account
• Remote Enable
Note:
You must grant these permissions on each Exchange server on which you will track
messages.
For More Information

For more information, see Exchange Server 2003 Management.
Planning a Split Permissions Model

The administrative model prescribed by the default configuration of Microsoft® Exchange and
Active Directory® directory service, especially with regard to user administration, may not fit
with the security and administrative roles defined by your organization. For some
organizations, the helpdesk-level administrators that create user accounts are not the same
administrators that administer mailboxes. However, the default configuration of Exchange and
Active Directory requires that mailbox administrators belong to the "Account Operators"
security group, and that members of the "Account Operators" group have read-read access to
Exchange objects.
This topic explains how you can configure permissions in Active Directory to correspond to
your administrative model. This granular level of permissioning is referred to as a split
permissions model. "Implementing a Split Permissions Model" describes the tools and
processes you need to understand to implement a split permissions model in your
organization.
"Split Permissions Model Reference" catalogues all of the Exchange attributes as they are
organized in the Active Directory Users and Computers Microsoft Management Console
(MMC) snap-in. Use this topic to help you identify the attributes and the appropriate
permissions you need to set on those attributes as you plan a split permissions model for
your organization.
40
Implementing a Split Permissions Model

This section explains how to apply a split permissions model appropriate to your organization.
"Split Permissions Model Reference" identifies all the attributes relevant to administering
Exchange users.
Access Control
To manage Exchange related-attributes on objects within the domain naming contexts of the
forest, modify permissions must be granted to the Exchange Administrators group. This is
accomplished by modifying the security descriptor on the object containing the attributes.
A security descriptor contains two access control lists (ACLs). An ACL is a list of user or
security group objects that have access or are denied access to a resource or object. ACLs
allow granular permissions to be applied to the entire object, a set of the object's properties,
or to an individual property of an object. Two types of access control lists are within an
object's security descriptor:
• Discretionary access control lists (DACLs) DACLs identify the users and groups
that are assigned or denied access permissions on an object. If a DACL does not
explicitly identify a user, or any groups that a user is a member of, the user will be denied
access to that object. By default, a DACL is controlled by the owner of an object or the
person who created the object, and it contains access control entries that determine user
access to the object.
• System access control lists (SACLs) SACLs identify the users and groups that
you want to audit when they successfully access or fail to access an object. By default, a
SACL is controlled by the owner of an object or the person who created the object. A
SACL contains access control entries that determine whether to record a successful or
failed attempt by a user to access a object using a given permission, for example, Full
Control and Read.
An access control entry (ACE) is an entry in an object's DACL that grants permissions to a
user or group. An ACE is also an entry in an object's SACL that specifies the security events
that are to be audited for a user or group.
Where to Apply Permissions

An Active Directory forest is comprised of one or more domains that share a common
configuration and schema boundary. Within those domains, objects can be further arranged
into containers known as organizational units. Each organization should devise an
41
organizational unit structure that meets their business needs and allows for optimum
delegation of administrative privileges.
For more information about designing an organizational unit structure, see Best Practice
Active Directory Design for Managing Windows Networks and Best Practices for Delegating
Active Directory Administration.
When you design a delegation model, there are several possibilities for applying permissions;
however, this guide discusses only the following two methods:
• Applying permissions at the domain level
• Applying permissions at the organizational unit level
Applying Permissions at the Domain Level

When you apply delegated permissions on the domain naming context, the permissions are
inherited to all objects (user, contact, group, domain DNS, computers, and so on); regardless
if the permissions only apply toward one specific class object.
On domain controllers that are running Microsoft Windows® 2000 Server, adding an
inheritable ACE at the domain level will cause the DACL to change for every object within the
domain. Depending on the number of ACEs added and the number of objects within the
domain, these changes could result in an "ACL bloat" (that is, unnecessary ACEs on objects
that increase the size of the ACL). An ACL bloat ultimately increases the physical size of the
NTDS.DIT file across all domain controllers within the domain.
On domain controllers that are running Windows Server™ 2003, a unique security descriptor
is stored only once rather than being stored for every object that inherits it. For every object
that inherits the security descriptor or otherwise stores an identical security descriptor, only a
pointer is stored. This change eliminates data redundancy and the database growth that can
result from changes to inheritable ACEs.
Applying Permissions at the Organizational

Unit Level
The recommended practice for applying delegated permissions is to apply the permissions on
a parent organizational unit. This approach isolates the application of the permissions to
specific class objects contained within the organizational unit and its child containers.
This method requires that all the managed objects be placed beneath a parent organizational
unit. Business requirements may prevent the organization from applying this methodology;
therefore, the permissions may need to be applied across multiple organizational units.
42
How to Apply Permissions

There are several ways to apply permissions. Microsoft provides two tools: ADSI Edit
(AdsiEdit.msc) and DSACLS (Dsacls.exe). Both tools are included on the Windows Server
2003 CD in Support\Tools. Several third-party products exist that can also be used to apply
these rights.
Note:
Incorrectly modifying the attributes of Active Directory objects by using ADSI Edit,
DSACLS, the LDP tool (ldp.exe), or any other LDAP (Lightweight Directory Access
Protocol) version 3 clients can cause serious problems. These problems may require
reinstallation of Windows Server, Exchange Server, or both. Problems that occur if
Active Directory object attributes are incorrectly modified may not be resolved. Modify
these attributes at your own risk.
Changing permissions in the domain naming context requires Domain Admin rights on the
object for which permissions are wanted.
Consider this example that shows how either one of the tools can be used to delegate certain
rights to Exchange Administrators. This example can be used as a sample for application of
delegated rights over users, contacts, and groups.
Exchange Administrators in the universal security group "ExAdminGroup" require the ability to
manage e-mail addresses, the display name, and to move mailboxes for all users located in
(and below) the organizational unit "UsersContainer" in the "company.com" domain. This
example assumes "ExAdminGroup" has "Exchange Administrator Role" in the source and
destination administrative groups. The examples show how to apply rights on the
UsersContainer by specifying read and/or write access on the following attributes within the
UsersContainer:
• displayName
• E-Mail Address (mail)
• homeMDB
• homeMTA
• msExchHomeServerName
• msExchPoliciesExcluded
• Proxy Addresses (proxyAddresses)
• targetAddress
• textEncodedORAddress
43
Using DSACLS to Apply Permissions

DSACLS (dsacls.exe) is a command-line tool that you can use to query and change
permissions and security attributes of Active Directory objects. It is the command-line
equivalent of the Security tab in the Windows 2000 Active Directory snap-in tools such as
Active Directory Users and Computers and Active Directory Sites and Services.
Note:
For more information about the DSACLS syntax, see "Split Permissions Model
Reference."
For more information about using DSACLS, see "How to Use DSACLS to Apply Permissions"
How to Use DSACLS to Apply Permissions

DSACLS (dsacls.exe) is a command-line tool that you can use to query and change
permissions and security attributes of Active Directory objects. It is the command-line
equivalent of the Security tab in the Windows 2000 Active Directory snap-in tools such as
Active Directory Users and Computers and Active Directory Sites and Services. DSACLS is
included with the Windows 2003 Support Tools.
This topic serves as an example for using DSACLS. After application of the example in this
topic, the "ExAdminGroup" security group can manage e-mail addresses, display names, and
move mailboxes for all users contained in the "UsersContainer" organizational unit hierarchy.
Before You Begin

DSACLS is case-sensitive. Therefore, you must be precise in the syntax that you pass to
DSACLS because all characters, including white spaces and carriage returns, are passed
literally. If you receive errors from DSACLS, review the command and/or try breaking the
command into smaller segments.
Procedure
To use DSACLS for permissioning
1. Log on to a system within the forest that has the Windows Support Tools
installed using an account that can perform the actions (for example, Domain Admin).
2. Open a command prompt, and type the following command:
dsacls "OU=UsersContainer,DC=company,DC=com" /I:S /G

44
"company\ExAdminGroup:RPWP;homeMDB;user"
"company\ExAdminGroup:RPWP;homeMTA;user"
"company\ExAdminGroup:RPWP;targetAddress;user"
"company\ExAdminGroup:RPWP;msExchHomeServerName;user"
"company\ExAdminGroup:WP;proxyAddresses;user"
"company\ExAdminGroup:WP;msExchPoliciesExcluded;user"
"company\ExAdminGroup:WP;mail;user"
"company\ExAdminGroup:WP;textEncodedORAddress;user"
"company\ExAdminGroup:WP;displayName;user"
3. If successful, the command will output the revised Windows NT security

descriptor in the command prompt window and output "The command completed
successfully".
Using ADSI Edit to Apply Permissions

ADSI Edit acts as a low-level editor for Active Directory. By using ADSI Edit, administrators
can view all objects (and associated properties) in the directory (including schema
information), modify objects, and set access control lists on objects.
For more information about using ADSI Edit, see "How to Use ADSI Edit to Apply
Permissions"
How to Use ADSI Edit to Apply

Permissions
ADSI Edit acts as a low-level editor for Active Directory. By using ADSI Edit, administrators
can view all objects (and associated properties) in the directory (including schema
information), modify objects, and set access control lists on objects.
This topic serves as an example for using ADSI Edit. After application of the example in this
topic, the "ExAdminGroup" security group can manage e-mail addresses, display names, and
move mailboxes for all users contained in the "UsersContainer" organizational unit hierarchy.
Before You Begin

If you use the ADSI Edit snap-in and you incorrectly modify the attributes of Active Directory
objects, you can cause serious problems. These problems may require you to reinstall
Microsoft Windows Server 2003, Microsoft Exchange Server 2003, or both. Serious problems
45
may occur if you incorrectly modify Active Directory object attributes. Modify these attributes
at your own risk.
Procedure
To use ADSI Edit for permissioning
1. Open ADSI Edit, on the Action menu, click Connect To, and then specify the
domain where you want to make changes. Click OK.
2. Expand the Domain Naming Context (Domain NC) hierarchy to the appropriate
container: OU=UsersContainer,DC=company,DC=com.
3. Right-click the container, and then select Properties.
4. Select the Security Tab, and then click Advanced.
5. In Advanced Security Settings for Group Name, click Add and then select the
group object, Company\ExAdmin Group. Click OK.
6. In Permission Entry for Users, click the Properties tab, and then select User
Objects from the list to change the Apply onto field.
7. For each of the following property rights, select the Allow permission:
• Read Proxy Addresses
• Read msExchPoliciesExcluded
• Read E-Mail Address
• Read textEncodedORAddress
• Read displayName
• Read Exchange Mailbox Store
• Read targetAddress
• Read homeMTA
• Write Proxy Addresses
• Write msExchPoliciesExcluded
• Write E-Mail Address
• Write textEncodedORAddress
• Write displayName
• Write Exchange Mailbox Store
• Read Exchange Home Server

46
• Write Exchange Home Server
• Write targetAddress
• Write homeMTA
8. Click OK.
Prerequisites to Implementing Permissions

Changes
To implement the permission changes that are discussed in this topic, you must make sure
that your Exchange environment is up-to-date.
Exchange Server 2003

You must install Service Pack 1 for Exchange Server 2003 to implement the split permission
model discussed in this document.
If the environment is a mixed-mode environment (that is, servers running both

Exchange 2000 Server and Exchange Server 2003), it is highly recommended that you only
use the Exchange Server 2003 System Manager to manage Exchange 2000 Server and
Exchange Server 2003 objects.
Exchange 2000 Server

The following Exchange 2000 Server items must be installed on any system where the
Exchange 2000 Server System Manager is installed:
• Service Pack 3 for Exchange 2000 Server and Exchange 2000 Server Enterprise
Edition (http://go.microsoft.com/fwlink/?linkid=17058)
• Latest Exchange 2000 Server Post-Service Pack 3 Rollup

(http://go.microsoft.com/fwlink/?LinkId=33457)
47
Permissions Granted During Exchange

Setup
Each permissions table begins with the distinguished name of the object it applies to. Then,
the table lists when the right is applied: for example, during the ForestPrep phase while
installing a server.
In some cases, the access control list (ACL) is not applied on the usual property
(ntSecurityDescriptor), but on some other property—for example,
"msExchMailboxSecurityDescriptor". The directory service cannot enforce security that is not
specified in the Microsoft® Windows® NT security descriptor; in most cases, these ACLs will
be replicated to store ACLs on appropriate objects by the store service. There is,
unfortunately, no tool for viewing these ACLs as anything other than raw binary data.
The columns of a permissions table are as follows:
• Account The security principal granted or denied the permissions.
• A Checked if this is an allow access control entry (ACE).
• D Checked if this is a deny ACE. Allow and Deny are mutually exclusive.
• I Checked if this ACE inherits to child objects.
• Right Checked if this ACE inherits to child objects.
• On Property/Applies To In some cases, the permission applies only to a given

property, property set, or object class. If so, that is specified here.
• Comments The reason this permission is required, or other information about the
permission.
The permissions that are removed by Microsoft Exchange Server 2003 Setup are indicated
by a double strike-through font (for example, double strike-through). These are permissions
that were set in Exchange 2000 Server, but they have since been deprecated from the
security model.
The permissions are generally listed in the table by the names used on the ADSIEdit Security
property page, in the Advanced view, on the View/Edit tab. The ADSIEdit Security property
page lists a much more condensed view of the rights. The LDP tool (Ldp.exe) displays the
access mask directly, as a numerical value. The setup code refers to the rights by predefined
constants.
The following table summarizes the relationships between these values.

48
Relationships between values
ADSIEdit Summary ADSIEdit Advanced #define Binary value

page page,
("Mask" in LDP)
View/Edit tab
Full Control Full Control WRITE_OWNER | 0x000F01FF

WRITE_DAC |
READ_CONTROL |
DELETE |
ACTRL_DS_CONT
ROL_ACCESS |
ACTRL_DS_LIST_O
BJECT |
ACTRL_DS_DELET
E_TREE |
ACTRL_DS_WRITE
_PROP |
ACTRL_DS_READ_
PROP |
ACTRL_DS_SELF |
ACTRL_DS_LIST |
ACTRL_DS_DELET
E_CHILD |
ACTRL_DS_CREAT
E_CHILD
Read List Contents + ACTRL_DS_LIST | 0x00020014

Read All Properties ACTRL_DS_READ_
+ Read Permissions PROP |
READ_CONTROL
Write Write All Properties ACTRL_DS_WRITE 0x00000028

+ All Validated _PROP |
Writes ACTRL_DS_SELF
List Contents ACTRL_DS_LIST 0x00000004
Read All Properties ACTRL_DS_READ_ 0x00000010

PROP
Write All Properties ACTRL_DS_WRITE 0x00000020

_PROP
Delete DELETE 0x00010000
Delete Subtree ACTRL_DS_DELET 0x00000040

E_TREE
49
ADSIEdit Summary ADSIEdit Advanced #define Binary value

page page,
("Mask" in LDP)
View/Edit tab
Read Permissions READ_CONTROL 0x00020000
Modify Permissions WRITE_DAC 0x00040000
Modify Owner WRITE_OWNER 0x00080000
All Validated Writes ACTRL_DS_SELF 0x00000008
All Extended Rights ACTRL_DS_CONT 0x00000100

ROL_ACCESS
Create All Child Create All Child ACTRL_DS_CREAT 0x00000001

Objects Objects E_CHILD
Delete All Child Delete All Child ACTRL_DS_DELET 0x00000002

Objects Objects E_CHILD
ACTRL_DS_LIST_O 0x00000080
BJECT
Extended rights are custom rights specified by individual applications. They are specified in
the ACL, but they are meaningless to the directory service; the particular application enforces
any extended rights. Examples of Exchange extended rights are "Create public folder" or
"Create named properties in the information store."
Permissions on Objects in the Exchange

Configuration Tree
Microsoft Exchange Container

cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>
Account A D I Right On Comments

Property/A
pplies To
During
ForestPre
p phase
50

Property/A
pplies To
Authentica X List Not Allows

ted Users Contents applicable DomainPre
Read All p to read
Properties Full Org
Admins
Designate X X Full Not Allows Full

d admin Control applicable Org Admin
account to
administer
organizatio
n
During
server
install
Exchange X X Read Not Allows

Domain Permissio applicable Exchange
Servers ns Read servers to
All read
Properties configurati
List on
Contents information
During
ADC setup
Exchange X X Full Not Allows

Services Control applicable ADC
servers to
create/dele
te objects
to keep
Exchange
configurati
on up-to-
date.
51
ADC Connection Agreement Container

cn=Active Directory Connections,cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<domain>

Property/A
pplies To
During
server
install
Exchange X X Full Not None

Domain Control applicable
Servers
Organization Container
cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Property/A
pplies To
During
ForestPre
p phase
Authentica X Read All Not Allows

ted Users Properties applicable DomainPre
ACTRL_D p to read
S_LIST_O Full Org
BJECT Admins.
Designate X X Send As Not Exchange

d admin applicable admins are
account not allowed
to open
mailboxes.
52

Property/A
pplies To
Designate X X Receive Not Exchange

d admin As applicable admins are
account not allowed
to open
mailboxes.
During
server
install
Enterprise X X Send As Not Windows N

Admins applicable T admins
are not
allowed to
open
mailboxes.
Enterprise X X Receive Not Windows N

Admins As applicable T admins
are not
allowed to
open
mailboxes.
Domain X X Send As Not Windows N

Admins of applicable T admins
root are not
domain allowed to
open
mailboxes.
Domain X X Receive Not Windows N

Admins of As applicable T admins
root are not
domain allowed to
open
mailboxes.
53

Property/A
pplies To
Everyone X X Create Not This

top-level applicable permission
public was
folder removed
by
Exchange
Server 200
3 Setup.
This
permission
was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
Everyone X X Create Not None

public applicable
folder
Everyone X X Create Not None

named applicable
properties
in the
informatio
n store
54

Property/A
pplies To
Everyone X X Read Applies to None

Permissio object
ns class:
msExchPri
Read All
vateMDB
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
Everyone X X Read Applies to None

Permissio object
ns class:
msExchPu
Read All
blicMDB
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
55

Property/A
pplies To
Everyone* X X Read Applies to This

Permissio object permission
ns class: mTA was
removed
Read All
by
Properties
Exchange
List Server 200
Contents 3 Setup.
ACTRL_D This
S_LIST_O permission
BJECT was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
56

Property/A
pplies To
Anonymou X X Create Not This

s Logon top-level applicable permission
public was
folder removed
by
Exchange
Server 200
3 Setup.
This
permission
was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
Anonymou X X Create Not In

s Logon public applicable Microsoft
folder Windows
Server 200
3™,
"Everyone"
no longer
includes
"Anonymo
us Logon,"
so these
rights are
granted
explicitly.
57

Property/A
pplies To
Anonymou X X Create Not None

s Logon named applicable
properties
in the
informatio
n store
Anonymou X X Read Applies to None

s Logon Permissio object
ns class:
msExchPri
Read All
vateMDB
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
Anonymou X X Read Applies to None

s Logon Permissio object
ns class:
msExchPu
Read All
blicMDB
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
58

Property/A
pplies To
Anonymou X X Read Applies to This

s Logon Permissio object permission
ns class: mTA was
removed
Read All
by
Properties
Exchange
List Server 200
Contents 3 Setup.
ACTRL_D This
S_LIST_O permission
BJECT was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
Exchange X X All Not None

Domain Extended applicable
Servers Rights
Exchange X X Create All Not None

Domain Child applicable
Servers Objects
Exchange X X Write Property Maintain

Domain Property Set: Public mail-
Servers Informatio enabled
n configurati
on objects
(for
example,
MAD).
59

Property/A
pplies To
Exchange X X Write Property Maintain

Domain Property Set: mail-
Servers Personal enabled
Informatio configurati
n on objects
(for
example,
MAD).
Exchange X X Full Applies to None

Domain Control object
Servers class:
siteAddres
sing
When
enabling a
Site
Replicatio
n Service
(ACE is
removed
when SRS
is
disabled.)
MACHINE X X Create All Not SRS must

$ Child applicable be able to
Objects create/dele
Delete All te admin
Child groups.
Objects
ACTRL_D
S_LIST_O
BJECT
Address Lists Container

cn=Address Lists Container,cn=<org>,cn=Microsoft
60

Property/A
pplies To
During
server
install
Authentica X X List Not None

ted Users Contents applicable
Addressing Container
cn=Addressing,cn=<org>,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>

Property/A
pplies To
During
server
install

Read All
Properties
Read
Permissio
ns
Recipient Update Services Container

cn=Recipient Update Services,cn=Address Lists Container,cn=<org>,cn=Microsoft
Exchange,cn=Services,cn=Configuration...
61

Property/A
pplies To
During
server
install

Servers
Administrative Group
cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft

Property/A
pplies To
During
server
install (set
on
attribute
msExchP
FDefaultA
dminACL)
Authentica X X Create Not None

ted Users public applicable
folder
Default Top Level Hierarchy

cn=Public Folders,cn=All Folder Hierarchies,cn=<admin group>,cn=Administrative
Groups,cn=<org>,cn=Microsoft Exchange...
62

Property/A
pplies To
During
server
install (set
on
attribute
msExchP
FDefaultA
dminACL)
Authentica X X Create Not None

ted Users public applicable
folder
Connections Container
cn=Connections,cn=<routing group>,cn=Routing Groups,cn=<admin group>,cn=Administrative
Groups,cn=<org>...

Property/A
pplies To
During
server
install

Servers
Servers Container
cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft
Exchange,cn=Services...
63

Property/A
pplies To
During
server
install, or
during
Exchange
ForestPre
p
Exchange X X Receive Not No server

Domain As applicable needs to
Servers read mail
except on
its own
MDBs.
During
server
install
(ACEs
defined in
schema
defaultSec
urityDescri
ptor)
Authentica X List Not None

Server Object
cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=<org>,cn=Microsoft
Exchange,cn=Services...
64

Property/A
pplies To
During
server
install (if
the server
is not a
cluster
virtual
machine)
MACHINE X X Full Not Server

$ Control applicable must be
able to
maintain its
configurati
on.
During
server
install (if
the server
is a cluster
virtual
machine)
NODE1$ X X Full Not Every node

NODE2$ Control applicable in a cluster
etc... that owns
a virtual
machine
(VM) must
be able to
maintain
the VM
configurati
on.
65

Property/A
pplies To
Exchange X X Full Not This

Domain Control applicable permission
Servers was
removed
by
Exchange
Server 200
3 Setup.
This
permission
was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
VM must
be able to
maintain its
own
configurati
on, but
Setup can't
tell which
specific
server to
grant
control to.
66

Property/A
pplies To
During
server
install
(ACEs
defined in
schema
defaultSec
urityDescri
ptor)
Authentica X Read Not None

ted Users Properties applicable
When
EDSLOCK
script is
run; ACE
is removed
by
Exchange
ForestPre
p
67

Property/A
pplies To
Exchange X X Receive Not This

Domain As applicable permission
Servers was
removed
by
Exchange
Server 200
3 Setup.
This
permission
was set in
Exchange
2000
Server, but
has since
been
deprecated
from the
security
model.
No server
needs to
read mail
except on
its own
MDBs.
Protocols Container
cn=Protocols,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative
Groups,cn=<org>,cn=Microsoft Exchange...
68

Property/A
pplies To
During
server
install
Everyone X X List Not None

Contents applicable
Everyone X X Read Not None

metabase applicable
properties
System Attendant Object

cn=Microsoft System Attendant,cn=<server>,cn=Servers,cn=<admin
group>,cn=Administrative Groups,cn=<org>...

Property/A
pplies To
During
server
install (set
on
attribute
msExchM
ailboxSec
urityDesc
riptor)
LocalSyste X X Read Not None

m Permissio applicable
ns
fsdspermU
serSendAs
fsdspermU
serMailbox
Owner
69

Property/A
pplies To
Exchange X X Read Not None

Domain Permissio applicable
Servers ns
fsdspermU
serSendAs
fsdspermU
serMailbox
Owner
5.5 X X Read Not None

Service Permissio applicable
Account (if ns
given) fsdspermU
serSendAs
fsdspermU
serMailbox
Owner
MTA Object
cn=Microsoft MTA,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative
Groups,cn=<org>...

Property/A
pplies To
During
server
install or
when
enabling
an SRS
70

Property/A
pplies To
5.5 X X Send As Not Required

Service applicable to
Account (if send/recei
given) ve mail
from
servers
running
Exchange
Server 5.5.
5.5 X X Receive Not Required

Service As applicable to
Account (if send/recei
given) ve mail
from
servers
running
Exchange
Server 5.5.
Permissions on Other Objects in the

Configuration Naming Context
Deleted Items Container

cn=Deleted Items,cn=Configuration,dc=<domain>

Property/A
pplies To
During
ForestPre
p phase
71

Property/A
pplies To
Designate X X Read Not Exchange

d admin Permissio applicable Administrat
account ns List ors must
Contents be able to
Read All add other
Properties admins or
Modify servers to
Permissio the ACL of
ns the
ACTRL_D Deleted
S_LIST_O Items
BJECT container.
During
server
install
Exchange X X List Not The DS-to-

Domain Contents applicable MB service
Servers must be
able to
determine
if DS
objects
have been
deleted.
Active Directory Connector Object

cn=Active Directory Connector,cn=Exchange
Settings,cn=<server>,cn=Servers,cn=<site>,cn=Sites,cn=Configuration...

Property/A
pplies To
During
ADC setup
72

Property/A
pplies To
Exchange X X Full Not ADC must

Services Control applicable be able to
alter its
own
configurati
on
information
.

Read All
Properties
Read
Permissio
ns
Permissions on Objects in the Domain

Naming Context
Domain Container
dc=<domain>

Property/A
pplies To
During
DomainPr
ep phase
73

Property/A
pplies To
Exchange X X Write Property Maintains

Enterprise Property Set: Public mail-
Servers Informatio enabled
n user
attributes.
Exchange X X Write Property Maintains

Enterprise Property Set: mail-
Servers Personal enabled
Informatio user
n attributes.
Exchange X X Write On None

Enterprise Property property:g
Servers roupType
Exchange X X Write On None

Enterprise Property property:di
Servers splayNam
e
Exchange X Manage Not Allows

Enterprise Replicatio applicable Recipient
Servers n Topology Update
Service to
track
replication
changes.
Exchange X X List Not Duplicates

Enterprise Contents applicable permission
Servers s granted
to "Pre-
Windows 2
000
Compatible
Access"
group.
Exchange X Read Not None

Enterprise Permissio applicable
Servers ns
74

Property/A
pplies To
Exchange X X Read Applies to None

Enterprise Permissio object
Servers ns Read class:user
All
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
Exchange X X Read Applies to None

Enterprise Permissio object
Servers ns Read class:grou
All p
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
Exchange X X Modify Applies to Maintains

Enterprise Permissio object ACLs for
Servers ns class:grou groups
p with hidden
distribution
list
membershi
p.
During
DomainPr
ep phase
(if running
against
Windows
Server 200
3 schema)
75

Property/A
pplies To
Exchange X X Read Applies to Same

Enterprise Permissio object permission
Servers ns Read class:Inet s required
All OrgPerso on
Properties n InetOrgPer
List sons as on
Contents Users.
ACTRL_D
S_LIST_O
BJECT
Domain Proxy Container

cn=Microsoft Exchange System Objects,dc=<domain>

Property/A
pplies To
During
DomainPr
ep phase
Exchange X X Full Not Adds/delet

Enterprise Control applicable es/modifies
Servers proxy
objects.
Exchange X X Full Not Adds/delet

Domain Control applicable es/modifies
Servers proxy
objects.
Authentica X X Read Not Allows

ted Users Permissio applicable access to
ns public
folder (PF)
objects.
76

Property/A
pplies To
Authentica X X Read garbageC Allows

ted Users Property ollPeriod access to
PF objects.
Authentica X X Read adminDisp Allows

ted Users Property layName access to
PF objects.
Authentica X X Read modifyTim Allows

ted Users Property eStamp access to
PF objects.
During
DomainPr
ep (ACEs
defined in
schema
defaultSec
urityDescri
ptor)
Authentica X Read Not None

ted Users Permissio applicable
ns Read
All
Properties
List
Contents
ACTRL_D
S_LIST_O
BJECT
Set by the
Recipient
Update
Service
77

Property/A
pplies To
All X X Full Not None

delegated Control applicable
org-level
and
admin-
group level
Full
Admins
All X X Read Not None

delegated Permissio applicable
org-level ns List
and Contents
admin- All
group level Validated
Admins Writes
Read All
Properties
Write All
Properties
Create All
Child
Objects
Delete All
Child
Objects
All X X Read Not None

delegated Permissio applicable
org-level ns Read
and All
admin- Properties
group level List
View-Only Contents
Admins ACTRL_D
S_LIST_O
BJECT
78
AdminSDHolder Container
cn=AdminSDHolder,cn=System,dc=<domain>

Property/A
pplies To
During
DomainPr
ep phase
Exchange X X Read Property This ACL is

Enterprise Property Set: Public applied to
Servers Write Informatio users with
Property n domain
admin
rights.
Exchange X X Read Property None

Enterprise Property Set:
Servers Write Personal
Property Informatio
n
Exchange X X Read On None

Enterprise Property property:di
Servers Write splayNam
Property e
Exchange X X List Not None

Enterprise Contents applicable
Servers
Pre-Windows 2000 Server Compatible Access

Group
cn=Pre-Windows 2000 Compatible Access,cn=Builtin,dc=<domain>
79

Property/A
pplies To
During
DomainPr
ep phase
Exchange X X Write On The

Enterprise Property property: Recipient
Servers member Update
Service
must add
all EDS
groups to
every
domains'
pre-
Windows 2
000 Server
group.
Exchange Enterprise Servers Group

cn=Exchange Enterprise Servers,cn=Users,dc=<domain>

Property/A
pplies To
During
DomainPr
ep phase
All existing X Full Not Admins

org-level Control applicable running
Full setup must
Admins be able to
add/remov
e machine
accounts
from
group.
80

Property/A
pplies To
Exchange X Full Not None

Enterprise Control applicable
Servers
Set by the
Recipient
Update
Service

org-level
Full
Admins
Exchange Domain Servers Group

cn=Exchange Domain Servers,cn=Users,dc=<domain>

Property/A
pplies To
During
DomainPr
ep phase
All existing X Full Not Admins

org-level Control applicable running
Full setup must
Admins be able to
add/remov
e machine
accounts
from
group.
Exchange X Full Not None

Enterprise Control applicable
Servers
81

Property/A
pplies To
Set by the
Recipient
Update
Service

org-level
Full
Admins
Exchange 2000 Server Permissions FAQ

The information in this section is specific to Microsoft® Exchange 2000 Server and does not
apply to Exchange Server 2003.
General Questions
Are there areas in Exchange 2000 Server where I should tighten security?
If some Exchange Administrators are not trustworthy and have the ability to directly logon to
the Exchange server console, you should implement the EDSLock script, which is discussed
in Microsoft Knowledge Base article 313807, "XADM: Enhancing the Security of
Exchange 2000 for the Exchange Domain Servers Group." This action will prevent these
administrators from elevating their permissions and logging on to non-local mailboxes.
Be careful when you deploy Exchange 2000 Server on servers that are running
Active Directory® directory service. Administrators who have console access to domain
controllers have the ability to elevate their permissions in Active Directory. For this reason and
others, it is recommended that you deploy Exchange 2000 Server on member servers. For
more information about restricting permissions, see Design Considerations for Delegation of
Administration in Active Directory.
Be aware that prior to Service Pack 2 (SP2) for Exchange 2000 Server, accounts belonging
to the local "Administrators" group on a server running Exchange 2000 Server had the
automatic permission to Send As any user in the organization.
82
What permissions do I need to upgrade a server running Exchange Server 5.5 to

Exchange 2000 Server?
The server running Exchange Server version 5.5 must be installed on a computer running
Microsoft Windows® 2000 Server in an Active Directory domain. You need to log on to
Active Directory as a user who has the following permissions:
• Admin role on the Exchange Server 5.5 organization naming context
• Admin role on the Exchange Server 5.5 site naming context
• Admin role on the Exchange Server 5.5 configuration naming context

• Either Exchange Full Administrator (as defined during ForestPrep) or delegated

Exchange Full Administrator role at the Organization level
• Member of the local Administrators group on the target upgrade server
If I choose to join an existing Exchange Server 5.5 organization during ForestPrep,

what permissions do I need to join the Exchange Server 5.5 organization?
You need the following permissions:
• Admin role on the Exchange Server 5.5 site naming context (for the site that you are
joining)
• Admin role on the Exchange Server 5.5 configuration naming context (for the site that
you are joining)
Additionally, you will need to know the service account name and password for the site that
relates to the server that you specify. If the Exchange Server 5.5 service account is in a
Windows NT 4.0 domain, you must create a two-way trust from the forest root domain to the
domain that contains the Exchange Server 5.5 service account.
What permissions do I need to install service packs for Exchange 2000 Server?
Service packs for Exchange need to be installed after Exchange 2000 Server. There is not an
integrated setup of Exchange that includes service packs. You need to have the following
permissions to apply service packs:
• Exchange Administrator role on the administration group where the server running
Exchange 2000 Server exists
• Member of the local Administrators group on the target server running

Exchange 2000 Server
There are two exceptions. First, when you are upgrading an Exchange 2000 Server cluster or
Key Management Service to Service Pack 2, you need to have the following permissions:
83
• Either Exchange Full Administrator (as defined during ForestPrep) or delegated

Exchange Full Administrator role at the organization level
• Member of the local Administrators group on the target server(s)
The second exception is if you are installing Service Pack 3 (SP3) for Exchange 2000 Server.
Because SP3 for Exchange 2000 Server Setup modifies rights on a protocol object in the
Exchange configuration container, you need one of the following permissions:
• Exchange Full Administrator role at the Organization level, or
• Exchange Full Administrator role on the administration group where the server
running Exchange 2000 Server exists
For more information about deploying SP3 for Exchange 2000 Server, see Microsoft
Knowledge Base article 326293, "White Paper: Microsoft Exchange 2000 Server Service
Pack 3 Deployment Guide."
What happens if I add my own user account to the 'Exchange Domain Servers' group?
If at least one computer running Exchange 2000 Server is installed in the same domain, you
would have significant permissions over the organization and all mailboxes. Indeed, it is
possible to use your account to logon to any mailbox in the organization. Interestingly, if your
account is also a Domain Admin or Enterprise Admin, you will be denied access (by default)
to other users mailboxes, as an explicit deny access control entry is placed on each
Exchange database for users in these groups.
If your domain had simply been prepared (through DomainPrep) and a server running
Exchange Server 2003 had not been installed in the domain, you would not acquire
permissions to open other users mailboxes, and you would not gain any permissions to the
Exchange organization.
To increase the security of your organization, consider one of the following approaches:
• Use the EDSlock script to prevent members of the 'Exchange Domain Servers' group
(from any domain) from accessing non-local resources. For more information about this
approach, see Microsoft Knowledge Base Article 313807, "XADM: Enhancing the
Security of Exchange 2000 for the Exchange Domain Servers Group."
• Install all servers running Exchange 2000 Server in a separate domain in the forest,
away from user accounts and normal domain administrators.
Additionally, you may want to place 'deny' access control entries (ACEs) on the two special
groups so that other administrators cannot change their membership.
What happens if I add my own user account to the 'Exchange Enterprise Servers'
group?
If at least one computer running Exchange 2000 Server had been installed in the same
domain, you would have significant permissions over the organization and all mailboxes.
Indeed, with Exchange 2000 Server, it is possible to use your account to logon to any mailbox
84
in the organization. Interestingly, if your account is also a Domain Admin or Enterprise Admin,
you will be denied access (by default) to other users mailboxes, as an explicit deny access
control entry is placed on each Exchange database for users in these groups.
If your domain had simply been prepared (through DomainPrep) and a server running
Exchange 2000 Server had not been installed in the domain, you would not acquire
permissions to open other users mailboxes, and you would not gain any permissions to the
Exchange organization.
Regardless, the Exchange services will automatically remove your account from the
'Exchange Enterprise Servers' group on next restart.
Exchange Instant Messaging

What permissions do I need to create and manage an Instant Messaging virtual
server?
To create and manage an Instant Messaging (IM) virtual server, you need the following
permissions:
• Exchange Administrator role on the administrative group where the Instant

Messaging virtual server will be created
If you need to change the firewall topology information for Instant Messaging within your
organization, you will need this additional permission:
• Exchange Administrator role on the Exchange organization
What permissions do I need to IM-enable users?
You need permissions to change attributes on each users' Active Directory object. For more
information about how to create 'mailbox administrators,' see "Exchange Server 2003
Delegation and Roles." Additionally, you need the following permissions:
• At least Exchange View Only Administrator role on the administrative group where
the Instant Messaging virtual server exists
Exchange Conferencing Server

What permissions do I need to install Microsoft Exchange 2000 Conferencing Server?
To install Exchange Conferencing Server, you need to be logged on to Active Directory as a

user with the following permissions:
• Exchange Full Administrator role at the Exchange 2000 Server organization level
• Member of the local "Administrators" group on the target server

85
What permissions do I need to update Exchange 2000 Conferencing Server to Service

Pack 2?
To update your Exchange Conferencing Server installation to Service Pack 2 (SP2), you need
to be logged on to Active Directory as a user with the following permissions:
• Exchange Full Administrator role at the Exchange 2000 Server organization level
• Member of "Domain Admins" in the domain where the conferencing server resides
• Member of the local "Administrators" group on the target server
You need to be a "Domain Admin" to update to SP2 because the installer creates a new
Global Security Group in the "Users" container called "Exchange Conferencing Access
Servers". This new group resolves past problems where non-Windows 2000 Server clients
could not join secure conferences.
How do the Exchange Administrator roles affect Exchange Conferencing Server

management?
The following table shows the different conferencing-related operations that administrators in
various roles can perform.
Conferencing-related operations available to administrators at the administrative

group level
Operation Exchange Full Exchange Exchange View Only

Administrator Administrator Administrator
Install or remove X Not applicable Not applicable

conferencing
services
Stop and start X Not applicable Not applicable

conferencing
services
Create or delete the X X Not applicable

Conference
Calendar mailbox
and resource
mailboxes
Add, remove, or X X Not applicable

configure
Conferencing
Technology
Providers
86
Operation Exchange Full Exchange Exchange View Only

Administrator Administrator Administrator
View conference X X X
settings
Modify conference X X Not applicable

settings
*Unless local Administrator permissions are granted
When joining a conference, an ActiveX control is downloaded to the user's machine.

What permissions are required to install the control?
The ActiveX control consists of two files; xcliacc_x86.dll and xcliacc.inf. Users must have
local administrator permissions to download the control into <drive>:\%WinDir%\Downloaded
Program Files.
Split Permissions Model Reference

This section is a reference to help you plan your split permissions model.
When you downloaded Working with Active Directory Permissions in Exchange Server 2003
from the Microsoft Download Center, a folder named DSACLS Snippets was also created in
the same folder where this guide was created. The DSACLS Snippets folder contains
DSACLS snippets that you can copy and paste into the Dsacls.exe tool. These snippets are
saved in individual text files that have names that correspond to the headings in this section.
See "DSACLS Command Syntax Snippets" for a complete list of the snippet text file names.
The tables in this section list attributes by their LDAP display name. If an attribute is followed
by text in parentheses, that text indicates the name as seen in Active Directory® directory
service interfaces (like ADSI Edit). All references to user objects also apply to the
inetOrgPerson object; however, the inetOrgPerson object is not specified in the section titles
because it is rarely used.
Most of the attributes apply to both Microsoft® Exchange 2000 Server and Exchange
Server 2003. However, there are some exceptions and these exceptions are indicated in the
tables.
87
Exchange-Related Attributes on User,

Group, and Contact Objects
The Exchange-related attributes are associated to user, inetOrgPerson, group, and contact
class objects. These attributes are listed according to each Exchange tab within the
Active Directory Users and Computers Microsoft Management Console MMC snap-in.
By granting an Exchange Administrator Read and Write access to the attributes that are
associated with the tabs listed below, the administrator can perform a particular function (for
example, manage e-mail addresses).
It is possible to be more granular in granting permissions. For example, the Exchange

Administrator may be granted the ability to modify only the attributes that are associated with
a particular function on the tab (for example, Delivery Restrictions).
Exchange General Tab

The following table lists the attributes that can be viewed on the Exchange General tab of a
mailbox-enabled user object when using the Exchange-enabled Active Directory Users and
Computers (ADU&C) MMC snap-in.
Exchange General tab - Mailbox-Enabled User or inetOrgPerson object
ADU&C location Attribute Description
Exchange General tab mailNickname (Alias) Mailbox alias
Delivery Restrictions button unauthOrig Messages rejected from (for

mailboxes)
Delivery Restrictions button authOrig Messages accepted from

(for mailboxes)
Delivery Restrictions button delivContLength Receiving message size
Delivery Restrictions button submissionContLength Sending message size
Delivery Restrictions button dLMemRejectPerms Messages rejected from (for

distribution groups)
Delivery Restrictions button dLMemSubmitPerms Messages accepted from

(for distribution groups)
88
Delivery Restrictions button msExchRequireAuthToSend Restrict messages from

To authenticated users only
(Applies only to Exchange

Server 2003)
Delivery Options button deliverAndRedirect Store and forward message
Delivery Options button publicDelegates Send on behalf
Delivery Options button altRecipient Forwarding address
Delivery Options button msExchRecipLimit Maximum recipient limits
Storage Limits button mDBOverHardQuotaLimit Prohibit send/receive
Storage Limits button mDBOverQuotaLimit Prohibit send
Storage Limits button mDBStorageQuota Warning size
Storage Limits button mDBUseDefaults Use store defaults
Storage Limits button garbageCollPeriod Deleted item retention
Storage Limits button deletedItemFlags Deleted item retention
mail-enabled group object when using the Exchange-enabled Active Directory Users and
Computers MMC snap-in.
Exchange General tab - Mail-Enabled Group object
Message Size section displayName (Display Display name

Name)
mailNickname (Alias) Group alias
Message Size section delivContLength Receive message size
Message Restrictions unauthOrig Messages rejected from (for

section mailboxes)
Message Restrictions authOrig Messages accepted from

section (for mailboxes)
Message Restrictions dLMemRejectPerms Messages rejected from (for

section distribution groups)
89
Message Restrictions dLMemSubmitPerms Messages accepted from

section (for distribution groups)
Message Restrictions msExchRequireAuthToSend Restrict messages from

section To authenticated users only
(Applies only to
Exchange Server 2003)
mail-enabled user or inetOrgPerson or contact object when using the Exchange-enabled
Active Directory Users and Computers MMC snap-in.
Exchange General tab - Mail-Enabled User, inetOrgPerson or Contact object
Exchange General tab proxyAddresses Proxy addresses
Exchange General tab targetAddress (E-mail External e-mail address

Address (External))
Exchange General tab mailNickname (Alias) Contact alias
Exchange General tab mail (E-mail Address) E-mail address
(Applies only to

section mailboxes)




(Applies only to
90
Exchange Features Tab

The following table lists the attributes that can be viewed on the Exchange Features tab of
the mailbox-enabled user or inetOrgPerson object when using the Exchange-enabled
Exchange Features tab - Mailbox-Enabled User or inetOrgPerson object
Exchange Features – msExchIMAddress User's Instant Messaging

Instant Messaging (IM) address
(Applies only to msExchIMMetaPhysicalURL IM fully qualified domain

Exchange 2000 Server) name (FQDN) URL
Exchange Features – msExchIMPhysicalURL IM physical machine URL

Instant Messaging
(Applies only to msExchIMVirtualServer IM virtual server

Exchange 2000 Server)
Exchange Features – msExchIMACL ACL for Instant Messaging

Instant Messaging
Mobile Services msExchOmaAdminWireless Control mobility functions

Enable
Server 2003)
Protocols protocolSettings Protocols used to access

mailbox
Server 2003)
E-Mail Addresses Tab

The following table lists the attributes that can be viewed on the E-Mail Addresses tab of a
user, inetOrgPerson, group, or contact object when using the Exchange-enabled
91
E-Mail Addresses Tab - User, InetOrgPerson, Group, and Contact object
E-mail Addresses tab proxyAddresses (Proxy All proxy addresses

Addresses)
E-mail Addresses tab msExchPoliciesExcluded Controlled by recipient

policy?
E-mail Addresses tab mail (E-Mail Address) Primary e-mail address
E-mail Addresses tab textEncodedORAddress Primary X.400 address
Exchange Advanced Tab

The following table lists the attributes that can be viewed on the Exchange Advanced tab of a
mailbox-enabled user or intetOrgPerson object when using the Exchange-enabled
Exchange Advanced tab - Mailbox-Enabled User or inetOrgPerson object
Exchange Advanced tab msExchHideFromAddressLi Hide object from GAL

sts
Exchange Advanced tab displayNamePrintable Legacy display name format

(Simple Display Name) for down-level mail systems
Exchange Advanced tab securityProtocol Downgrade high priority mail

bound for X.400
Protocol Settings button protocolSettings Protocols used to access

mailbox
(Applies only to
Exchange 2000 Server )
ILS Settings button autoReplyMessage (ILS Internet locator service

Settings) information
Custom Attributes button extensionAttribute1 (Custom Custom attribute

Attribute 1)
Custom Attributes button extensionAttribute10 Custom attribute

(Custom Attribute 10)

92





Attribute 2)

Attribute 3)

Attribute 4)

Attribute 5)

Attribute 6)

Attribute 7)

Attribute 8)

Attribute 9)
mail-enabled group object when using the Exchange-enabled Active Directory Users and
Computers MMC snap-in.
Exchange Advanced tab - Mail-Enabled Group object

sts
93

Exchange Advanced tab msExchExpansionServerNa Group expansion Server

me
Exchange Advanced tab oOFReplyToOriginator Send OOF messages to

message originator
Exchange Advanced tab homeMTA Exchange Server message

transfer agent (MTA)
(coordinated with expansion
server)
Delivery Reports section reportToOwner Send delivery report to

owner
Delivery Reports section reportToOriginator Send delivery report to

originator

Attribute 1)







Attribute 2)

Attribute 3)

Attribute 4)
94

Attribute 5)

Attribute 6)

Attribute 7)

Attribute 8)

Attribute 9)
mail-enabled user, inetOrgPerson, or contact object when using the Exchange-enabled
Exchange Advanced tab - Mail-Enabled User, inetOrgPerson, or Contact object

sts

Exchange Advanced tab mAPIRecipient Use MAPI Rich Text Format

(RTF)
ILS Settings button autoReplyMessage (ILS Internet locator service

Settings) information

Attribute 1)



95




Attribute 2)

Attribute 3)

Attribute 4)

Attribute 5)

Attribute 6)

Attribute 7)

Attribute 8)

Attribute 9)
User-Related Tasks
Each organization defines what it expects from an Exchange administrator. However,
Exchange administrators need to perform certain common tasks with regard to user and
inetOrgPerson objects. For example:
• Mailbox-enabling user or inetOrgPerson objects
• Moving mailboxes
• Mailbox-disabling user or inetOrgPerson objects
• Mail-enabling user or inetOrgPerson objects

96
• Mail-disabling user or inetOrgPerson objects
• Removing Exchange attributes
Administrators can perform these tasks by using the Exchange Tasks Wizard in the
Exchange-enabled Active Directory Users and Computers MMC snap-in.
Mailbox-Enabling User Objects

To mailbox-enable a user or inetOrgPerson object, the Exchange administrator must apply
the Exchange delegated role, Exchange View-Only Administrator (or higher), on the target
administrative group.
In addition, the Exchange administrator must have Read and Write access to the following
user or inetOrgPerson object attributes:
• adminDisplayName
• autoReplyMessage (ILS Settings)
• displayName (Display Name)
• dLMemDefault
• homeMDB (Exchange Mailbox Store)
• homeMTA
• legacyExchangeDN
• mail (E-Mail Address)
• mailNickname (Alias)
• mAPIRecipient
• mDBUseDefaults
• msExchADCGlobalNames
• msExchControllingZone
• msExchFBURL
• msExchHideFromAddressLists
• msExchHomeServerName (Exchange Home Server)
• msExchMailboxGuid
• msExchMailboxSecurityDescriptor
• msExchPoliciesIncluded
97
• msExchResourceGUID
• msExchUserAccountControl
• proxyAddresses (Proxy Addresses)
• showInAddressBook
• targetAddress
Moving Mailboxes
Beginning with Exchange Server 2003 Service Pack 1 (SP1), there are two methods for
moving mailboxes depending on the organization mode in which your Exchange environment
is operating.
• If you are in mixed mode, the Move Mailbox Task will present you with two options.
• Same Administrative Group Move
• Cross Administrative Group Move
• If you are in native mode, you can move a mailbox within and between administrative
groups.
Mixed Mode Move Mailbox Permissions

The permissions required to move mailboxes in a mixed mode environment are different
depending on whether you are moving mailboxes to a different administrative group.
Permissions for Mixed Mode Same Administrative Group

Mailbox Move Operations
To move mailboxes, the Exchange administrator must have the Exchange delegated role,
Exchange Administrator (or higher), on the source and destination administrative groups.
The Exchange Administrator must be a local administrator on the workstation which is being
used to perform the Move Mailbox task. In addition, the Exchange Administrator must have
Read and Write access to the following user or inetOrgPerson object attributes:
• homeMTA
• targetAddress
98
• msExchOmaAdminWirelessEnable
Note:
This attribute is removed if you are moving a mailbox to a server running
Exchange Server 5.5 or Exchange 2000 Server.
• msExchOmaAdminExtendedSettings
Note:
Permissions for Mixed Mode Cross Administrative Group

Mailbox Move Operations
To move mailboxes across the administrative group boundary while operating in mixed mode,
the Exchange administrator must have:
• The Exchange delegated role, Exchange Administrator (or higher), on the source and
destination administrative groups.
Note:
If you are moving mailboxes from an Exchange 5.5 server, then you will need the
Exchange delegated role, Admin (or higher) on the 5.5 site and configuration contexts
that contain the mailboxes.
• The Exchange delegated role, Exchange View Only Administrator role (or higher)
delegated at the organization level to read the properties of the ADC Configuration
Connection Agreements to determine the target administrative group’s responsible SRS.
• The Exchange delegated role, Admin (or higher) on the source 5.5 site and the 5.5
site that contains the target administrative group’s SRS (this is granted through the
Exchange 5.5 Administrator program).
The Exchange administrator must be a local administrator on the workstation which is being
• homeMTA
• targetAddress
• proxyAddresses
99
Permissions for Native Mode Mailbox Move

Operations
To move mailboxes, the Exchange administrator must have the Exchange delegated role,
Exchange Administrator (or higher), on the source and destination administrative groups.
The Exchange Administrator must be a local administrator on the workstation which is being
• homeMTA
• targetAddress
• msExchOmaAdminWirelessEnable
Note:
• msExchOmaAdminExtendedSettings
Note:
Mailbox-Disabling User Objects

Some organizations have policies stating that they must disable a mailbox for a specific
period of time prior to deleting it. To mailbox-disable a user or inetOrgPerson object, the
Exchange Administrator must have the Exchange delegated role, Exchange View-Only
Administrator (or higher), on the target administrative group. In addition, the Exchange
Administrator must have Read and Write access to the following user or inetOrgPerson object
attributes:
Note:
Mailbox-disabling an object marks the mailbox for deletion within the Exchange
database; it does not disable the object as an authentication principal.
100
• altRecipient
• authOrig
• deletedItemFlags
• delivContLength
• deliverAndRedirect
• displayNamePrintable (Simple Display Name)
• dLMemDefault
• dLMemRejectPerms
• dLMemSubmitPerms
• extensionAttribute1 (Custom Attribute 1)
• folderPathname (Outlook Web Access Server)
• garbageCollPeriod
• homeMTA
101
• internetEncoding
• mAPIRecipient
• mDBOverHardQuotaLimit
• mDBOverQuotaLimit
• mDBStorageQuota
• mDBUseDefaults
• msExchExpansionServerName
• msExchFBURL
• msExchMasterAccountSid (Applies only to Exchange Server 2003)
• msExchOmaAdminExtendedSettings (Applies only to Exchange Server 2003)
• msExchOmaAdminWirelessEnable (Applies only to Exchange Server 2003)
• msExchRecipLimit
• protocolSettings
• publicDelegates
• securityProtocol
• submissionContLength
102
• targetAddress
• unauthOrig
Mail-Enabling User Objects

Mail-enabled user or inetOrgPerson objects are objects that have an e-mail address, but they
do not have a mailbox stored on the servers running Exchange in that forest. These objects
are similar to a contact, which can also be mail-enabled, except that there are security rights
associated with the user object that a contact object does not possess within the forest
boundary. To mail-enable a user or inetOrgPerson object, the Exchange Administrator must
have the Exchange delegated role, Exchange View-Only Administrator (or higher), on the
target administrative group. In addition, the Exchange Administrator must have Read and
Write access to the following user or inetOrgPerson Object attributes:
• dLMemDefault
• homeMTA
• mAPIRecipient
• msExchFBURL
103
• targetAddress
Mail-Disabling User Objects

Disabling mail-enabled user or inetOrgPerson objects is sometimes necessary if
organizations have a policy to disable the accounts prior to deletion. To mail-disable a user or
inetOrgPerson object, the Exchange Administrator must have the Exchange delegated role,
Exchange View-Only Administrator (or higher), on the target administrative group. In addition,
the Exchange Administrator must have Read and Write access to the following user or
inetOrgPerson object attributes:
Note:
Mail-disabling an object removes mail-related properties from the object; it does not
disable the object as an authentication principal.
• altRecipient
• authOrig
• delivContLength
• dLMemDefault

104

• homeMTA
• mAPIRecipient
• mDBStorageQuota
• mDBUseDefaults
• msExchFBURL
105
• publicDelegates
• targetAddress
• unauthOrig
Removing Exchange Attributes on User

Objects
In Service Pack 2 (SP2) for Exchange 2000 Server and later, administrators can use the
Remove Exchange Attributes task to remove Exchange attributes from user or inetOrgPerson
objects. Use this option with caution as it forcibly removes all Exchange-related attributes
from the object.
To remove all Exchange attributes on a user object, the Exchange Administrator must have
administrative group. In addition, the Exchange Administrator must have Read and Write
access to the following user or inetOrgPerson object attributes:
106
• altRecipient
• authOrig
• autoReply
• delivContLength
• deliveryMechanism
• delivExtContTypes
• dLMemDefault
• dnQualifier
• enabledProtocols
• expirationTime

107
• extensionData
• formData
• forwardingAddress
• heuristics
• homeMTA
• importedFrom
• language
• languageCode
• mAPIRecipient
• mDBStorageQuota
• mDBUseDefaults
• msExchALObjectVersion
• msExchCustomProxyAddresses
• msExchFBURL
• msExchInconsistentState
108
• msExchMailboxUrl
• msExchPfRootUrl
• msExchPolicyEnabled
• msExchPolicyOptionList
• msExchPreviousAccountSid
• msExchProxyCustomProxy
• msExchUnmergedAttsPt
• msExchUseOAB
• pOPCharacterSet
• pOPContentFormat
• publicDelegates
• replicatedObjectVersion
• replicationSensitivity
• replicationSignature
• targetAddress
109
• unauthOrig
• unmergedAtts
Mail-Enabled Group Related Tasks

Each organization defines what it expects from an Exchange administrator relating to mail-
enabled group management. However, there are certain common tasks that Exchange
Administrators need to perform with regard to group objects. For example:
• Mail-enabling group objects
• Mail-disabling group objects
• Hiding group membership
These tasks can be performed using the Exchange Tasks Wizard in the Exchange-enabled
Mail-Enabling Group Objects

Mail-enabled groups can be of two types: distribution groups and security groups. The
difference between the two groups is that security groups may be used to assign permissions
against a resource in the forest. To mail-enable a group object, the Exchange Administrator
must have the Exchange delegated role, Exchange View-Only Administrator (or higher), on
the target administrative group. In addition, the Exchange Administrator must have Read and
Write access to the following group object attributes:
• autoReplyMessage
• dLMemDefault
• homeMTA
• mail
110
• mAPIRecipient
• msExchFBURL
• reportToOriginator
• targetAddress
Mail-Disabling Group Objects

To mail-disable a group object, the Exchange Administrator must have the Exchange
delegated role, Exchange View-Only Administrator (or higher), on the target administrative
group. In addition, the Exchange Administrator must have Read and Write access to the
following group object attributes:
Note:
Mail-disabling a group object only removes mail-related properties from the object;
the group itself is not deleted and membership is not affected.
• altRecipient
• authOrig
• delivContLength
• dLMemDefault
111

• folderPathname
• hideDLMembership
• homeMTA
• mail
• mAPIRecipient
• msExchFBURL

112
• oOFReplyToOriginator
• publicDelegates
• reportToOwner
• targetAddress
• unauthOrig
Hiding Group Membership

Sometimes it is necessary to hide the members of a mail-enabled group to protect the privacy
of the recipients. To hide group membership for a mail-enabled group object, the Exchange
Administrator must have the Exchange delegated role, Exchange View-Only Administrator (or
higher), on the target administrative group. In addition, the Exchange Administrator must have
Read and Write access to the following membership attributes:
• permissions
• reportToOwner
Note:
The permissions attribute is not a property of group objects. It is an object right for
the group class object (for example, grant Read and Modify Permissions). For
113
information about how to set this attribute correctly, see the Hiding Group
Membership DSACLS snippet text file.
Removing Exchange Attributes on Group

Objects
Remove Exchange Attributes task to remove Exchange attributes from group objects. Use
this option with caution because it forcibly removes all Exchange-related attributes from the
object.
To remove all Exchange attributes on a group object, the Exchange Administrator must have
access to the following group object attributes:
• altRecipient
• authOrig
• delivContLength
• dLMemDefault
• dnQualifier
• expirationTime

114

• extensionData
• folderPathname
• formData
• heuristics
• homeMTA
• importedFrom
• language
• languageCode
• mail
• mAPIRecipient
115
• msExchFBURL
• pOPCharacterSet
• publicDelegates
• reportToOwner
116
• targetAddress
• unauthOrig
• unmergedAtts
Contact Related Tasks

Each organization defines what it expects from an Exchange Administrator regarding contact
management. However, there are certain common tasks that Exchange Administrators need
to perform with regard to contact objects. For example:
• Mail-enabling contact objects
• Mail-disabling contact objects
These tasks can be performed using the Exchange Tasks Wizard in the Exchange-enabled
Mail-Enabling Contact Objects

To mail-enable a contact object, the Exchange Administrator must have the Exchange
delegated role, Exchange View-Only Administrator (or higher) on the target administrative
following contact object attributes:
• dLMemDefault
• homeMTA
• mAPIRecipient
117
• msExchFBURL
• targetAddress (E-Mail Address (External))

Mail-Disabling Contact Objects

To mail-disable a contact object, the Exchange Administrator must have the Exchange
delegated role, Exchange View-Only Administrator (or higher) on the target administrative
following contact object attributes:
Note:
Mail-disabling a contact object only removes mail-related properties from the object;
the contact itself is not deleted.
• altRecipient
• authOrig
• delivContLength
• dLMemDefault

118

• folderPathname
• homeMTA
• mAPIRecipient
• msExchFBURL
119
• publicDelegates

• unauthOrig
Removing Exchange Attributes on Contact

Objects
Remove Exchange Attributes task to remove Exchange attributes from contact objects. Use
this option with caution because it forcibly removes all Exchange-related attributes from the
object.
To remove all Exchange attributes on a contact object, the Exchange Administrator must have
the Exchange delegated role, Exchange View-Only Administrator (or higher) on the target
access to the following contact object attributes:
• altRecipient
• authOrig
• delivContLength

120
• dLMemDefault
• dnQualifier
• expirationTime

• extensionData
• folderPathname
• formData
• heuristics
• homeMTA
• importedFrom
121
• language
• languageCode
• mAPIRecipient
• msExchFBURL
• pOPCharacterSet
• publicDelegates
122
• unauthOrig
• unmergedAtts
Query-Based Distribution Groups

A query-based distribution group is a new type of distribution group introduced in Exchange
Server 2003. A query-based distribution group provides the same functionality as a standard
distribution group. However, instead of specifying static user memberships, a query-based
distribution group allows you to use a Lightweight Directory Access Protocol (LDAP) query to
dynamically build membership in the distribution group (for example, "All full-time employees
in my company").
Using query-based distribution groups results in a much lower administrative cost, given the
dynamic nature of the distribution group. However, query-based distribution groups require
higher performance cost for queries that produce a large number of results. This cost is
equated with server resources (such as high CPU and increased working set) because every
time an e-mail message is sent to a query-based distribution group, an LDAP query is
executed against Active Directory to determine its membership.
Query-based distribution groups function in a pure Exchange Server 2003 deployment or in a

native Exchange 2000 Server and Exchange Server 2003 deployment in which all servers
running Exchange 2000 Server are running Service Pack 3 (SP3) with Windows Server 2003
global catalog servers.
For more information about query-based distribution groups, see Administration Features
in Exchange Server 2003.
For more information about Exchange related attributes of query-based distribution group
objects, see Exchange-Related Attributes of Query-Based Distribution Group Objects.
For information about troubleshooting query-based distribution groups, see Microsoft

Knowledge Base article, "How to Troubleshoot Query-Based Distribution Groups."
123
Exchange-Related Attributes of Query-

Based Distribution Group Objects
The following tables list the Exchange Server 2003 attributes that can be viewed on the
Exchange-related tabs of a query-based distribution group object when using the Exchange-
enabled Active Directory Users and Computers MMC snap-in. By granting Read and Write
access to these attributes, an Exchange Administrator can manage these properties.
General tab - query-based distribution group object
General tab mail (Internet E-Mail E-mail address

Address)
General tab proxyAddresses (Proxy Proxy addresses

Addresses)
General tab description Description field
Filter section msExchPurportedSearchUI LDAP search criteria
Filter section msExchDynamicDLFilter LDAP filter
Filter section msExchDynamicDLBaseDN LDAP filter base

distinguished name
Exchange General tab - query-based distribution group object
Exchange General tab displayName (Display Display name

Name)
Exchange General tab mailNickname (Alias) Group alias

section mailboxes)



124

E-Mail Addresses tab - query-based distribution group object
E-mail Addresses tab proxyAddresses (Proxy All proxy addresses

Addresses)
E-mail Addresses tab msExchPoliciesExcluded Controlled by recipient

policy
E-mail Addresses tab mail (Internet E-Mail Primary e-mail address

Address)
E-mail Addresses tab textEncodedORAddress Primary X.400 address
Exchange Advanced tab - query-based distribution group object
Exchange Advanced tab msExchHideFromAddressLi Hide object from global

sts address list (GAL)

Exchange Advanced tab msExchExpansionServerNa Group expansion Server

me
Exchange Advanced tab oOFReplyToOriginator Send Out of Facility (OOF)

messages to message
originator
Exchange Advanced tab homeMTA Exchange Server message

transfer agent (MTA)
(coordinated with expansion
server)
Delivery Reports section reportToOwner Send delivery report to

owner
Delivery Reports section reportToOriginator Send delivery report to

originator
125

Attribute 1)







Attribute 2)

Attribute 3)

Attribute 4)

Attribute 5)

Attribute 6)

Attribute 7)

Attribute 8)

Attribute 9)
126
Other GAL-Related User, Group, and

Contact Attributes
Other topics discuss Exchange-specific tasks and Exchange-related attributes on the user,
group, and contact class objects. There are, however, other related attributes on those
objects that may require delegation. For example, administrators may want to manage the
properties of those attributes that relate to the global address list (GAL).
The following table lists the attributes for user, group, and contact objects that are seen within
the GAL. You can view and modify these attributes on specific tabs of the appropriate object
by using the Active Directory Users and Computers (ADU&C) MMC snap-in.
Note:
The following table lists examples of attributes that an Exchange Administrator may
want to modify. Depending on the organization's business needs and processes,
attributes may be added to or removed from this list. Regardless, the same steps
apply as to how to delegate responsibilities.
Other GAL-related attributes
Applies to object ADU&C location Attribute Description
User, Contact General tab physicalDeliveryOffi Office

ceName
User, Contact General tab displayName Display name
User, Contact General tab givenName First name
User, Contact General tab initials Initial
User, Contact General tab sn Last name
User, Contact General tab telephoneNumber Business number
User, Contact General tab otherTelephone Business number 2
User, Contact Telephones tab homePhone Home phone number
User, Contact Telephones tab otherHomePhone Home phone number

2
User, Contact Telephones tab pager Pager phone number
User, Contact Telephones tab mobile Mobile phone

number
User, Contact Telephones tab facsimileTelephoneN Fax number

umber
127
Applies to object ADU&C location Attribute Description
User, Contact Telephones tab info Notes field
User, Contact Organization tab manager Manager
User, Contact Organization tab directReports Direct reports
User, Contact Organization tab title Title
User, Contact Organization tab company Company name
User, Contact Organization tab department Department name
User, Contact Address tab streetAddress Street address
User, Contact Address tab postOfficeBox Post office box
User, Contact Address tab l City
User, Contact Address tab st State
User, Contact Address tab postalCode ZIP code or postal

code
User, Contact Address tab countryCode Country
User, Contact Not applicable telephoneAssistant Assistant's

telephone
User, Contact Not applicable msExchangeAssista Assistant's name

ntName
Group Managed By tab managedBy Group owner
Group General tab Info Notes field
Note:
The attributes telephoneAssistant and secretary must be manually entered using the
LDP tool (Ldp.exe) or ADSI Edit (AdsiEdit.msc). The ActiveDirectory Users and
Computers MMC snap-in does not expose these fields.
DSACLS Command Syntax Snippets

This topic provides information about the DSACLS command syntax text files. You can find
the text files in the folder named DSACLS Snippets, which is in the download from Working
with Active Directory Permissions in Exchange Server 2003. The following is a complete list
of the text files.
128
• Email Addresses Tab – Mail-Enabled Group Object.txt
• Email Addresses Tab – Mail-Enabled Contact Object.txt
• Email Addresses Tab – Mailbox or Mail-Enabled User Object.txt
• Email Addresses Tab – Mailbox or Mail-Enabled InetOrgPerson Object (Exchange

2003).txt
• Email Addresses Tab – Query-Based Distribution Group (Exchange 2003).txt
• Exchange Advanced Tab - Query-Based Distribution Group (Exchange 2003).txt
• Exchange Advanced Tab – Mail-Enabled User Object.txt
• Exchange Advanced Tab – Mail-Enabled InetOrgPerson Object (Exchange 2003).txt

• Exchange Advanced Tab – Mail-Enabled Group Object.txt
• Exchange Advanced Tab – Mail-Enabled Contact Object.txt
• Exchange Advanced Tab – Mailbox-Enabled User Object (Exchange 2003).txt
• Exchange Advanced Tab – Mailbox-Enabled User Object (Exchange 2000).txt
• Exchange Advanced Tab – Mailbox-Enabled InetOrgPerson Object

(Exchange 2003).txt
• Exchange Features Tab – Mailbox-Enabled User Object (Exchange 2003).txt
• Exchange Features Tab – Mailbox-Enabled User Object (Exchange 2000).txt
• Exchange Features Tab – Mailbox-Enabled InetOrgPerson Object

(Exchange 2003).txt
• Exchange General Tab – inetOrgPerson Object (Exchange 2003).txt
• Exchange General Tab – inetOrgPerson Object (Exchange 2000).txt
• Exchange General Tab – Mail-Enabled User Object (Exchange 2003).txt
• Exchange General Tab – Mail-Enabled User Object (Exchange 2000).txt
• Exchange General Tab – Mail-Enabled Group Object (Exchange 2003).txt
• Exchange General Tab – Mail-Enabled Group Object (Exchange 2000).txt
• Exchange General Tab – Mail-Enabled Contact Object (Exchange 2003).txt
• Exchange General Tab – Mail-Enabled Contact Object (Exchange 2000).txt
• Exchange General Tab – Mailbox-Enabled User Object (Exchange 2003).txt
• Exchange General Tab – Mailbox-Enabled User Object (Exchange 2000).txt
• Exchange General Tab – Mailbox-Enabled InetOrgPerson Object

(Exchange 2003).txt
• Exchange General Tab – Query-Based Distribution Group (Exchange 2003).txt

129
• Exchange Remove Attributes – InetOrgPerson Object (Exchange 2003).txt
• Exchange Remove Attributes – User Object (Exchange 2003).txt
• Exchange Remove Attributes – User Object (Exchange 2000).txt
• General Tab - Query-Based Distribution Group (Exchange 2003).txt
• Hiding Group Membership.txt
• Mail-Disable InetOrgPerson Object (Exchange 2003).txt
• Mail-Disable User Object (Exchange 2003).txt
• Mail-Disable User Object (Exchange 2000).txt
• Mail-Disabling Contact Objects (Exchange 2003).txt

• Mail-Disabling Contact Objects (Exchange 2000).txt
• Mail-Disabling Group Objects (Exchange 2003).txt
• Mail-Disabling Group Objects (Exchange 2000).txt
• Mail-Enable InetOrgPerson Object (Exchange 2003).txt
• Mail-Enable User Object.txt
• Mail-Enabling Contact Objects.txt
• Mail-Enabling Group Objects.txt
• Mailbox-Disable User Object (Exchange 2003).txt
• Mailbox-Disable User Object (Exchange 2000).txt
• Mailbox-Enable InetOrgPerson Object (Exchange 2003).txt
• Mailbox-Enable User Object.txt
• Mailbox Move InetOrgPerson Object (Exchange 2003).txt
• Mailbox Move User Object.txt
• Removing Exchange Attributes on Contact Objects (Exchange 2003).txt
• Removing Exchange Attributes on Contact Objects (Exchange 2000).txt
• Removing Exchange Attributes on Group Objects (Exchange 2003).txt
• Removing Exchange Attributes on Group Objects (Exchange 2000).txt
Note:
Incorrectly modifying the attributes of Active Directory® directory service objects by
using ADSI Edit (AdsiEdit.msc), DSACLS (Dsacls.exe), the LDP tool (Ldp.exe), or
any other Lightweight Directory Access Protocol (LDAP) version 3 clients can cause
serious problems. These problems may require reinstallation of Microsoft® Windows
Server, Microsoft Exchange Server, or both. Problems that occur if ActiveDirectory
130
object attributes are modified incorrectly may not be solved. Modify these attributes at
your own risk.
The format for DSACLS is the following:

dsacls "<ContainerPath>" /I:S /G "<Domain>\<Alias>:RPWP;<Attribute>;<ClassObject>"
Where:
• <ContainerPath> is the distinguished name of the object (for example, domain,

organizational unit);
• <Domain>\<Alias> is the account\group being granted access; where <Attribute> is

the attribute to which access is being granted;
• <ClassObject> is the class object (user, group, contact, and so on) to which the
attribute is associated.
The /I:S switch signals DSACLS to apply the permissions to sub-objects contained within the
container path. The /G switch signals DSACLS to grant the necessary permissions (as
opposed to deny or remove the permissions).
The RP argument signals DSACLS to grant the Read access for the property in question. The
WP argument signals DSACLS to grant Write access for the property in question.
Note:
The syntax for DSACLS is one command line, which contains no line breaks.
Copyright
The information contained in this document represents the current view of Microsoft
Corporation on the issues discussed as of the date of publication. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on
the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information
presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting
the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express
written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
131
written license agreement from Microsoft, the furnishing of this document does not give you
any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted in examples herein are fictitious. No
association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred.
© 2006 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync,
ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN,
Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile,
Windows NT, and Windows Server System are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.

E2 K 3 ADPerm

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

E2 K 3 ADPerm

Uploaded by

Copyright:

Available Formats

Working with Active Directory Permissions

in Microsoft Exchange Server 2003

Published: December 12, 2006

Author: Exchange Server Documentation Team

Comments? Send feedback to exchdocs@microsoft.com.

Working with Active Directory Permissions in Exchange Server...............................................7

Exchange Server 2003 Data and Active Directory....................................................................9

Schema Naming Context..........................................................................................................9

Configuration Naming Context................................................................................................10

Domain Naming Context.........................................................................................................10

Exchange Server 2003 Delegation and Roles........................................................................11

Exchange Full Administrator...................................................................................................11

Exchange View Only Administrator.........................................................................................13

Effective Permissions Granted by the Exchange Administration Delegation Wizard..............13

Exchange Server 2003 Permissions FAQ...............................................................................15

Active Directory Connector.....................................................................................................15

Exchange Server 2003 Deployment.......................................................................................20

Exchange Server 2003 Management.....................................................................................33

Planning a Split Permissions Model.......................................................................................39

Implementing a Split Permissions Model................................................................................40

Where to Apply Permissions...................................................................................................40

Applying Permissions at the Domain Level.............................................................................41

Applying Permissions at the Organizational Unit Level..........................................................41

How to Apply Permissions......................................................................................................42

Using DSACLS to Apply Permissions.....................................................................................43

How to Use DSACLS to Apply Permissions............................................................................43

Using ADSI Edit to Apply Permissions....................................................................................44

How to Use ADSI Edit to Apply Permissions...........................................................................44

Prerequisites to Implementing Permissions Changes............................................................46

Permissions Granted During Exchange Setup.......................................................................47

Permissions on Objects in the Exchange Configuration Tree.................................................49

Permissions on Other Objects in the Configuration Naming Context.....................................70

Permissions on Objects in the Domain Naming Context........................................................72

Exchange 2000 Server Permissions FAQ...............................................................................81

Exchange Instant Messaging..................................................................................................84

Exchange Conferencing Server..............................................................................................84

Split Permissions Model Reference........................................................................................86

Exchange-Related Attributes on User, Group, and Contact Objects.......................................87

Exchange General Tab...........................................................................................................87

Exchange Features Tab..........................................................................................................90

E-Mail Addresses Tab.............................................................................................................90

Exchange Advanced Tab........................................................................................................91

Mailbox-Enabling User Objects..............................................................................................96

Mailbox-Disabling User Objects..............................................................................................99

Mail-Enabling User Objects..................................................................................................102

Mail-Disabling User Objects.................................................................................................103

Mail-Enabled Group Related Tasks......................................................................................109

Mail-Enabling Group Objects................................................................................................109

Mail-Disabling Group Objects...............................................................................................110

Hiding Group Membership....................................................................................................112

Removing Exchange Attributes on Group Objects................................................................113

Contact Related Tasks..........................................................................................................116

Mail-Enabling Contact Objects..............................................................................................116

Mail-Disabling Contact Objects.............................................................................................117

Removing Exchange Attributes on Contact Objects.............................................................119

Query-Based Distribution Groups.........................................................................................122

Exchange-Related Attributes of Query-Based Distribution Group Objects...........................123

Other GAL-Related User, Group, and Contact Attributes.....................................................126

DSACLS Command Syntax Snippets...................................................................................127

Working with Active Directory Permissions

Introduction to the Working with Active

• Explanation of the schema, domain, and configuration Active Directory naming