Intune Connector for AD fails with SeLogonAsServicePrivilege when you bring your own gMSA

You install the updated Intune Connector for Active Directory, point it at a group managed service account (gMSA) your AD team created for you, and the configuration fails with a SeLogonAsServicePrivilegeMissing error even though the account clearly has the "Log on as a service" right. In June 2026 Microsoft documented this as a known issue and shipped an opt-in switch in connector build 6.2604.2000.3. In this post I'll cover the documented cause and fix, how the connector's service account model works, and how to check connector health before and after.

Symptoms#

• You're configuring the connector with the TenantConfiguredManagedServiceAccount key set to your own gMSA, rather than letting the connector create its msaODJ##### account.
• Enrollment or configuration of the connector fails. The connector UI or its setup logs contain an entry similar to the example Microsoft publishes, often surfaced as a SeLogonAsServicePrivilegeMissing configuration error:

System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn, SafeAccessTokenHandle& safeTokenHandle)

• The gMSA does have Log on as a service assigned, typically through a GPO or a local group, and often the same configuration works if you simply try again later.

Why it happens#

According to Microsoft, before enrollment the connector runs a pre-check that validates the SeLogonAsServicePrivilege right for the service account. Internally that check performs a Kerberos Service-for-User (S4U) logon of the gMSA, which is the KerbS4ULogon call in the error. The failure occurs when the right has been assigned to the gMSA but hasn't yet propagated to the connector host at the moment the validation runs. In other words, the configuration is correct; the check is just early.

It helps to know what the connector expects from a custom account, all of which is on the hybrid join page:

• The account must be a gMSA or a standalone MSA in the same domain as the connector server, referenced as account@domain.
• It must be installed on the connector host (Install-ADServiceAccount), and for a gMSA the host must be allowed to retrieve the password.
• It needs the local Log on as a service right, granted directly or through group membership.
• Create-computer-object permissions on the target OUs must be granted manually, and using your own account disables the connector's OU updates, so Microsoft tells you to add DisableOUUpdates set to true.

How to tell it apart from the other connector errors#

The known issues page also lists, for build 6.2501.2000.5, the error Cannot start service ODJConnectorSvc with "The service did not start due to a logon failure" after the MSA is created. That one means the service genuinely can't run as the account, and Microsoft names group or local policy restricting Log on as a service as a cause. The practical difference: if a GPO defines "Log on as a service", it replaces any locally granted entries, so an account that was added locally loses the right at the next policy refresh. Check gpresult /h C:\gp.html on the host and open User Rights Assignment. If the gMSA is absent from the effective policy, fix the GPO; the skip switch below won't help. If it's present and you still fail during the pre-check, you're looking at this known issue.

How to fix it#

1. Confirm the gMSA is ready on the host. In an elevated PowerShell session on the connector server:
   PowerShell

   Install-ADServiceAccount -Identity gmsaODJ
   Test-ADServiceAccount -Identity gmsaODJ
   Get-ADServiceAccount -Identity gmsaODJ -Properties PrincipalsAllowedToRetrieveManagedPassword

   Test-ADServiceAccount must return True, and the host (or a group it's in) must appear in the password-retrieval principals.
2. Install build 6.2604.2000.3 or later. Download ODJConnectorBootstrapper.exe from Devices › Windows › Enrollment › Intune Connector for Active Directory › Add in the Microsoft Intune admin center. Connector versions older than 6.2501.2000.5 are deprecated and no longer process requests, so a legacy connector must be uninstalled first.
3. Add the switch to the configuration file. Open C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard\ODJConnectorEnrollmentWizard.exe.config and inside <appSettings> make sure you have:
   XML

   <add key="TenantConfiguredManagedServiceAccount" value="gmsaODJ@contoso.com" />
   <add key="DisableOUUpdates" value="true" />
   <add key="SkipByoMsaPrivilegeCheck" value="true" />

   The default for SkipByoMsaPrivilegeCheck is false, so the pre-check keeps running unless you add the key explicitly. Microsoft says the connector writes a trace line confirming the skip and then proceeds with configuration.
4. Restart the configuration. Open Intune Connector for Active Directory from the Start menu, go to the Enrollment tab and select Sign In with an Intune administrator account that has an Intune licence. The account is only needed at enrollment time.
5. Grant the OU permission by hand. Because OU updates are disabled, delegate Create Computer objects on the target OU to the gMSA in Active Directory Users and Computers (Object Types must include Service Accounts). Without it the account hits the default limit of 10 domain joins.

Verify the fix#

• The Enrollment tab shows the connector as enrolled and Sign In is greyed out.
• On the server, Get-Service ODJConnectorSvc reports Running, and in Services the Log On As column shows your gMSA.
• In the admin center, Devices › Windows › Enrollment › Intune Connector for Active Directory lists the server as Active with version 6.2604.2000.3 or later. It can take several minutes to appear; inactive connectors are cleaned up automatically after 30 days.
• The connector's event logs under Applications and Services Logs › Microsoft › Intune › ODJConnectorService (Admin and Operational) show no errors after a test hybrid join deployment, and the new computer object appears in the expected OU.

Prevent it next time#

• Assign Log on as a service to the gMSA through the same GPO that governs the connector servers, run gpupdate /force on the host, and wait for replication before you start the wizard. Then you may not need the skip at all.
• Keep one connector per server and a separate connector per domain, with at least two servers per domain for redundancy, and update them together so build numbers stay consistent.
• Subscribe to the RSS feed on the Windows Autopilot known issues page and the Autopilot "What's new" page, which announced this connector build on the same day.

References#

• Windows Autopilot known issues
• Deploy Microsoft Entra hybrid joined devices by using Intune and Windows Autopilot
• Windows Autopilot: What's new