ActiveSync and AdminSDHolder

Today I ran across an issue where a user, after having been migrated from one domain to another, was unable to establish an ActiveSync partnership. The exact steps that led to this issue are listed below.

  1. User is in domain A
  2. User has their ActiveSync disabled
  3. User has their ActiveSync devices removed (read leaf objects)
  4. User has their ExchangeActiveSyncDevices container object removed
  5. User is migrated to domain B
  6. User is added to domain B’s domain admins group
  7. User has their ActiveSync enabled
  8. User is unable to establish an ActiveSync partnership

The following assumes you’re up to speed with AdminSDHolder. If not, know that when a user is added to specific elevated groups in AD they’re subject to a process that removes ACL inheritance from their object and changes their ACL to match the ACL on “CN=AdminSDHolder,CN=System,DC=contoso,DC=com”. This process is by design and intended to protect elevated accounts that could accidently be misplaced and inherit loose permissions. In other words, it keeps your help desk from compromising an elevated account if it were to accidently become within the scope of their management. The first reference listed below by John Policelli is a great explanation. 

Where to begin? Let’s start with timing. The AdminSDHolder process runs hourly. As we all know ActiveSync is chatty and within a few minutes of being re-enabled a partnership usually builds. Well, in my case somewhere in-between the time I  added my user to the domain admins group and re-enabled ActiveSync the AdminSDHolder process ran and removed the needed Exchange permissions from the user’s object. What permission are those you ask? While I can’t say for sure I’m almost positive it’s the Exchange Windows Permissions. While duplicating the problem I took note of the ACL before and after the AdminSDHolder process ran and found a difference of 79 Exchange related security groups ACEs. Among those missing were for Exchange Recipient Administrators, Exchange Servers, Exchange Enterprise Servers, and most notably Exchange Windows Permissions. 

So, why does the ACL for AdminSDHolder not include ACEs for all the Exchange groups? This was explained back in 2009 on the Exchange Team Blog. 

However, as a result of the ACEs applied on AdminSDHolder, a malicious administrator could elevate their privileges and thus gain control of the Active Directory forest. In particular, the malicious administrator must grant themselves membership in the Exchange Windows Permissions security group. A malicious administrator could either be a person that simply has local administrative rights to log on to an Exchange 2010 RC server, or be a person that is a member of the Exchange Organization Management role. Once the malicious administrator is a member of the Exchange Windows Permissions security group, the malicious administrator can elevate themselves to domain administrator or enterprise administrator.

To fix the issue I re-enabled ACL inheritance on the user object to pull down the needed Exchange permissions. After that the user was able to build an ActiveSync partnership. Did this technically create a brief security hole? Yes, but the environment I'm working in is locked down and those who could compromise the user's domain admin privileges already have domain admin privileges. I then waited for about an hour and sure enough the AdminSDHolder process ran and hardened the ACL on the user object. 

Does this have to happen every-time a user who's subject to AdminSDHolder wants to build a new ActiveSync partnership? The answer is no. In my testing it appears that once the user's ExchangeActiveSyncDevices container has been created than sufficient permissions are in place for additional ActiveSync leaf objects (i.e. iPhone§ApplF970982098309).


Understanding AdminSDHolder and Protected Groups (John Policelli's Blog)

Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue