Share via

Planning and Implementing a Split Permissions Model

  • Article

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

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

  • Write access to the following attributes:

    • legacyExchangeDN

    • displayName

    • adminDisplayName

    • displayNamePrintable

    • publicDelegates

    • garbageCollPeriod

    • textEncodedORAddress

    • showInAddressBook

    • proxyAddresses

    • mail

  • 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.

  1. Run the following command to manage Exchange-related attributes on objects within the OU.

    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

  2. Run the following command to provide Generic Read permission for all objects within the OU.

    Add-ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericRead

  3. Run the following commands to grant the appropriate permission to manage dynamic distribution groups within the OU:

    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

    For Exchange 2007 Service Pack 1 (SP1), run the following command:

    ADPermission -Identity "ou=Container1,dc=Contoso,dc=com" -User "Contoso\OU1AdminGroup" -AccessRights GenericAll -ChildObjectTypes msExchDynamicDistributionList

  4. Run the following command to grant the OU1AdminGroup security group extended right to access the Recipient Update Service.

    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

  5. Run the following commands to grant OU1AdminGroup security group the ability to update the address lists and e-mail address policies.

    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.

  1. 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.

  2. Open a Command Prompt window, and type the following commands to manage Exchange-related attributes on objects within the OU.

    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;"

  3. Open a Command Prompt window, and type the following command to grant the appropriate rights to manage dynamic distribution groups within the OU.

    dsacls "OU=OUContainer1,DC=Contoso,DC=com" /I:S /G "Contoso\OU1AdminGroup:GA;; msExchDynamicDistributionList"

  4. Open a Command Prompt window, and type the following command to grant the OU1AdminGroup security group extended right to access the Recipient Update Service.

    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"

  5. 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.

    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.