Restrict Group Membership for users not from particular OU

active-directoryorganizational-unitsecurity-groups

I need to configure two type of users that can administer AD users and security groups:

  • Type 1 – Can only create users within particular OU.
  • Type 2 – Can only change group membership of users created in OU mentioned above.

I'm doing that basing on Delegation Control feature. Idea is to do not have single trust point to create users and add them to Security Groups, so atleast 2 persons will be required for that operation.

Everything is clear with Type 1 users. I just configured Delegation Control for user account and managed to create users within only set OU(i.e. Operators) with that.

With Type 2 it went more complicated because as it was noticed by me it is not group linked to user but actually user linked to group.
I'm able to change group membership only for 1 OU (i.e. Operators Group) but i can add ANY user to groups within that OU. This means that user responsible for modifying of group membership can add himself to any of the groups what is not acceptable for me, as only users created by Type 1 user can be added to Security Groups controlled by Type 2 users.

Theoretically i see only proper solution how to implement that is to restrict on Security Group or OU level to modify group membership for users who is not in allowed OU, however i was googling and investigating Microsoft knowledge base but was not able to find any sufficient information how this can be done.

Maybe somebody knows how this can be implemented or can suggest how else i can implement necessary configuration?

Best Answer

user responsible for modifying of group membership can add himself to any of the groups

Sure. This is by design. The linked relationship between groups and group members in Active Directory makes the forward link from group to user writable (the member attribute) while the backlink from user to group (the memberOf attribute) is internally computed and read-only. You cannot delegate ability to edit the memberOf attribute on a user. More info on how this is stored in Florian's blog.

The implication for this case: group membership is controlled by the user's ability to edit the group, not the target user to be added to the group. This is normally because a group is "owned" by a particular person or team within an organization, as it controls access to that team's privileged resources. Therefore, that team designated security lead should have discretion to determine which members of the organization are granted the permissions conferred by the group. This is a discretionary access control policy.

Learning point: You cannot delegate control over a group such that the user can only add members from a particular OU.

How can I make this work?

Your desired end-goal describes a combination of mandatory and discretionary access control policies:

  • Mandatory: user should only be permitted to add users from a particular OU
  • Discretionary: user should have discretion to determine which users from that OU are in their group

This is not possible using the default Active Directory delegation mechanisms for the reason I outlined at the outset. Any suitable implementation of this will need to be a non-technical (i.e. policy) system, or a separate substrate which the user makes their group membership changes with:

Policy

Make all staff aware that they should only add members from their controlled OUs to their delegated groups. Set up automated reports to monitor violations of this policy, and either automatically correct them (by removing the user in violation) or send an email notification to relevant authorities.

Bespoke software

Don't delegate control for users to edit group memberships directly. Instead, use a third-party software package (which you might custom develop). The software package is delegated control to edit any of the managed groups. It can sanity check a user's choice of user to add (by checking the OU against an ACL, etc.) before it makes the change on the user's behalf.

Complex ACL setup

You could envisage a situation in which you flip the logic -- create two groups for each OU:

  1. OU group: The first group contains everyone in the OU. Control over this group is not delegated.
  2. OU deny group: The second group contains users who should be denied access to that OU's resources. Control over this group is delegated. New users are added to this group by default (policy decision).

When creating an ACL on a resource, you add the OU group with full access, and the deny group with all ACEs set to deny. The delegated permissions mean the end-users can deny access to anyone they choose (from any OU). This doesn't break the model, because users need allow privileges to gain access, and these are only available from the OU group which you don't delegate modification rights over.

This isn't ideal on multiple fronts:

  • RBAC: I've not talked about role-based access control, which is recommended but this simple method neglects talking about.
  • Explicit deny where implicit deny is preferable: our access rights become unnecessarily complex, our deny rights are explicit rather than implicit, and we can easily get into a situation where users are unwittingly granted access if we don't understand the complex interplay between the default and the deny group.

I recommend you do one of the following:

  • re-think your problem
  • re-appraise your resources to make them non-OU specific
  • break your environment up into multiple domains along departmental lines (offering more granularity)
  • centralise ACL management
  • implement suitable policies to manage and/or audit the process of granting permissions
  • use third-party software to manage your group memberships, which understand the specific semantics of the policy your organization needs to enforce
Related Topic