It is true. For certain accounts in the domain, you will notice that permissions applied to those objects will disappear regardless if the permissions are inherited or even if you directly applied them to the object. I came across this bizarre behavior years ago when Blackberry user’s first noticed that their handhelds weren’t receiving messages that were delivered to their Exchange mailboxes. It was quickly realized that while looking at the user’s account properties, that several key permissions were missing from some of the accounts in Active Directory. The solution was easy, just apply the permissions.
However, after about an hour, the issue re-appeared. When the account was checked once again, the permissions were gone. The permissions were fine for about 99% of the other accounts in the domain. This was very strange because the inheritance check box was enabled so why weren’t the permissions remaining inherited? Soon after, it was realized that the all of the user’s that were affected, were members of important Active Directory groups such as Domain Admins.
Reaching out to Microsoft and continuing our troubleshooting provided insight into what was occurring. This was a proactive security measure to ensure that key accounts in the domain could not be jeopardized by accounts with a lower level of security access. For example, without this protection, it is possible that through a domain wide delegated permission of resetting passwords, that a Help Desk technician would be able to change the account password for a domain administrator.
Therefore to prevent such an occurrence, a process that runs on domain controllers every hour turns off permissions inheritance on user objects that are members of certain privileged groups and replaces all existing permissions with permissions defined in a template. Therefore any permission inherited or directly added would be removed within the hour.
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 Active Directory. This is the object that acts as a template for permissions that will be applied to those special groups such as Enterprise Admins and Domain Admins. The groups affected depend on the version of Windows OS you are running for your DCs.
Microsoft has a great article that covers this topic in detail: http://support.microsoft.com/Default.aspx?id=817433
You can modify how often the AdminSDHolder background process runs. If the default frequency of 60 minutes for the background AdminSDHolder process to run isn’t sufficient, you can change it by creating or modifying the AdminSDProtectFrequency entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey.
If this key doesn’t exist, the default frequency (60 minutes) is used.
You can configure the frequency to anywhere between one minute and two hours. You must enter the number of seconds when creating or modifying the registry entry. The following command will configure SDPROP to run every 10 minutes (600 seconds):
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600
You should be aware that modifying this subkey may not be in your best interest as doing so can increase LSA (Local Security Authority) processing overhead.
In conclusion, it is evident that the AdminSDHolder is an important security feature in Active Directory. The AdminSDHolder, together with the Security Descriptor Propagator, help secure user accounts that contain elevated
Active Directory permissions. Hopefully this information has shed some light on this mysterious process.
Recommended Books & Training Resources