Description

Scenario One:

• single keycloak realm
• two ldap providers configured each of a different OU containing user accounts in the same Active Directory Domani/KDC realm:
  - provider L1 has userA, priority=10 - OU=finance
  -provider L2 has userB, priority=20 - OU=technology
• both ldap providers configured for Keberos SSO - this tested independently and working
• userA connects to a resource - OIDC flows and SSO occurs in the authentication. All good
• userB connects to same resource - OIDC flow begins, SSO doesn't happen and form-based login form presented. Error: "User with username userB already exists, but is not linked to provider [L1]"

So it appears that only one provider store is checked - the one with the highest priority that has also successfully decrypted the SPNEGO ticket.

If the ldap providers are both set to the same priority, the SSO working becomes random.

N.B. Also tried to create a kerberos provider (K1) and disablde the kerberos on both ldap providers. However SSO fails for all users: "User with username userA already exists, but is not linked to provider [K1]" and there appears no mechanism to tell it to use one or more ldap provider stores.

Ran out of configuration options to try after this.

Solution proposal:
I think it would work best if a single kerberos provider configuration can be explicitly mapped to multiple ldap provider stores for our scenario so that each can be tried in succession in order of priority to find a match for the kerberos user principal found in the SPNEGO ticket after decrypting/verifying with the keytab file.

Discussion

I have seen a similar discussion (but different) where each ldap provider is a separate KDC realm. Again apparently it tries the highest priority provider and then gives up rather than trying the next. I would also like this addressed at the same time.

Motivation

You generally have no control over how a legacy AD domain has been managed/mismanaged. In our case they kept dead accounts in multiple subtrees under "Managed Users" along with multiple live account subtrees (for multiple organisations). So we had a poor choice of syncing all user accounts at the "Managed Users" level and subtrees with a single ldap provider but putting up with all the dead accounts being synced (which caused some email conflict sync errors) or create multiple ldap providers to target the Live account subtree under each organisation OU.
You might suggest that we could use the ldap filter to filter out the subtree OUs that we don't want - but AD ldap doesn't support the extension that is needed to achieve that - (distinguishedName=*Dead*)

Details

Add a mapping capability to map a kerberos provider to one or more ldap provider stores so that it searches for the kerberos user principal in each of the mapped ldap provider stores until it finds it.

btw, the testing was done on v18 and v19