none
Delegate control Move user Objects from one OU to another OU RRS feed

  • Question

  • how do i Delegate control for an OU so that members of a group that has been delegated control and move user accounts/objects from one OU to another?
    I can delegate control for users and groups but can't seem to be able to delegate control in a way that allows me give admins rights to move them from OU to OU
    Systems is Windows Server 2008 Active Directory.

     

    Saturday, January 21, 2012 10:55 AM

Answers

  • Yes, that's more like the two-way move I'd mentioned before. The downside to the linked solution is that you're also allowing the delegated users to re-write the values of the user object - which may not comply with business process (i.e. the Helpdesk changing personal phone numbers, etc). It's kind of a catch-all for specifically allocating the rewriting of the three attributes required for a move:

    • distinguishedName (Distinguished Name)
    • rdn (name)
    • cn (Name)

    Purely as an observation, it strikes me as a little odd that ADUC even attempts to rewrite the rdn and cn, since neither are changing in a move. When using LDP, the only attribute you need to modify is literally the distinguishedName.

    Cheers,
    Lain


    • Edited by Lain Robertson Monday, January 23, 2012 9:22 AM Added an example of business logic
    • Marked as answer by Bruce-Liu Tuesday, January 31, 2012 2:05 AM
    Monday, January 23, 2012 9:21 AM

