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. The 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. 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 Disabledhttp://support.microsoft.com/kb/817433 Modify the AdminSDHolder Containerhttp://technet.microsoft.com/en-us/library/cc772662(WS.10).aspx

AdminCount  AdminSDHolder  and SDProp - 62AdminCount  AdminSDHolder  and SDProp - 14