OpenCloud + integrated keycloak + external Active Directory

[b0ykoe]

Hello everyone,

I did set up OpenCloud using the Keycloak example stack and extended it to connect to my external Active Directory. Users created in the local LDAP through Keycloak work fine and can log in.

Users coming from the external AD cannot log in. Keycloak does not expose the real objectGUID. Instead it maps it to a string that represents the binary form of the objectGUID, and this string is what ends up in the JWT. From what I found this seems to be a known Keycloak limitation, which might be the reason AD users are blocked.

I am a bit confused on the example here https://github.com/opencloud-eu/opencloud-compose/blob/main/idm/ldap-keycloak.yml

Do I have to change the "OC_LDAP_xx" values to my active directory one and remove the open-ldap container? I sadly couldn't find much documentation about these environment values.

I also have found https://github.com/orgs/opencloud-eu/discussions/1261 it was overriden these values. In addition I saw and tested https://github.com/orgs/opencloud-eu/discussions/1014 this works for me but authentik does not seem as flexible as keycloak (specially in terms of default groups once synced from AD)

Has anyone run into this before or found a workaround? Any hints or examples would help a lot.

[ocroquette]

I am in a similar situation, I want to use an existing AD server to authenticate the users. I have done that for many applications in the past and I am surprised how difficult it is with OpenCloud. I use an external proxy and I came up with the following value for COMPOSE_FILE:

COMPOSE_FILE=docker-compose.yml:weboffice/collabora.yml:external-proxy/opencloud.yml:external-proxy/collabora.yml:idm/ldap-keycloak.yml:external-proxy/keycloak.yml

OpenCloud and Keycloak start correctly. In Keycloak, I see in "User federation" a provider named "ldap". I created another one with the provider "Active directory". In "Users", I then see the AD users. The username is "firstname lastname" (lowercase, with a space). I do not know where the value comes from, but if I try to log in using it, OpenCloud says that the username is invalid because of the space. If I use instead the email address of the user, then I get past the login screen, but I immediately get an error message:

Not logged in

This could be because of a routine safety log out, or because your account is either inactive or not yet authorized for use. Please try logging in after a while or seek help from your Administrator.

I had a look at the log files, but they did not help. The thing is that I am not even sure if what I did is the right way. For instance:

• why is the username "firstname lastname" and how can I use samAccountName instead?
• is it correct to create a new LDAP provider next to the one created automatically and called "ldap", or should I edit or remove it?

This is a common setup for target audience of OpenCloud, who probably does not have experience with Keycloak, so a step-by-step guide would be very helpful. I am ready to write one, once I get it working 😉

[micbar]

The compose setup has not been designed to achieve that. The compose project focuses on single node simple setups which are covering 80% of the community needs.

For a commercial setup with MS AD, we have a helm chart which is part of our subscription.

[ocroquette]

Thanks for the feedback! I am setting up Opencloud to evaluate it, therefore the subscription is not yet an option. I do not need a fancy solution, a short page in the documentation would be enough. Opensource projects with optional commercial support usually offer that.
The way I see it, this aspect is also part of sovereignty. It should be possible for users to set up an instance on their own including all standard features. Not being able to that gives a bad feeling, compared to Nextcloud, for instance.

[micbar]

It should be possible for users to set up an instance on their own including all standard features.

That is already possible.

[ocroquette]

"It is possible to fulfill this simple requirement but I won’t tell you how". Is that really what you are saying? I will try to find the time to investigate by myself, but clearly this does not speak for OpenCloud in our evaluation. As a side note, the question has been asked a few times:
https://github.com/orgs/opencloud-eu/discussions/1737
https://github.com/orgs/opencloud-eu/discussions/1015

[dragotin]

What are you evaluating OpenCloud for? We appreciate every usage of OpenCloud, but free software does not mean free of cost in every situation, as you know. We have to pay staff to maintain all aspects of the project and be able to provide this software at all, so I think it is fair to ask for a kind of commercial relationship as soon it becomes a commercial solution, for which using AD is a good indicator.

That said, to help you in the evaluation and give you a clear and reliable way forward, you could get in touch with sales and talk. That does not mean you have to pay in the first place, but gives us all a chance to build on a reliable fundament.

Does that make sense for you?

[vadikonline1]

De ce nu este posibil să configurez un LDAP simplu pentru a mă putea conecta cu AD și administrator local, în OCIS am reușit să mă conectez cel puțin prin LDAP, dar cu OC nu este deloc posibil.
Nu este nevoie de multă filozofie, doar o pagină simplă, ce setări sunt necesare pentru a conecta LDAP și Atribuirea Automată a Rolurilor AD

[vadikonline1]

If you need LDAP directly: https://github.com/vadikonline1/ocsi-owncloud-s3-docker/blob/main/opencloud_LDAP_AD.md