Fix Intune Connector gMSA SeLogonAsServicePrivilegeMissing in Autopilot Hybrid Join

If the Intune Connector for Active Directory fails while you are setting up a custom gMSA for Windows Autopilot hybrid join, and the connector UI or setup log shows SeLogonAsServicePrivilegeMissing, the problem is usually not the gMSA syntax and not a broken Autopilot profile. Microsoft now documents this as a known issue in the updated ODJ connector flow.

The failure shows up when the connector runs a pre-enrollment validation for Log on as a service and that right has not fully propagated to the connector host yet. In other words, the permission can be correctly assigned in Active Directory or by policy, but the wizard still fails because the validation happens before the host can use it.

That makes this a painful bench-side issue for Autopilot hybrid join teams. The connector looks like it is misconfigured, the gMSA looks valid, and the setup still stops before you can finish enrollment. The practical fix is to move to the connector build Microsoft just updated for this scenario, confirm the custom gMSA prerequisites, and use the new opt-in bypass key only for the pre-check that is getting in your way.

Quick Fix checklist

Use this order before you keep rerunning connector setup:

1. Confirm you are using your own gMSA with the Intune Connector for Active Directory, not the connector-created MSA.
2. Verify the connector version is 6.2604.2000.3 or later.
3. Confirm the gMSA is installed on the connector server and can retrieve its password.
4. Confirm the gMSA has Log on as a service assigned, whether directly or through group membership or GPO.
5. Update ODJConnectorEnrollmentWizard.exe.config with the custom MSA key.
6. Add DisableOUUpdates if you are using your own MSA.
7. Add SkipByoMsaPrivilegeCheck with value="true" and rerun the connector configuration.
8. If the service still will not start, check for DC replication delay and local policy conflicts instead of assuming the new key failed.

If you skip step 2, you can waste time debugging a connector build that does not include the documented workaround.

What the error actually means

Microsoft added this exact issue to the Windows Autopilot known-issues page on June 18, 2026. The failure affects environments where the Offline Domain Join (ODJ) Connector is configured to use a customer-managed service account instead of the account automatically provisioned by the connector.

The example error Microsoft calls out is a configuration failure often surfaced as SeLogonAsServicePrivilegeMissing, with the setup logs showing a KerbS4ULogon call:

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

Microsoft says the root cause is timing. The connector runs a pre-enrollment check for SeLogonAsServicePrivilege, and that check internally performs a Kerberos Service-for-User (S4U) logon of the gMSA. If the right has not propagated to the connector host yet, the validation fails even though the gMSA may already be configured correctly in the directory.

That distinction matters. This is not the same as a permanently missing service right. It is a validation problem during setup.

Why this happens more often in real hybrid join environments

This issue tends to appear in the same kinds of environments that already have more moving parts in Autopilot hybrid join:

• multiple domain controllers with normal replication delay
• a custom gMSA instead of the connector-created MSA
• OU delegation handled by a separate AD team
• local rights granted through GPO rather than directly on the server
• a bench workflow where admins want the connector working immediately after the right is assigned

Microsoft’s troubleshooting FAQ already documented a related connector symptom: Cannot start service ODJConnectorSvc on computer '.' can happen when the MSA is created on one domain controller but validation hits another before replication completes. The new SeLogonAsServicePrivilegeMissing behavior fits the same pattern. The directory and policy state can be correct in principle while the connector host is still not ready to pass the validation in practice.

That is why repeated retries without checking build level, config keys, and replication timing usually go nowhere.

Logs and where to check first

Connector setup logs

Start here when the wizard fails:

C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard\ODJConnectorUI.log

That is the log Microsoft tells admins to use for detailed connector setup failures. If this issue is in play, look for the SeLogonAsServicePrivilegeMissing wording or the KerbS4ULogon stack reference.

ODJ connector event logs

After installation, the connector logs to Event Viewer here:

Applications and Services Logs > Microsoft > Intune > ODJConnectorService

Review both Admin and Operational logs. If the connector gets past sign-in but fails when trying to use the service account, this log path is where you want to pivot next.

Connector version in Intune

In the Intune admin center, go to:

Devices > Enrollment > Windows > Windows Autopilot > Intune Connector for Active Directory

Confirm the connector version is at least 6.2604.2000.3 if you plan to use the new bypass key. Microsoft added the fix in that build.

The Microsoft-supported fix path

Microsoft documented the new behavior in two places on the same date: the Windows Autopilot known issues page and What’s new in Windows Autopilot. Both say build 6.2604.2000.3 adds an optional <appSettings> key named SkipByoMsaPrivilegeCheck.

When set to true, the connector skips the pre-enrollment SeLogonAsServicePrivilege check for environments using their own gMSA. Microsoft is explicit that this key is opt-in and defaults to false.

Step 1: Confirm the custom gMSA prerequisites

Before using the bypass, verify the basics Microsoft still requires for a custom managed service account:

