Grant permission in Active Directory to add users / modify / changed password / add them to group them but not delete them

Question

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?

Solution

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.

Comments

[Zoredache]

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?

[MadBoy]

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.

[HostBits]

That's what backups are for. Also, in Server 2008 R2 you can protect your objects from accidental deletion.

[Zoredache]

Well if you are concerned you can enable the Recycle bin. technet.microsoft.com/en-us/library/dd392261(WS.10).aspx

[MadBoy]

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]

@Zoredache we do have that enabled. Still the question is vital for me.

[raja]

You can do this by mucking about with AD permissions, but don't- you'll break something else and more importantly there is some junior admin that decides they need to delete something and can't so they start playing with fire on your production AD, just enable the recycle bin and call it done, technically once that's enabled nothing is deleted (since the new deleted attribute is isrecycled - isdeleted now lets you know it's in the bin)

[raja]

also given the scenario you described, setting the perms as requested might also make all OUs permanent

[raja]

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)

[HostBits]

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.

[MDMarra]

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.

[HostBits]

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.

[MDMarra]

@Cheekaleak It would be best practice to delegate Modify to only the attributes that you need Modify on to complete the requested task. There are many links on technet detailing AD attributes and permissions, it's more a matter of the OP taking the time to read it than anything else. Say, for example, you make this group that has Deny to delete for your whole AD tree. Then a user is a member of a different group that should be able to delete very specific things. Because of how the ACLs will be evaluated, you'll get access denied. This is why Deny is bad and should almost never be used.

[Greg Askew]

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.

[MadBoy]

The Write all properties settings affects this change right?

[Greg Askew]

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.