AD User Objects & Permission Inheritance

G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

I noticed something when one of the users in charge of an OU reported he
could no longer modify the user objects. The user rights were not inheriting
permissions from its parent OU's. I enabled the Inherit permissions check box
and the next day it was disabled again. Then I went looking at all other user
objects in the different OU's and some OU's had users with permission
inheritance enabled and other OU's user objects had inheritance disabled. How
would this be? Is there a setting in a GPO somewhere to control this? It
seems so sporadic and it makes it hard to pinpoint.
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

Do you have Win 2000 SP4 installed and the phenomenon happened recently /
intermittently?

Are these admins also members of a security group within the OU delegated
rights to manage the OU?

See
http://support.microsoft.com/default.aspx?scid=kb;en-us;817433

Method 2 in the KB would be the less disruptive resolution to this
'security' problem.

Do let us know if it helps. Thanks!

"Arcom" wrote:

> I noticed something when one of the users in charge of an OU reported he
> could no longer modify the user objects. The user rights were not inheriting
> permissions from its parent OU's. I enabled the Inherit permissions check box
> and the next day it was disabled again. Then I went looking at all other user
> objects in the different OU's and some OU's had users with permission
> inheritance enabled and other OU's user objects had inheritance disabled. How
> would this be? Is there a setting in a GPO somewhere to control this? It
> seems so sporadic and it makes it hard to pinpoint.
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

Personally, I don't think method two is suitable. The adminSDHolder object
is there for a reason. After all, this behaviour is by design. In many
environments, setting the inherit flag will add a lot of additional,
unnecessary permissions to the protected accounts.

If you have the need to delegate control to a user or group to administer
users in an OU, and in that OU reside other protected users you have two
choices -remove them from those protected groups (most of the time they are
members for legacy reasons, and should no longer be in there); or delegate
the control to an existing admin-type person, i.e. one of the protected
group members -you can then grant that user or protected group to which he/
she belongs permissions to the adminSDHolder object.

If neither of these suit your needs, I would apply the permissions that you
applied to the OU in question to the adminSDHolder object. This is better
than simply allowing the adminSDHolder to inherit permissions, as you are
still limiting access to these protected users.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

"Desmond Lee" <mcp@donotspamplease.mars> wrote in message
news:BD1A4EDE-EE11-4979-9FB2-B5A6D42009F2@microsoft.com...
Do you have Win 2000 SP4 installed and the phenomenon happened recently /
intermittently?

Are these admins also members of a security group within the OU delegated
rights to manage the OU?

See
http://support.microsoft.com/default.aspx?scid=kb;en-us;817433

Method 2 in the KB would be the less disruptive resolution to this
'security' problem.

Do let us know if it helps. Thanks!

"Arcom" wrote:

> I noticed something when one of the users in charge of an OU reported he
> could no longer modify the user objects. The user rights were not
> inheriting
> permissions from its parent OU's. I enabled the Inherit permissions check
> box
> and the next day it was disabled again. Then I went looking at all other
> user
> objects in the different OU's and some OU's had users with permission
> inheritance enabled and other OU's user objects had inheritance disabled.
> How
> would this be? Is there a setting in a GPO somewhere to control this? It
> seems so sporadic and it makes it hard to pinpoint.
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

Thanks for all the help. I went ahead and enabled inheritance on the
adminSDholder object to verify that this indeed was the cause and 60 minutes
later all user objects began to inherit permissions again. At this point I
will look into the best way to provide a "middle ground" solution so as not
to open up all user accounts to inheritance but at the same time allowing the
necessary OU admins the proper rights to its users. My only remaining
question that I was not able to clearly answer through the responses or KB
article is whether every single user under an OU that contains a protected
user account gets inheritance disabled because of that one protected account?
Reason I ask is because certaion OU's contain only a handlful of customer
service users that have never been in a protected group yet they too were not
inherating permissions. Thanks again for all your time and information.

"ptwilliams" wrote:

