Recipient Permission Delegation in Exchange Server 2007

[The_Exchange_Team]

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

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

Permission Model

Unlike previous versions of Exchange, implementing a split permission model will require far fewer access control entries than before thanks to the implementation of property sets (see previous blog post). For an Exchange administrator to manage all mail-related properties, the administrator only needs the following permissions within the domain partition:

• Read and write access to the following property sets:
  • Exchange Personal Information
  • Exchange Information
• Read and 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
• Read Permissions access right
• List Contents access right
• Read All Properties access right

Please note that the above list is for managing recipient 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 are 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	EMC 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
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
Group	Group Information tab	managedBy	Group Owner
Group	Group Information	info	Notes Field

Planning 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 been granted or 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 total 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 cmdlet 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 read and/or write access on the following attributes within the "OUContainer1":

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

The group will also require read and 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
• Read Permissions access right
• List Contents access right
• Read All Properties access right

In addition, the group will also require:

• Access Recipient Update Service extended right on the Exchange 2007 administrative group
• Administer Information Store extended right on the Exchange organization container
• 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 mail-enable/disable mail 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.

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

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

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=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" /I:T /G "company\OU1AdminGroup:CA;Administer Information Store"

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

Exchange Management Shell Procedure

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

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 Descendants -InheritedObjectType msExchDynamicDistributionList

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

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=CompanyOrg,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" -User "company\OU1AdminGroup" -ExtendedRights ms-Exch-Store-Admin -InheritanceType All

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

- Ross Smith IV