Exchange 2010 RC1 and AdminSDHolder

 

This post discusses Release Candidate software which may or may not reflect the final shipping version.

With the recent release of Exchange 2010 RC1, I threw it into a new sandbox to see what its schema and Forest/Domain Prep steps were like.

A picture is worth a thousand words.

After the PrepareAD steps have finished, AdminSDHolder has several new ACEs added to it.  I’ve highlighted the most inappropriate ACE: Write Property for member, granted to the new Exchange Windows Permissions group.  This makes it possible for an Exchange Organization Administrator to elevate themselves to Enterprise Administrator with two actions (left as a simple exercise to the reader).

AdminSDHolder exists to protect the critical security groups, such as Enterprise Admins, from inadvertent  or accidental tampering by periodically setting the ACEs on those objects to known good values.  Since those values were originally defined by the authors of the AD code, they probably know a thing or two about what values are needed to protect AD.  With the new ACE on AdminSDHolder, AD itself now dutifully ensures that the new Exchange group can manage group membership for the Enterprise Admins group (along with Domain Admins, Account Operators and all other groups that were supposed to be “protected”).

Beyond AdminSDHolder, PrepareAD also throws down identical ACEs on the domain head, including ACEs like Write DACL inherited to all objects.  But from a controls perspective, none are needed beyond the initial Write Property for member.

If your organization has any rules for separation of duties between Exchange Admins and Enterprise Admins, the ACEs introduced by Exchange 2010 RC1 make that very difficult to enforce, if not impossible.