RE: [ActiveDir] AdminSDHolder orphans
I think you make a great point here. Actually I'd prefer something like this in the Eventlog: "Event xxx: AdminSDHolder has detected that the following account does not contain to any administrative groups anymore. Administrative Action is required to set security on this object as intended. Please set the attribute admincount to 0 after justifying the security-settings on this account." You know - the same thing as we get when we didn't backup for a while, when clients log on whos IP doesn't belong to any AD-Subnets, ... one of those maintenance events ;-) Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Montag, 22. Januar 2007 01:00 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Hi Ulf Thanks for the thoughts. I can see there could be issues with trying to revert settings after an object is removed from one of the protected groups. I'm now leaning towards the idea of reporting, rather than taking wholesale action. It would be good to have a canned report that shows all of the objects currently protected by the AdminSDHolder, compared with all those that have an adminCount value of 1 (or higher). An administrator could then make the decision to enable permissions inheritance on a case-by-case basis for objects listed in the second category but not the first. Sounds like a feature Joe should add to one of his many freeware tools. The behaviour would be similar to OldCMP. ;-) Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, 22 January 2007 11:32 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Hi Tony, late response as well - sorry. I guess why this isn't cleaned up is the same thing as in many other issues. If you have an admin which is in certain operators groups, and he's "loosing" those groups, it's likely that he has been delegated in some other ways. So not reversing the settings the account is still protected from malicious delegated admins and someone with higher privileges has to look at this account and take care of it (e.g. looking if it's still in the right OU). On the other hand - and as the others mentioned - this task of cleaning up should not run as often. And you'll either need to store the previous permissions (we don't have an attribute for this right now), or reset to some default permissions (we don't have a container to store them right now), or force the reset of the inheritance and propagate parent permissions down. Also how would we decide to reset the inheritance flag automatically - there might be accounts in the OU which have on purpose the inheritance flag turned off - so is a prior admin supposed to have inheritance turned on or off in those OUs? I don't think the task of resetting the inheritance flag would be complicated, but it's complicated to generalize that it should be reset in any case. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Dienstag, 19. Dezember 2006 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 objects 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
RE: [ActiveDir] AdminSDHolder orphans
Hi Ulf Thanks for the thoughts. I can see there could be issues with trying to revert settings after an object is removed from one of the protected groups. I'm now leaning towards the idea of reporting, rather than taking wholesale action. It would be good to have a canned report that shows all of the objects currently protected by the AdminSDHolder, compared with all those that have an adminCount value of 1 (or higher). An administrator could then make the decision to enable permissions inheritance on a case-by-case basis for objects listed in the second category but not the first. Sounds like a feature Joe should add to one of his many freeware tools. The behaviour would be similar to OldCMP. ;-) Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, 22 January 2007 11:32 a.m. To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Hi Tony, late response as well - sorry. I guess why this isn't cleaned up is the same thing as in many other issues. If you have an admin which is in certain operators groups, and he's "loosing" those groups, it's likely that he has been delegated in some other ways. So not reversing the settings the account is still protected from malicious delegated admins and someone with higher privileges has to look at this account and take care of it (e.g. looking if it's still in the right OU). On the other hand - and as the others mentioned - this task of cleaning up should not run as often. And you'll either need to store the previous permissions (we don't have an attribute for this right now), or reset to some default permissions (we don't have a container to store them right now), or force the reset of the inheritance and propagate parent permissions down. Also how would we decide to reset the inheritance flag automatically - there might be accounts in the OU which have on purpose the inheritance flag turned off - so is a prior admin supposed to have inheritance turned on or off in those OUs? I don't think the task of resetting the inheritance flag would be complicated, but it's complicated to generalize that it should be reset in any case. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Dienstag, 19. Dezember 2006 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 objects 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.activedir.org/ma/default.aspx List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ma/default.aspx
RE: [ActiveDir] AdminSDHolder orphans
Hi Tony, late response as well - sorry. I guess why this isn't cleaned up is the same thing as in many other issues. If you have an admin which is in certain operators groups, and he's "loosing" those groups, it's likely that he has been delegated in some other ways. So not reversing the settings the account is still protected from malicious delegated admins and someone with higher privileges has to look at this account and take care of it (e.g. looking if it's still in the right OU). On the other hand - and as the others mentioned - this task of cleaning up should not run as often. And you'll either need to store the previous permissions (we don't have an attribute for this right now), or reset to some default permissions (we don't have a container to store them right now), or force the reset of the inheritance and propagate parent permissions down. Also how would we decide to reset the inheritance flag automatically - there might be accounts in the OU which have on purpose the inheritance flag turned off - so is a prior admin supposed to have inheritance turned on or off in those OUs? I don't think the task of resetting the inheritance flag would be complicated, but it's complicated to generalize that it should be reset in any case. Gruesse - Sincerely, Ulf B. Simon-Weidner Profile & Publications: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308- B489-F2F1214C811D Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Dienstag, 19. Dezember 2006 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 objects 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.activedir.org/ma/default.aspx
RE: [ActiveDir] AdminSDHolder orphans
OK, I'm embarrassed :-s That was just so lame. I thought the email from Tony was a PM. Oh, well... back to hiding from emails :) Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Akomolafe, Deji Sent: Thu 12/21/2006 6:06 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder orphans Sorry, Tony. I've been away from emails for most of the week. Did you get a useful response to your question? If not, does my 2-part AdminSDHolder blog (http://www.akomolafe.com/JustSaying/tabid/193/EntryID/19/Default.aspx and http://www.akomolafe.com/JustSaying/tabid/193/EntryID/20/Default.aspx) help? No? Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Tony Murray Sent: Mon 12/18/2006 5: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/
RE: [ActiveDir] AdminSDHolder orphans
Sorry, Tony. I've been away from emails for most of the week. Did you get a useful response to your question? If not, does my 2-part AdminSDHolder blog (http://www.akomolafe.com/JustSaying/tabid/193/EntryID/19/Default.aspx and http://www.akomolafe.com/JustSaying/tabid/193/EntryID/20/Default.aspx) help? No? Sincerely, _ (, / | /) /) /) /---| (/_ __ ___// _ // _ ) /|_/(__(_) // (_(_)(/_(_(_/(__(/_ (_/ /) (/ Microsoft MVP - Directory Services www.akomolafe.com - we know IT -5.75, -3.23 Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: Tony Murray Sent: Mon 12/18/2006 5: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/
RE: [ActiveDir] AdminSDHolder orphans
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: 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 wo
RE: [ActiveDir] AdminSDHolder orphans
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 AdminSDHo
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: 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 cam
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: 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.activ
RE: [ActiveDir] AdminSDHolder orphans
? 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 : 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. <>
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/
[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 objects 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/
