Security Advisor

Disappearing Permissions

Joern uncovers an obscure AD behavior while configuring ActiveSync for a user with an iPhone on an Exchange 2010 server.

• By Joern Wettern
• 03/01/2010

When looking at big security issues, it's easy to overlook small details. This column covers one of these small items: the AdminSDHolder object in Active Directory.

I recently rediscovered an obscure AD behavior when I had to configure ActiveSync for a user with an iPhone on an Exchange 2010 server. Exchange complained that the user account in AD didn't have the required inherited permissions the Exchange server needed to create an object representing the iPhone. When I checked, the permissions were in place at the domain level, but when I looked at the user object's security settings I noticed that inheritance had been disabled.

This was strange because the inheritance check box was checked for other user objects. I enabled inheritance, but a few minutes later this setting mysteriously disappeared. Soon enough I realized what was going on. The user in question was a member of the Domain Admins group and permissions inheritance had been disabled because of an obscure AD mechanism that exists to protect privileged user accounts.

Hidden Protection
When Microsoft first designed AD, its developers were concerned domain-wide permissions might jeopardize the security of accounts that require a higher level of protection. For example, if you let helpdesk personnel reset user passwords in your domain, what would prevent them from changing the passwords of administrators so the admins could no longer log onto the domain? In a well-organized AD structure, you can prevent this by delegating permissions only for some Organizational Units (OUs) and moving all privileged accounts into a different OU. But, let's face it, most companies place all users into a single OU, and anyone who can change objects representing regular users can also change objects representing admins.

To prevent this from happening, a process that runs on domain controllers every hour turns off permissions inheritance on all user objects that are members of certain privileged groups and replaces all existing permissions with permissions that are defined in a template. As a result, inadvertent permissions at the domain level that would let a non-privileged user account make changes to a privileged account are reversed in an hour or less. For example, even if you grant domain-wide permissions to change passwords to your help desk personnel, they'll be blocked from resetting an administrator's password as soon as the background process runs the next time.

Permissions Problems
The restrictive permissions are applied to privileged accounts that are based on those set on the AdminSDHolder object, which exists in the System folder in AD. (To see this object, you first need to activate Advanced Features from the View menu in AD Users and Computers.) The AdminSDHolder object essentially acts as a template, and any permission you define on it will be applied to any member of several privileged groups, including Domain Admins and Enterprise Admins. Which groups are affected depends on the Windows version. A full list and a description of the default permissions are available in a blog post by Microsoft MVP John Policelli.

That still leaves the question of how I solved the iPhone problem. The best solution would've been to have the user check his e-mail using a non-privileged account. Unfortunately, I couldn't convince him to do this. However, I found another solution. I temporarily re-enabled inheritance, which allowed the user to establish an ActiveSync connection. At this point, Exchange could write the required data to AD. Everything continued to work flawlessly from then on, even after the automated process reset the account permissions to the AdminSDHolder values. What I learned from this episode was the value of being able to recall small details. The last time I ran into AdminSDHolder was in the old Windows 2000 days, but once I realized what was going on I knew where to look for a solution.