Exchange Delegation






Exchange Delegation

Exchange delegation is a delicate and complicated topic. It is discussed in this chapter with the scripts so that it is fresh in your mind and so you understand the level of permissions required to do the tasks that are illustrated.

Most of the Exchange permissions are granted through access control lists (ACLs) on objects in Active Directory. These permissions in Active Directory can be delegated in a very granular way. Exchange consolidates the permissions into three main layers of delegation called roles:

  • Exchange View Only Administrator allows you to look at the Exchange System.

  • Exchange Administrator allows you to fully administer Exchange Server computer information.

  • Exchange Full Administrator allows you to fully administer Exchange.

Be aware that none of these Exchange Roles give you access rights on user objects themselves. You can be an Exchange Full Administrator and not be able to mailbox-enable a single user. For that, you need to determine what rights you want the Exchange Administrators to have on user objects and grant them separately.

Unfortunately, it is beyond the scope of this book to dig into all of the various ways to delegate rights to Active Directory objects. We will assume for the remainder of this chapter that any administrator who needs to make changes to a user or group, such as mail-enabling or mailbox-enabling a user, mail-enabling a distribution group, creating a contact, etc. is a member of the Account Operators group with the additional permissions outlined in the next paragraph delegated in Active Directory.

By default, Account Operators have permissions to manage user objects, inetOrgPerson objects, and group objects. They do not have permissions to manage contacts or query-based distribution lists. In order for an Account Operator to be able to fully manage mail-specific contents of Active Directory, you must grant permissions separately to create, delete, and manage contacts (i.e., objects with an objectClass of contact), and query-based distribution groups (i.e., objects with an objectClass of msExchDynamicDistributionList) have to be added separately. For details on Active Directory security and delegation, see Chapter 11.

In this security-aware world we now live in, it would be lax to not discuss delegation best practices. Security best practices dictate a separation of duties for different types of administrators. This is also known as the principle of least privileges. Exchange is definitely large enough to follow this type of model and has a couple of levels where these separations can most logically be made.

The first level involves the Help Desk or Call Center Exchange troubleshooters. These are people who you don't want making changes. You only want them to look at what is in place so they can properly escalate to the next level of support if the issue is truly an Exchange issue. These administrators will just need view-only access to Exchange and Active Directory; this would map to the Exchange View Only Admin Role.

The second level are the Exchange Data Administrators, administrators who are responsible for manipulating which users do and don't get mailboxes, as well as managing contacts and distribution lists. They will need to be able to manipulate users and other mail-enabled objects, but not manipulate the overall Exchange system configuration. This level is often automated and the functionality wrapped into some sort of provisioning system as the requests and responses should be standardized. This level of permission will need Exchange view access and various create/delete/change permissions on the user, contact, and group objects in the forest. This would map to the Exchange View Only Admin Role coupled with the specially delegated Account Operator permissions as specified earlier. The primary tool these administrators use will be the Active Directory Users and Computers (ADUC) snap-in.

This functionality, placed in a custom web-based application with a proper authentication and authorization system, could be pushed to the Help Desk or even out to the business users so that business management can directly manage who can and can't have email access based on rules specified by Exchange Administrators.


Finally, you have Exchange Service Administrators; these are the main Exchange administrators who are actually managing the overall service. They need to be able to manipulate the servers and the system configuration but don't generally need to manipulate the mail objects, such as users , groups, and contacts. This level would map to Exchange Admin or Exchange Full Admin Roles. This level also requires local Administrator rights on the Exchange Servers. There could be times that these administrators will need additional permissions in Active Directory on User objects, most notably if they are moving mailboxes or reconnecting mailboxes. The primary tool these administrators will use will be the Exchange System Manager (ESM) snap-in.

Depending on the size of your company and the security concerns you have, you may have none of these divisions, a subset of these divisions, or possibly even more divisions.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows