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/
