During our recent setup of Azure ADConnect for one of our Clients we've been getting permission-issue – Insufficient access rights to perform this operation error. While there are many articles on the Internet it's either outdated stuff for DirSync or trying to fix it by Enabling inheritance. The case we had was much simpler. During setup our administrator has chosen the AzureAD Custom Setup and when that happens no permissions are set for you on the Active Directory side. We knew where to look, we just didn't knew what permissions are missing from the setup made by one of admins.
If you check Synchronization Service Manager you can find recent status for all tasks.
While most tasks were ending up successfully export task completed with error: permission-issue. This can be from broken inheritance or due to synchronization of Domain Admins accounts which is not going to work. But in our case it was none of that. Any account you would create it would error out.
When you check documentation regarding permissions you need to setup the list is pretty clear.
| Feature |
Permissions |
| Password sync |
- Replicate Directory Changes
- Replicate Directory Changes All
|
| Exchange hybrid deployment |
Write permissions to the attributes documented in Exchange hybrid writeback for users, groups, and contacts. |
| Password writeback |
Write permissions to the attributes documented in Getting started with password management for users. |
| Device writeback |
Permissions granted with a PowerShell script as described in device writeback. |
| Group writeback |
Read, Create, Update, and Delete group objects in the OU where the distributions groups should be located. |
However when you compare it with what express setup uses when it setups account it has much wider scope of data. Following permissions are given to express account:
Replicate Directory Changes
Replicate Directory Changes All
Password sync
Read/Write all properties – User
Import and Exchange hybrid Read/Write all properties – iNetOrgPerson
Import and Exchange hybrid Read/Write all properties – Group
Import and Exchange hybrid Read/Write all properties – Contact
Import and Exchange hybrid Reset password
Preparation for enabling password write back
Having that knowledge in mind when you start comparing it with documentation data above one thing stands out – Read / Write All Properties for Users. It's nowhere on the list. And indeed if you add it to the list things start to work…
Actually after some testing just setting Write All Properties is enough.
It's interesting it's not on the list for permissions thou.
Following code is an easy way to give proper permissions for Office 365 Password Write-back on the domain side. The Out-null is left commented out so you can check out the output. If you don't like it, just add it back.
$passwordOU = "DC=DOMAIN,DC=COM"
$accountName = "DOMAIN\adconnect"
$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd #| Out-Null
$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd #| Out-Null
$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd #| Out-Null
$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd #| Out-Null
Following code is an easy way to give proper permissions for Office 365 Replicating Directory Changes on the domain side. While it's possible to do this manually, this way is much faster.
###--------variables
$Account = "DOMAIN\adconnect"
$RootDSE = [ADSI]"LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$ConfigurationNamingContext = $RootDse.configurationNamingContext
###---Update Attributes
#Object type: user
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes`";'"
Invoke-Expression $cmd
$cmd = "dsacls '$DefaultNamingContext' /G '`"$Account`":CA;`"Replicating Directory Changes All`";'"
Invoke-Expression $cmd