Access Denied when trying to delete users from Active Directory using Remove-ADUser RRS feed

  • General discussion

  • Hey all,

    I'm experiencing some real weird behavior using the Remove-ADUser cmdlet to delete users from AD.  Basically what I'm finding the majority of the time the script fails with the below exception, although I was actually able to get it to work once or twice without altering any of the code!  The same behavior occurs when using Remove-ADObject.

    Remove-ADUser : Access is denied
    At D:\Operational Scripts\Operations - Delete AD Users.ps1:61 char:13
    +             Remove-ADUser -identity $person.distinguishedName -Confir ...
    +             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : PermissionDenied: (CN=TestUser...C=contoso,DC=com:ADUser) [Remove-ADUser], UnauthorizedAccessException
        + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.UnauthorizedAccessException,Microsoft.ActiveDirectory.Management.Commands.RemoveADUser

    The account I'm using to execute the script has been delegate rights to delete users from AD.  Also, when log in to ADUC using the same account I'm able to delete users just fine.  I have tried running the script in PowerShell Admin mode yet this does not make any difference.  

    Has anyone else ran into this behavior?  Thanks in advance for any input!


    • Changed type Bill_Stewart Monday, July 29, 2019 7:23 PM
    • Moved by Bill_Stewart Monday, July 29, 2019 7:24 PM Not a scripting question
    Wednesday, August 1, 2018 8:01 PM

All replies

  • Objects that are protected from deletion cannot be deleted until the prot4ection flag is removed.


    Wednesday, August 1, 2018 9:21 PM
  • Relevant link for protection from accidental deletion:


    In most cases an admin manually removes the protection, then deletes the object. If you need to remove the protection in bulk, this script can help:


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Wednesday, August 1, 2018 10:15 PM
  • Thanks for the reply. Unfortunately, the objects I'm trying to delete does not have the protect flag checked, nor are they objects that are protected by the adminSDholder.  These are standard, Domain User accounts.
    Thursday, August 2, 2018 1:26 PM
  • That means your account does not have delete permission on those objects.  Just delegating the OU to a user does not account for the permissions on existing objects unless it is delegated to propagate correctly.


    Thursday, August 2, 2018 1:43 PM
  • After re-reading your original post, I only have one idea. Perhaps your permissions have not replicated to all DCs. If a script fails to delete an object, then later succeeds, maybe you were connected to a different DC. Maybe use ADREPLSTATUS or Repadmin to troubleshoot.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, August 2, 2018 1:48 PM
  • Yes.  Replication problems can cause this to happen but on 2012 and later the replication for this should be immediate and errors would show in the event logs.

    Running REPLSTAT would be a good next step.  Most often I have found that delegation was wrong or incomplete.  I know this because I have done it to myself more than once.  So check that too.


    Thursday, August 2, 2018 1:53 PM
  • Replication is working fine, and just to rule it out I elevated the service account to Account Operator yet the script is still failing.  Also, when I inspect the ACLs on the individual user objects that are being targeted for deletion my service account has "full control".  I'm at a loss...
    Thursday, August 2, 2018 3:56 PM
  • Are you running the command directly on a domain controller? (If that's the case, you may need to use an elevated window.)

    In any case, If it worked part of the time, and you are sure your command is correct, then you don't have a scripting issue and the cause lies elsewhere.

    -- Bill Stewart [Bill_Stewart]

    Thursday, August 2, 2018 4:10 PM
  • Service accounts are restricted by design.  They are a security precaution and have many limitations.

    Mark the accounts for removal by disabling them and moving to n OU.  I have one "Accounts to be Deleted".  I can then log in and delete them periodically.  There is no need to delete immediately and the service account can alter attributes.

    Also see: https://docs.microsoft.com/en-us/windows/desktop/AD/access-control-and-object-deletion


    Thursday, August 2, 2018 4:10 PM
  • If it worked part of the time, and you are sure your command is correct, then you don't have a scripting issue and the cause lies elsewhere.

    -- Bill Stewart [Bill_Stewart]

    Assuming all of the objects are in the same OU.  We still haven't heard the replication report results.

    Picking a known server would work.  I am not sure what the error is if you pick an RODC and no writable DC is available.


    Thursday, August 2, 2018 4:13 PM
  • Thanks guys for all the input- I found that once I modified the script to execute against a different DC it worked fine.  What's odd is the replication report looks fine during this entire time, so it must just be the ACLs/delegations that are not replicating currently.  I'm going to open a case with Microsoft for further investigation!
    Thursday, August 2, 2018 6:04 PM
  • It can also be that Kerberos is not working on one or more DCs.  Check the clocks on all DCs and the workstation involved.  Also network issues can cause a failure.  If you have RODCs then be sure they are working and configured correctly as the request for a write should never be handled by an RODC.


    Thursday, August 2, 2018 6:10 PM