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
Jorge, thanks for the mail back i am duly noted on the re-enabling of the inheritance if i may develop this thread a little further .. is there any specific logging of the activity of the adminsdholder process or do we have to fall back to the directory auditing ?? presumably as i understand, there would be a number of elements to this; i. enumeration of objects that are members of protected groups (is this constrained to user objects ??) ii. change of admincount attribute iii. change of inheritance iv. reset of permissions on objects G > either explicit or inherited permissions will be replaced by the > permissions > defined on the adminsdholder object > > so if re-applying inheritance is not enough... you would need to define > explicit > defined permissions... > > for the default perms you can use the DEFAULT button and all custom added > permissions would need to be defined again > > 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 Graham Turner > Sent: Tue 2007-01-16 17:37 > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] adminsdholder > > > > Jorge, thanks for your reply post > > i certainly favour the former option on account of the other being a > forest-wide > configuration. > > on this basis if we have removed the user from protected groups then doesn't > setting > do the job ? > > the permission we are 'losing' is not one that is set at parent OU level and > set > explicitly on the object so inheritance of the permission is not > > OR is there something else that needs to be re-enabled by changing the > inhertiance > on the user object ?? > > GT > > > 1. removed user from all protected groups > > >> setting the attribute to 0 only will not help >> >> to stop the adminsdholder from managing a certain group/user you either: >> * remove it from a protected group, check inheritance and reset admincount >> to > set> >> * configure dsheuristics (forest-wide config) as mentioned in >> http://support.microsoft.com/?id=817433 for some default protected groups >> (not >> recommended as you should not use the default admin groups, but instead >> delegate >> stuff) >> >> also see: >> http://blogs.dirteam.com/blogs/jorge/archive/2006/05/16/981.aspx >> >> 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 Graham Turner >> Sent: Tue 2007-01-16 15:37 >> To: activedir@mail.activedir.org >> Subject: [ActiveDir] adminsdholder >> >> >> >> Dear all, i think we experieincing issues re not being able to reset >> permissions >> on >> an object that was previously member of protected groups >> >> i have read that the issue is around the reset of the value of 'admincount' >> attribute. >> >> as i learn this gets set to 1 when it is becomes a member of protected >> groups, but >> ju >> >> i wanted to confirm that is a 'supported' operation to merely reset this >> data to 0 >> to undo the effect of adminssdholder ?? >> >> or whether there are other changes that need to be considered. ? >> >> G >> >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> 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. >> >> > > > 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
either explicit or inherited permissions will be replaced by the permissions defined on the adminsdholder object so if re-applying inheritance is not enough... you would need to define explicit defined permissions... for the default perms you can use the DEFAULT button and all custom added permissions would need to be defined again 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 Graham Turner Sent: Tue 2007-01-16 17:37 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] adminsdholder Jorge, thanks for your reply post i certainly favour the former option on account of the other being a forest-wide configuration. on this basis if we have removed the user from protected groups then doesn't setting do the job ? the permission we are 'losing' is not one that is set at parent OU level and set explicitly on the object so inheritance of the permission is not OR is there something else that needs to be re-enabled by changing the inhertiance on the user object ?? GT 1. removed user from all protected groups > setting the attribute to 0 only will not help > > to stop the adminsdholder from managing a certain group/user you either: > * remove it from a protected group, check inheritance and reset admincount to > set> > * configure dsheuristics (forest-wide config) as mentioned in > http://support.microsoft.com/?id=817433 for some default protected groups (not > recommended as you should not use the default admin groups, but instead > delegate > stuff) > > also see: > http://blogs.dirteam.com/blogs/jorge/archive/2006/05/16/981.aspx > > 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 Graham Turner > Sent: Tue 2007-01-16 15:37 > To: activedir@mail.activedir.org > Subject: [ActiveDir] adminsdholder > > > > Dear all, i think we experieincing issues re not being able to reset > permissions on > an object that was previously member of protected groups > > i have read that the issue is around the reset of the value of 'admincount' > attribute. > > as i learn this gets set to 1 when it is becomes a member of protected > groups, but > ju > > i wanted to confirm that is a 'supported' operation to merely reset this data > to 0 > to undo the effect of adminssdholder ?? > > or whether there are other changes that need to be considered. ? > > G > > > > > > > > > > > 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 > > > > > 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. > > 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
Jorge, thanks for your reply post i certainly favour the former option on account of the other being a forest-wide configuration. on this basis if we have removed the user from protected groups then doesn't setting do the job ? the permission we are 'losing' is not one that is set at parent OU level and set explicitly on the object so inheritance of the permission is not OR is there something else that needs to be re-enabled by changing the inhertiance on the user object ?? GT 1. removed user from all protected groups > setting the attribute to 0 only will not help > > to stop the adminsdholder from managing a certain group/user you either: > * remove it from a protected group, check inheritance and reset admincount to > set> > * configure dsheuristics (forest-wide config) as mentioned in > http://support.microsoft.com/?id=817433 for some default protected groups (not > recommended as you should not use the default admin groups, but instead > delegate > stuff) > > also see: > http://blogs.dirteam.com/blogs/jorge/archive/2006/05/16/981.aspx > > 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 Graham Turner > Sent: Tue 2007-01-16 15:37 > To: activedir@mail.activedir.org > Subject: [ActiveDir] adminsdholder > > > > Dear all, i think we experieincing issues re not being able to reset > permissions on > an object that was previously member of protected groups > > i have read that the issue is around the reset of the value of 'admincount' > attribute. > > as i learn this gets set to 1 when it is becomes a member of protected > groups, but > ju > > i wanted to confirm that is a 'supported' operation to merely reset this data > to 0 > to undo the effect of adminssdholder ?? > > or whether there are other changes that need to be considered. ? > > G > > > > > > > > > > > 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 > > > > > 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. > > 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
You'll also need to re-enable inheritance on the affected account. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Tuesday, January 16, 2007 6:37 AM To: activedir@mail.activedir.org Subject: [ActiveDir] adminsdholder Dear all, i think we experieincing issues re not being able to reset permissions on an object that was previously member of protected groups i have read that the issue is around the reset of the value of 'admincount' attribute. as i learn this gets set to 1 when it is becomes a member of protected groups, but ju i wanted to confirm that is a 'supported' operation to merely reset this data to 0 to undo the effect of adminssdholder ?? or whether there are other changes that need to be considered. ? G 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
setting the attribute to 0 only will not help to stop the adminsdholder from managing a certain group/user you either: * remove it from a protected group, check inheritance and reset admincount to * configure dsheuristics (forest-wide config) as mentioned in http://support.microsoft.com/?id=817433 for some default protected groups (not recommended as you should not use the default admin groups, but instead delegate stuff) also see: http://blogs.dirteam.com/blogs/jorge/archive/2006/05/16/981.aspx 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 Graham Turner Sent: Tue 2007-01-16 15:37 To: activedir@mail.activedir.org Subject: [ActiveDir] adminsdholder Dear all, i think we experieincing issues re not being able to reset permissions on an object that was previously member of protected groups i have read that the issue is around the reset of the value of 'admincount' attribute. as i learn this gets set to 1 when it is becomes a member of protected groups, but ju i wanted to confirm that is a 'supported' operation to merely reset this data to 0 to undo the effect of adminssdholder ?? or whether there are other changes that need to be considered. ? G 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 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
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/
RE: [ActiveDir] AdminSDHolder
OK thanks, I have made a note. I will bring it up when I am
with someone who could make a difference with it. I have also made a note in the
folder that has suggestions for future joeware and/or Deviant Software
tools/solutions.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Tuesday, March 21, 2006 3:16
AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
Neal: Would you like to alter the list because you
would like to add your own custom groups/users to get controlled like that or do
you just want to just change what is protected at
all?
joe: the
former
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
joeSent: 20 March 2006 21:27To:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
But that is
perl -e "print \"very
\"x1000,\"\n\""
dangerous.
If you happen to drop one of these objects in an OU that
has some inherited permissions defined such as user:FC to some folks
with lesser powers then it is all over.
But yes, it is a Security Descriptor level mod which
includes the ACLs (both DACL and SACL), inheritence setting (aka
protected), owner, primary group, etc.
Neal: Would you like to alter the list because you would
like to add your own custom groups/users to get controlled like that or do you
just want to just change what is protected at all?
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-WeidnerSent: Monday, March 20, 2006 3:32 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
Hi Neil,
as mentioned in my blog entry you are able to change if it
applies to the operator-groups (and which).
The whole nTSecurityDescriptor is copied, since there is
inheritance disabled on the adminSdHolder-Object inheritance is disabled by
default on those protected objects as well. If you enable inheritance on the
adminSdHolder the objects will inherit permissions.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die Expertentipps":
http://tinyurl.com/44zcz Weblog:
http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Monday, March 20, 2006 11:01
AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I
never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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
se
RE: [ActiveDir] AdminSDHolder
Neal: Would you like to alter the list because you
would like to add your own custom groups/users to get controlled like that or do
you just want to just change what is protected at
all?
joe: the
former
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
joeSent: 20 March 2006 21:27To:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
But that is
perl -e "print \"very
\"x1000,\"\n\""
dangerous.
If you happen to drop one of these objects in an OU that
has some inherited permissions defined such as user:FC to some folks
with lesser powers then it is all over.
But yes, it is a Security Descriptor level mod which
includes the ACLs (both DACL and SACL), inheritence setting (aka
protected), owner, primary group, etc.
Neal: Would you like to alter the list because you would
like to add your own custom groups/users to get controlled like that or do you
just want to just change what is protected at all?
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-WeidnerSent: Monday, March 20, 2006 3:32 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
Hi Neil,
as mentioned in my blog entry you are able to change if it
applies to the operator-groups (and which).
The whole nTSecurityDescriptor is copied, since there is
inheritance disabled on the adminSdHolder-Object inheritance is disabled by
default on those protected objects as well. If you enable inheritance on the
adminSdHolder the objects will inherit permissions.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die Expertentipps":
http://tinyurl.com/44zcz Weblog:
http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Monday, March 20, 2006 11:01
AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I
never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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.
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 t
RE: [ActiveDir] AdminSDHolder
Yes - sorry - didn't want to suggest doing that - just
wanted to outline how it works.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
joeSent: Monday, March 20, 2006 10:27 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
But that is
perl -e "print \"very
\"x1000,\"\n\""
dangerous.
If you happen to drop one of these objects in an OU that
has some inherited permissions defined such as user:FC to some folks
with lesser powers then it is all over.
But yes, it is a Security Descriptor level mod which
includes the ACLs (both DACL and SACL), inheritence setting (aka
protected), owner, primary group, etc.
Neal: Would you like to alter the list because you would
like to add your own custom groups/users to get controlled like that or do you
just want to just change what is protected at all?
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-WeidnerSent: Monday, March 20, 2006 3:32 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
Hi Neil,
as mentioned in my blog entry you are able to change if
it applies to the operator-groups (and which).
The whole nTSecurityDescriptor is copied, since there is
inheritance disabled on the adminSdHolder-Object inheritance is disabled by
default on those protected objects as well. If you enable inheritance on the
adminSdHolder the objects will inherit permissions.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die
Expertentipps": http://tinyurl.com/44zcz Weblog:
http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Monday, March 20, 2006 11:01
AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and
(by default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup
Operators are protected by the PDCE checking the ACL on the AdminSDHolder
object, I never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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.
RE: [ActiveDir] AdminSDHolder
But that is
perl -e "print \"very
\"x1000,\"\n\""
dangerous.
If you happen to drop one of these objects in an OU that
has some inherited permissions defined such as user:FC to some folks
with lesser powers then it is all over.
But yes, it is a Security Descriptor level mod which
includes the ACLs (both DACL and SACL), inheritence setting (aka
protected), owner, primary group, etc.
Neal: Would you like to alter the list because you would
like to add your own custom groups/users to get controlled like that or do you
just want to just change what is protected at all?
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B.
Simon-WeidnerSent: Monday, March 20, 2006 3:32 PMTo:
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir]
AdminSDHolder
Hi Neil,
as mentioned in my blog entry you are able to change if it
applies to the operator-groups (and which).
The whole nTSecurityDescriptor is copied, since there is
inheritance disabled on the adminSdHolder-Object inheritance is disabled by
default on those protected objects as well. If you enable inheritance on the
adminSdHolder the objects will inherit permissions.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die Expertentipps":
http://tinyurl.com/44zcz Weblog:
http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Monday, March 20, 2006 11:01
AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I
never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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.
RE: [ActiveDir] AdminSDHolder
Hi Neil,
as mentioned in my blog entry you are able to change if it
applies to the operator-groups (and which).
The whole nTSecurityDescriptor is copied, since there is
inheritance disabled on the adminSdHolder-Object inheritance is disabled by
default on those protected objects as well. If you enable inheritance on the
adminSdHolder the objects will inherit permissions.
Gruesse - Sincerely,
Ulf B. Simon-Weidner
MVP-Book "Windows XP - Die Expertentipps":
http://tinyurl.com/44zcz Weblog:
http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile="">
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]Sent: Monday, March 20, 2006 11:01
AMTo: ActiveDir@mail.activedir.orgSubject: RE:
[ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I
never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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.
Re: [ActiveDir] AdminSDHolder
You can remove ( but not add )
You can remove any of the following:
Account Operators
Server Operators
Print Operators
Backup Operators
See
http://support.microsoft.com/kb/817433
steve
- Original Message -
From:
[EMAIL PROTECTED]
To: ActiveDir@mail.activedir.org
Sent: Monday, March 20, 2006 2:00
AM
Subject: RE: [ActiveDir]
AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I
never see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present
for those groups?
Thanks and sorry again if this seems really stupid or basic.
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.
RE: [ActiveDir] AdminSDHolder
A few minor additions to other posts in this
thread:
The list of objects protected by SDPROP is hard coded
AFAIK. The SD applied to adminsdholder is then copied to those objects and (by
default), all other ACEs are removed and inheritance is disabled
too.
We discussed changing the list of objects protected in
previous threads and concluded that this was not possible. I, for one, would
like the flexibility to alter the list.
neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom
KernSent: 17 March 2006 20:24To:
activedirectorySubject: [ActiveDir]
AdminSDHolder
This may sound like a stupid question, but here goes-
When MS says that Print Operators, Account Operators,or Backup Operators
are protected by the PDCE checking the ACL on the AdminSDHolder object, I never
see those groups in the ACE.
Where are they listed?
How are they protected?
What ACL is the PDCE checking to determine what perms should be present for
those groups?
Thanks and sorry again if this seems really stupid or
basic.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.
RE: [ActiveDir] AdminSDHolder
The SD of the adminSDHolder object is the nTSecurityDescriptor attribute of that object. It is in the System container of the domain in question. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Friday, March 17, 2006 7:26 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] AdminSDHolder when you say " if the SD of one of those objects is not the same as what is on the adminSDHolder object...", where on the adminSDHolder object are these values kept that help it determine the SD? Thanks On 3/17/06, joe <[EMAIL PROTECTED]> wrote: The SDPROP thread monitors groups/users that are considered "sensitive" and if the SD of one of those objects is not the same as what is on the adminSDHolder object, that SD is applied to the object. They are not specified in the ACL on the adminSDHolder object because they shouldn't have permissions over those sensitive objects. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Friday, March 17, 2006 3:24 PMTo: activedirectorySubject: [ActiveDir] AdminSDHolder This may sound like a stupid question, but here goes- When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see those groups in the ACE. Where are they listed? How are they protected? What ACL is the PDCE checking to determine what perms should be present for those groups? Thanks and sorry again if this seems really stupid or basic.
RE: [ActiveDir] AdminSDHolder
The securityDescriptor of the adminSdHolder is copied to be the same as the securityDescriptor of the Object in Question. Just look at the Security-Tab of both, they are the same. If you change to one of a protected Object (adminCount <>0) it will be reset to be the same within one hour. AdminSdHolder is a object which has IMHO no specific use, just to hold a securityDescriptor to use as template. Gruesse - Sincerely, Ulf B. Simon-Weidner MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile=""> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, March 18, 2006 1:26 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] AdminSDHolder when you say " if the SD of one of those objects is not the same as what is on the adminSDHolder object...", where on the adminSDHolder object are these values kept that help it determine the SD? Thanks On 3/17/06, joe <[EMAIL PROTECTED]> wrote: The SDPROP thread monitors groups/users that are considered "sensitive" and if the SD of one of those objects is not the same as what is on the adminSDHolder object, that SD is applied to the object. They are not specified in the ACL on the adminSDHolder object because they shouldn't have permissions over those sensitive objects. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Friday, March 17, 2006 3:24 PMTo: activedirectorySubject: [ActiveDir] AdminSDHolder This may sound like a stupid question, but here goes- When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see those groups in the ACE. Where are they listed? How are they protected? What ACL is the PDCE checking to determine what perms should be present for those groups? Thanks and sorry again if this seems really stupid or basic.
Re: [ActiveDir] AdminSDHolder
when you say " if the SD of one of those objects is not the same as what is on the adminSDHolder object...", where on the adminSDHolder object are these values kept that help it determine the SD? Thanks On 3/17/06, joe <[EMAIL PROTECTED]> wrote: The SDPROP thread monitors groups/users that are considered "sensitive" and if the SD of one of those objects is not the same as what is on the adminSDHolder object, that SD is applied to the object. They are not specified in the ACL on the adminSDHolder object because they shouldn't have permissions over those sensitive objects. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Friday, March 17, 2006 3:24 PMTo: activedirectorySubject: [ActiveDir] AdminSDHolder This may sound like a stupid question, but here goes- When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see those groups in the ACE. Where are they listed? How are they protected? What ACL is the PDCE checking to determine what perms should be present for those groups? Thanks and sorry again if this seems really stupid or basic.
RE: [ActiveDir] AdminSDHolder
The SDPROP thread monitors groups/users that are considered "sensitive" and if the SD of one of those objects is not the same as what is on the adminSDHolder object, that SD is applied to the object. They are not specified in the ACL on the adminSDHolder object because they shouldn't have permissions over those sensitive objects. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Friday, March 17, 2006 3:24 PMTo: activedirectorySubject: [ActiveDir] AdminSDHolder This may sound like a stupid question, but here goes- When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see those groups in the ACE. Where are they listed? How are they protected? What ACL is the PDCE checking to determine what perms should be present for those groups? Thanks and sorry again if this seems really stupid or basic.
RE: [ActiveDir] AdminSDHolder
Hi Tom, I do not fully understand what you mean. > When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see > those groups in the ACE. Wrong - MS does not say that the Operators are protected by the PDCE checking any ACL. The PDCE runs the process which ensures that the adminCount Attribut of members of those groups (+ others and accounts you havent mentioned) is <>0, then it resets the Security-Descriptor to be the same as the AdminSdHolder-Process. You've never seen ACEs for AOs? Did you check a user, group, computer, inetorgperson or OU? Account Operators have the right to create child/delete child on OUs for Users, Groups, Computers, INetOrgPersons, and they also have Full Control on those Objects. > Where are they listed? Security Tab > How are they protected? See above > What ACL is the PDCE checking to determine what perms should be present for those groups?No ACL, it's checking the groups, and resets the rights of their members. The adminCount Attribute is helper. In the thread before my blog about this was mentioned, I think it clarifies some stuff: http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx Gruesse - Sincerely, Ulf B. Simon-Weidner MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile=""> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Friday, March 17, 2006 9:24 PMTo: activedirectorySubject: [ActiveDir] AdminSDHolder This may sound like a stupid question, but here goes- When MS says that Print Operators, Account Operators,or Backup Operators are protected by the PDCE checking the ACL on the AdminSDHolder object, I never see those groups in the ACE. Where are they listed? How are they protected? What ACL is the PDCE checking to determine what perms should be present for those groups? Thanks and sorry again if this seems really stupid or basic.
RE: [ActiveDir] Adminsdholder Propertiy Qustion...
so I put a little trap on the machine. It was configured to not directly allow local logon for anyone. I didn't do it in the regular way, I dorked with the default profile so that when a user who had permissions to log on, logged on, a script in the profile would log the user back off[3]. This was immensely successful and I had a log of everyone that tried to log in... The profile directory. My thought was any admin not "knowledgeable" enough to understand how that was done, wasn't "knowledgeable" enough to be messing with that system. I played a hunch that if they weren't "knowledgeable" enough to understand, they wouldn't be "knowledgeable" enough to manipulate it in bad ways remotely. All and all, it was a roaring success, that system went and went for a lng time with no issue. I had spoken with one admin whom I knew to be knowledgable and had discussed with him how it had been done (basically I said if it did this and this, what would you look at it and he nailed it in about 45 seconds). That way I wasn't the only one who knew and I knew this admin wasn't into casually changing things, a great admin, naturally constructively lazy. When I eventually left to go to another division I was one day called and a new admin was saying he needed to log on and change some stuff but couldn't figure out how to log on. I didn't give out the info. Then the manager called and I told him who knew how to get on. A few weeks after that, I was contacted by them again, seems they made some modifications to the system and now it was dead on the floor. I laughed and told them good luck. I figured if I went in and figured out how it broke and fixed it for them they were no better off, they were simply running. This way, the pressures was on for the person who broke it to fix it and thereby understand the system a little. It was broken for some time, eventually it got fixed. I believe the issue at the time was that they updated the DAO/ODBC stuff. Back then DAO/ODBC stuff was terribly buggy and any given version of it worked very differently from any other version and if you changed something there were even odds you would have to rewrite sections of code to make it work again. joe [1] Three people always seems like the magic number of the teams I am on. [2] Clueless or otherwise. [3] I have also been known to set the default shell to be command prompt, this really kills many Windows Admins. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Sunday, May 22, 2005 10:24 AM To: 'TIROA YANN '; Jorge de Almeida Pinto; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... For the sake of security you could move the print server role to other server(s) in your environment that are member servers. In this case you cannot use the print operators group if a member server is the print server. You need at least permissions to: * Create printer instances * Install printer drivers * Share printer instances * Manager the printer instances Or let the designated domain admins do those tasks I don't know how to configure this only. If a print admin is a member of the local admins group on the member server I'm sure he has enough power to manage printing on that member server... Maybe someone else on this list knows how to specifically delegate the print admin permissions as mentioned above on member servers with giving away the local admins group membership Cheers #JORGE# -----Original Message- From: TIROA YANN To: Jorge de Almeida Pinto; [EMAIL PROTECTED]; ActiveDir@mail.activedir.org Sent: 5/22/2005 3:56 PM Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi Jorge, WAAOOU ! Endeed i was not aware that print operators group was able to log on to my DCs and do task as reboot !! And yes,my DCs are also prints servers. maybe it's not good for security... but it's hard to convince my direction to buy a server ONLY for printers purposes. So i'd better review the best security practices as you suggested rather than "playing" with the adminsdhlder.. Thanks for your feedback. ;-) Regards, Yann Cordialement, Yann TIROA Centre de Ressources Informatique. Campus Scientifique de la DOUA. Bât. Gabriel Lippmann - 2 ème étage - salle 238. 43, Bd du 11 Novembre 1918. 69622 Villeurbanne Cedex. -Message d'origine- De : Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Envoyé : dimanche 22 mai 2005 15:18 À : TIROA YANN; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Objet : RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This artic
RE: [ActiveDir] Adminsdholder Propertiy Qustion...
What I mentioned also applies to some other built-in groups... see also http://www.windowsecurity.com/articles/Built-in-Groups-Delegation.html #JORGE# -Original Message- From: TIROA YANN To: Jorge de Almeida Pinto; [EMAIL PROTECTED]; ActiveDir@mail.activedir.org Sent: 5/22/2005 3:56 PM Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi Jorge, WAAOOU ! Endeed i was not aware that print operators group was able to log on to my DCs and do task as reboot !! And yes,my DCs are also prints servers. maybe it's not good for security... but it's hard to convince my direction to buy a server ONLY for printers purposes. So i'd better review the best security practices as you suggested rather than "playing" with the adminsdhlder.. Thanks for your feedback. ;-) Regards, Yann Cordialement, Yann TIROA Centre de Ressources Informatique. Campus Scientifique de la DOUA. Bât. Gabriel Lippmann - 2 ème étage - salle 238. 43, Bd du 11 Novembre 1918. 69622 Villeurbanne Cedex. -Message d'origine- De : Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Envoyé : dimanche 22 mai 2005 15:18 À : TIROA YANN; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Objet : RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This article describes how you can configure which default protected groups are protected or not by the adminsdholder object. Although possible I do not recommend it as there is more like I mention below. You are using the group "print operators" to manage printers, so this means your DCs are also print servers. Is this correct? Are you aware that the admin that manages the OU and its child objects (has Full Control) can log on to your DCs? That admin can change the password of the user that is a member of the print operators. After that he can use that user's credentials to log on to a DC. Why? By default print operators have ability to logon to DCs and do some stuff like shutting down the DC and load and unload device drivers (install printer drivers and others) I'm not sure if you already do it, but I recommend to distinguish between normal user accounts (to read mail, create documents, etc.) and admin accounts (to do all kinds of admin stuff). In my opinion each admin should logon to their workstation using their normal user account and do admin tasks using the RUNAS option. It is better however to have a separate workstation (or TS or Citrix) (protected like other servers) to do admin tasks. Using his normal workstation the admin user sets up a terminal session using RDP or ICA to the ADMIN workstation and does this things Cheers, #JORGE# -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 5/22/2005 2:39 PM Subject: [ActiveDir] Adminsdholder Propertiy Qustion... Hello ;-) I had a strange issue yesterday. An administrator who has full control(ct) of his OU and the child objects, was not able to modify a user account properties or password. The security option of the user object shows that the admin was not on the user object acl: the inheritance case that allows the parents to apply to this object ...was disabled !! After searching on the net, i have found that the adminsdholder was responsible for that. Endeed, user was member of print operators and thus is protected by adminsdholder throw his membershhip of this protected group. So i enabled the inheritance on the security option of the adminsdholder attribute, wait for less than 1 hour that PDCemulator "do his job", and checked that user object has the inheritance case activated: that's was OK and delegated admin was enjoyed ! :-) BUT, for my personnal interest, i think disabling the inheritance of the adminsdholder in not a good option dûe to security pruposes. So in this case, how can I just enabling inheritance of only this user acl without enabling it on the whole adminsdholder so the OU's admin have full ct on the user object. I also would like the user to continue to be member of the print operators. Thanks for your expert advices :o) NB: do not bother about my poor english writing and be indulgent 8-) Regards, Yann List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. This e-mail and
RE: [ActiveDir] Adminsdholder Propertiy Qustion...
For the sake of security you could move the print server role to other server(s) in your environment that are member servers. In this case you cannot use the print operators group if a member server is the print server. You need at least permissions to: * Create printer instances * Install printer drivers * Share printer instances * Manager the printer instances Or let the designated domain admins do those tasks I don't know how to configure this only. If a print admin is a member of the local admins group on the member server I'm sure he has enough power to manage printing on that member server... Maybe someone else on this list knows how to specifically delegate the print admin permissions as mentioned above on member servers with giving away the local admins group membership Cheers #JORGE# -Original Message- From: TIROA YANN To: Jorge de Almeida Pinto; [EMAIL PROTECTED]; ActiveDir@mail.activedir.org Sent: 5/22/2005 3:56 PM Subject: RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi Jorge, WAAOOU ! Endeed i was not aware that print operators group was able to log on to my DCs and do task as reboot !! And yes,my DCs are also prints servers. maybe it's not good for security... but it's hard to convince my direction to buy a server ONLY for printers purposes. So i'd better review the best security practices as you suggested rather than "playing" with the adminsdhlder.. Thanks for your feedback. ;-) Regards, Yann Cordialement, Yann TIROA Centre de Ressources Informatique. Campus Scientifique de la DOUA. Bât. Gabriel Lippmann - 2 ème étage - salle 238. 43, Bd du 11 Novembre 1918. 69622 Villeurbanne Cedex. -Message d'origine- De : Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Envoyé : dimanche 22 mai 2005 15:18 À : TIROA YANN; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Objet : RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This article describes how you can configure which default protected groups are protected or not by the adminsdholder object. Although possible I do not recommend it as there is more like I mention below. You are using the group "print operators" to manage printers, so this means your DCs are also print servers. Is this correct? Are you aware that the admin that manages the OU and its child objects (has Full Control) can log on to your DCs? That admin can change the password of the user that is a member of the print operators. After that he can use that user's credentials to log on to a DC. Why? By default print operators have ability to logon to DCs and do some stuff like shutting down the DC and load and unload device drivers (install printer drivers and others) I'm not sure if you already do it, but I recommend to distinguish between normal user accounts (to read mail, create documents, etc.) and admin accounts (to do all kinds of admin stuff). In my opinion each admin should logon to their workstation using their normal user account and do admin tasks using the RUNAS option. It is better however to have a separate workstation (or TS or Citrix) (protected like other servers) to do admin tasks. Using his normal workstation the admin user sets up a terminal session using RDP or ICA to the ADMIN workstation and does this things Cheers, #JORGE# -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 5/22/2005 2:39 PM Subject: [ActiveDir] Adminsdholder Propertiy Qustion... Hello ;-) I had a strange issue yesterday. An administrator who has full control(ct) of his OU and the child objects, was not able to modify a user account properties or password. The security option of the user object shows that the admin was not on the user object acl: the inheritance case that allows the parents to apply to this object ...was disabled !! After searching on the net, i have found that the adminsdholder was responsible for that. Endeed, user was member of print operators and thus is protected by adminsdholder throw his membershhip of this protected group. So i enabled the inheritance on the security option of the adminsdholder attribute, wait for less than 1 hour that PDCemulator "do his job", and checked that user object has the inheritance case activated: that's was OK and delegated admin was enjoyed ! :-) BUT, for my personnal interest, i think disabling the inheritance of the adminsdholder in not a good option dûe to security pruposes. So in this case, how can I just enabling inheritance of only this user acl without enabling it on the whole adminsdholder so the OU's admin have full ct on the user object. I also would like the user to continue to be member of the print operators. Thanks for your expert advices :o) NB: do not bother about
RE: [ActiveDir] Adminsdholder Propertiy Qustion...
Hi Jorge, WAAOOU ! Endeed i was not aware that print operators group was able to log on to my DCs and do task as reboot !! And yes,my DCs are also prints servers. maybe it's not good for security... but it's hard to convince my direction to buy a server ONLY for printers purposes. So i'd better review the best security practices as you suggested rather than "playing" with the adminsdhlder.. Thanks for your feedback. ;-) Regards, Yann Cordialement, Yann TIROA Centre de Ressources Informatique. Campus Scientifique de la DOUA. Bât. Gabriel Lippmann - 2 ème étage - salle 238. 43, Bd du 11 Novembre 1918. 69622 Villeurbanne Cedex. -Message d'origine- De : Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED] Envoyé : dimanche 22 mai 2005 15:18 À : TIROA YANN; '[EMAIL PROTECTED] '; 'ActiveDir@mail.activedir.org ' Objet : RE: [ActiveDir] Adminsdholder Propertiy Qustion... Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This article describes how you can configure which default protected groups are protected or not by the adminsdholder object. Although possible I do not recommend it as there is more like I mention below. You are using the group "print operators" to manage printers, so this means your DCs are also print servers. Is this correct? Are you aware that the admin that manages the OU and its child objects (has Full Control) can log on to your DCs? That admin can change the password of the user that is a member of the print operators. After that he can use that user's credentials to log on to a DC. Why? By default print operators have ability to logon to DCs and do some stuff like shutting down the DC and load and unload device drivers (install printer drivers and others) I'm not sure if you already do it, but I recommend to distinguish between normal user accounts (to read mail, create documents, etc.) and admin accounts (to do all kinds of admin stuff). In my opinion each admin should logon to their workstation using their normal user account and do admin tasks using the RUNAS option. It is better however to have a separate workstation (or TS or Citrix) (protected like other servers) to do admin tasks. Using his normal workstation the admin user sets up a terminal session using RDP or ICA to the ADMIN workstation and does this things Cheers, #JORGE# -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 5/22/2005 2:39 PM Subject: [ActiveDir] Adminsdholder Propertiy Qustion... Hello ;-) I had a strange issue yesterday. An administrator who has full control(ct) of his OU and the child objects, was not able to modify a user account properties or password. The security option of the user object shows that the admin was not on the user object acl: the inheritance case that allows the parents to apply to this object ...was disabled !! After searching on the net, i have found that the adminsdholder was responsible for that. Endeed, user was member of print operators and thus is protected by adminsdholder throw his membershhip of this protected group. So i enabled the inheritance on the security option of the adminsdholder attribute, wait for less than 1 hour that PDCemulator "do his job", and checked that user object has the inheritance case activated: that's was OK and delegated admin was enjoyed ! :-) BUT, for my personnal interest, i think disabling the inheritance of the adminsdholder in not a good option dûe to security pruposes. So in this case, how can I just enabling inheritance of only this user acl without enabling it on the whole adminsdholder so the OU's admin have full ct on the user object. I also would like the user to continue to be member of the print operators. Thanks for your expert advices :o) NB: do not bother about my poor english writing and be indulgent 8-) Regards, Yann List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adminsdholder Propertiy Qustion...
Hi, Have you seen "Delegated permissions are not available and inheritance is automatically disabled" (http://support.microsoft.com/?id=817433) This article describes how you can configure which default protected groups are protected or not by the adminsdholder object. Although possible I do not recommend it as there is more like I mention below. You are using the group "print operators" to manage printers, so this means your DCs are also print servers. Is this correct? Are you aware that the admin that manages the OU and its child objects (has Full Control) can log on to your DCs? That admin can change the password of the user that is a member of the print operators. After that he can use that user's credentials to log on to a DC. Why? By default print operators have ability to logon to DCs and do some stuff like shutting down the DC and load and unload device drivers (install printer drivers and others) I'm not sure if you already do it, but I recommend to distinguish between normal user accounts (to read mail, create documents, etc.) and admin accounts (to do all kinds of admin stuff). In my opinion each admin should logon to their workstation using their normal user account and do admin tasks using the RUNAS option. It is better however to have a separate workstation (or TS or Citrix) (protected like other servers) to do admin tasks. Using his normal workstation the admin user sets up a terminal session using RDP or ICA to the ADMIN workstation and does this things Cheers, #JORGE# -Original Message- From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: 5/22/2005 2:39 PM Subject: [ActiveDir] Adminsdholder Propertiy Qustion... Hello ;-) I had a strange issue yesterday. An administrator who has full control(ct) of his OU and the child objects, was not able to modify a user account properties or password. The security option of the user object shows that the admin was not on the user object acl: the inheritance case that allows the parents to apply to this object ...was disabled !! After searching on the net, i have found that the adminsdholder was responsible for that. Endeed, user was member of print operators and thus is protected by adminsdholder throw his membershhip of this protected group. So i enabled the inheritance on the security option of the adminsdholder attribute, wait for less than 1 hour that PDCemulator "do his job", and checked that user object has the inheritance case activated: that's was OK and delegated admin was enjoyed ! :-) BUT, for my personnal interest, i think disabling the inheritance of the adminsdholder in not a good option dûe to security pruposes. So in this case, how can I just enabling inheritance of only this user acl without enabling it on the whole adminsdholder so the OU's admin have full ct on the user object. I also would like the user to continue to be member of the print operators. Thanks for your expert advices :o) NB: do not bother about my poor english writing and be indulgent 8-) Regards, Yann List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] AdminSDHolder and Default button
Thanks Guido/Jorge As far as I know I should be fine with doing that as there shouldn't be any custom permissions set (I hope). But in any case, is that the recommended way of 'UNDO-ing' the adminsdholder restriction? Or is there a better way?... Thank you and have a splendid day! Kind Regards, Freddy Hartono Windows Administrator (ADSM/NT Security) Spherion Technology Group, Singapore For Agilent Technologies E-mail: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Wednesday, April 20, 2005 3:09 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder and Default button I can confirm what Jorge expects below - yes, all explicit permissions are removed and then the default from whatever is defined in the schema is set. You can script the resetting of permissions back to the default using the DSACLS.exe or ACLDiag.exe tools (I can't remember if only one of them or both have the /reset permission option) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Dienstag, 19. April 2005 10:51 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder and Default button (1) I expect the default permissions to REPLACE all existing permissions, because otherwise the DEFAULT buttonb would be meaningless (2) The DEFAULT button reads the security descriptor in the schema for that particular object and places that onto the object and it enables the "allow inherit from parent flag". Have checked Microsoft Scriptcenter For a script to reset the ADMINCOUNT = 1 to ADMINCOUNT = 0 see MS-KBQ817433 "Delegated permissions are not available and inheritance is automatically disabled" Cheers, Jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: dinsdag 19 april 2005 3:50 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] AdminSDHolder and Default button Hi all, If a user used to be a member of Account Operators group (affected by AdminSDHolder permissions) and has left that group - it is found that the permissions are not set back to default. Hence this user will have a very restrictive settings on itself and other members of account operators will not have rights over this username (eventhough it is no longer a member of that group). In Win2003 there's a button "Default" - user properties - security - advanced - DEFAULT. Description is set to replace all permission entries with the default setting". I've enabled this on a couple of accounts and seems to work expectedly. Question: 1) Does default removes any explicitly defined ACL on the user accounts? (I sure hope not). 2) How do I script this default function? Is this an attribute or something within the object itself? I have quite a few users that needs its permissions to be 'resetted' Thanks! Thank you and have a splendid day! Kind Regards, Freddy Hartono Windows Administrator (ADSM/NT Security) Spherion Technology Group, Singapore For Agilent Technologies E-mail: [EMAIL PROTECTED] List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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%40mail.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%40mail.activedir.org/
RE: [ActiveDir] AdminSDHolder and Default button
I can confirm what Jorge expects below - yes, all explicit permissions are removed and then the default from whatever is defined in the schema is set. You can script the resetting of permissions back to the default using the DSACLS.exe or ACLDiag.exe tools (I can't remember if only one of them or both have the /reset permission option) /Guido -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Dienstag, 19. April 2005 10:51 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AdminSDHolder and Default button (1) I expect the default permissions to REPLACE all existing permissions, because otherwise the DEFAULT buttonb would be meaningless (2) The DEFAULT button reads the security descriptor in the schema for that particular object and places that onto the object and it enables the "allow inherit from parent flag". Have checked Microsoft Scriptcenter For a script to reset the ADMINCOUNT = 1 to ADMINCOUNT = 0 see MS-KBQ817433 "Delegated permissions are not available and inheritance is automatically disabled" Cheers, Jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: dinsdag 19 april 2005 3:50 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] AdminSDHolder and Default button Hi all, If a user used to be a member of Account Operators group (affected by AdminSDHolder permissions) and has left that group - it is found that the permissions are not set back to default. Hence this user will have a very restrictive settings on itself and other members of account operators will not have rights over this username (eventhough it is no longer a member of that group). In Win2003 there's a button "Default" - user properties - security - advanced - DEFAULT. Description is set to replace all permission entries with the default setting". I've enabled this on a couple of accounts and seems to work expectedly. Question: 1) Does default removes any explicitly defined ACL on the user accounts? (I sure hope not). 2) How do I script this default function? Is this an attribute or something within the object itself? I have quite a few users that needs its permissions to be 'resetted' Thanks! Thank you and have a splendid day! Kind Regards, Freddy Hartono Windows Administrator (ADSM/NT Security) Spherion Technology Group, Singapore For Agilent Technologies E-mail: [EMAIL PROTECTED] List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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%40mail.activedir.org/
RE: [ActiveDir] AdminSDHolder and Default button
(1) I expect the default permissions to REPLACE all existing permissions, because otherwise the DEFAULT buttonb would be meaningless (2) The DEFAULT button reads the security descriptor in the schema for that particular object and places that onto the object and it enables the "allow inherit from parent flag". Have checked Microsoft Scriptcenter For a script to reset the ADMINCOUNT = 1 to ADMINCOUNT = 0 see MS-KBQ817433 "Delegated permissions are not available and inheritance is automatically disabled" Cheers, Jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: dinsdag 19 april 2005 3:50 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] AdminSDHolder and Default button Hi all, If a user used to be a member of Account Operators group (affected by AdminSDHolder permissions) and has left that group - it is found that the permissions are not set back to default. Hence this user will have a very restrictive settings on itself and other members of account operators will not have rights over this username (eventhough it is no longer a member of that group). In Win2003 there's a button "Default" - user properties - security - advanced - DEFAULT. Description is set to replace all permission entries with the default setting". I've enabled this on a couple of accounts and seems to work expectedly. Question: 1) Does default removes any explicitly defined ACL on the user accounts? (I sure hope not). 2) How do I script this default function? Is this an attribute or something within the object itself? I have quite a few users that needs its permissions to be 'resetted' Thanks! Thank you and have a splendid day! Kind Regards, Freddy Hartono Windows Administrator (ADSM/NT Security) Spherion Technology Group, Singapore For Agilent Technologies E-mail: [EMAIL PROTECTED] List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.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. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
