The Centralized Mailbox Micro-manager and Control Problem in Federations

I am working with a politically federated customer inside a single domain. So far, they've taken Microsoft's recommendations quite well regarding delegation and centralization, but they are running into a problem that I feel is worth sharing. Email is centralized in this scenario and the database deisgn has been built for optimal performance. However, user management is delegated back out to individual departments and this customer has asked me how they can prevent localized overrides of mailbox size limits.

The easy answer is that they cannot. Exchange 2003 is designed to allow for policy-based control of message stores and that control, by design, can be overridden for individual users (in the Exchange General property tab of the user object). So the problem statement is that they don't want the individual administrators overriding the default settings, as it will impact storage capacity and performance on the servers where these mailboxes reside. 

A possible solution is to change permissions at the attribute level so that delegated administrators cannot make changes to the default settings in the Mailbox Storage Limits property page. However, that creates some issues, as exemplified below:

-->DOMAIN CONTAINER
|----- USER OBJECT 1
|----- USER OBJECT 2
|----- OU A
|----- USER OBJECT 3
|----- OU B
|----- USER OBJECT 4

Assign DENY WRITE To mDBUseDefaults Attribute on All USER OBJECTS at the DOMAIN Level for Restricted Admins
Assign FULL CONTROL to OU A for OU A Administrators
Make OU A Administrators a member of Restricted Admins
Make Administrator X a Member of OU A Administrators

Under this scenario, Administrator X would by denied from changing the mDBUseDefaults attribute on User Object 1, User Object 2, and User Object 4, but would have full control on User Object 3. This is because explicit permissions granting full control on OU A are overriding the inherited permission. Since explicit permissions have not been granted on OU B, the inherited deny permission takes effect. The DENY takes effect at the domain level regardless because it is explicitly granted at that level and would therefore override any ALLOW permissions.

Unfortunately, this is by design. According to our own documentation:

• Inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry.
• Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.

The solution, therefore, is to grant EXPLICIT DENY permissions to the Restricted Admins group at each OU where user objects are contained. Or, permissions must be designed so that when a delegation is done, it must be selectively granted (as opposed to the full control granted in our scenario above). 

When dealing with your own federations, take care to properly design your delegation strategy and identify up front those tasks which will be centrally managed. Where conflicts could potentially exist, document them early on in the process to ensure that you don't get stuck adding more complexity to correct an overly complex design.

UPDATE (8/1/2006): I have constructed a script that might facilitate the creation of these permissions in large federations. The script is designed to nest through the entire OU Structure. If a user is found within the OU, the script will output a DSACLS command that can be piped into a batch file for actually setting the permissions. The script is as follows:

'*** This recursive subroutine counts all the users in a container

Sub CountUsersContacts (ObjOU)

   Users = 0

   For Each FoundObject in ObjOU

       Select Case FoundObject.class

          Case "user"

              Users = Users + 1

          Case "organizationalUnit"

              CountUsersContacts (FoundObject)

       End Select

   Next

If Users > 0 Then

   Wscript.Echo "DSACLS " & chr(34) & ObjOU.distinguishedName & chr(34) & " /D " & chr(34) & "[Domain]\[Group Name]:WP;mDBUseDefaults;user" & chr(34)

End If

End Sub

'*** Set the value below for your top-level domain name

Set TopLevel = GetObject (LDAP://DC=domainName,DC=com)

'*** Call the recursive function, starting at the top level

CountUsersContacts (TopLevel)