Move disabled user from one OU to Target OU having access denied issue always

[Atiruveedula]

Hi all,

Offboarding automation in Flow Designer (Zurich), using the Microsoft Active Directory (ADv2) spoke. The final step moves the disabled user into an Archived OU. Every other AD action works fine (Disable User, Remove from Groups, Update User), but the move fails.

What happens:
Using the OOTB "Update Object OU" action with the user's full distinguishedName as the Object and the target OU as the Organizational Unit, the action finds the object and reaches the DC, then fails with:

Error: Access is denied
responseBody: { "body": "Access is denied", "status": "Error" }
Step Status: {"code":1,"message":"Error: Access is denied"}

What I've already ruled out:
- DN is correct - an earlier attempt with just the sAMAccountName gave "Cannot find an object with identity", but with the full DN the object IS found, so identity is fine.
- Not the action - my earlier custom PowerShell (Move-ADObject) action fails the same way.
- Not the account - I tested with the default ADv2 connection account AND a dedicated service account (both via the spoke), identical "Access is denied".
- The MID Server reaches the DC i assume; ports are open; it's a move (delete-from-source + create-in-destination), not a modify.

Can anyone confirm wat is the root cause and wat is the other alternative solution for this if i have to move the User from One OU to the target OU.

Environment: ServiceNow Zurich, on-prem AD via ADv2 spoke, MID Server.

Thanks!

[Vikram Reddy]

Hi @Atiruveedula,

This is an Active Directory permissions gap, not a spoke or MID Server problem. A move is really a delete-from-source plus create-in-destination under the hood (your screenshots confirm the account is svcaussnowadspk, and the failure is the same generic "Access is denied" whether it goes through Update Object OU or your custom Move-ADObject PowerShell), so the service account needs the delegated Create/Delete child object rights on both the source OU and the Archived OU, not just write access to attributes like memberOf or userAccountControl that the other actions use. Also check whether Protect object from accidental deletion is enabled on the user object itself or on either OU: that flag denies the implicit delete and throws exactly this error. Have your AD team run the Delegation of Control wizard on both OUs for that account (create/delete of User objects), confirm the protection flag, then retest.

References

• Move-ADObject : Access is denied
• Microsoft Active Directory Spoke

Thank you,
Vikram Karety
Octigo Solutions INC