Delegating Control | Secure Messaging with Microsoft Exchange Server 2000

In an ideal world, Exchange administrators would only have to worry about administering Exchange-related work, not doing the boring chore of creating user accounts, tracking down network problems, and so forth. What makes this possible is delegation: the assignment of permission to perform different administrative tasks to separate users or groups. Exchange 2000 was designed to be usable in very large enterprise environments—the kind in which there are separate groups of people responsible for user account management, server management, messaging, and the network plumbing that ties everything together. As a result of this design decision, Exchange supports very flexible delegation in three primary ways: direct delegation, access controls through property sets, and access controls for individual properties.

Direct Delegation

The direct delegation model is simple: you separate administrators into those who should have the ability to manage Active Directory accounts and those who should manage Exchange-related items like mailbox stores and connectors. (Note that I am ignoring the question of who manages the underlying operating system; those functions aren’t pertinent to this discussion.) You then assign the relevant users to two newly created security groups: one for account management and one for Exchange management. Putting the users into groups allows you to collect all of the users with related privileges into one entity and assign permissions to the entity, not the individuals. (In addition, granting permission on an object then adds only a single ACE—for the group—instead of one for each individual administrator’s account).

Delegating Account Management To delegate account management power, you must give the Active Directory administrators access to manage accounts. This can be accomplished by using the Windows 2000 Delegation of Control Wizard to grant them the Create, Delete, and Manage User Accounts permission set (see Figure 7-1). The actual process to do this is quite simple. Begin by launching the Active Directory Users and Computers snap-in and navigating to the container where the user accounts you want managed are stored. The Delegation of Control Wizard allows you to delegate permission for a set of predefined tasks when you run it against an OU; if you use the Users container, you’ll have to manually specify the permissions you want to grant. Next, right-click the container and select the Delegate Control… command. The Delegation of Control Wizard appears; click Next.

click to expand
Figure 7-1: Use the Windows 2000 Delegation of Control Wizard to give your account managers the needed permissions.

In the Users Or Groups page, click Add and use the resulting selection dialog box to add the security group you’ve designated for account administration to the Selected Users And Groups list. Click Next after you’ve added all the relevant groups. At this point, what you see depends on whether you’re delegating to an OU or not. Let’s proceed under the assumption that you’re delegating control over a single OU; this is actually quite common, because OUs are often used to group accounts in regional or branch offices. (If you’re delegating to the Users container, see the sidebar “Delegating Control on the Users Container.”) Here’s how to delegate control:

In the Tasks To Delegate wizard page (see Figure 7-1), make sure that the Create, Delete, And Manage User Accounts check box is selected. Note that you can easily use this page to grant other, wider ranging permissions (including the ability to reset passwords, modify groups, and assign Group Policy) to these same administrators. Click Next once you’ve selected the tasks you want to delegate.
Carefully review the summary wizard page; it tells you what you’ve chosen to delegate and to whom. The reason I emphasize “carefully” is that there is no automatic or easy way to undo delegation; once you delegate access, you’ll have to manually use ADSIEdit to remove ACEs on directory objects, an error-prone and tedious process. Once you’re satisfied with the delegated permissions, click Finish to make them active.

Delegating Control on the Users Container

If you want to give an account management group control over the entire Users container, you can, but it requires more work than doing so on an individual OU because the Delegation of Control Wizard treats delegation in the Users container as a custom task. Once you’ve launched the wizard and selected the group to which you’re delegating, here’s how to proceed:

The Active Directory Object Type page lets you specify which objects in the designated container can be managed by the designated group. There’s a long list of object types, including many Exchange-specific ones. If you accept the default setting of This Folder, Existing Objects In This Folder, And Creation Of New Objects In This Folder, you’ll be granting your administrators complete access to every object in the Users container. It’s better to select the Only The Following Objects In The Folder option, then scroll down the list of object types and make sure that only User Objects is selected.
Use the Permissions page of the wizard (Figure 7-2) to specify what you’re granting access to. The General check box should be selected so that you see sets of properties that can be delegated. (If you select the Property-Specific check box, you’ll see individual properties, which is useful for delegating individual properties, discussed later.) To grant access to user account properties, you have two choices.

Figure 7-2: The Permissions page of the Delegation of Control Wizard is where you specify which individual properties or property sets are being delegated.

The easiest thing to do is to grant the Full Control permission. This enables the delegated group to fully manage accounts. However, it also allows directory administrators to read and set all of the account-specific properties that pertain to Exchange. The more secure solution is to give your directory administrators access only to individual property sets, as described in the next section.

Tip

Why not just put your account managers in the Account Operators group? Members of this group have an explicit allow ACE on every user object, meaning that group members essentially can change any account-related property, including those associated with Exchange. If you wanted to prevent them from doing so, you would have to add explicit deny ACEs to each user object—a time- consuming prospect.

