The Entra Cloud Sync agent ran successfully on two domain controllers for roughly eight months. After an internet outage, both agent services stopped and would no longer start, reporting "Error 5: Access is denied." The gMSA already appeared to have the expected Log on as a service and Log on as a batch job rights, and the agent folder permissions were checked as well. Adding the gMSA to the built-in Administrators group on the domain controllers immediately allowed the services to start, but that seems excessive and undesirable from a security perspective. Installing the same agent on a member server worked without any permission changes. Is there a domain-controller-specific behavior involving gMSAs, user-rights assignments, or Group Policy that explains the difference? What is the proper way to resolve this without making the gMSA a domain administrator-level account?
3 Answers
Entra Cloud Sync is supported on domain controllers, so the difference is usually the security policy applied to DCs rather than a change to how gMSAs work. Domain controllers receive separate Group Policy settings, and rights such as Log on as a service can be overwritten by a domain-controller policy. Check the effective policy on the affected DCs—not just the local security policy—and verify that the gMSA is included in the applicable user-right assignment. Also check for a Deny log on as a service or related deny assignment, because deny rights take precedence. After changing policy, refresh it and restart the service. The gMSA should only need the documented service rights and required file or registry permissions, not membership in the built-in Administrators group.
Even if the agent can run on a DC, a member server is generally the cleaner and safer placement for it. The successful member-server installation gives you a practical workaround and avoids granting broad privileges on a domain controller. If you need to investigate the DC behavior, compare effective GPOs, service logon configuration, and security-event logs around the time the service failed. An outage itself normally should not permanently change gMSA permissions, so a policy refresh, GPO change, or security baseline is more likely than a fundamental gMSA change.
Adding the gMSA to Built-in Administrators is a useful diagnostic clue, but it should not be the permanent fix. It indicates that the account is missing a required right or access permission, or that a restrictive policy is overriding the intended configuration. Remove that membership, identify the effective DC policy, explicitly grant only the required service-logon right to the gMSA, and confirm that no deny policy or GPO is removing it. If the organization does not specifically need the agent on DCs, keep it on the member server instead.
That also explains why the member server worked: it is receiving a different set of policies. Compare the Resultant Set of Policy for the member server and each DC, especially under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.