I seldom get time to write here but when I see the same issue come up multiple times, I try to get something on-line about it.
In this case it is Exchange 2010 and Active Sync phones.
A little background: Exchange 2010 adds a passel of schema and security extensions. I am not going to discuss the schema extensions here but focus on the security additions. The security that is of interest here is all at the domain level – on the domain object. Two new security groups are added for Exchange 2010: ‘Exchange Trusted Subsystem’ and ‘Exchange Windows Permissions’ each with 17 aces (if I count correctly). Additional aces are also added for the ‘Exchange Servers’ group. The important Aces here are:
- Allow create/delete rights for msExchangeActiveSyncDevices child objects to a user object,
- Allow create/delete rights for msExchangeActiveSyncDevice child objects to the above msExchangeActiveSyncDevices object, and
- Read/ write all properties of these new objects.
I am not privy to why Microsoft does things but prior to Exchange 2010 there was no structure to contain ActiveSync device information other than the user account or the mailbox itself. With the msExchangeActiveSyncDevices object acting as a container a user can now have multiple msExchangeActiveSyncDevice objects for multiple Active Sync devices. I.e. a Phone and an iPad. Forward thinking. Very good Microsoft. Oops, I said I wasn’t going to discuss schema extensions.
So why does any of this matter? Here is why. The security that allows Exchange to create, delete, and use these new objects is all inherited from the Domain object. If it does not inherit to a user object, Exchange cannot create the new the objects. The result is simple. Move the user’s mailbox to an Exchange 2010 server and their phone stops syncing.
There can be various reasons the security is not inherited. On one extreme, you could be in a hosted environment running some variant of Microsoft Provisioning Services (MPS). On the other, a network admin that is no longer there was too clever by half and blocked security on OU’s for reasons no one remembers. Whatever the case, you can allow the security to inherit and then block it again if there is good reason. In either case, this represents a relatively straight-forward solution.
Finally to the issue I have seen multiple times already. There is this process that lives in relative obscurity and has been running on DC’s since the NT5 Betas—the Security Descriptor Propagator (SDPROP). It actually does the inheritance of security from parent to child objects in Active Directory. On the PDC role holder it has an additional function — it protects the security on security principles that have elevated rights. ‘Elevated Rights’ is defined as the user being a member of one of a list of built-in groups. These groups are defined as ‘Protected Groups’. Any ‘User’ that is a member of a ‘Protected Group’ has its security overwritten by the security descriptor on the AdminSDHolder object in the ‘System’ container by SDPROP and its ‘adminCount’ attribute set to ‘1’. Since inheritance is blocked on the AdminSDHolder’s security descriptor, inheritance is also blocked on the user object. This happens every time SDPROP runs on the PDC role holder. By default, that is once an hour.
The list of Protected Groups has varied from Windows 2000 RTM till now. The groups in 2008 R2 are:
- Account Operators,
- Administrators,
- Backup Operators,
- Domain Admins,
- Domain Controllers,
- Enterprise Admins,
- Print Operators,
- Read-Only Domain Controllers,
- Replicator,
- Schema Admins, and
- Server Operators.
If a user with a phone is (or has ever been) in any of these groups, directly or transitively through group nesting, even via distribution group, their phone will not work with their mailbox on an Exchange 2010 MBX role server.
The solution is obvious. Give people that need administrative rights, administrative accounts and tie their phone to a normal user account. This is best practice anyway.
If you are determined to not do this, you have several options:
- Remove the users from the groups that are causing the issue. This also requires you clear the ‘adminCount’ attribute in their account since SDPROP will not clear it for you. Then enable inheritance.
- Alter the Security on the AdminSDHolder object security descriptor by adding the new Exchange security to it. Since the aces added in Exchange 2010 are numerous, this can be a bit tedious but it will work if you get it right. Don’t forget to maintain it in the future.
- Change the behavior of SDPROP. Only four groups were protected in Windows 2000 RTM. As the list of Groups has expanded, Microsoft has provided a vehicle to modify the list. This is done by setting the dsHeuristics attribute of the Directory Service object in the configuration container. Using this attribute, you can selectively exclude Account Operators, Print Operators, Server Operators, or Backup Operators from the list of Protected Groups. Realize when you do this you are weakening the security of your forest.
Details of the last option are discussed here:
http://support.microsoft.com/kb/817433
If you want to be proactive before you start moving mailboxes, you can search for all users in you forest that have an ‘adminCount’ of ‘1’. Lots of ways to do this. Here is an Ldifde example:
ldifde -f AdminUsers.txt -d dc=<domain DN> -r “(&(objectcategory=person)(objectclass=user)(admincount=1))” -l samAccountName
Nick