On Wed, Nov 20, 2024 at 2:51 PM viktor_krumm <viktor_kr...@proton.me.invalid> wrote:
> Hello, > > Apologies if this is a re-send. I'm trying to unify Guacamole with LDAP > and Keycloak. My main goal is to get WebAuthn support with Guacamole. To do > so, I've setup Keycloak. Keycloak and Guacamole (via OIDC) work fine. The > issue there is I need to maintain 2 databases of accounts - Keycloak > accounts and Guacamole accounts, and map between the two. > > I thought LDAP would solve that issue - a centralized database of both > users and connections. I have LLDAP and Guacamole working just fine. I can > create both users and connections in LLDAP, and log into Guacamole > correctly. > > I cannot seem to unify all three fully, however. I have LLDAP as a User > Federation in Keycloak. I can successfully open Guacamole, get redirected > to Keycloak as an OIDC provider, authenticate through Keycloak with an > LLDAP account, and return to Guacamole. > > My main issue is, my connections are not available. If I take my same > database, turn off Keycloak, and revert it to just LLDAP<->Guacamole, I see > my connections, proving they're configured just fine. But connections are > lost when Keycloak/OIDC is reintegrated. I don't know enough about LDAP > mappings to exactly pinpoint the problem, or if its an issue with the > workflow between Guacamole, OIDC extension, LDAP extension, or whichever. > Has anyone gotten this sort of thing working? Is there an easier > integration for WebAuthn and Guacamole? > > This is a pretty often-asked question, and I suspect you're running into a similar issue as the other folks who have asked in the past. The LDAP authentication module has a specific behavior that leverages LDAP's built-in security and access control to allow you to control access to Guacamole connection data stored in LDAP. What happens during the LDAP login flow is this: * User enters username + password * LDAP extension binds to LDAP with the Search DN and password configured in guacamole.properties * LDAP extension executes a search on the LDAP tree for the user who is logging in, based on constraints configured in guacamole.properties (username attribute, user search base, etc.). * If LDAP user is successfully located, LDAP extension ***unbinds*** from LDAP with the search DB and re-binds ***using the DN of the user it has just located and the password entered by the user.*** * LDAP extension then searches for Guacamole connections, groups, etc., that are accessible to the user logging in. In this way, the LDAP user logging in can only see the connection data that is accessible to them in LDAP, and, so, you can limit the connections available to the user by simply putting the connections in LDAP locations that they can (or cannot) read/browse/search. The challenge with this process is that, when a user logs in with another extension, particularly an SSO extension where the password is not available to Guacamole, the LDAP extension cannot bind as the user who is logging in, and so connection data cannot be located for that user - essentially it fails at the step of re-binding as the user and then searching for available connections. And, currently, there is no way within Guacamole to make the LDAP extension behave any differently. I think there's a feature request out there for it, but no implementation of that feature today. So, you have two options today: * If you want the SSO module to work, store the connections in the JDBC module, instead of LDAP, and use the layering available within Guacamole to assign permissions to connections to users and/or groups from SSO. * Drop the SSO module and just use the LDAP module, requiring users to authenticate to Guacamole, but allowing you to leverage the LDAP connection storage and the security built-in to LDAP. -Nick > Sent with [Proton Mail](https://proton.me/mail/home) secure email.
