Recipe17.7.Delegating Exchange for the First Time


Recipe 17.7. Delegating Exchange for the First Time

Problem

You want to delegate permissions to manage Exchange. This recipe allows you to configure the basic delegation of the three Exchange roles to users or groups.

Solution

Using a graphical user interface

  1. Log on to a machine with an account that is in the initially delegated Exchange Group from Recipe 17.2.

  2. Per your corporate standards, create three groups called ExchangeViewAdmins, ExchangeAdmins, and ExchangeFullAdmins. The groups can be any scope. See Chapter 7 in Active Directory Cookbook (O'Reilly) for assistance on creating groups and the ramifications of the different group scopes.

  3. Open the Exchange System Manager (ESM) snap-in.

  4. In the left pane, right-click on the Organization name (e.g., RALLENCORPMAIL) and select Delegate Control.

  5. On the Welcome screen, click Next.

  6. On the Users and Groups screen, click Add.

  7. On the Delegate Control screen, click Browse.

  8. On the Select Users, Computers, Or Groups screen, type into the text box the name of the group to which you want to delegate Exchange View Admin rights (e.g., RALLENCORP\ExchangeViewAdmins).

  9. Back on the Delegate Control screen, verify that Exchange View Only Administrator is listed in the role drop-down menu and click OK.

  10. Repeat steps 6-9 for ExchangeAdmins and ExchangeFullAdmins, selecting the appropriate permissions in the role drop-down menu.

  11. If you used a group in the root delegation in Recipe 17.2, you may still see one or more accounts listed in the Users and Groups box. Remove these from the list by selecting them and clicking Remove.

  12. Review the list of Users and Groups and click Next. You should have the following groups and roles listed:

    • ExchangeAdmins with role Exchange Administrator

    • ExchangeFullAdmins with role Exchange Full Administrator

    • ExchangeViewAdmins with role Exchange View Only Administrator

  13. On the Completed Wizard screen, click Finish.

  14. Add the accounts of the administrators to the various groups with your favorite group management tool.

Discussion

Exchange delegation is a delicate and complicated topic. 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 Admins to have on user objects and grant them separately.

Unfortunately, it is beyond the scope of this chapter to dig into all of the various ways to delegate rights to Active Directory objects. I'll 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, permissions 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 14 of Active Directory Cookbook (O'Reilly).

In this security-aware world we now live in, I would be lax if I didn't talk about delegation best practices. Security best practices dictate for 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 admins will need only 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 and 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 standard. 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 as specified earlier. The primary tool these admins use will be the 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. Microsoft also helps in the automation of this level by distributing a tool in the Exchange Resource Kit for automatically handling distribution lists called AutoDL. This tool has the concept of Distribution List subscriptions and managed Distribution Lists and has a web front-end for ease of use by nontechnical users.


Finally, you have Exchange Service Administrators; these are the main Exchange administrators who actually manage 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 or Exchange Full Admin Roles. This level also requires local Administrator rights on the Exchange Servers. There could be times that these Admins will need additional permissions in Active Directory on User objects, most notably if they are moving mailboxes, as discussed in Recipe 17.16, or reconnecting mailboxes, as discussed in Recipe 17.14. The primary tool these administrators will use will be the 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.

See Also

MS KB 823018 (Overview of Exchange Administrative Role Permissions in Exchange 2003), MS KB 316792 (Minimum permissions necessary to perform Exchange-related tasks), Chapters 7 and 14 of Active Directory Cookbook (O'Reilly), Active Directory Delegation Whitepaper and Appendix (www.microsoft.com/downloads), and http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3ad.mspx



Windows Server Cookbook
Windows Server Cookbook for Windows Server 2003 and Windows 2000
ISBN: 0596006330
EAN: 2147483647
Year: 2006
Pages: 380
Authors: Robbie Allen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net