An Active Directory-sourced Okta user displays group memberships that do not match the Active Directory (AD) records. This discrepancy occurs due to Just-In-Time (JIT) provisioning conflicts, nested group flattening, or insufficient permissions for the Okta service account. Verify JIT provisioning settings, check AD group nesting, and validate service account permissions to resolve the mismatch.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Active Directory (AD)

Group membership discrepancies between Okta and AD occur for several reasons. JIT provisioning updates group memberships using the AD tokenGroups attribute, which a standard import cannot overwrite. Additionally, Okta flattens nested AD groups during import, adding nested groups directly to the user profile. Finally, the Okta service account might lack the necessary permissions to read user and group memberships in AD.

How are group membership discrepancies for Active Directory-sourced users resolved in Okta?

Troubleshoot and resolve group membership mismatches by verifying Just-In-Time (JIT) provisioning, checking for nested groups, and validating Okta service account permissions using PowerShell.

1. Verify if JIT provisioning is enabled. JIT provisioning synchronizes an Okta profile with AD during each login using the AD tokenGroups attribute to determine group membership. If JIT updates a user profile, a regular import cannot remove the group membership because imports use a different mechanism. Initiate JIT provisioning by having the user sign in to Okta with their username and password.
2. Check the AD tokenGroups attribute for the user using the following PowerShell command. If the results do not match the group membership in AD, an issue exists with the AD object. Replace any value wrapped in < > with the information described.

   Get-ADUser -SearchScope Base -SearchBase '<DN of affected user>' -Filter * -Properties tokenGroups -Credential '<Okta service account>' -Server '<DC Hostname>' | %{ $_.tokenGroups } | %{ $_.Value }  | foreach {Get-ADGroup $_ }

3. Check the AD group membership for nested groups if the user belongs to more groups in Okta than in AD. Okta flattens group membership upon import. If other groups nest inside an existing group, Okta adds those groups directly to the group membership list for the user.
4. Verify that the Okta service account possesses permission to view both the AD user and group membership by running the following PowerShell commands on a Domain Controller. Replace any value wrapped in < > with the information described.
   Run this command to view the group membership for a user:

   Get-ADPrincipalGroupMembership -Credential <service account> <AD user> | select name

   Run this command to view the user membership for a group:

   Get-ADGroup -Credential '<Okta service account>' -SearchBase '<DN of group>' -LDAPFilter '(|(&(objectCategory=group)(cn=<Group CN>)))' | foreach {Get-ADGroupMember $_ |Select name,SamAccountName, distinguishedName}

5. Enable verbose logging on the Okta AD agent, run a Full Import, gather the logs, and submit them to Okta Support to open a new support case.

Related References

• Import groups from Active Directory
• How to Retrieve Okta Logs for Troubleshooting
• How Does Okta Handle Active Directory Nested Groups
• Enabling Verbose Logging on Okta AD Agent (Video)