> Personally, I don't think method two is suitable. The adminSDHolder object
> is there for a reason. After all, this behaviour is by design. In many
> environments, setting the inherit flag will add a lot of additional,
> unnecessary permissions to the protected accounts.
>
> If you have the need to delegate control to a user or group to administer
> users in an OU, and in that OU reside other protected users you have two
> choices -remove them from those protected groups (most of the time they are
> members for legacy reasons, and should no longer be in there); or delegate
> the control to an existing admin-type person, i.e. one of the protected
> group members -you can then grant that user or protected group to which he/
> she belongs permissions to the adminSDHolder object.
>
> If neither of these suit your needs, I would apply the permissions that you
> applied to the OU in question to the adminSDHolder object. This is better
> than simply allowing the adminSDHolder to inherit permissions, as you are
> still limiting access to these protected users.
>
> --
>
> Paul Williams
>
> http://www.msresource.net/
> http://forums.msresource.net/
>
> "Desmond Lee" <mcp@donotspamplease.mars> wrote in message
> news:BD1A4EDE-EE11-4979-9FB2-B5A6D42009F2@microsoft.com...
> Do you have Win 2000 SP4 installed and the phenomenon happened recently /
> intermittently?
>
> Are these admins also members of a security group within the OU delegated
> rights to manage the OU?
>
> See
> http://support.microsoft.com/default.aspx?scid=kb;en-us;817433
>
> Method 2 in the KB would be the less disruptive resolution to this
> 'security' problem.
>
> Do let us know if it helps. Thanks!
>
> "Arcom" wrote:
>
> > I noticed something when one of the users in charge of an OU reported he
> > could no longer modify the user objects. The user rights were not
> > inheriting
> > permissions from its parent OU's. I enabled the Inherit permissions check
> > box
> > and the next day it was disabled again. Then I went looking at all other
> > user
> > objects in the different OU's and some OU's had users with permission
> > inheritance enabled and other OU's user objects had inheritance disabled.
> > How
> > would this be? Is there a setting in a GPO somewhere to control this? It
> > seems so sporadic and it makes it hard to pinpoint.
>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

I went ahead and granted the Account Operators built in group rights on the
adminSDholder object according to what I want the OU admins to have. I will
add the OU Admins to the Account Operators built in group and this should
solve the problem with the least amount of security weakening. If anyone sees
a flaw in this thought process please mention it. Thanks in advance.

"Arcom" wrote:

> Thanks for all the help. I went ahead and enabled inheritance on the
> adminSDholder object to verify that this indeed was the cause and 60 minutes
> later all user objects began to inherit permissions again. At this point I
> will look into the best way to provide a "middle ground" solution so as not
> to open up all user accounts to inheritance but at the same time allowing the
> necessary OU admins the proper rights to its users. My only remaining
> question that I was not able to clearly answer through the responses or KB
> article is whether every single user under an OU that contains a protected
> user account gets inheritance disabled because of that one protected account?
> Reason I ask is because certaion OU's contain only a handlful of customer
> service users that have never been in a protected group yet they too were not
> inherating permissions. Thanks again for all your time and information.
>
> "ptwilliams" wrote:
>
> > Personally, I don't think method two is suitable. The adminSDHolder object
> > is there for a reason. After all, this behaviour is by design. In many
> > environments, setting the inherit flag will add a lot of additional,
> > unnecessary permissions to the protected accounts.
> >
> > If you have the need to delegate control to a user or group to administer
> > users in an OU, and in that OU reside other protected users you have two
> > choices -remove them from those protected groups (most of the time they are
> > members for legacy reasons, and should no longer be in there); or delegate
> > the control to an existing admin-type person, i.e. one of the protected
> > group members -you can then grant that user or protected group to which he/
> > she belongs permissions to the adminSDHolder object.
> >
> > If neither of these suit your needs, I would apply the permissions that you
> > applied to the OU in question to the adminSDHolder object. This is better
> > than simply allowing the adminSDHolder to inherit permissions, as you are
> > still limiting access to these protected users.
> >
> > --
> >
> > Paul Williams
> >
> > http://www.msresource.net/
> > http://forums.msresource.net/
> >
> > "Desmond Lee" <mcp@donotspamplease.mars> wrote in message
> > news:BD1A4EDE-EE11-4979-9FB2-B5A6D42009F2@microsoft.com...
> > Do you have Win 2000 SP4 installed and the phenomenon happened recently /
> > intermittently?
> >
> > Are these admins also members of a security group within the OU delegated
> > rights to manage the OU?
> >
> > See
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;817433
> >
> > Method 2 in the KB would be the less disruptive resolution to this
> > 'security' problem.
> >
> > Do let us know if it helps. Thanks!
> >
> > "Arcom" wrote:
> >
> > > I noticed something when one of the users in charge of an OU reported he
> > > could no longer modify the user objects. The user rights were not
> > > inheriting
> > > permissions from its parent OU's. I enabled the Inherit permissions check
> > > box
> > > and the next day it was disabled again. Then I went looking at all other
> > > user
> > > objects in the different OU's and some OU's had users with permission
> > > inheritance enabled and other OU's user objects had inheritance disabled.
> > > How
> > > would this be? Is there a setting in a GPO somewhere to control this? It
> > > seems so sporadic and it makes it hard to pinpoint.
> >
> >
> >
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

