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:
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:
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:
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
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":
The group will also require read and write access to the following property sets:
The group will require access to the following properties:
In addition, the group will also require:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.