? My first thought would be YES, it should reverse the changes it made previously...on the other side...why doesn't it already? there is a script...2003 is the second AD version... so I suspect something else might be the reason why it does not do it adminSDHolder sets the list you mention below when it finds a user or group that is a member of some protected group. That is easy to do because it only checks the known protected users, know protected groups and its members. Not that difficult to query. Now remove user X from a protected group or a group that is a member of a protected group. What is left over? Permissions still reflect the config of the adminSDHolder, inheritance is not enabled and adminCount=1. (1) By querying known protected users, know protected groups and its members you know who is protected. By querying for adminCount=1 you get the protected users and the users who once were protected. From that list remove everyone that is protected. Left overs are sec. princ. who are not protected anymore but still have adminCount=1 (assuming nobody sets adminCount=1 just for fun ;-) ). Set adminCount=0, enable inheritance and revert permissions back to schema default. Possible issues here are if some programs/apps have set their own permissions on objects. You do not know what was previously there except for the schema defaulf perms. The same still aplies know when you need to do it manually, so there would not be much difference (2) OR just get everyone with adminCount=1 and check if it is a direct member of a protected group or an indirect member of a protected group (group nesting). If not set adminCount=0, enable inheritance and revert permissions back to schema default. just some euro thoughts ;-) Met vriendelijke groeten / Kind regards, Ing. Jorge de Almeida Pinto Senior Infrastructure Consultant MVP Windows Server - Directory Services LogicaCMG Nederland B.V. (BU RTINC Eindhoven) ( Tel : +31-(0)40-29.57.777 ( Mobile : +31-(0)6-26.26.62.80 * E-mail : <see sender address>
________________________________ From: [EMAIL PROTECTED] on behalf of Tony Murray Sent: Tue 2006-12-19 02:32 To: [EMAIL PROTECTED] Subject: [ActiveDir] AdminSDHolder orphans 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 object�s 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/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
<<winmail.dat>>
