| Author | Messages | |
ifconfig
Posts:49
 | | 01/19/2010 10:44 PM |
| As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be
creating accounts during migration that do not have the "Include inheritable
permissions from this object’s parent" checked in the security attributes.
I'd like to, with PoSH or something suitable, be able to go through the
several hundred accounts affected and programmatically set this DACL (am I
correct in thinking this?) to allow inheritable permissions from the
object's parent to propagate.
Many thanks.
Fred Woodbridge
| | | |
| Tony
Posts:152
| | 01/19/2010 11:22 PM |
| You might want to first check whether the objects are protected by the AdminSDHolder. For example, if they are direct or indirect members of a protected group that is protected then setting the DACL will simply be overwritten once you’ve changed it.
Check the value of AdminCount. Usually this attribute is excluded by QMMAD so if the value is set to 1 on the target object then this would be a good indicator that it is a protected object.
If the objects are not protected you can find a script that will re-set the permissions inheritance flag here:
http://support.microsoft.com/kb/817433
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 11:43 a.m.
To: activedir@activedir.org
Subject: [ActiveDir] Programmatically Setting Object Security
As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be creating accounts during migration that do not have the "Include inheritable permissions from this object’s parent" checked in the security attributes. I'd like to, with PoSH or something suitable, be able to go through the several hundred accounts affected and programmatically set this DACL (am I correct in thinking this?) to allow inheritable permissions from the object's parent to propagate.
Many thanks.
Fred Woodbridge
| | | |
| ifconfig
Posts:49
| | 01/19/2010 11:43 PM |
| Tony:
These accounts weren't members of the any protected groups in the source
domain nor are they in the target domain.
Thanks, I'll follow up with the KB article ... I am intrigued by the QMMAD
assertion however: you say it is "usually excluded" ... under what
circumstances is the attribute not excluded?
Thanks!
Fred W.
On Tue, Jan 19, 2010 at 16:22, Tony Murray <tony@activedir.org> wrote:
> You might want to first check whether the objects are protected by the
> AdminSDHolder. For example, if they are direct or indirect members of a
> protected group that is protected then setting the DACL will simply be
> overwritten once you’ve changed it.
>
>
>
> Check the value of AdminCount. Usually this attribute is excluded by QMMAD
> so if the value is set to 1 on the target object then this would be a good
> indicator that it is a protected object.
>
>
>
> If the objects are not protected you can find a script that will re-set the
> permissions inheritance flag here:
>
>
>
> http://support.microsoft.com/kb/817433
>
>
>
> Tony
>
>
>
> *From:* activedir-owner@mail.activedir.org [mailto:
> activedir-owner@mail.activedir.org] *On Behalf Of *Frederic Woodbridge,
> III
> *Sent:* Wednesday, 20 January 2010 11:43 a.m.
> *To:* activedir@activedir.org
> *Subject:* [ActiveDir] Programmatically Setting Object Security
>
>
>
> As usual, I come to GOAL or Gurus Of the Activedir List with questions:
>
> For some unexplained reason, the Quest AD Migration tool seems to be
> creating accounts during migration that do not have the "Include inheritable
> permissions from this object’s parent" checked in the security attributes.
> I'd like to, with PoSH or something suitable, be able to go through the
> several hundred accounts affected and programmatically set this DACL (am I
> correct in thinking this?) to allow inheritable permissions from the
> object's parent to propagate.
>
> Many thanks.
>
> Fred Woodbridge
>
| | | |
| Tony
Posts:152
| | 01/20/2010 12:32 AM |
| Hi Fred
Interesting. Do the source objects have inheritance unchecked? If so, the state will (I believe) always propagate through to the target object.
Regarding the adminCount attribute being excluded, I may be getting confused with ADMT behaviour, but I recall there is a list of default attributes that are carried across and those that aren’t. I thought adminCount was not part of the default list.
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 12:41 p.m.
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Programmatically Setting Object Security
Tony:
These accounts weren't members of the any protected groups in the source domain nor are they in the target domain.
Thanks, I'll follow up with the KB article ... I am intrigued by the QMMAD assertion however: you say it is "usually excluded" ... under what circumstances is the attribute not excluded?
Thanks!
Fred W.
On Tue, Jan 19, 2010 at 16:22, Tony Murray <tony@activedir.org> wrote:
You might want to first check whether the objects are protected by the AdminSDHolder. For example, if they are direct or indirect members of a protected group that is protected then setting the DACL will simply be overwritten once you’ve changed it.
Check the value of AdminCount. Usually this attribute is excluded by QMMAD so if the value is set to 1 on the target object then this would be a good indicator that it is a protected object.
If the objects are not protected you can find a script that will re-set the permissions inheritance flag here:
http://support.microsoft.com/kb/817433
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 11:43 a.m.
To: activedir@activedir.org
Subject: [ActiveDir] Programmatically Setting Object Security
As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be creating accounts during migration that do not have the "Include inheritable permissions from this object’s parent" checked in the security attributes. I'd like to, with PoSH or something suitable, be able to go through the several hundred accounts affected and programmatically set this DACL (am I correct in thinking this?) to allow inheritable permissions from the object's parent to propagate.
Many thanks.
Fred Woodbridge
| | | |
| kevinrjames
Posts:35
| | 01/20/2010 1:59 AM |
| I believe admincount is calculated and set/cleared by the system
Indicates that a given object has had its ACL's changed to a more secure value by the system because it was a member of one of the administrative groups (directly or transitively).
http://msdn.microsoft.com/en-us/library/ms675212(VS.85).aspx
Regards,
Kevin R. James
602.284.9158 Fax: 623.581.3500
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Tony Murray
Sent: Tuesday, January 19, 2010 5:31 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Programmatically Setting Object Security
Hi Fred
Interesting. Do the source objects have inheritance unchecked? If so, the state will (I believe) always propagate through to the target object.
Regarding the adminCount attribute being excluded, I may be getting confused with ADMT behaviour, but I recall there is a list of default attributes that are carried across and those that aren’t. I thought adminCount was not part of the default list.
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 12:41 p.m.
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Programmatically Setting Object Security
Tony:
These accounts weren't members of the any protected groups in the source domain nor are they in the target domain.
Thanks, I'll follow up with the KB article ... I am intrigued by the QMMAD assertion however: you say it is "usually excluded" ... under what circumstances is the attribute not excluded?
Thanks!
Fred W.
On Tue, Jan 19, 2010 at 16:22, Tony Murray <tony@activedir.org> wrote:
You might want to first check whether the objects are protected by the AdminSDHolder. For example, if they are direct or indirect members of a protected group that is protected then setting the DACL will simply be overwritten once you’ve changed it.
Check the value of AdminCount. Usually this attribute is excluded by QMMAD so if the value is set to 1 on the target object then this would be a good indicator that it is a protected object.
If the objects are not protected you can find a script that will re-set the permissions inheritance flag here:
http://support.microsoft.com/kb/817433
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 11:43 a.m.
To: activedir@activedir.org
Subject: [ActiveDir] Programmatically Setting Object Security
As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be creating accounts during migration that do not have the "Include inheritable permissions from this object’s parent" checked in the security attributes. I'd like to, with PoSH or something suitable, be able to go through the several hundred accounts affected and programmatically set this DACL (am I correct in thinking this?) to allow inheritable permissions from the object's parent to propagate.
Many thanks.
Fred Woodbridge
Sent to activedir@mail.activedir.org from Kevin R. James
Virus scanned by GFI MailSecurity 19/1/2010
| | | |
| Tony
Posts:152
| | 01/20/2010 2:18 AM |
| Hi Kevin
The adminCount value is set by the system, but is not cleared when an object is removed from a protected state.
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Kevin R. James
Sent: Wednesday, 20 January 2010 2:58 p.m.
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Programmatically Setting Object Security
I believe admincount is calculated and set/cleared by the system
Indicates that a given object has had its ACL's changed to a more secure value by the system because it was a member of one of the administrative groups (directly or transitively).
http://msdn.microsoft.com/en-us/library/ms675212(VS.85).aspx
Regards,
Kevin R. James
602.284.9158 Fax: 623.581.3500
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Tony Murray
Sent: Tuesday, January 19, 2010 5:31 PM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Programmatically Setting Object Security
Hi Fred
Interesting. Do the source objects have inheritance unchecked? If so, the state will (I believe) always propagate through to the target object.
Regarding the adminCount attribute being excluded, I may be getting confused with ADMT behaviour, but I recall there is a list of default attributes that are carried across and those that aren’t. I thought adminCount was not part of the default list.
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 12:41 p.m.
To: activedir@mail.activedir.org
Subject: Re: [ActiveDir] Programmatically Setting Object Security
Tony:
These accounts weren't members of the any protected groups in the source domain nor are they in the target domain.
Thanks, I'll follow up with the KB article ... I am intrigued by the QMMAD assertion however: you say it is "usually excluded" ... under what circumstances is the attribute not excluded?
Thanks!
Fred W.
On Tue, Jan 19, 2010 at 16:22, Tony Murray <tony@activedir.org> wrote:
You might want to first check whether the objects are protected by the AdminSDHolder. For example, if they are direct or indirect members of a protected group that is protected then setting the DACL will simply be overwritten once you’ve changed it.
Check the value of AdminCount. Usually this attribute is excluded by QMMAD so if the value is set to 1 on the target object then this would be a good indicator that it is a protected object.
If the objects are not protected you can find a script that will re-set the permissions inheritance flag here:
http://support.microsoft.com/kb/817433
Tony
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Wednesday, 20 January 2010 11:43 a.m.
To: activedir@activedir.org
Subject: [ActiveDir] Programmatically Setting Object Security
As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be creating accounts during migration that do not have the "Include inheritable permissions from this object’s parent" checked in the security attributes. I'd like to, with PoSH or something suitable, be able to go through the several hundred accounts affected and programmatically set this DACL (am I correct in thinking this?) to allow inheritable permissions from the object's parent to propagate.
Many thanks.
Fred Woodbridge
Sent to activedir@mail.activedir.org from Kevin R. James
Virus scanned by GFI MailSecurity 19/1/2010
| | | |
| barkills
Posts:214
| | 01/20/2010 4:47 PM |
| I have .net code I use to programmatically set directory ACEs. Dunno if that'd be suitable enough for you or not. You can see a vb.net example here under the .net code section:
http://www.netid.washington.edu/documentation/courseGroupPrivacy.aspx
I can supply a c# version too.
From: activedir-owner@mail.activedir.org [mailto:activedir-owner@mail.activedir.org] On Behalf Of Frederic Woodbridge, III
Sent: Tuesday, January 19, 2010 2:43 PM
To: activedir@activedir.org
Subject: [ActiveDir] Programmatically Setting Object Security
As usual, I come to GOAL or Gurus Of the Activedir List with questions:
For some unexplained reason, the Quest AD Migration tool seems to be creating accounts during migration that do not have the "Include inheritable permissions from this object’s parent" checked in the security attributes. I'd like to, with PoSH or something suitable, be able to go through the several hundred accounts affected and programmatically set this DACL (am I correct in thinking this?) to allow inheritable permissions from the object's parent to propagate.
Many thanks.
Fred Woodbridge
| | | |
| ifconfig
Posts:49
| | 01/20/2010 6:21 PM |
| On Tue, Jan 19, 2010 at 17:31, Tony Murray <tony@activedir.org> wrote:
> Hi Fred
>
>
>
> Interesting. Do the source objects have inheritance unchecked? If so, the
> state will (I believe) always propagate through to the target object.
>
> No, the source objects all have inheritance normally checked.
> Regarding the adminCount attribute being excluded, I may be getting
> confused with ADMT behaviour, but I recall there is a list of default
> attributes that are carried across and those that aren’t. I thought
> adminCount was not part of the default list.
>
> You're right. It seems that at some point, some of those accounts were
placed in the DA (or some other protected) group and they all do indeed have
the adminCount attribute set to 1.
Thanks for the help.
>
> Tony
>
>
| | | |
|
|