Here’s another interesting one. I suppose this is one of the reasons why we should be careful not to install AAD Connect on a domain controller.
I needed to sync a few newly created AD users but when I opened AAD Connect the following message popped up…
As it turns out, the associated service “Microsoft Azure AD Sync” wasn’t running.
And, the service failed to start with “Error 1069: The service did not start due to logon failure“.
The associated “AAD_” account permissions were confirmed and an attempt to start the service resulted in the same error.
The next step was to restart the server that AAD Connect was installed on. But again, AAD Connect had the same error and the service would not start.
After removing and reinstalling AAD Connect, then restarting the server, the same errors occurred.
Next, AAD Connect was removed manually and reinstalled. This time, after restarting the server, AAD Connect functioned normally.
However, after some time had passed, the same errors occurred again.
I decided to look to the “Log on as a service” setting in the Local Security Policy and sure enough the “AAD_” account (or any group it was a member of) wasn’t one of the assigned users. In fact, the “Log on as a service” setting was being managed by group policy and none of the default accounts were assigned (i.e. “NETWORK SERVICE” and “NT SERVICE\ALL SERVICES”).
After receiving permission from the customer, the “Log on as a service” setting in the “Default Domain Policy” was updated to include the appropriate accounts.
NOTE: “Log on as a service” group policy setting is found under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
Once the group policy was updated, “gpupdate /force” was run from the Command Prompt to apply the new changes to the affected server.
Finally, the “Microsoft Azure AD Sync” was able to start without further issue and AAD Connect was able to be opened.
Related Articles in this Blog:
Reference(s):
“After receiving permission from the customer, the “Log on as a service” setting in the “Default Domain Policy” was updated to include the appropriate accounts.”
I have same error, I added the AAD account as you described, but no other. You say “included the appropriate accounts” can you state specifically which other accounts. I add the AAD account only. Thanks
“NETWORK SERVICE” and “NT SERVICE\ALL SERVICES”
Would changing the local user (AAD_*) used for the service to a domain user with “log on as a service” access work ? Our sysadmin here prefer to user domain user when possible. I tried that and the service did not start “in a timely fashion” (as in did not work at all).
It should however one thing to understand is that the Default Domain Policy group policy in this specific scenario had been modified and wasn’t working with any user account we tested with until the GPO was reset to its default settings and applied to the server hosting AAD Connect; as described in this article.
If a service account is going to be used for the ‘Microsoft Azure AD Sync’ service, keep in mind that it only needs to be a domain user and must be a member of the domain ‘ADSynAdmins’ domain group. That group is not a member of any privileged groups such as Domain Admins, Enterprise Admins or Schema Admins.
Hope that helps to clarify your question.
The default domain policy does not apply to domain controllers. This change will need to happen to a group policy object applied directly to the domain controller OU or even specifically to the domain controller in question. It would be recommended to make a new policy object and not reuse any of the ‘defaults’
I respectfully disagree as this is not the only time I’ve had to address and resolve this issue for customers.
Thanks for this information! The same thing happened in our environment, although I’m not sure why it suddenly happened.. I added the AAD service account to the default domain controller policy and the issue was resolved.