Once I got a request ticket from one of our administrators whom are delegated some permissions in their parts of AD to. The person told me that he didn’t have permissions for some accounts. Well, no problem: I investigated the issue, found that the inheritance on that record was broken and I fixed it – one checkbox and “OK” button – big deal! The next day I received another request… for the same person. The inheritance was broken again! Ok, I’m not a newbie, I even know something about adminCount, adminSDHolder and SDProp. So I went and checked if the account was a member of any of protected groups: no, it wasn’t though it had been before. So I tried several more tricks, like moving the account to another OU and back. No luck. And and that point I received another request, from other administrator with the same problem but an other account. And this other person had been domain admin before too.
Well, at this point I was almost sure, that it is because SDProp overwrites the permissions. Quick check of adminCount attribute showed that I was right: it was set to 1. After I had set it to 0 and restored inheritance to the object everything became normal. And a bit of investigation showed that when an account leaves a protected group, adminCount attribute doesn’t switch to 0. After that a bit more of investigation showed me that it is by design. In more detail read here and here. Next time, I won’t be so lazy and will trust my inner admin