See this KB
Manually initializing the SD propagator thread to evaluate inherited permissions for objects in Active Directory http://support.microsoft.com/kb/251343 steve -------------- Original message -------------- From: "WATSON, BEN" <[EMAIL PROTECTED]> > 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" > To: > 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/