If you want your Active Directory administrators to be able to mail-enable user accounts, they can do so; however, their accounts will need at least Exchange View Only permissions (granted by the Exchange Delegation Wizard) on the Exchange administrative group that contains the server where the mailbox is to be created. Without this permission, the Active Directory administrators cannot create or delete mailboxes. Exchange View Only permission is harmless, so it’s fairly safe to grant it as long as you realize that those who hold it can inspect—but not change—details of your Exchange infrastructure.

Delegating Mailbox Management Once you’ve delegated account management to the correct security groups, you still have some work to do: in essence, you’ve got to repeat the delegation process, this time granting Exchange-specific permissions to the proper groups. Your mailbox managers must have Exchange View Only permission to the administrative groups that contain the servers where their managed mailboxes are homed; in addition, mailbox administrators need some Active Directory permissions that aren’t granted by default.

Begin by assigning the mailbox administrators the correct Exchange permissions using the Exchange Administration Delegation Wizard. From within Exchange System Manager, navigate to the Administrative Groups container and expand it until you can see the administrative group to which you want to delegate access. Right- click the target administrative group and select the Delegate Control command.

Note

If you don’t see any administrative groups, you’ll need to select the Exchange organization object and open its Properties dialog box; there’s a check box there that controls whether administrative and routing groups are visible within Exchange System Manager.

When the wizard launches, do the following:

In the Users Or Groups page, click Add. This opens the Delegate Control dialog box (Figure 7-3).

Figure 7-3: Delegate Exchange permissions by selecting the group you want to delegate to and the role that the group should have.
Click Browse, then select the group you’re delegating access to from the Select Users, Computers, Or Groups dialog box. Click OK to confirm your selection.
Use the Role drop-down list box to select the role you want the delegated group to have. In this case, you’ll want your mailbox managers to have Exchange View Only Administrator; to delegate access over individual administrative groups to local administrators, you’d choose one of the other two roles.
Click OK to close the Delegate Control dialog box, then click Next in the wizard. The wizard summarizes what groups you’ve chosen to delegate to; click Finish to complete the delegation. As with the Windows 2000 Delegation Wizard, there’s no “undelegate” button, so make sure that you’re delegating the correct access to the correct group.

Next, you’ll need to grant your mailbox administrators a limited set of Active Directory permissions, because mailbox settings are just directory attributes. You do so by following the delegation process described earlier in this section, but with a difference: the only Active Directory attributes you want your mailbox administrators to touch are those involving mailboxes. You can just grant them the Read All Properties and Write All Properties permissions on the account container; that’s easy, but it grants power to change attributes (like remote access permissions, the user’s display name, and permissions on the mailbox) that you might not want them to change. If giving access to all properties provides too much access for your needs, you can delegate by property set instead.

Delegating by Property Set

Windows 2000 and Exchange together provide hundreds of properties for each individual user object. It is certainly possible to set ACEs on each individual property of each account. For example, you might set an ACE of Domain Admins:Full Control on the display name property of all accounts in a container. You could likewise set a deny ACE on properties you don’t want particular groups or accounts to be able to change. The problem with this approach is that each ACE takes space. The more ACEs an ACL contains, the more space it requires to store, and the longer it takes Windows to replicate it or parse it when making an access control decision. Minimizing the number of ACEs on each object is a standard practice for Windows administrators.

To make this easier, Active Directory groups related properties into property sets. These sets are the equivalent of the composite permissions (like Full Control or No Access) that you’re probably used to seeing on NTFS objects. By delegating access to a property set, you can allow a security principal to manage a limited set of properties without the hassle of setting individual ACEs on all of the managed objects. The property sets are shown on the Permissions page of the wizard (see Figure 7-2). To see this particular page, you’ll have to do the following:

Open the Delegation of Control Wizard from within the Active Directory Users and Computers snap-in and click Next in the Welcome page. Select the group you’re delegating to from the Users Or Groups page, then click Next.
In the Tasks To Delegate page (if shown; you’ll only see this when delegating access on an OU), select the Create A Custom Task To Delegate option, then click Next.
In the Active Directory Object Type page, select the Only The Following Objects In The Folder option, then scroll down the list of object types and ensure that User Objects is selected. Click Next.
In the Permissions page, select the property sets that you want to delegate access to, then click Next.
In the wizard summary page, carefully review your choices before clicking Finish; they cannot be automatically reversed if you later change your mind.

Table 7-2 lists the property sets available to you from the Windows 2000 Delegation of Control Wizard. The Grant to Exchange Mailbox Admins? column has three possible values, two of which are obvious. Items marked as Maybe indicate that you might want to give mailbox administrators rights to these property sets, but there are some included properties in those sets that you might not want them to have control over.

