Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2008-02-05
Organizations that implement a split permissions model typically want to restrict specific permissions granted to administrators to enhance accountability and security. In Microsoft Exchange Server 2007, permissions on Exchange recipient attributes are grouped together. This minimizes the manual permission configuration that you must do to split Exchange permissions from other administrative permissions.
By default, only Exchange Organization Administrators can manage both Exchange recipient and configuration data. However, to manage object creation, modification, and deletion within a specific domain, these administrators also require membership in the Windows Account Operators security group or a higher level security group. For information about how to grant Account Operators permissions, see Windows Server 2003 Product Help.
Access Control
To manage Exchange-related attributes on objects within the domain naming context of the forest, Modify permissions must be granted to the Exchange Server Administrators group. You do this by changing the security descriptor on the object that contains the attributes.
A security descriptor contains two access control lists (ACL). 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 specific permissions to be applied to the whole object, a set of properties of the object, or to an individual property of an object. Two types of ACLs are in the security descriptor of an object:
- Discretionary access control lists
(DACL) DACLs determine the users and groups
that are assigned or denied access permissions on an object. If a
DACL does not explicitly determine a user or any groups that a user
is a member of, the user is 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 (ACE) that determine user access to the object.
- System access control lists
(SACL) SACLs determine the users and groups
that you want to audit when they successfully access or cannot
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
ACEs that determine whether to record a successful or failed
attempt by a user who uses a specific permission, such as Full
Control and Read, to access an object.
An ACE is an entry in the DACL of an object that grants permissions to a user or group. An ACE is also an entry in the SACL of an object that specifies the security events that are to be audited for a user or group.
Where to Apply Permissions
An Active Directory directory service forest consists of one or more domains that share a common configuration and schema boundary. Within those domains, objects can also be arranged into containers known as organizational units (OU). The administrators of each organization must design an OU structure that meets their business needs and optimizes delegation of administrative permissions.
For more information about how to design an OU 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 methods for applying permissions. This topic discusses only the following two methods:
- Applying permissions at the domain level
- Applying permissions at the OU level
Applying Permissions at the Domain Level
When you apply delegated permissions on the domain level, the permissions are inherited by all objects. This includes users, contacts, groups, domain DNS, and computers. On domain controllers that are running Microsoft Windows 2000 Server, adding an inheritable ACE at the domain level causes 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 can result in what is known as ACL bloat. ACL bloat means unnecessary ACEs on objects increase the size of the ACL. An ACL bloat increases the physical size of the Ntds.dit file across all domain controllers within the domain. This can cause Active Directory performance issues.
On domain controllers that are running Microsoft Windows Server 2003, a unique security descriptor is stored only one time instead of being stored for every object that inherits it. This change reduces data redundancy and the database growth that can result from changes to inheritable ACEs.
Applying Permissions at the OU Level
The recommended practice for applying permissions is to apply the permissions on a parent OU. This isolates the application of the permissions to specific class objects that are contained within the OU and its child containers. This method requires that all managed objects be put within a parent OU. Business requirements may prevent your organization from applying this method. If business requirements prevent this, you can apply the permissions across multiple OUs.
How to Apply Permissions
Microsoft provides two tools to apply permissions:
- ADSI Edit (AdsiEdit.msc)
- DSACLS (Dsacls.exe)
Both tools are included on the Windows Server 2003 CD in Support\Tools. Several third-party products can also be used to apply permissions.
Note: |
---|
If you incorrectly modify the attributes of Active Directory objects when you use Active Directory Service Interfaces (ADSI) Edit, DSACLS, the LDP (Ldp.exe) tool, or another Lightweight Directory Access Protocol (LDAP) version 3 client, serious problems may occur. These problems may require that you reinstall Windows Server, Exchange 2007, or both. Modify Active Directory object attributes at your own risk. |
For more information about how to use ADSI Edit, see How to Use ADSI Edit to Apply Permissions.
The recommended practice for applying permissions in Exchange 2007 is to use the Add-ADPermission cmdlet in the Exchange Management Shell. For more information, see Add-ADPermission. For more information about the Exchange Management Shell, see Using the Exchange Management Shell.
Examples of How to Apply Permissions
Because of the implementation of property sets in Exchange 2007, implementation of a split permission model requires far fewer ACEs than in earlier versions of Exchange Server.
For an Exchange 2007 administrator to manage all mail-related properties, the administrator must have the following permissions within the domain partition:
- Write access to the following property sets:
- Exchange Personal Information
- Exchange Information
- Exchange Personal Information
- Write access to the following attributes:
- legacyExchangeDN
- displayName
- adminDisplayName
- displayNamePrintable
- publicDelegates
- garbageCollPeriod
- textEncodedORAddress
- showInAddressBook
- proxyAddresses
- mail
- legacyExchangeDN
- Create permission for msExchDynamicDistributionList
objects
- Delete permission for msExchDynamicDistributionList
objects
- Full control permission for
msExchDynamicDistributionList objects
- Generic Read permission. This includes Read Permissions, List
Contents, List Object, and Read All Properties.
In addition to these permissions, the recipient administrator must also have the following permissions in the Exchange organization:
- Exchange View-Only Administrator role or higher
Note: Certain operations, such as moving mailboxes, require Exchange Server Administrator role or higher. - Write access to the msExchLastAppliedRecipientFilter and
msExchRecipientFilterFlags attributes on the Address Lists
container in the Exchange organization. These permissions are
required so the recipient administrator can execute the
Update-AddressList cmdlet.
- Write access to the msExchLastAppliedRecipientFilter and
msExchRecipientFilterFlags attributes on the Recipient
Policies container within the Exchange organization. These
permissions are required so the recipient administrator can execute
the Update-EmailAddressPolicy cmdlet.
- The Access Recipient Update Service extended right on the
Exchange 2007 administrative group. This extended right is
required because in Exchange 2007, the address-related
information is stamped on the recipient during the provisioning
process.
Note: |
---|
These permissions are for managing attributes that are specific to Exchange. Exchange administrators cannot manage attributes that were created outside Exchange unless the administrators are delegated the appropriate permissions. |
How to Use the Exchange Management Shell to Apply Permissions
This section provides an example of how to use the Exchange Management Shell to delegate permissions.
The commands in this example enable the administrators in the OU1AdminGroup security group to mail-enable and mail-disable recipients, manage e-mail addresses, and display names for all users, groups, and contacts that are contained in the Container1 OU hierarchy in the Contoso.com forest that contains the ContosoOrg Exchange organization.
If you want to perform these tasks for your organization, run the following commands for each container where you want to grant access. Replace the domain name, Exchange organization, and account information with your own domain information.
You must run the following commands in this order to grant the permissions.
- Run the following command to manage Exchange-related attributes
on objects within the OU.
Copy Code Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail
- Run the following command to provide Generic Read permission
for all objects within the OU.
Copy Code Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericRead
- Run the following commands to grant the appropriate permission
to manage dynamic distribution groups within the OU:
Copy Code Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericAll -InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList
Copy Code ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericAll -ChildObjectTypes msExchDynamicDistributionList
- Run the following command to grant the OU1AdminGroup security
group extended right to access the Recipient Update Service.
Copy Code Add-ADPermission -Identity "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "Contoso\OU1AdminGroup " -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents
- Run the following commands to grant OU1AdminGroup security
group the ability to update the address lists and e-mail address
policies.
Copy Code Add-ADPermission -Identity "CN=Address Lists Container,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "company\OU1AdminGroup" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags Add-ADPermission -Identity "CN=Recipient Policies,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" -User "company\OU1AdminGroup" -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags
If this is successful, each command will output the ACEs that were added to the object.
How to Use DSACLS to Apply Permissions
This section provides an example of how to use DSACLS (Dsacls.exe) to apply permissions.
DSACLS is a command-line tool that you can use to query and change permissions and security attributes of Active Directory objects. DSACLS is included with the Windows Server 2003 Support Tools. Also, it is the command-line equivalent of the Security tab in the Windows 2000 Server Active Directory snap-in tools, such as Active Directory Users and Computers and Active Directory Sites and Services.
The commands in this example enable the administrators in the OU1AdminGroup security group to mail-enable and mail-disable recipients, manage e-mail addresses, and display names for all users, groups, and contacts that are contained in the OUContainer1 OU hierarchy in the Contoso.com forest that contains the ContosoOrg Exchange organization.
Note: |
---|
DSACLS is case sensitive. You must be precise in the syntax that you pass to DSACLS because all characters are passed literally. This includes white spaces and carriage returns. If you receive errors from DSACLS, review the command to make sure that it is correct, or try breaking the command into smaller segments. For more information about how to use DSACLS, see Microsoft Knowledge Base article 281146, How to Use Dsacls.exe in Windows Server 2003 and Windows 2000. |
You must run the following commands in this order to grant the permissions.
- Log on to a computer within the forest that has the
Windows Support Tools installed by using an account that can
perform the tasks, such as Domain Administrator. Replace the
domain name, Exchange organization, and account information
with your own domain information.
- Open a Command Prompt window, and type the following commands
to manage Exchange-related attributes on objects within the OU.
Copy Code dsacls "OU=OUContainer1,DC=Contoso,DC=com" /I:T /G "Contoso\OU1AdminGroup:RPWP;legacyExchangeDN" "Contoso\OU1AdminGroup:RPWP;displayName" "Contoso\OU1AdminGroup:RPWP;adminDisplayName" "Contoso\OU1AdminGroup:RPWP;displayNamePrintable" "Contoso\OU1AdminGroup:RPWP;publicDelegates" "Contoso\OU1AdminGroup:RPWP;garbageCollPeriod" "Contoso\OU1AdminGroup:RPWP;textEncodedORAddress" "Contoso\OU1AdminGroup:RPWP;showInAddressBook" "Contoso\OU1AdminGroup:RPWP;proxyAddresses" "Contoso\OU1AdminGroup:RPWP;mail" "Contoso\OU1AdminGroup:RPWP;Exchange Personal Information" "Contoso\OU1AdminGroup:RPWP;Exchange Information" "Contoso\OU1AdminGroup:CCDC;msExchDynamicDistributionList" "Contoso\OU1AdminGroup:GR;"
- Open a Command Prompt window, and type the following command to
grant the appropriate rights to manage dynamic distribution groups
within the OU.
Copy Code dsacls "OU=OUContainer1,DC=Contoso,DC=com" /I:S /G "Contoso\OU1AdminGroup:GA;; msExchDynamicDistributionList"
- Open a Command Prompt window, and type the following command to
grant the OU1AdminGroup security group extended right to access the
Recipient Update Service.
Copy Code dsacls "CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:S /G "Contoso\OU1AdminGroup:CA;Access Recipient Update Service;msExchExchangeServer"
- Open a Command Prompt window, and type the following commands
to grant the OU1AdminGroup security group the ability to update the
address lists and e-mail address policies.
Copy Code dsacls "CN=Address Lists Container, CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:T /G "company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter" "company\OU1AdminGroup:WP;msExchRecipientFilterFlags" dsacls "CN=Recipient Policies, CN=ContosoOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com" /I:T /G "company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter" "company\OU1AdminGroup:WP;msExchRecipientFilterFlags"
If this is successful, the command will output the
revised Windows security descriptor and display The
command completed successfully
at the command
prompt.
Configure Split Permissions Script
There is a script located in the \Exchange Server\Scripts directory that can help you to configure your split permissions model.
Using the Exchange Management Shell, you can run the following script:
- ConfigureSplitPerms.ps1 You can use the
ConfigureSplitPerms.ps1 script to configure the necessary
permissions discussed in this topic.
For more information on scripting, see Using the Exchange Management Shell.
For More Information
For more information about split permissions, Exchange-related attributes and user, contact, and group-related tasks, see Split Permissions Model Reference.