• the account exists in the same domain as the connector server
• the service account value is formatted as <msaAccountName@domain>
• the account is installed on the connector server
• the gMSA host has permission to retrieve the password
• the account has Log on as a service
• permissions to create computer objects in the target OU are delegated manually

For gMSA validation on the connector server, these PowerShell checks are useful:

Install-ADServiceAccount -Identity gmsa-odj
Test-ADServiceAccount -Identity gmsa-odj

If Test-ADServiceAccount fails, do not jump straight to the bypass key. Fix the underlying gMSA readiness first.

Step 2: Update the connector config for a custom MSA

Microsoft says to update this file:

C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard\ODJConnectorEnrollmentWizard.exe.config

In the <appSettings> section, add your custom MSA value:

<add key="TenantConfiguredManagedServiceAccount" value="gmsa-odj@contoso.com" />

Use the account format Microsoft documents. If you are copying a gMSA name from AD tools, clean up the value so it matches the required account@domain pattern in the config file.

Step 3: Disable OU updates when you use your own MSA

Microsoft also says that using your own MSA disables connector OU updates, regardless of any OrganizationalUnitsUsedForOfflineDomainJoin configuration. To avoid connector errors, add this key too:

<add key="DisableOUUpdates" value="true" />

This is easy to miss. If you supply your own MSA and leave OU update behavior in place, you can create a second problem and think the original gMSA fix did not work.

Step 4: Add the new bypass key

On build 6.2604.2000.3 or later, add the new workaround key Microsoft introduced:

<add key="SkipByoMsaPrivilegeCheck" value="true" />

Then reopen the connector and sign in again to restart configuration.

This key only skips the pre-enrollment privilege validation that was failing. It does not grant the right, create OU permissions, or repair a broken gMSA.

Practical remediation workflow I would use

If I had to clear this in a production-like lab or bench flow, I would use this order:

1. Check whether the environment is actually using a custom gMSA

If the connector is using the auto-created msaODJ##### account, this specific workaround is probably the wrong branch. Go back to standard connector troubleshooting instead.

2. Confirm the connector server can use the gMSA

Run:

Test-ADServiceAccount -Identity gmsa-odj

If this returns False, check the host group allowed to retrieve the password, AD replication, and whether the account was installed on the connector server.

3. Confirm Log on as a service is really in scope

If the right was assigned by GPO, allow time for policy and replication to land. If you want to verify policy application before another setup attempt, use:

gpupdate /force

Then review the resulting local rights state through policy reporting or your normal security baseline tooling.

4. Update the config file with all three relevant keys

For a custom gMSA scenario, the config usually needs the full set:

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

Make the change carefully. A malformed XML edit creates a different failure and muddies the result.

5. Retry the connector enrollment or configuration

Reopen Intune Connector for Active Directory, sign in, and rerun the configuration flow. If the environment was blocked only by the privilege pre-check timing, this is the point where setup should move forward.

6. If the service still fails, pivot to replication and rights

Microsoft’s troubleshooting FAQ says a delayed DC replication path can also block ODJConnectorSvc from starting correctly. If the connector still fails after the new key is in place, check:

• whether the gMSA was created on one DC and validated against another
• whether local policy or GPO is stripping Log on as a service
• whether the OU delegation for computer object creation was completed manually
• whether the server can reach DCs and required Intune endpoints

At that point, the problem is no longer the new known issue alone.

Caveats and limitations

The bypass is not a substitute for the actual right

SkipByoMsaPrivilegeCheck helps when the right is assigned but not yet visible to the pre-check. It does not mean you can ignore SeLogonAsServicePrivilege permanently.

If a security baseline or deny policy actually prevents the account from running as a service, the connector will still fail later.

Custom MSA mode changes OU behavior

Microsoft explicitly says that when you use your own MSA, the connector stops performing OU updates. That is why DisableOUUpdates=true matters. If your process depended on the connector doing those updates automatically, you need to account for that operational change.

Hybrid join still depends on the usual ODJ prerequisites

Even after you fix this setup blocker, you still need the normal hybrid Autopilot foundations: DC reachability, delegated OU permissions, correct connector version, and healthy Intune enrollment plumbing. Do not let the new error hide older prerequisites.

Conclusion

SeLogonAsServicePrivilegeMissing in the Intune ODJ connector is now a documented Autopilot hybrid join issue, not just a weird one-off. Microsoft’s June 18, 2026 update matters because it finally gives admins a supported path for custom gMSA environments where the privilege exists but the pre-enrollment validation runs too early.

The clean fix is to update to Intune Connector for Active Directory 6.2604.2000.3 or later, verify the custom gMSA is actually usable on the connector host, add the required custom-MSA keys, and then enable SkipByoMsaPrivilegeCheck only for this scenario. If the setup still fails after that, stop retrying blindly and move to replication, OU delegation, and local rights validation.