Updated: Recipient permission delegation in Exchange Server 2007


NOTE: This article has also been published in the official Exchange 2007 documentation here. We recommend that you check the documentation for the most up-to-date version.


This is an update to an earlier article we posted. The main updated areas are: updated permissions requirements through the document, updated DSACLS commands and the section on creating a custom MMC snapin.


Working with Active Directory directory service permissions related to Microsoft Exchange can be a complex task. This article has been written to aid Exchange architects in their understanding of how they may implement 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.

While the majority of this guide focuses on understanding and configuring a split permissions model, there are several other permission-related topics that may need to be reviewed beforehand:


• Explanation of the schema, domain, and configuration partitions: http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/61080b45-8bce-4c23-b744-ed264d5f0b7d.mspx.

• • Explanation of the administrative roles available in Exchange 2007 and the permissions granted: http://www.microsoft.com/technet/prodtechnol/exchange/E2k7Help/2964c198-e624-46a1-ad3b-2e4f529466e3.mspx.


Permission Model


Unlike previous versions of Exchange, implementing a split permission model will require far less access control entries than before thanks to the implementation of property sets.

For an Exchange administrator to manage all mail-related properties, the administrator only needs 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 msExchDynamicDistributionList objects access right
  • Delete msExchDynamicDistributionList objects access right
  • Full control over msExchDynamicDistributionList objects
  • Generic Read access right (includes Read Permissions, List Contents, List Object, Read All Properties)

In addition, the recipient administrator will also require the following rights within the Exchange organization:



  • The Exchange View Only Administrator role or higher (Note: Certain operations like move mailbox require Exchange Server Administrator role or higher).
  • The ‘Access Recipient Update Service’ extended right on the Exchange 2007 administrative group. This extended right is required because in Exchange 2007 address related information is stamped on the recipient during the provisioning process.
  • Write access to the msExchLastAppliedRecipientFilter and msExchRecipientFilterFlags attributes on the Address Lists Container container within the Exchange organization. These rights are required so that 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 rights are required so that the recipient administrator can execute the Update-EmailAddressPolicy cmdlet.

Please note that the above list is for managing attributes that are specific to Exchange. Attributes that were created outside of Exchange will not be manageable by Exchange administrators unless they are delegated the appropriate permissions.

Address Book Attributes


Exchange utilizes many attributes for storing Exchange related data. In addition, Exchange utilizes other recipient attributes that can be utilized by other directory aware applications. As a result, these attributes were not added to the Exchange specific property sets; these attributes may reside in other property sets created during Active Directory installation or they may not belong to any property set.

The attributes listed below constitute the data that is provided to end users via the Global Address List service. If Exchange administrators require the ability to update these attributes and they are not a member of a domain privileged security group (e.g. Account Operators), then the Active Directory administrator will need to grant read/write access using similar procedures as outlined in the next section.





















































































































































Address Book Related Attributes


Applies to Object


Exchange Management Console Location


Attribute


Description


User, Contact


User/Contact Information tab


givenName


First Name


User, Contact


User/Contact Information tab


initials


Middle Initial


User, Contact


User/Contact Information tab


sn


Last Name


User, Contact


User/Contact Information tab


info


Notes Field


User, Contact


Address and Phone tab


streetAddress


Street Address


User, Contact


Address and Phone tab


l


City


User, Contact


Address and Phone tab


st


State/Province


User, Contact


Address and Phone tab


postalCode


ZIP/Postal Code


User, Contact


Address and Phone tab


countryCode


Country


User, Contact


Address and Phone tab


telephoneNumber


Business Phone


User, Contact


Exchange Management Shell Only


otherTelephoneNumber


Alternate Business Phone


User, Contact


Address and Phone tab


pager


Pager


User, Contact


Address and Phone tab


facsimileTelephoneNumber


Fax


User, Contact


Address and Phone tab


homePhone


Home Phone


User, Contact


Exchange Management Shell Only


otherHomePhone


Alternate Home Phone


User, Contact


Address and Phone tab


mobile


Mobile Phone


User, Contact


Exchange Management Shell Only


otherFacsimileTelephoneNumber


Alternate Fax


Contact


Exchange Management Shell Only


telephoneAssistant


Assistant Phone


Contact


ADSIEdit / LDP


telephoneAssistant


Assistant Phone


User, Contact


Organization tab


title


Title


User, Contact


Organization tab


company


Company


User, Contact


Organization tab


department


Department


User, Contact


Organization tab


physicalDeliveryOfficeName


Office


User, Contact


Organization tab


manager


Manager


User, Contact


Organization tab


directReports


Direct Reports


User, Contact


Exchange Management Shell Only


msExchAssistantName


Assistant Name


Group


Group Information tab


managedBy


Group Owner


Group


Group Information


info


Notes Field


Planning and Implementing a Split Permission 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.


