Have you noticed that some of your Active Directory user objects’ Access Control List (ACL) seem to be “resetting” on a continuous basis back to default settings? If so, it’s not a bug in Active Directory…it’s probably due to SDProp.
With the release of Active Directory Domain Services in Windows 2000, the
AdminSDHolder object and Security Descriptor Propagator (SDProp) process was introduced. It was first introduced as a hotfix with Windows 2000 but later included in Windows 2003 SP2.
The primary goal was to secure privileged users and groups from having their Access Control List (ACL) modified. In the Active Directory domain, there is an object called
AdminSDHolder which is located in the
System container of the domain.
AdminSDHolder object has a unique ACL, which is used to control the permissions of certain security principals that are members of built-in privileged Active Directory groups, which will be referred to as “protected” groups.
On a scheduled basis, which is every hour by default, a background process runs on the PDC Emulator called SDProp. With the SDProp process, a comparison is made between the ACL on all security principals, which include user, group, and computer objects that belong to “protected” groups against the ACL on the
AdminSDHolder reference object.
If the comparison produces different results, the security descriptor on the object is overwritten by the security descriptor from the
AdminSDHolder object. This hourly process ensures that users and groups that are members of these “protected” groups remain secure.
In addition, inheritance is disabled on these privileged accounts preventing permissions applied at the parent object from being applied to the child objects in these “protected” groups.
The frequency of the
AdminSDHolder process, or SDProp, depends on a registry entry called
AdminSDProtectFrequency found here (value in seconds 60 – 7200):
The value can be adjusted but it’s recommended to leave the default setting of 60 minutes. The maximum value can be 120 minutes. If you want to determine if a security principal is affected by SDProp, you can view the object’s properties using ADSIEdit, or Attribute Editor in ADUC.
One thing to note is that if a security principal falls out of the scope of
AdminSDHolder because it was removed from a protected group, the
adminCount attribute and the inheritance setting are not automatically reset. You will need to reset the
adminCount and re-enable the inheritance setting manually or via script.
Usually you should avoid using administrative accounts for the daily routine to prevent issues that may appear that depend on certain security settings, such as with the Blackberry Enterprise Server application. Remove regular users from being members of these protected groups such as Domain Admins.
However, if necessary, you can change the default permissions on administrative accounts to reflect your organization’s needs. You can do this by modifying the permissions on:
This can be accomplished using
Dsacls.exe is available as part of the Windows Support Tools. For more information, read an article: http://go.microsoft.com/fwlink/?LinkID=44321.
Some additional resources:
Delegated Permissions are not Available and Inheritance is Automatically Disabled
Modify the AdminSDHolder Container