It really depends on what you need to achieve in accordance to your AD
design, administrative / IT operational setup and corporate security
policies. In essence, the goal is to restore what that has been lost due to
AD implementation specifics which were changed and sort of beyond one's
control.

How best adminSDholder inheritance could be re-enabled is something only you
can decide eventually.

Nevertheless, do let us know if this KB helped you solve the problem. Thanks!
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

That's what I'd do ;-)


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

"Arcom" <Arcom@discussions.microsoft.com> wrote in message
news:B848F938-788A-4568-A90C-829E83CCB59B@microsoft.com...
I went ahead and granted the Account Operators built in group rights on the
adminSDholder object according to what I want the OU admins to have. I will
add the OU Admins to the Account Operators built in group and this should
solve the problem with the least amount of security weakening. If anyone
sees
a flaw in this thought process please mention it. Thanks in advance.

"Arcom" wrote:

> Thanks for all the help. I went ahead and enabled inheritance on the
> adminSDholder object to verify that this indeed was the cause and 60
> minutes
> later all user objects began to inherit permissions again. At this point I
> will look into the best way to provide a "middle ground" solution so as
> not
> to open up all user accounts to inheritance but at the same time allowing
> the
> necessary OU admins the proper rights to its users. My only remaining
> question that I was not able to clearly answer through the responses or KB
> article is whether every single user under an OU that contains a protected
> user account gets inheritance disabled because of that one protected
> account?
> Reason I ask is because certaion OU's contain only a handlful of customer
> service users that have never been in a protected group yet they too were
> not
> inherating permissions. Thanks again for all your time and information.
>
> "ptwilliams" wrote:
>
> > Personally, I don't think method two is suitable. The adminSDHolder
> > object
> > is there for a reason. After all, this behaviour is by design. In many
> > environments, setting the inherit flag will add a lot of additional,
> > unnecessary permissions to the protected accounts.
> >
> > If you have the need to delegate control to a user or group to
> > administer
> > users in an OU, and in that OU reside other protected users you have two
> > choices -remove them from those protected groups (most of the time they
> > are
> > members for legacy reasons, and should no longer be in there); or
> > delegate
> > the control to an existing admin-type person, i.e. one of the protected
> > group members -you can then grant that user or protected group to which
> > he/
> > she belongs permissions to the adminSDHolder object.
> >
> > If neither of these suit your needs, I would apply the permissions that
> > you
> > applied to the OU in question to the adminSDHolder object. This is
> > better
> > than simply allowing the adminSDHolder to inherit permissions, as you
> > are
> > still limiting access to these protected users.
> >
> > --
> >
> > Paul Williams
> >
> > http://www.msresource.net/
> > http://forums.msresource.net/
> >
> > "Desmond Lee" <mcp@donotspamplease.mars> wrote in message
> > news:BD1A4EDE-EE11-4979-9FB2-B5A6D42009F2@microsoft.com...
> > Do you have Win 2000 SP4 installed and the phenomenon happened recently
> > /
> > intermittently?
> >
> > Are these admins also members of a security group within the OU
> > delegated
> > rights to manage the OU?
> >
> > See
> >
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;817433
> >
> > Method 2 in the KB would be the less disruptive resolution to this
> > 'security' problem.
> >
> > Do let us know if it helps. Thanks!
> >
> > "Arcom" wrote:
> >
> > > I noticed something when one of the users in charge of an OU reported
> > > he
> > > could no longer modify the user objects. The user rights were not
> > > inheriting
> > > permissions from its parent OU's. I enabled the Inherit permissions
> > > check
> > > box
> > > and the next day it was disabled again. Then I went looking at all
> > > other
> > > user
> > > objects in the different OU's and some OU's had users with permission
> > > inheritance enabled and other OU's user objects had inheritance
> > > disabled.
> > > How
> > > would this be? Is there a setting in a GPO somewhere to control this?
> > > It
> > > seems so sporadic and it makes it hard to pinpoint.
> >
> >
> >
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.active_directory (More info?)

The KB certainly helped, thanks alot for the pointer.

"Desmond Lee" wrote:

> It really depends on what you need to achieve in accordance to your AD
> design, administrative / IT operational setup and corporate security
> policies. In essence, the goal is to restore what that has been lost due to
> AD implementation specifics which were changed and sort of beyond one's
> control.
>
> How best adminSDholder inheritance could be re-enabled is something only you
> can decide eventually.
>
> Nevertheless, do let us know if this KB helped you solve the problem. Thanks!
>