Table 7.2: Property Sets Available for Delegation
Property Set Name	Included Properties	Grant to Exchange Mailbox Admins?
Read And Write General Information	Display name, user comment	Maybe
Read And Write Account Restrictions	Account expiration date, date of last password reset	No
Read And Write Logon Information	Home directory, last logon and logoff times, path to user profile	No
Read And Write Group Membership	List of groups that this account belongs to	No
Read And Write Personal Information	Address, telephone/fax numbers, user S/MIME certificate	Maybe
Read And Write Phone And Mail Options	None	No
Read And Write Web Information	Web URL for this user	No
Read And Write Public Information	Common name, department, e-mail addresses, user principal name, “hide from address book” flag	Yes
Read And Write Remote Access Information	Remote Access Service permissions, callback numbers	No

After allowing access to the property sets, you need to add deny ACLs to disallow access to the Active Directory properties that the delegated administrators should not have access to. This is a straightforward process that requires you to use the Active Directory Users and Computers snap-in. Make sure that Advanced Features are enabled from the View menu of the snap-in. Here’s what to do:

Right-click the container to which you’re delegating access. Select the Properties command. When the Properties dialog box appears, click the Security tab.
Find the ACE for the delegate you just gave permissions to. Click Advanced. When the Access Control Settings dialog box (see Figure 7-4) opens, the first entry should be marked as having Special permissions. Select it, then click View/Edit.

Figure 7-4: Edit the ACE added by the Delegation of Control Wizard to deny access to sensitive properties
When the ACL editor dialog box appears, make sure that the Apply Onto drop-down list is set to User Objects. Select the Deny check box for the Delete, Delete Subtree, Modify Permissions, Modify Owner, All Extended Rights, Create All Child Objects, Delete All Child Objects, Change Password, Receive As, Reset Password, and Send As permissions.
Click OK. The snap-in warns you that deny ACEs take precedence over allow ACEs—precisely the behavior we’re looking for. Click Yes to dismiss the warning.
You’ll now be back to the Security tab. Click Advanced again; this time, when the Access Control Settings dialog box appears, click Add.
In the Select User, Computer Or Group dialog box, select the delegate you’ve been working with. Click OK.
When the Permission Entry dialog box reappears, click its Object tab, which is what you use to set ACEs on individual permissions. Set the Apply Onto drop-down list to User Objects.
Add deny ACEs for the Write Account Restrictions, Write Logon Information, Write Remote Access Information, Write Web Information, Write Logon Name, Write Logon Name (pre-Windows 2000), and Write Logon Workstations permissions. Click OK when you’ve selected the appropriate entries.
When the Access Control Settings dialog box comes back, notice that you now have several new ACEs. Click OK to close the dialog box, then click OK again to close the Properties dialog box.

The final step in this process is to use Exchange System Manager to delegate Exchange View Only access on the Exchange administrative group to your Exchange mailbox managers; they need at least this level of permission to create and remove mailboxes for user accounts.

Granting Access to Individual Properties

Here’s a big surprise: the most flexible approach to delegation is also the most complicated. Managing delegation by controlling access to property sets will suffice for most applications, but if you require ultimate control you can always set ACEs on individual properties in Active Directory. There are approximately 75 properties that have to have ACE entries added, either to deny access to Active Directory administrators or allow it for Exchange administrators (Appendix C of the permissions white paper referenced in the “Additional Reading” section has a complete list). Not all of these properties are exposed through the ACL editor interface, so you’ll have to use the DSACLS command to set them. DSACLS is part of the optional Windows 2000 Support Tools included with Windows 2000 Server and Windows 2000 Advanced Server. By default, DSACLS is located in the \Program Files\Support Tools\ folder. Here’s an example that adds a deny ACL for the homeMDB attribute to an Active Directory user administrator group:

DSACLS "ou=Engineering,dc=hsv,dc=fabrikam,dc=local" /I:S /D  "User Admins@fabrikam":WP;homeMDB;user

In this example, we’re passing four parameters to DSACLS, all of which are case- sensitive (online help for the tool is available by running it with no parameters):

The first parameter is the complete name (enclosed in double quotes) of the OU or container that holds the object on which you’re setting the ACE.
The /I switch lets you control what inheritance is applied. The T modifier applies to the specified object and its children; S applies the change to subobjects only, and the very useful P modifier applies the change to the specified object and its direct descendants.
The /D switch indicates that you want to add a deny ACE. To add an allow ACE, use /G instead. These two switches must be followed by two key pieces of information: the group or user to whom the ACE pertains (in this case, a group named User Admins in the RA domain) and the ACE to apply, expressed in the form mode;attributeName;objectType.

In this case, we want to deny permission to write the property, so WP is the mode we use. There are other modes, including SD (delete), DT (delete an object and its children), and CC (create child object). The attribute we’re ACLing is homeMDB, and we want the ACE to apply to user objects only.

Applying ACEs to individual property sets has two significant drawbacks. First, it’s a tedious process unless you use a script to automate it, in which case you should test your script very thoroughly on a test machine before turning it loose on your Active Directory. Second, adding many ACEs to each of the objects you have to protect can have a significant negative effect on your directory services’ performance. For that reason, I normally steer people away from this method unless there are specific security requirements that cannot be met using one of the other two models.