All replies

  • Hi Ammad,

    There's two rights that usually need to be delegated in order to move an object from one OU to another:

    • Create <specific object type, or all children>
    • Delete <specific object type, or all children>

    The right solution depends on your exact requirement. Let's say you have two OUs, which we'll refer to as OU1 and OU2. You can set the delegation up to allow the movement of users in either direction (two-way) or only from one OU to the other (one-way).

    Two-way delegation:

    This is the easiest option and the result is that the delegated user can move the specified objects from either OU to the other. Specify the following permissions on both OUs:

    • Right-click the OU -> Permissions -> Advanced button -> Add button
    • Select the user or group you with to delegate the new permission to -> OK button
    • Change the "Apply to" drop-down list to "This object only" - unless you want them to be able to manage objects in sub-OUs as well
    • Based on your initial question, tick the "Create User objects" and "Delete User objects" options, or if you don't want to get that specific, you can tick the "Create all child objects" and "Delete all child object" options
    • Click the OK button twice to confirm your changes

    One-way delegation:

    If you wanted to tighten up the security a little and only want your delegates to move objects specifically from OU1 to OU2, or vice-versa, then you will want to follow these steps:

    • On the source OU: right-click the OU -> Permissions -> Advanced button -> Add button
    • Select the user or group you with to delegate the new permission to -> OK button
    • Change the "Apply to" drop-down list to "This object only" - unless you want them to be able to manage objects in sub-OUs as well
    • Based on your initial question, tick the "Delete User objects" option, or if you don't want to get that specific, you can tick the "Delete all child object" option

     

    • On the destination OU: right-click the OU -> Permissions -> Advanced button -> Add button
    • Select the user or group you with to delegate the new permission to -> OK button
    • Change the "Apply to" drop-down list to "This object only" - unless you want them to be able to manage objects in sub-OUs as well
    • Based on your initial question, tick the "Create User objects" option, or if you don't want to get that specific, you can tick the "Create all child object" option

    You can mix the delegated perimissions and scopes as you see fit, but this at least provides two ways for you to consider.

    Cheers,
    Lain


    • Edited by Lain Robertson Saturday, January 21, 2012 11:16 AM Formatting change
    Saturday, January 21, 2012 11:15 AM
  • Hi Lain,

    Previously i was using the "Delegation control wizard", but it was not working.

    Now i remvoed all permissions and then i did "One way delegation" but still its "Access is denied"

     

    i am using AD-Remote admin tools on Windows 7.

     

    thanks,

    Saturday, January 21, 2012 11:51 AM
  • Hi Ammad,

    When you say removed all the permissions, you just mean from the delegated groups, right? You didn't remove all permissions?

    In the destination OU, have you tried creating a new user as a test? Obviously testing the source OU is a bit harder, since you don't want to delete a user - unless you create a test user there first as well with another administrative account.

    I'll go and double-check the process myself, as I wrote up the above from memory, so maybe I've overlooked a particular right.

    Using ADUC remotely is fine, so there's nothing to worry about there.

    Cheers,
    Lain

    Saturday, January 21, 2012 12:11 PM
  • Hi Lain,

    Permissions i remvoed was delegated groups right.

    I can create the users in Destination OU, and also can modify the user in source OU, but when i try to move it to destination OU, (That OU is Child OU ) it gives me access denied.

    source ou = A-OU

    destination ou  = B-OU  ( This is the Child-OU of A-OU).

     

    Permissions are set to this object and Child objects.

    Saturday, January 21, 2012 12:16 PM
  • Yes, that's may fault. It's been a while since I actually did this as part of setting up role-based delegation. I've just revisited the topic and have the relevant attributes.

    You are going to need to use AdsiEdit.msc for this, as ADUC (dsa.msc) does not expose one of the required attributes.

    • In Adsiedit, connect to the default naming contect, then browse to the source OU
    • Right-click the OU and choose Properties, then the Security tab, then Add button
    • Select the Properties tab
    • Choose the group you wish to delegate the rights to
    • Change the "Apply to" to "Descendant User objects"
    • Tick the "Write Distinguished Name" checkbox
    • Scroll down and tick the "Write name" checkbox - note this is the lowercase version of "name"
    • Just below that, tick the "Write Name" checkbox - note this is the uppercase version of "Name"
    • Click the OK button three times to accept the changes

    Although this screenshot doesn't show the detail, it should give you a feel for what you should be seeing after the changes from the first post and this are complete.

    You should now be able to move the user objects one-way.

    Keep in mind you would have to apply the same three ACEs to the destination directory if you wanted to be able to move users in both directions.

    Cheers,
    Lain

    Saturday, January 21, 2012 1:55 PM
  • Hi Lain,

     

    I am very sorry, i am unable to find "Write Distinguised Name", can you please send a snap

     

     

    thanks

    Saturday, January 21, 2012 9:29 PM
  • Hi Ammad,

    Please remember, this is with AdsiEdit. You won't see this option under ADUC.

    Cheers,
    Lain

    Saturday, January 21, 2012 9:49 PM
  • Hi Lain,

     

    Thanks for continoues support,

    i did all these steps but the problem is still there,

    Again i removed group from the delegation control.

    and performed the following steps

    1. One-way delegation:

    2. ADSI

    Sunday, January 22, 2012 6:27 AM
  • Hi Ammad,

    Below is a table of the five rights you need to assign. There is only one you need to assign to the source OU, while there are four that need to be assigned to the destination OU.

    Just use AdsiEdit for the whole process.

    I took the time to double-check the ACLs step-by-step from scratch, and as expected, the member of the test group progressed from Access Denied to successfully moving the account.

    Delegation target Permissions Tab Group Apply to Permission
    Source OU Object Delegated group This object only Delete User objects
    Source OU Properties Delegated group Descendant User objects Write Distinguished Name
    Write name
    Write Name
    Destination OU Object Delegated group This object only Create User objects

    Cheers,
    Lain

    • Edited by Lain Robertson Sunday, April 2, 2017 11:16 PM Fixed table.
    Sunday, January 22, 2012 1:02 PM
  • Hi,

     

    Here is a similar thread in which we discussed moving computer objects between OUs.

     

    Delegate Control of an OU

     http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/f1d6d833-f3d1-4ef9-a717-1f685e99b1a2/#a27472ee-b7a4-4f2c-90c8-2048a98d696b 

     

    Hope it helps.

     

    Regards,

    Bruce

    Monday, January 23, 2012 8:51 AM
  • Yes, that's more like the two-way move I'd mentioned before. The downside to the linked solution is that you're also allowing the delegated users to re-write the values of the user object - which may not comply with business process (i.e. the Helpdesk changing personal phone numbers, etc). It's kind of a catch-all for specifically allocating the rewriting of the three attributes required for a move:

    • distinguishedName (Distinguished Name)
    • rdn (name)
    • cn (Name)

    Purely as an observation, it strikes me as a little odd that ADUC even attempts to rewrite the rdn and cn, since neither are changing in a move. When using LDP, the only attribute you need to modify is literally the distinguishedName.

    Cheers,
    Lain


    • Edited by Lain Robertson Monday, January 23, 2012 9:22 AM Added an example of business logic
    • Marked as answer by Bruce-Liu Tuesday, January 31, 2012 2:05 AM
    Monday, January 23, 2012 9:21 AM
  • Hi,

    Short update on this topic. For me the moving of the users was not working until i didn't checked Delete option on the Descendant user objects. So the configuration at the end was:

    Delegation target Permission tab Group Apply to Permission
    Source/Destination OU Object Delegated group This object and all child objects Create/Delete user
    Source OU Object Delegated group Descendant User objects Delete user
    Source/Destination OU Properties Delegated group Descendant User objects Write cn
    Source/Destination OU Properties Delegated group Descendant User objects Write name
    Source/Destination OU Properties Delegated group Descendant User objects Write distinguishedName            

    Cheers,
    Darko



    Wednesday, March 14, 2012 10:34 AM
  • Hi,

    one more update - for Windows 2008 R2 DCs: I tried to reduce the rights beginning with the table above until the point where I cannot remove a single right without disabling the possibility to move. In my eyes this is the least required rights list then and it leads me to the following rights table:

    Tool

    OU

    Permission tab

    Apply to

    Permission

    AD Users & Computers

    Source

    Object

    This object only

    Delete User objects

    AD Users & Computers

    Destination

    Object

    This object only

    Create User objects

    ADSIEDIT

    Source

    Properties

    Descendant User objects

    Write name

    ADSIEDIT

    Source

    Properties

    Descendant User objects

    Write Name            

    Everything else was not required during my tests. In the end it sounds partly logical for me, cause I'd expect the Properties to be written either before of after the move, but not twice. Interestingly the CN changes in fact, although the user does not have the granted right to change it. Maybe this is always calculated from the position of the object?

    Regards,

    Tobias

    Wednesday, June 6, 2012 9:54 AM
  • Hello,

    Unfortunatly the delegated user has the ability to delete any user account. It's posible restrict more this permission?

    Regards,

    Pedro

    Friday, February 1, 2013 11:10 AM
  • Hi,

    one more update - for Windows 2008 R2 DCs: I tried to reduce the rights beginning with the table above until the point where I cannot remove a single right without disabling the possibility to move. In my eyes this is the least required rights list then and it leads me to the following rights table:

    Tool

    OU

    Permission tab

    Apply to

    Permission

    AD Users & Computers

    Source

    Object

    This object only

    Delete User objects

    AD Users & Computers

    Destination

    Object

    This object only

    Create User objects

    ADSIEDIT

    Source

    Properties

    Descendant User objects

    Write name

    ADSIEDIT

    Source

    Properties

    Descendant User objects

    Write Name            

    Everything else was not required during my tests. In the end it sounds partly logical for me, cause I'd expect the Properties to be written either before of after the move, but not twice. Interestingly the CN changes in fact, although the user does not have the granted right to change it. Maybe this is always calculated from the position of the object?

    Regards,

    Tobias

    This works.

    As a side note - this may be for 2012 as well, maybe you just didn't see it, but you do not need to add the 'write name' and 'write Name' permissions in ADSI edit.  You can do it thorough the advanced security tab and just find it in the huge (yet alphabetical) list.

    Tuesday, January 9, 2018 8:25 PM