Keycloak LDAP with Nextcloud LDAP Backend and OIDC login

[Misu4]

Hi,

We use nextcloud with the LDAP Backend with default settings. That means "internal Users" with UUID.
Now we would like to use keycloak as an identity provider without changing the existing environment, i.e. remapping all users.

Unfortunately my efforts are not successful.
The Keycloak token seems to be OK, because all the defined values are filled in correctly and mapped to the right OIDC attributes . But the OIDC-Login can not fetch the user DN (Error getting DN for user).

Keycloak mapping:
kc_id = LDAP_ID
kc_upn = username
kc_email = email
kc_username = username

OIDC mapping:
id = kc_id
name = kc_username (also test with 'name' or kc_upn)
mail = kc_email (also test with 'email')
ldap_uid = kc_id

What is my mistake?

Many thanks.
Best regards, Michael

[muppeth]

@Misu4 Are you trying to run with LDAP proxy mode or replace ldap with keycloak entirely.
I am working on similar setup but I would prefer not to use LDAP if this could be avoided once it's synced to Keycloak.

[Misu4]

Hi, muppeth. Thank you for your reply.

Yes, I tried this app with and without LDAP proxy mode.
The problem is the default setting of the Nextcloud LDAP backend. In this case the internal username of the nextcloud user account is the LDAP UUID so that a user is unique and a name change is possible, for example. A later change, e.g. to the UID, results in a new creation of the user accounts or in an error message if the automatic user creation is disabled. I think, this behaviour is also the case if we change completly to Keycloak.

We have been using nextcloud for several years and have almost 100 user accounts with shares and files, so the creation of new Nextcloud user accounts with a data migration or an unsupported Nextcloud user database change is not an option.

But in the meantime we found a working solution to our problem:

Now we are using the "Social Login" app with a customization to map the Keycloak LDAP-UUID token attribute to the "Social Login"-App profileID (OpenID).

And you are right. In a new environment, we would go directly to an OpenID identity provider that can also use LDAP in its own backend.

Best regards.