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, nested distribution groups, 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. Active Directory does not evaluate distribution groups in tokenGroups queries, preventing Okta from importing inherited group memberships from nested distribution groups via JIT. 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.

What steps resolve group membership discrepancies for Active Directory-sourced users?

Verify Just-In-Time (JIT) provisioning, check for nested groups, and validate 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, there is an issue with the AD object. Replace any value wrapped in < > with the information described. NOTE: This PowerShell command is only relevant for affected security groups because distribution groups do not use tokenGroups. Use this command only for troubleshooting affected security groups.
   

   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 if the nested groups are distribution groups. Active Directory does not evaluate distribution groups in tokenGroups queries. Consequently, Okta does not import inherited group memberships from nested distribution groups via JIT provisioning. Perform an import to update distribution groups.
5. 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}

6. 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)