5

I would like to add delegate user ability to:

  • add new users to container
  • change password
  • modify group membership
  • modify users properties (such as email / name etc)
  • move users between OU's

Basically user will be able to do most things with account besides deleting it. I tried using Delegation of Control Wizard but the common tasks are too wide (usually including Delete part) so I need to go into custom task to delegate.

This are the options that I selected:

  • Only the following objects in the folder (User objects)

But the last permissions page is very wide and I wouldn't like to give user too much power. Can anyone share which options are necessary for the specified question? And as an extension to this write what each option means and what power it assigns?

8
  • 1
    Why don't you want to permit deletes? If someone can modify user properties then they can already trash existing accounts. Do you want them to submit a request to you whenever a person leaves?
    – Zoredache
    Dec 1, 2011 at 17:50
  • We never delete accounts for future reference of their time sheet and SharePoint history. And I worked for a company that gave guys from Helpdesk full Domain Admins.. and one day the whole City container vanished. Imagine yourself 600 accounts getting deleted :-) Shit does happen. I want to prevent it.
    – MadBoy
    Dec 1, 2011 at 17:54
  • 2
    That's what backups are for. Also, in Server 2008 R2 you can protect your objects from accidental deletion.
    – HostBits
    Dec 1, 2011 at 17:58
  • Well if you are concerned you can enable the Recycle bin. technet.microsoft.com/en-us/library/dd392261(WS.10).aspx
    – Zoredache
    Dec 1, 2011 at 17:58
  • We do backups and we protect objects from accidental deletion. However since I was asked to not give delete rights I prefer to do so. As for the other company, Lets just say that company had problems finding "working backups".
    – MadBoy
    Dec 1, 2011 at 17:59

2 Answers 2

5

To delegate permission for a domain user to:

  • add new users to container
  • change password
  • modify group membership
  • modify users properties (such as email / name etc)
  • move users between OU's

I had to create 2 groups as Delegation Wizard wouldn't let me specify what to choose on each User object when I choose more then User object. So I decided to create 2 groups. One for user management and one for group management.

First one required this steps:

  • Right click on container and choose Delegate Control
  • When Delegation Wizard opens up click Next
  • On another page choose group you want to give permissions to and press Next
  • On next page Create a custom task to delegate and choose Next
  • Choose Only the following objects in the folder and go to the bottom of the list and choose User objects. Choosing anything more then just one entry will not give you possibility of granular choice of properties to change.
  • Make sure to have Create selected objects in this folder checked and press Next
  • Choose:

    • Read All Properties
    • Write All Properties
    • Read and write general information
    • Read and write logon information
    • Read and write phone and mail options
    • Read and write web information
    • Read and write Terminal Server license server
    • Read and write remote access information
    • Change password
    • Reset password

This allows to create user and enable / disable user but not delete it. At this moment user isn't able to change group membership as this has to be done differently.

3
  • FYI - the userAccountControl attribute controls a lot of the security-critical account features (disabling, smartcard, delegation, encryption). If you do not want this group to modify these features, you would need an ACE to deny write for descendant user objects for the userAccountControl property on the OU where the permission is granted for the user objects.
    – Greg Askew
    Dec 1, 2011 at 19:42
  • The Write all properties settings affects this change right?
    – MadBoy
    Dec 1, 2011 at 19:52
  • Correct. I mention this because Write All Properties may inadvertently confer a higher level of permissions than you intended. We actually use that deny acl on our "Users" sub-OU's, because we need to to disable accounts to conform with regulatory requirements (and be assured that they are not re-enabled), and we have some accounts that may be sensitive and should not be delegated. UserAccountControl is the property that controls these security-sensitive functions.
    – Greg Askew
    Dec 1, 2011 at 20:33
0

You should take a look at the available ACEs on the user objects and delegate what you need, minus the Delete ACE.

Although, it is still better practice to only give these types of rights to people you can trust to not delete your objects. There certainly will be accidents, but as I mentioned before, there are backups and other ways (prevent accidental deletion, AD recycle bin) to recover from those.

6
  • Someone want to explain the down vote? If something is technically incorrect I'm happy to correct it.
    – HostBits
    Dec 1, 2011 at 18:20
  • I didn't downvote but I would not recommend changing perms on a default group - create a new one if you want to do that (if this works I haven't thought that far ahead yet)
    – Jim B
    Dec 1, 2011 at 18:24
  • No, I would agree that changing permissions on a default group would be a bad idea. My thought was more to create a specific group with the delegated users, and set the deny permission to THAT group. I also think doing this at all is a bad idea.
    – HostBits
    Dec 1, 2011 at 18:26
  • 2
    I would guess that it's because it's not best practice to use a Deny ACE in place of properly researching what needs to be granted. There's no reason to use a Deny here other than being too lazy to research what you need to allow and granularly granting modify to just those attributes.
    – MDMarra
    Dec 1, 2011 at 18:27
  • But it is a Deny to only user objects and only to deleting the object. Would it be more "best practice" use a specific group and give them the same rights as Account Operators, minus the delete ACE.
    – HostBits
    Dec 1, 2011 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .