You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by "Druve, Matthias" <ma...@tu-berlin.de.INVALID> on 2022/10/07 08:13:06 UTC
LDAP extension - understanding problem
Hey,
I'm new to the guacamole experience, but the configuration of the LDAP extension (+postgresdb) raised a question or two.
It took me a good amount of time to figure out, why I can't see any groups while administer the frontend,
before I found a half-sentence somewhere which mentions that not the LDAP bind user in the guacamole.properties configured,
will be used, but the actual guacamole logged-in user (which has not the needed LDAP permissions).
I can't figure it out by myself, why the bind user isn't used for polling groups and users.
In my eyes a user connection to the LDAP is only needed to verify the account credentials (password, account disabled, etc.) while logging in.
The guacadmin (local postgresql admin account) has to configure which LDAP user will be able to administer the frontend.
So not every LDAP user would be able to see and configure every other polled LDAP user and group from the bind user.
In my opinion at the moment I have to give atleast two LDAP accounts extended permissions, to be able to login (first account - bind user) and to administer guacamole (second - the logged-in user).
There isn't even a backup admin included. So, perhaps even more accounts.
Background:
Here at the university we have an LDAP/AD for the whole campus and a lot of self-managed faculties, institutes and chairs
which will get only a service account with special permissions for the LDAP. This account can be used for a lot of services as bind user.
The service can be run by an admin who don't have administrator rights on the LDAP, but can be an admin for instance like guacamole in his/her institute (like me, now).
Question:
So, my two questions are.
1. Why isn't the bind user used for all the polling when the administration/administrator for guacamole can be done with another database (postgresql) and rights management (in guacamole itself)?
2. I'm not good with java programming and tried to dig into the source code already. Is it easily possible to change the behavior of the extension from user polling to bind polling?
Or is my evaluation wrong? Is it something I'm doing wrong?
Maybe someone can give me an insight!
BIG thanks for the patience of reading and the replies
Matthias Druve
PS: is this the right place to ask these questions? : )
---
Matthias Druve
Systemadministrator
Institut für Geodäsie und Geoinformationstechnik (Fak.VI)
Technische Universität Berlin
KAI 2-2 - Hr. Druve
Kaiserin-Augusta-Allee 104-106
10553 Berlin
Telefon: (030) 314 - 23204
Telefax: (030) 314 - 12323204
E-Mail: matthias.druve@tu-berlin.de
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: LDAP extension - understanding problem
Posted by Nick Couchman <vn...@apache.org>.
On Fri, Oct 7, 2022 at 7:48 AM Druve, Matthias
<ma...@tu-berlin.de.invalid> wrote:
>
> Hey,
>
> thanks for your quick and extended response!
>
> Alright, so the decision was made because of the optional part which allows you to store the connections in LDAP.
> Okay, that I understand.
> I maybe would have divided the authentication/pulling information part based of the used or unused optional setting but I understand where it is coming from.
> (or even use another flag for true/false for bind user only or something like it)
As I said, it was very intentionally designed this way. I think there
has been some noise on the list, and maybe even an item in Jira,
lately, to add an option for forcing everything to happen as the bind
DN, but no work has been done on that.
>
> I'm also glade to hear that it is possible to modify the extension to "always" (except the authentication) use the bind user for pulling data.
> (that's what I thought, but like I said, Java is not my specialty)
>
> "while modifying the extension to use the bind DN shouldn't
> be too difficult, modifying it to continue group search even when
> authentication fails would probably take some work."
>
> ^^
> The last part isn't important to me and needed, I already logged in with my LDAP user account,
> which has not the permissions to read groups and made myself admin with the help of the guacadmin account,
> so the LDAP extension is already in use.
Okay, so your goal is that, when a user successfully logs in with LDAP
credentials, group membership for that user should be retrieved, but
should be retrieved under the bind DN instead of the user who is
logging in.
>
> So, maybe you can point me in the direction where I would have to modify the extension?
There are a few things you'd have to change...
* The main code for retrieving goups for a particular user is located
here: https://github.com/apache/guacamole-client/blob/0af17df712d1f2128b8fbc4df543e423939ef905/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/group/UserGroupService.java#L100-L163
* In particular, the call to queryService.search() is where the
configuration is pulled together for the LDAP connection and the group
search base: https://github.com/apache/guacamole-client/blob/0af17df712d1f2128b8fbc4df543e423939ef905/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/group/UserGroupService.java#L132-L140
* However, you'd also probably need to implement a different version
of config.getLDAPConnection() that gets a connection strictly using
bindDN and password rather than the user who is logging in. That's a
quick guess on my part without digging through the code, but looking
at the search() method(s) in ObjectQueryService, it's what makes sense
to me.
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
AW: LDAP extension - understanding problem
Posted by "Druve, Matthias" <ma...@tu-berlin.de.INVALID>.
Hey,
thanks for your quick and extended response!
Alright, so the decision was made because of the optional part which allows you to store the connections in LDAP.
Okay, that I understand.
I maybe would have divided the authentication/pulling information part based of the used or unused optional setting but I understand where it is coming from.
(or even use another flag for true/false for bind user only or something like it)
I'm also glade to hear that it is possible to modify the extension to "always" (except the authentication) use the bind user for pulling data.
(that's what I thought, but like I said, Java is not my specialty)
"while modifying the extension to use the bind DN shouldn't
be too difficult, modifying it to continue group search even when
authentication fails would probably take some work."
^^
The last part isn't important to me and needed, I already logged in with my LDAP user account,
which has not the permissions to read groups and made myself admin with the help of the guacadmin account,
so the LDAP extension is already in use.
So, maybe you can point me in the direction where I would have to modify the extension?
Big thanks and a nice weekend in advance!
Matthias
---
Matthias Druve
________________________________________
Von: Nick Couchman <vn...@apache.org>
Gesendet: Freitag, 7. Oktober 2022 13:16
An: user@guacamole.apache.org
Betreff: Re: LDAP extension - understanding problem
> 1. Why isn't the bind user used for all the polling when the administration/administrator for guacamole can be done with another database (postgresql) and rights management (in guacamole itself)?
This was a very intentional design, because it allows the LDAP
extension to leverage security built-in to LDAP - LDAP access controls
- to make sure that the information that is being pulled from LDAP is
only accessible to the user who is actually logging in, and not to the
initial bind user that has been used to locate the user. While this is
certainly applicable and relevant to looking for groups, it is
actually more important when one stores Guacamole connections in LDAP,
because the extension relies on the LDAP ACLs to limit what
connections the user can see and access.
> 2. I'm not good with java programming and tried to dig into the source code already. Is it easily possible to change the behavior of the extension from user polling to bind polling?
It is possible, and it shouldn't be too difficult, but also not a
matter of just tweaking one or two lines of code. The portion of the
code that deals specifically with searching for groups would have to
be tweaked to pull in and use the bind dn and password rather than the
current user credentials, so there could be a handful of changes
required to make it happen.
That said, I'm not 100% sure that making this change would
automatically allow all users and groups to show up in the Guacamole
admin interface, when logging in with a database-only user (guacadmin,
for example). The other aspect of this is that the authentication
extensions are evaluated in order (alphabetical, by default), and so
if you log in as a user through the database module, and that login
succeeds, then the authentication within the LDAP module will never be
tried or evaluated, and the groups will not be enumerated. I believe
this is more likely the core issue for you and not which user account
is used to search the LDAP tree for groups?
The best way to resolve this issue is to administer Guacamole with a
LDAP account that has also been granted admin access within the JDBC
module, which can be accomplished by using the guacadmin user to
create a new account with the same username as the LDAP user, and
grant that user account admin privileges (make sure not to specify a
password so that Guacamole generates a random one that is different
from the LDAP module). This should allow you to log in with the LDAP
user, which will evaluate the LDAP groups (and connections, if you're
using those), but also have admin access to the database and be able
to assign LDAP users and groups permissions within the database.
The alternative, which is the path you started down would be to 1)
modify the LDAP extension to use the bind DN, 2) modify the LDAP
extension to search for groups even when a user is not successfully
authenticated, and 3) re-order extension processing within your
Guacamole install to evaluate LDAP before JDBC. This could be quite a
process - while modifying the extension to use the bind DN shouldn't
be too difficult, modifying it to continue group search even when
authentication fails would probably take some work.
> PS: is this the right place to ask these questions? : )
Yep, this is the place!
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: LDAP extension - understanding problem
Posted by Nick Couchman <vn...@apache.org>.
> 1. Why isn't the bind user used for all the polling when the administration/administrator for guacamole can be done with another database (postgresql) and rights management (in guacamole itself)?
This was a very intentional design, because it allows the LDAP
extension to leverage security built-in to LDAP - LDAP access controls
- to make sure that the information that is being pulled from LDAP is
only accessible to the user who is actually logging in, and not to the
initial bind user that has been used to locate the user. While this is
certainly applicable and relevant to looking for groups, it is
actually more important when one stores Guacamole connections in LDAP,
because the extension relies on the LDAP ACLs to limit what
connections the user can see and access.
> 2. I'm not good with java programming and tried to dig into the source code already. Is it easily possible to change the behavior of the extension from user polling to bind polling?
It is possible, and it shouldn't be too difficult, but also not a
matter of just tweaking one or two lines of code. The portion of the
code that deals specifically with searching for groups would have to
be tweaked to pull in and use the bind dn and password rather than the
current user credentials, so there could be a handful of changes
required to make it happen.
That said, I'm not 100% sure that making this change would
automatically allow all users and groups to show up in the Guacamole
admin interface, when logging in with a database-only user (guacadmin,
for example). The other aspect of this is that the authentication
extensions are evaluated in order (alphabetical, by default), and so
if you log in as a user through the database module, and that login
succeeds, then the authentication within the LDAP module will never be
tried or evaluated, and the groups will not be enumerated. I believe
this is more likely the core issue for you and not which user account
is used to search the LDAP tree for groups?
The best way to resolve this issue is to administer Guacamole with a
LDAP account that has also been granted admin access within the JDBC
module, which can be accomplished by using the guacadmin user to
create a new account with the same username as the LDAP user, and
grant that user account admin privileges (make sure not to specify a
password so that Guacamole generates a random one that is different
from the LDAP module). This should allow you to log in with the LDAP
user, which will evaluate the LDAP groups (and connections, if you're
using those), but also have admin access to the database and be able
to assign LDAP users and groups permissions within the database.
The alternative, which is the path you started down would be to 1)
modify the LDAP extension to use the bind DN, 2) modify the LDAP
extension to search for groups even when a user is not successfully
authenticated, and 3) re-order extension processing within your
Guacamole install to evaluate LDAP before JDBC. This could be quite a
process - while modifying the extension to use the bind DN shouldn't
be too difficult, modifying it to continue group search even when
authentication fails would probably take some work.
> PS: is this the right place to ask these questions? : )
Yep, this is the place!
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org