Active Directory rights delegation – part 2


This time, we will try to delegate rights to group of users who are responsible for creating new user accounts or new groups in a domain. In our case, we will consider this group as local HelpDesk. To allow users from HelpDesk this possibility, you need to delegate appropriate permissions to them. If you want to do that, I would strongly recommend to create appropriate groups in a domain for all tasks and put HelpDesk group into them. Please consider this group as a role!

So, let’s start. First of all, you need to create domain local security groups for all required tasks:

  • user management in each OU
  • user password reset
  • group management in each OU
  • group membership management

as reference, you can use this naming convention

  • dlg-ou-create-user
  • dlg-ou-create-group
  • dlg-modify-group-members
  • dlg-resete-user-password

Domain Local groups

then create global security groups using the same naming convention (but instead of dlg prefix use gg prefix) and make them members of appropriate domain local groups

Global groups

Now, when you have all necessary groups created, you can start delegating tasks into appropriate Organizational Units. Select desired OU and run “Delegation Control” wizard

Start delegating tasks

Delegating task

add domain local group for appropriate task (for user management) in this example it is dlg-ou-finance-create-user and go further

Selecting appropriate group

in this step, please select “Create, delete, and manage user accounts” to allow user account management

Delegating rights

and finish wizard by clicking on “Finish” button

Closing wizard

So, user management is almost done on this OU, now we need to only allow resetting user passwords. Re-run “Delegating Control” wizard and add another group and grant this permission

Password reset group

from available options, please select “Reset user passwords and force password change at next logon

Reset password permission

and finish wizard. After you did that, user management for that OU is done. Repeat this action for each OU on whch you want to grant user management permissions (with its own domain local groups!).

Now, it is time to delegate tasks for group management. Pleas run wizard on an OU where you have groups to which you want to grant access and follow below steps

Delegating group management permissions

go to user/group selection and choose appropriate group to which you are delegating rights

Selecting group

and grant selected group required permissions

Granting permissions

and finish wizard. Now we need to only grant permissions to modify groups membership. Run wizard once again and follow below steps

Modify group membership delegation task

and assign permission selected on a screen below

Permission to modify group members

finish wizard and that’s all you needed to grant for user/group management. Repeat all above steps for another OUs to which you want to grant mentioned permissions for appropriate groups. Now, it’s time to handle HelpDesk role.

Create new global group named role-HelpDesk-it

HelpDesk role

put there all users who are working on that position and should have assigned appropriate permissions that you configured previously. Now, place role-HelpDesk-it global group into each domain local group to which you delegated tasks. When you do that, role-HelpDesk-it group member will have all required permissions on specified OUs.

HelpDesk role

From now, each time you add new user into role-HelpDesk-it group he/she will be able to:

  • create users
  • modify users
  • delete users
  • resete user passwords
  • create group
  • modify groups membership
  • delete groups

Active Directory Delegating Control ss really great option as you can see!

I hope that I was able to show you a way of delegating tasks instead of granting users “Domain Admins” membership to achieve some basic AD tasks πŸ˜€

You can simply try to use another delegation task in AD environment by yourself but remember, if you do not know what you are doing, do not touch productive environment. You can always test everything in test environment.

I wish you good luck and enjoy delegated tasks!

<<< Previous part

Author: Krzysztof Pytko


8 responses to “Active Directory rights delegation – part 2”

  1. George says :

    Hi Krzysztof,

    I enjoyed reading your post that clearly shows how to implement the concept of a delegating roles based tasks in Active Directory. I’ve always been a fan of delegating administration, because it helps reduce the number of Domain Admins, and that’s a good thing for security.

    The only challenge I have found is that once I have delegated roles/tasks, I find it very difficult to then go back and look at all the permissions in Active Directory and try to list who is delegated what access in the Active Directory.

    I recently came across a rather interesting discussion How to find out who is delegated what access in Active Directory and have been following it to see if there is any easy of doing the opposite of delegation i.e. finding out who is delegated what.

    You seem pretty experienced in delegation, so maybe you can share some thoughts on how you try to find out who is delegated what access in Active Directory?

    Thank you – I look forward to your thoughts.


    • iSiek says :

      Hi George,

      thank you for reading my blog πŸ™‚ and I’m sorry for delayed answer, I was on vacations πŸ˜€

      According to your question, there are several ways for that (described in the order of the most useful)…

      1) The best way for that is “Administrator’s documentation” where all users/groups are briefly described. That’s the most useful documentation which shows you all delegated permissions in a domain. In reality, I know how this looks like πŸ˜‰ and I know that documentation in many cases doesn’t exist πŸ™‚

      This is also very difficult evaluating delegated permissions without the documentation when you overtaking another environment. If delegated permissions documentation doesn’t exist then you need to follow one of below described methods

      2) Using 3rd party tool called LIZA. This is free tool allowing you to gather all necessary information about delegated permissions within a domain. This is really simply in use GUI tool which requires .NET 2.0 Framework, so it might be impossible to run directly on 2003 Domain Controllers. However, this allows you to run from any domain member machine with .Net 2.0 installed (let’s say your notebook πŸ™‚ ) Using this tool you can simply evaluate all delegated tasks to users/groups.

      I would really recommend this way if documentation doesn’t exist at all.

      LIZA can be simply downloaded from

      3) Another method to gather all required information is to use DSACLS command. But this requires scripting knowledge and received output requires much more work that using GUI tool. However, if you’re interested this way, please let me know directly on my e-mail (you can find it in “About me” tab) and I will try to help you using DSACLS command in script mode

      4) The least useful way but also working is to collect all information manually reviewing each container/OU in a domain over “Active Directory Users and Computers” console, documenting them during this action.

      All mentioned methods by me above you can also find described on Microsoft Technet page at


  2. Jason says :

    Hi Krzysztof,

    Why did you create all the gg (global groups)? You only used the dlg groups and the Helpdesk role global group to create that delegated set of rules. The global group named role-HelpDesk-it is a member off all the dlg groups you created. Where did the gg groups with the same names go?


    • iSiek says :

      Hi Jason,

      first of all, I’m really sorry for delayed answer. A lot of work and less time for blog answers.

      Going back to your question. That’s really good you pointed this out. I was using this group name convention due to single forest multiple domain environment where you are responisble for access management in entire forest.

      Normally, as Microsoft best practices you should always add user account into global group. Global group should be a member of universal group or in case that you are not using them, within domain local group(s).

      So, in this case all gg groups (global) are members of each dlg (domain local) with equals name after group scope. In example gg-group1 is a member of dlg-group1. This make sense in multiple domain environmnet whereas in single forest single domain it is not obvious because this structure might be unusefyl to you. This requires double number of groups.

      HelpDesk role is a global security group whihc is a part of domain local groups as granting user membership of that group, allows him all required privilages.
      As Microsoft states that global group should be a member of universal or domain local group, I placed the role group into domain local. I wanted to prevent global group nesting. Of course, if you need and you wish, you may use global group nesting and make that role group a member of of each gg global groups.

      I hope it is a little bit more clear now ?


  3. Scott says :

    I’ve done some delegation to our Helpdesk and have a question. I’ve only delegated the rights to unlock accounts and we’ve discovered that this works if they are using ADUC. If they try to use the newer AD Administrative Center, it does not work. Do you know why and how to fix this?

    • iSiek says :

      Hm, strange. Looks like Active Directory Administrative Center is using also another AD attributes. I will check that and I will let you know



Leave a Reply

Your email address will not be published. Required fields are marked *