AD User Objects & Permission Inheritance

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
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/

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!
 
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.
 
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.
 
That's what I'd do ;-)


--

Paul Williams

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

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.
 
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!
 
Back
Top