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/
