Just wanted to get your opinion on something. When an object becomes a member of one of the groups protected by the AdminSDHolder, the next run of the SDProp thread will:
Replace the objects security descriptor with that of the AdminSDHolder; Disable permissions inheritance on the object; Set a new adminCount attribute with a value > 0 on the object. If the object is then removed from the protected group(s), the changes made by the AdminSDHolder are not reversed. In other words, the adminCount value remains the same, as does the security descriptor. Is it just me or does anyone think this behaviour a little strange? What I am finding in many environments is a large number of these AdminSDHolder orphans. These can arise quite easily, e.g. an account is made a temporary member of a privileged group to perform a specific task or someone changes role within the organisation. Of course I realise that in a perfect world these scenarios would be minimised by the use of dual accounts for splitting standard vs. admin functions, but the reality is that it is all too common. The AdminSDHolder orphans can cause problems when troubleshooting delegation issues. For example, I came across this issue recently when setting up permissions for GAL Sync using IIFP. I had to tidy up before the sync would complete without errors. Does anyone run a regular cleanup using the script provided in this article (or similar)? http://support.microsoft.com/kb/817433 Do you think the AdminSDHolder behaviour should be changed to clean-up after itself? Tony ________________________________________________________________ Sent via the WebMail system at mail.activedir.org List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir@mail.activedir.org/