By default, only Exchange Organization Administrators have the ability to manage Exchange recipient data in addition to managing Exchange configuration data. However, in order to manage object creation/modification/deletion within the domain partition, these administrators also require membership in at least the “Account Operators” security group, but this is not granted by default.


This configuration may not fit the needs of all customers, thus many customers must plan a split permissions model accordingly using the steps identified below.


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


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.


In addition, if the Exchange administrator has the appropriate rights within the Active Directory domain partition, the Add-ADPermission task within the Exchange Management Shell can be used to apply the appropriate permissions, in lieu of ADSI Edit or DSACLS.


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 partition may require 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 OU administrators that have a business requirement to manage the Exchange-related data for their recipient population. This example can be used as a sample for application of delegated rights over users, contacts, and groups.


OU Administrators in the universal security group “OU1AdminGroup” require the ability to manage Exchange related data (e.g. e-mail addresses, the display name, etc) for all mail recipients located in (and below) the organizational unit “OUContainer1” in the “company.com” forest that contains the CompanyOrg Exchange organization.


The example shows how to apply rights on the “OUContainer1” by specifying write access on the following attributes within the “OUContainer1”:



• legacyExchangeDN
• displayName
• adminDisplayName
• displayNamePrintable
• publicDelegates
• garbageCollPeriod
• textEncodedORAddress
• showInAddressBook
• proxyAddresses
• mail


The group will also require write access to the following property sets:



• Exchange Personal Information
• Exchange Information


The group will require access to the following properties:



• Create msExchDynamicDistributionList objects access right
• Delete msExchDynamicDistributionList objects access right
• Full Control over msExchDynamicDistributionList objects
• Generic Read access right (includes Read Permissions, List Contents, List Object, Read All Properties)


In addition, the group will also require:



• Access Recipient Update Service extended right on the Exchange 2007 administrative group
• Write access to the msExchLastAppliedRecipientFilter and msExchRecipientFilterFlags attributes on the Address Lists Container container within the Exchange organization
• Write access to the msExchLastAppliedRecipientFilter and msExchRecipientFilterFlags attributes on the Recipient Policies container within the Exchange organization
• Exchange View-Only Administrator role (or higher)


Note: The permissions identified above will not provide the “OU1AdminGroup” group the ability to modify many Address Book related attributes (e.g. last name, etc).


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 “OU1AdminGroup” security group can manage e-mail addresses, display names, , mail-enable recipients, etc for all users, groups, and contacts contained in the “OUContainer1” organizational unit hierarchy in the company.com forest that contains the CompanyOrg Exchange organization.


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.


ADSIEdit Procedure


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 commands (remember to replace the relevant parts like domain name, Exchange organization, accounts):



dsacls “OU=OUContainer1,DC=company,DC=com” /I:T /G
“company\OU1AdminGroup:RPWP;legacyExchangeDN”
“company\OU1AdminGroup:RPWP;displayName”
“company\OU1AdminGroup:RPWP;adminDisplayName”
“company\OU1AdminGroup:RPWP;displayNamePrintable”
“company\OU1AdminGroup:RPWP;publicDelegates”
“company\OU1AdminGroup:RPWP;garbageCollPeriod”
“company\OU1AdminGroup:RPWP;textEncodedORAddress”
“company\OU1AdminGroup:RPWP;showInAddressBook”
“company\OU1AdminGroup:RPWP;proxyAddresses”
“company\OU1AdminGroup:RPWP;mail”
“company\OU1AdminGroup:RPWP;Exchange Personal Information”
“company\OU1AdminGroup:RPWP;Exchange Information”
“company\OU1AdminGroup:CCDC;msExchDynamicDistributionList”
“company\OU1AdminGroup:GR;”


dsacls “OU=OUContainer1,DC=company,DC=com” /I:S /G “company\OU1AdminGroup:GA;; msExchDynamicDistributionList “


dsacls “CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” /I:S /G “company\OU1AdminGroup:CA;Access Recipient Update Service;msExchExchangeServer”


dsacls “CN=Address Lists Container, CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” /I:T /G “company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter ” “company\OU1AdminGroup:WP;msExchRecipientFilterFlags “


dsacls “CN=Recipient Policies, CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” /I:T /G “company\OU1AdminGroup:WP;msExchLastAppliedRecipientFilter ” “company\OU1AdminGroup:WP;msExchRecipientFilterFlags “


3. If successful, the command will output the revised Windows NT security descriptor in the command prompt window and output “The command completed successfully”.


How to Use the Exchange Management Shell to Apply Permissions


The Exchange Management Shell is a command-line interface that allows you to retrieve and configure objects that pertain to Exchange. The Exchange Management Shell includes a task, Add-ADPermission that can be used to apply permissions against objects that are stored within the Active Directory.


