I artikeln står det så här:
Most Active Directory administrators become aware of AdminSDHolder, protected groups and SDPROP through a scenario like this one:
You delegate permissions on an Organizational Unit (OU). You're later informed that the permissions are in place for most—but not all—user accounts in the OU. You determine that the ACL on the affected accounts is different from what you delegated and that inheritance is not enabled, so you enable inheritance to resolve the issue. Initially, this seems to work, but later the issue resurfaces. You again determine that the ACL is different and inheritance has been disabled.
I've seen individuals go through this seeming endless cycle over and over.
This situation actually occurs by design, however. It's caused by AdminSDHolder, protected groups and SDPROP.
The accounts affected by this issue belong to a protected group. As a result, the ACL on these accounts is inherited from the AdminSDHolder object in the domain, and inheritance is disabled by default. That's why the permissions that you delegated aren't applied to the affected user accounts. When you manually enable inheritance on these accounts, the delegated permissions are added to the ACL.
However, when the background process runs on the domain controller that holds the PDC Emulator operations master role—by default, every 60 minutes—the ACL is overwritten to match the ACL on the AdminSDHolder object and inheritance is disabled.
Artikeln är riktigt intressant och ger en riktigt bra förståelse för vad som händer på djupet i ADt...
Många har troligen råkat ut för detta. Om inte annat så är risken stor att man kommer att påverkas nån gång i framtiden. Å varför inte läsa artikeln och sedan bli hjälten som läser det "hopplösa" problemet. :)
