[
https://issues.apache.org/jira/browse/GUACAMOLE-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885918#comment-17885918
]
Daniel Hoffend edited comment on GUACAMOLE-1985 at 9/30/24 2:31 PM:
--------------------------------------------------------------------
We were trying to get the same configuration going but [~armfem] was faster
reporting the configuration problem:
We're using guacomale as remote desktop gateway to several internal systems,
while using LDAP as our main authentication and connection database. (btw: It's
nice to directly assign users to groupOfNames and connect them via
member/seeAlso attribute to connections they're allowed to use).
The problem is: we want to extend the use of guacamole from internal network
accesses to external network accesses as well. But connections from external
(untrusted) sources would require a 2nd factor (this is where an additional
OpenID Provider comes into play). Those external guacamole servers are
seperated from the internal servers)
* In this setup the authentication provider will be switched from ldap to
openid + ldap (priority to openid).
* On login request, the OpenID provider checks the user credentials and
multi-factor components and redirects the user back to guacamole with a
relevant subset of groups he's part of.
* The connection storing method is still be the ldap database, no additional
(sql) database required
* The given group membership should somehow be resolved and user is provided
with a list of connections he's allowed to use.
Comments:
* Right now it seems that only a real (sql) database connection backend would
allow openid authenticated users to access their (withing the db assigned)
connections. As I mentioned we would like to don't run an additional database.
Don't maintain the connections multiple times (ldap, db1, db2, db3 ...)
* I guess it would need an configuration option to control weather the search
bind user is used to load connections and check group memberships or the real
user.
* It's also a security discussion if the real user bind should be used to load
connections or the search ldap user (need to known principal). Maybe the user
isn't allowed to see the connection details, but the search your should be
allowed, especially when the connection has internal credentials or tunnel
configurations saved in it.
Hope that helps to clarify. Maybe [~armfem] has the same use case.
was (Author: JIRAUSER302220):
We were trying to get the same configuration going but [~armfem] was faster
reporting the configuration problem:
We're using guacomale as remote desktop gateway to several internal systems,
while using LDAP as our main authentication and connection database. (btw: It's
nice to directly assign users to groupOfNames and connect them via
member/seeAlso attribute to connections they're allowed to use).
The problem is: we want to extend the use of guacamole from internal network
accesses to external network accesses as well. But connections from external
(untrusted) sources would require a 2nd factor (this is where an additional
OpenID Provider comes into play). Those external guacamole servers are
seperated from the internal servers)
* In this setup the authentication provider will be switched from ldap to
openid + ldap (priority to openid).
* On login request, the OpenID provider checks the user credentials and
multi-factor components and redirects the user back to guacamole with a
relevant subset of groups he's part of.
* The connection storing method is still be the ldap database, no additional
(sql) database required
* The given group membership should somehow be resolved and user is provided
with a list of connections he's allowed to use.
Comments:
* Right now it seems that only a real (sql) database connection backend would
allow openid authenticated users to access their (withing the db assigned)
connections. As I mentioned we would like to don't run an additional database.
Don't maintain the connections multiple times (ldap, db1, db2, db3 ...)
* I guess it would need an configuration option to control weather the search
bind user is used to load connections and check group memberships or the real
user.
* It's also a security discussion if the real user bind should be used to load
connections or the search ldap user (need to known principal)
Hope that helps to clarify. Maybe [~armfem] has the same use case.
> There is no account reconciliation between OIDC and LDAP
> --------------------------------------------------------
>
> Key: GUACAMOLE-1985
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1985
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole-auth-ldap
> Environment: LDAP: AD
> SSO: OIDC with LemonLDAP
> Reporter: armfem
> Priority: Minor
>
> Bonjour,
>
> I had configured guacamole users through LDAP, which work very nice. Then I
> added an SSO (LemonLDAP) which is connected via OIDC to guacamole. Which also
> seems to work quite nice to access it.
> The problem is that when connecting through OIDC I cannot access the users
> that are in LDAP, there are only users already connected through OIDC.
> Furthermore, it seems that the OIDC user is not reconciled with same name
> LDAP user.
>
> For the time being, I avoid the problem creating a group in LDAP and a group
> in Guacamole, and then the application is able to reconcile the groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