This topic serves as an example for using Add-ADPermission task. After application of the example in this topic, the “OU1AdminGroup” security group can mail-enable/disable recipients, manage e-mail addresses, display names, etc, for all users, groups, and contacts contained in the “OUContainer1” organizational unit hierarchy in the company.com forest that contains the CompanyOrg Exchange organization.


EMS Procedure


1. Log on to a system within the forest that has the Exchange Management Tools installed using an account that can perform the actions (for example, Domain Admin).


2. Open the Exchange Management Shell and type the following commands (remember to replace the relevant parts like domain name, Exchange organization, accounts) for each container where you want to grant access:



Add-ADPermission –identity “ou=Container1,dc=company,dc=com” –user “company\OU1AdminGroup” -AccessRights ReadProperty, WriteProperty -Properties Exchange-Information, Exchange-Personal-Information, legacyExchangeDN, displayName, adminDisplayName, displayNamePrintable, publicDelegates, garbageCollPeriod, textEncodedORAddress, showInAddressBook, proxyAddresses, mail


Add-ADPermission -identity “ou=Container1,dc=company,dc=com” -user “company\OU1AdminGroup” -AccessRights GenericRead


Add-ADPermission -identity “ou=Container1,dc=company,dc=com” -user “company\OU1AdminGroup” -AccessRights GenericAll –InheritanceType Descendents -InheritedObjectType msExchDynamicDistributionList


Add-ADPermission -identity “ou=Container1,dc=company,dc=com” -user “company\OU1AdminGroup” -AccessRights CreateChild, DeleteChild -ChildObjectTypes msExchDynamicDistributionList


3. Type the following commands into the Exchange Management Shell (remember to replace the relevant parts like domain name, Exchange organization, accounts)



Add-ADPermission -Identity “CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” -User “company\OU1AdminGroup ” -InheritedObjectType ms-Exch-Exchange-Server -ExtendedRights ms-Exch-Recipient-Update-Access -InheritanceType Descendents


Add-ADPermission –identity “CN=Address Lists Container,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” –user “company\OU1AdminGroup” -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags


Add-ADPermission –identity “CN=Recipient Policies,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com” –user “company\OU1AdminGroup” -AccessRights WriteProperty -Properties msExchLastAppliedRecipientFilter, msExchRecipientFilterFlags


4. If successful, each command will output the access control entries that were added to the object.


Creating a Recipient Configuration Custom Exchange Management Console MMC


Now that you have assigned the appropriate permissions for recipient administrators, you may want to provide them with a custom MMC that does not show the entire Exchange Management Console, but instead just provides them with the Recipient Configuration node.


Procedure


1. Log onto a server that has the Exchange Management Console installed.


2. Click Start, select Run and type in MMC. Click OK.


3. In the MMC applet, click File and select Add/Remove Snap-in



a. Click Add.



Select Exchange Server 2007 and click Add and then click Close.



b. Click OK.


4. Right-click the Recipient Configuration node and select New Window from Here.


5. Close the Console Root window.


6. Maximize the Recipient Configuration window.


7. Select File and select Options.



a. Change the console name from Console1 to Exchange Management Console – Recipient Configuration.



b. Change the console mode from Author Mode to User Mode – Full Access.



c. Enable the checkbox for Do not save changes to this console.



d. Click OK.


8. Select File and choose Save As and save the custom MSC file to the desired location.


9. Distribute the custom MSC file to your recipient administrators.


Ross Smith IV


Comments (5)
  1. Anonymous says:

    NOTE: the updated, newer version ofn this article can be found here.

    Working with Active Directory directory…

  2. Anonymous says:

    Preserving Nickname Cache in Exchange Migrations Apple challenges Microsoft Exchange Google to Replace

  3. Anonymous says:

    If you are looking at decentralized deployment of Exchange with multiple admins you should check out

  4. Kevin says:

    The previous article had the following line under "In addition, the group will also require:"

      "Administer Information Store extended right
      on the Exchange organization container"

    Now that has been removed, which is great. Hopefully this means a recipient administrator doesn’t need that right to change the mailbox rights on someone’s mailbox in ADUC on Exchange 2007.

    However I have a question about Exchange 2003. Is there no way to give someone delegated access over user mailbox rights without giving them "administer Information Store" rights? We want them to be able to change mailbox rights on generic and user mailboxes,
    however not be able to stop and start the stores. Anyway? please … :)

    Kevin

  5. Steven says:

    Hello-

    I’ve successfully executed the 7 EMS Add-ADPermission commands listed under "EMS Procedure" numbers 2 and 3 and am still unable to create mailboxes and new user accounts into the OU configured.  I’m actually unable to even enumerate the Exchange mailbox databases.  Are there any other Exchange or AD groups that the delegate needs to be a member of in order for this to work?  We are looking for the bare-minimum rights to delegate to the admin?  Please let me know asap?  Thank you very much in advance.

    Steven

Comments are closed.