The "permission-issue" error with error code 8344 in Azure AD Connect can have two causes. One is not directly an error but more of a security precaution, the other actually has to do with permissions.
The error looks like this:
Reason 1, Security (Administrator)
I haven't seen this reason officially anywhere yet, but I've already encountered it in two new environments. Users that were in the "Domain Administrator" or "Enterprise Administrator" group were not synchronized and displayed with error 8344.
Of course I didn't mind! Because users with administrator rights in the local domain should only be used there. There is no reason to also use them in Azure AD with possibly even admin rights there.
In this case it is either to remove the users from the group or to move them to an unsynchronized OU.
Reason 2, AD permissions
If it is not the first reason, the "permission-issue" error (8344) in Azure AD Connect usually occurs after activating "Password Sync" or when changing the sign-in options. This is because the service account you specified or was automatically created in an earlier step does not have the correct/necessary permissions.
You can supplement/check the authorizations as follows:
- Right-click on the domain forest (e.g. ad.scloud.work)
- Ensure the permissions of the service account in the Security Tab via Advanced:
(Automatically generated and named MSOL_randomID)- Replicate Directory Change
- Replicate Directory Changes All
- change password
- reset password
- If authorization inheritance is switched off on an OU, these must also be assigned there.
- Ready
Permission reference: Azure AD Connect: Accounts and permissions - Microsoft Entra | Microsoft Learn
You can also "simply" put the user in the domain admin group, then it will also work. But don't do this!
Since version 1.4.x, such an account (domain or enterprise admin) can no longer be stored during setup.
In the permission reference I don't see the permission "Change Password", is this still correct? But I tried both soluctions and none of them worked. Do you have any other ideas?
Yes, that is still correct.
Automatically generated heist MSOL_randomID. What does this mean?
Oh, that should be: Automatically generated and named MSOL_randomID
Hi Florian, I got this problem with only 1 account transferring old adconnect server to a new one.
I've tried to apply your "Reason n. 2" by adding "change password" permission to the MSOLxxx account (the only one missing from permissions tab) using descendant user objects as "applies to".
But the adsync still reports "error 8344", always for that account.
Is there something that I can do about?
Is the account in an isolated OU? If so, does it work with others in that same OU?
The account was in a created OU, together with other more than 2500 accounts. Solved by enabling inheritance just for that account. MSOLxxx account appeared in security tab just as MSOL permissions in advanced. But as soon as the first sync was successfully done, both MSOL account and permission disappeared from security/advanced tab even if the adsync goes on with no errors.
Weird, isn it?