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?


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
| improve this answer | |
  • 2
    There's a nice summary of the necessary delegation parameters here: social.technet.microsoft.com/wiki/contents/articles/… – Evan Anderson Dec 2 '14 at 20:51
  • 1
    Wait, @voretaq7 just posted an answer to an AD question, then updated it to include a PowerShell example? I... I... +1 – jscott Dec 2 '14 at 22:51
  • 1
    @jscott TheCleaner added the powershell stuff & the "Protect against accidental deletion" (which didn't exist the last time I touched an AD thing) -- I just know that LDAP/AD moves are "Copy and Delete" actions :-) – voretaq7 Dec 2 '14 at 23:13
  • @voretaq7 Ah, apologies. I completely missed that in the mobile app. – jscott Dec 3 '14 at 9:56
  • This is as good of a compromise as I can get. I want to prevent intentional deletions, but hopefully this will discourage the lazier technicians. – Fëanor Dec 5 '14 at 1:48

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').

| improve this answer | |
  • I appreciate you suggesting some outside-the-box methods to make this possible. I tend to steer away from custom coding/web apps that I'm the only one who knows how to support, but the PowerShell sessions are definitely something I'll look into! – Fëanor Dec 5 '14 at 1:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.