Active Directory Group Administrator

This is probably an easy one. Basically, I want to know why something is happening. Specifically, I have 3 containers.

Container A
Container B
Container Special

I have a container admin for Container A, and a container admin for Container B. Neither container admin A or B has rights to any object in Container Special. Also, container admin A cannot add/modify/delete objects in Container B and vice versa.

So, I want to allow both container admin A and container admin B  to add/delete users from only one specific group under Container Special. This seems easy enough and I grant the Container A and B admin groups access to just this one group (pretty much full control to just the one group object, not descendant objects or anything else).

Everything works as expected except for one thing. Container admin A can add users from Container B into this group under Container Special (and Container admin B can add user from Container A).

I can understand how the members attribute for the group object in the special container can be updated by either admin A or B (they have full rights to the group). Where my brain fails today is why/how they are allowed to update the memberof attribute for a user they don't have rights to?

I have a feeling this is just the way it works, but I'm curious as to why. Any light that can be shed on this would be helpful.

Thanks,
TMR
timmr72Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Joseph MoodyBlogger and wearer of all hats.Commented:
If the container A admin can read the objects in container B, then container A admin can add users from container B to security groups.

For example, take a security group in container A and add users to it from container B.

If you did not want this behavior to happen, you would need to remove the ability for container A admin to read container B. Then you would create a security group in Container A named something like "A Nested Container Special". Then make that group a member of Container Special Security Group.

Then the container A admin could add users to the nest container A special group. But wouldn't need to permission to any other containers.
0
als315Commented:
Admins A and B are modifying only Container Special (if you are adding user to some container, you are doing nothing with this user, you are changing this container). So this is correct behaviour.
0
tigermattCommented:
Great question! Yep, you're exactly right on the "member" attribute part. That is stored in the group object, and since the admins have security permissions granting them control over that property of the group, they can modify it and add/remove members.

memberOf is not actually a real property but is a so-called "backlink" attribute. Adding a member to a group is the forward-link, and this operation is both read-and-write. However, the backlink on the user object is read-only and automatically calculated by Active Directory. Without going into all the technical detail, this is how the admins have the ability to seemingly update the memberOf attribute on those user accounts. They are not writing to it; AD is calculating it internally.

Florian has a good blog on this here: http://www.frickelsoft.net/blog/?p=130

Incidentally, this architecture is also one of the motivating reasons behind the role played by the Infrastructure Master FSMO holder in a multi-domain forest. In order to represent the forward-link when a user is added to a group in a different domain, AD creates phantoms in the foreign domain of the group so that the user object can be referred back to. The infrastructure role has to maintain these phantoms to ensure they do not get out-of-date. My article on FSMO roles goes in to a bit more detail: http://www.experts-exchange.com/Software/Server_Software/File_Servers/Active_Directory/A_2796-Demystifying-the-Active-Directory-FSMO-Roles.html

Ultimately, the security consideration is on the control of the security group. Security groups grant access to resources, so it seems prudent that the manager of the group has the say in who becomes a member of that group, rather than the manager of the user account object.

-Matt
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
timmr72Author Commented:
Thank  you Matt. This is exactly what I was looking for. Great answer!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.