I was working with a client earlier this week who had brought in a security company to tighten up their infrastructure because they were a victim of a major hack just before we were brought in. That security company did a number of things to user accounts we found… odd, and that turned out to cause errors in our customers Azure Entra Connect Sync service.
When we investigated, we foul Azure Synchronization Service Manager had about 20 sync failures. All of them were Insufficient access rights to perform the operation
.
The Insufficient access rights to perform the operation
is simply telling you that the on-prem Active Directory account the Azure Synchronization Service Manager created during install (without tell you!), does NOT have access to the users in question.
As you can see in the screenshot above, the solution is just to add the MSOL account to have READ and WRITE permissions on each of the problematic user accounts. We did this via the GUI because there were only a few users to correct, but we could have used a simple PowerShell script:
$user = "CN=John Doe,OU=Users,DC=example,DC=com"
$acl = Get-ACL -Path "AD:$user"
$acl.Access | Where-Object { $_.IdentityReference -eq "DOMAIN\MSOL_<hex-digits>" }
That gets to two questions:
The MSOL account (e.g., MSOL_hex-numbers) is a service account created during the installation of Azure AD Connect. This account is used to manage and synchronize objects between your on-premises Active Directory and Azure Active Directory.
The hex part of the username after MSOL_ (e.g., MSOL_827c9e7b0924) is a unique identifier generated during the installation of Azure AD Connect:
That account NEEDS specific permissions to read and write information to your Active Directory, ensuring that changes made on-premises are correctly reflected in Azure AD. It plays a fundamental role in the synchronization process, handling tasks such as password synchronization, group membership updates, and attribute changes
In our clients case we found it most odd that there were just a few of these strange accounts that needed the MSOL read and write permissions added. But then we step back and look at the list and realize that most of them were in just two or three Organizational Units (OU’s). We went to those OU’s, right clicked on the name, selected PROPERTIES, then the SECURITY tab, and added the MSOL_xxxxx account there.
We then:
Start-ADSyncSyncCycle -PolicyType Delta
After some more investigating, we found the security company that had been brought in, had disabled security INHERITANCE from the OU to some of the users. This was an annoying surprise, the client was happy for us to undo.
To enable inheritance on the security of an Active Directory (AD) user object, follow these steps:
Win + R
, type dsa.msc
, and press Enter to open ADUCWe then forced another Azure Entra ID Sync and found no more errors.
This website uses cookies.