[
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:20 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)
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
* 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 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)
