Active Directory Permissions: Delete vs Move

I want our help desk to be able to move user accounts but NOT delete them. Here is the summary of our current permissions set on the affected OU's (this DOES allow them to delete user accounts):

  • Allow - Full Control - Descendant User objects
  • Allow - Create/Delete User objects - This object and all descendent objects

If I change that top row by editing the ACE and unchecking the "Delete" box, I get my desired result of the help desk being unable to delete user objects. However then they get Access Denied errors when they try to move users between OUs.

Is what I want possible? Does Microsoft seriously not distinguish moves versus deletions?


Solution 1:

Logically a "move" is a copy (or in filesystem parlance a hard link) followed by a delete: you can't move something if you can't remove it from its original location.

So no, Microsoft doesn't distinguish between "move" and "delete" because in order to do the former you must, by necessity, do the latter.

If you want to prevent accidental deletion of user accounts/objects within AD you can set them to "Protect object from accidental deletion" either manually on the Object tab of the user in ADUC:

enter image description here

or you can script it for every user object in AD all at once:

Get-ADObject -filter {(ObjectClass -eq "user")} | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Solution 2:

Voretaq7 has provided a good answer to your specific question (AD does not distinguish), but I do want to add that what you want is possible, depending on how much extra work you want to put in.

The methods to do this involve giving your help desk users specific, delegated permissions to perform functions with a service account that is higher-privileged than they are, without logging in directly as this service account.

All of them also involve being very careful with exception handling and allowed inputs so that your users can't provide unexpected input that exploits the higher privileges of the service account.

You could, for instance:

  • Have users log into a web page with a bunch of pre-cooked options like 'move a user' or 'disable an account'. Their input can then go off to your server and kick off an action by the service account (please don't include the function in the webpage code such that somebody could e.g. harvest the service account credentials by using 'view source'.)
  • Use powershell session configurations. These allow you to delegate one user or group rights to invoke specific commands as another user or group (much like Linux root delegation below). Move-ADObject is the cmdlet you're interested in here, again be careful the account you let them invoke as doesn't have excessive privileges (i.e. definitely not a domain admin because you don't want them moving your DC's around randomly!)

For reference, I believe linux has something similar to this with users having limited su privileges to do specific things with specific commands (I found several resources with a google for 'root delegation').