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.
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: