map a kerberos provider to one or more ldap provider stores

[davot]

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

[wkruse]

We have the same setup:

• single keycloak realm
• two ldap providers (also because of two OUs, and we couldn't find a way to filter out the subtrees that we don't want)
• Kerberos enabled for both

When both ldap providers are enabled, Kerberos SSO doesn't work, we always get

User with username [xxx] already exists, but is not linked to provider [yyy]

Kerberos/SPNEGO authentication succeeded with username [xxx], but couldn't find or create user with federation provider [yyy]

Where the user "xxx" exists in L1, but is being searched in L2.

When we disable the L2, Kerberos SSO works.

When we disable the L2 and disable Kerberos SSO in L2, Kerberos SSO doesn't work. Yes, the settings in the disabled ldap provider make a difference.

So, the only working configuration for us is

• enabled L1 with enabled Kerberos SSO
• disabled L2 with enabled Kerberos SSO

We are running Keycloak 19.0.3.

[wkruse]

Related https://keycloak.discourse.group/t/multiple-domains-and-kerberos/16132

[wkruse]

It turns out, this is an issue with ldap priorities, as @davot described it. In Keycloak 19.0.3 the ldap priorities are

• not visible in the UI
• probably the same per default, but in User federation > Manage priorities the list is sorted alphabetically, so it tricked us to think the priority was correct
• moving the ldap providers per drag and drop back and forth, fixed the priority

So, the core issue is, that only one (lowest number which is highest priority) ldap provider is checked for Kerberos SSO.

[wkruse]

Related #9422.

[wkruse]

Related #9290.

[wkruse]

Related https://issues.redhat.com/browse/RHSSO-2064.

[fit-sw]

We are running into the same issue with Keycloak 21.0.1.
Can we get an update of the status of this issue?