Source: http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx

Symptom
Usually you delegate permission in Active Directory via OUs. Those permissions apply (if configured so) to objects like users underneath that OU. However you may experience that they don’t apply to all user-accounts (e.g. a delegated admin is able to change the phonenumber for most users, but not on a few others), or that the permissions are being reset/lost on some accounts. If you look at the permissions of that user-account you’ll find that the accounts security-descriptor is set not to inherit permissions from parent objects. If you set the security-descriptor to inherit permissions again, you’ll see that this will be reset after a while. If you configure permissions directly on the object they will be reset after a while as well.

Reason
Active Directory protects certain accounts not to inherit delegated permission. This behavior applies to direct and nested members of the following security-groups:

Windows 2000 SP3:
Enterprise Admins
Schema Admins
Domain Admins
Administrators

Windows 2000 SP4 or Windows Server 2003 additional:
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers

Additional the accounts Administrator and krbtgt are protected.

Why are those accounts protected?
Delegation via AD permissions is usually used to delegate administrative rights to regular user-accounts, to implement administrative roles like Site-Administrator. Those might be assigned to reset passwords, deactivate accounts or other tasks. The AdminSdHolder-Thread assures that such an administrative roles gains not more permissions or is able to compromise the privileged accounts.

How are those accounts protected?
The AdminSdHolder/Ds Propagator tread modifies all accounts which are direct or nested members of one of those groups and increases the attribut adminCount to a value higher than 0. This thread runs once an hour on the Domaincontroller holding the PDC-Emulator role. The thread further resets the security-descriptor of those accounts with the default permissions for administrative accounts which is defined by the security-descriptor of the object cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This also resets the flag to disable inheritance of parent objects.

But what can I do if I need different permissions?
If you need different permissions on those accounts there are a few approaches you can take:

1. Usually you should avoid using administrative accounts for the daily routine. Use a regular user-account, and just start administrative applications (such as Active Directory-Users and -Computers) with administrative credentials (via RunAs or Context-Menu, Open with…).
   Active Directory enabled applications or Site-Admins would be able to change the regular user-account of the Administrators, which is usually sufficient, but their administrative accounts are protected. This protects the Administrator from administrative errors of delegated administrators, and he’s further protected against virusses/worms when surfing the web/reading e-mail.
2. You could use a domain-admin account for AD-enabled applications: This would be a solution, but should be avoided whenever possible. It’s quite easy to delegate AD-integrated applications only write-permissions to the attributes they need, so use that feature to protect your AD. Many times those applications only need permissions to add/modify/delete objects which are defined by their schema extension, and write-permissions on attributes on existing objects their schema extension also added.
3. If absolutely necessary you are able to change the default permissions on administrative accounts to reflect the need of those applications. You can easily do this by modifying the permissions on cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This can be accomblished using ADSIEdit.msc or DsAcls.exe. DsAcls is a commandline-tool for modifying AD-permissions, which every administrator who delegates rights in AD should know. Be sure to test in advance which attributes of which objects are being modifies by the application.

What else is important to know?

1. AdminSdHolder also applies the permissions to accounts which are nested members through distribution groups. E.g. if User1 is a member of the distribution group Maillist-KnowHow, which is a member of account operators, then User1 is considered as one of the protected accounts (since the distribution group could be converted to a security group).
   Be aware that the command whoami /all does show nested group memberships, but not nested groups through distribution groups.
   Usually you should avoid nesting distribution groups in one of the protected groups.
2. Users, which are removed out of one of the protected groups (or their nested groups) do not inherit permissions from parent objects. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users.
   If you have many accounts which are protected by the AdminSdHolder/DS Propagation-Thread, you might notice that the lsass-process on the Domaincontrller holding the PDC-Emultor raises to 100% once an hour. Therefore you should avoid putting loads of users in the protected groups, and rather use delegated administration whenever possible.
3. Depending on your need you might want to remove Backup Operators, Printer Operators, Server Operators or Account Operators out of the AdminSdHolder protection. You can get a Hotfix at Microsoft PSS which allows to configure that. See the following KB for more informations on that:
   http://support.microsoft.com?id=817433