Either: http://support.microsoft.com/kb/251343
Or create an LDIF file which performs the same actions. neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WATSON, BEN Sent: 19 December 2006 15:13 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Paul, On a side note, this part of your response caught my eye... "...and then retriggered SDPROP." Is there a way to manually trigger SDPROP? There have been times when I have wanted to do this but didn't know how or if it was possible. Thanks, ~Ben -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Tuesday, December 19, 2006 1:29 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] AdminSDHolder orphans The SDPROP thread technically, doesn't do anythign with inheritance. That is a trait of the security descriptor, which SDPROP sets. So, realistically, SDPROP overwrites the nTSecurityDescriptor attribute and increments adminCount to 1. The step of setting inheritance to off is unnecessary in the bulleted list (sorry, I know that's pedantic). Should this be reversed? Good question. There could be a cleanup task, but in my mind it shouldn't be part of SDPROP. SDPROP spikes the PDCe enough as it is. Perhaps it should be a different process, possibly running less frequently, e.g. once every 24 hours. As it is, this needs to be process driven. For example, on the current design I'm working on, if an administrator in the English sense of the word (as opposed to the techie definition) requires additional administrative access for a particular change they are elevated via a semi-automated workflow process. This process is done via Active Roles. We're currently working on the technical side of how to undo the effects of SDPROP when such an action occurs, e.g. elevated to schema admins. In the past I've occasionally brute forced this and queried for anyone with an adminCount of 1, set that back to 0 and enabled inheritance and then retriggered SDPROP. We've discussed scheduling this periodically but I don't like it. For one, there might be additional ACEs that are not needed. Cleaning those up is more tricky - you need to strip the ACE, inherit and set any default ACEs, as well as any non-inherited bespoke ACEs back. It's an interesting question. One no doubt the DS guys have pondered. The mechanics of a rollback seem more tricky, as does some of the security implications I'm sure. On another note, adminCount is also a quick and dirty way of proving to someone just how many users they have that have more rights than they need. Especially when they're spewing a load of BS re. how they delegate most functions and only have a select few admins. Just some semi-cohesive thoughts from me for y'all anyway. --Paul ----- Original Message ----- From: "Brian Desmond" <[EMAIL PROTECTED]> To: <ActiveDir@mail.activedir.org> Sent: Tuesday, December 19, 2006 2:38 AM Subject: RE: [ActiveDir] AdminSDHolder orphans > Yeah this caused me issues when I was at a large client which had this > proposensity to put everyone and their brother into a group that > triggered this behavior. What I would do is dump everyone with > admincount>0, then set admincount=0 on all of them, wait a bit, and see > who was back to >0 and then fix the deltas. > > Thanks, > Brian Desmond > [EMAIL PROTECTED] > > c - 312.731.3132 > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:ActiveDir- >> [EMAIL PROTECTED] On Behalf Of Tony Murray >> Sent: Monday, December 18, 2006 8:32 PM >> 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/ > 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/ 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/ 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/ PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies. 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/
