You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by carlog <cg...@turlock.ca.us> on 2020/04/28 05:08:08 UTC
Re: ldap-user-search-filter problem
Thank you for posting your solution. However I'm having the same issue.
Works in 1.0 but not in 1.1 nor 1.2. anybody else having this issue? How
can I debug this against a Windows domain controller?
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: ldap-user-search-filter problem
Posted by Nick Couchman <vn...@apache.org>.
On Sun, May 3, 2020 at 9:49 AM Fabio Corsi <
fabio1299.discussionlists@gmail.com> wrote:
> Thanks Nick.
>
> Not sure what *above* would be in my case.
> Can you suggest what kind of information should I be looking for in my log
> file?
>
>
Sorry, after looking at this, again, I see what the issue is. In your
guacamole.properties, you are not specifying the ldap-search-bind-dn and
ldap-search-bind-password parameters. This means that Guacamole is not
actually searching for the user that is attempting to log in, it is just
computing the DN of the username by taking the username attribute (uid),
the username (user_not_in_guacusers) and the ldap-user-base-dn
(ou=users,dc=my,dc=domain) and putting together a user DN
(uid=user_not_in_guacusers,ou=users,dc=my,dc=domain) and then attempting to
bind with that account - and succeeding.
If you want successful LDAP logins to actually be limited to the items
in ldap-user-search-filter, you'll need to specify a LDAP account that
Guacamole will use to search the tree ahead of time and find the users, and
then that filter will not only apply to the users that are enumerated
within the admin interface, but also to the users trying to log in.
-Nick
Re: ldap-user-search-filter problem
Posted by Fabio Corsi <fa...@gmail.com>.
Thanks Nick.
Not sure what *above* would be in my case.
Can you suggest what kind of information should I be looking for in my log file?
The two groups of entries I posted are consecutive in the log file and there are no entries in between the two sets. I only split them for clarity...
Thanks,
Fabio
> On May 3, 2020, at 8:41 AM, Nick Couchman <vn...@apache.org> wrote:
>
>
> See responses inline...
>
>> On Wed, Apr 29, 2020 at 8:55 AM Fabio Corsi <fa...@gmail.com> wrote:
>> Hi Nick,
>>
>> Sorry for my previous emails that kept sending before I was done… didn’t have access to my computer yesterday.
>>
>> My configuration is a bit different as I’m using openLDAP (libldap-2.4-2:amd64) on Ubuntu 18.04.
>>
>> My LDAP configuration in my guacamole.properties is:
>>
>> # LDAP properties
>> ldap-hostname: configserver.my.domain
>> ldap-port: 389
>> ldap-user-base-dn: ou=users,dc=my,dc=domain
>> ldap-username-attribute: uid
>> ldap-user-search-filter: (&(objectClass=person)(memberof=cn=guacusers,ou=groups,dc=my,dc=domain))
>> ldap-config-base-dn: ou=guac_config,dc=my,dc=domain
>> ldap-group-base-dn: ou=groups,dc=my,dc=domain
>>
>> Which I’m expecting to allow login only to members of the group “guacusers”.
>> However what I'm experience is that every user on my LDAP server is allowed to login, whether they are members of the guacusers group or not.
>>
>> I have previously used this same configuration when I was testing version 0.9.14 and it seemed to be working...
>>
>> I can use the same filter directly querying my LDAP server, e.g.:
>> ldapsearch -x -LLL -H ldap:/// -b "ou=users,dc=my,dc=domain" -s sub "(memberof=cn=guacusers,ou=groups,dc=my,dc=domain)”
>> And I get the expected result….
>>
>> I’ve also tried adding other specifiers to the filter, like
>> (memberof=cn=guacusers,ou=users,dc=my,dc=domain)
>>
>> they all work when I query the LDAP server with ldapsearch, but don’t seem to have any effect when I use them in Guacamole.
>>
>> Here are the log entries on my LDAP server for a Guacamole access for a user (“user_in_guacusers”) that is in the guacusers group:
>> slapd[904]: conn=9470 fd=48 ACCEPT from IP=10.16.33.12:52422 (IP=0.0.0.0:389)
>> slapd[904]: conn=9470 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
>> slapd[904]: conn=9470 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
>
> I think the relevant entries might actually be *above* this, because at this point it is already accepting the bind as the user, which means it has already bound as the search user, done the search for the user who is logging in, and successfully located the entry.
>
>> slapd[904]: conn=9470 op=0 RESULT tag=97 err=0 text=
>> slapd[904]: conn=9470 op=1 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
>> slapd[904]: conn=9470 op=1 SEARCH RESULT tag=101 err=0 nentries=5 text=
>> slapd[904]: conn=9470 fd=48 closed (connection lost)
>> slapd[904]: conn=9471 fd=48 ACCEPT from IP=10.16.33.12:52424 (IP=0.0.0.0:389)
>> slapd[904]: conn=9471 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
>> slapd[904]: conn=9471 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
>> slapd[904]: conn=9471 op=0 RESULT tag=97 err=0 text=
>> slapd[904]: conn=9471 op=1 SRCH base="ou=users,dc=my,dc=domain" scope=2 deref=0 filter="(&(&(objectClass=person)(memberOf=cn=guacusers,ou=groups,dc=my,dc=domain))(|(uid=*)))"
>> slapd[904]: conn=9471 op=1 SEARCH RESULT tag=101 err=0 nentries=6 text=
>> slapd[904]: conn=9471 op=2 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(cn=*)))"
>> slapd[904]: conn=9471 op=2 SEARCH RESULT tag=101 err=0 nentries=46 text=
>> slapd[904]: conn=9471 op=3 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
>> slapd[904]: conn=9471 op=3 SEARCH RESULT tag=101 err=0 nentries=5 text=
>> slapd[904]: conn=9471 op=4 SRCH base="ou=guac_config,dc=my,dc=domain" scope=2 deref=0 filter="(&(objectClass=guacConfigGroup)(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)(seeAlso=cn=group1,ou=groups,dc=my,dc=domain)(seeAlso=cn=group2,ou=groups,dc=my,dc=domain)(seeAlso=cn=group3,ou=groups,dc=my,dc=domain)(seeAlso=cn=group4,ou=groups,dc=my,dc=domain)(seeAlso=cn=guacusers,ou=groups,dc=my,dc=domain)))"
>> slapd[904]: conn=9471 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
>>
>> …and for the user (“user_not_in_guacusers”) that is not in the guacusers group:
>> slapd[904]: conn=9478 fd=88 ACCEPT from IP=10.16.33.12:52430 (IP=0.0.0.0:389)
>> slapd[904]: conn=9478 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" method=128
>> slapd[904]: conn=9478 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
>
> Again, I think you need the log entries from slapd *above* this, because the search has already succeeded, determined the user is okay, and is now re-binding as that user.
>
> -Nick
Re: ldap-user-search-filter problem
Posted by Nick Couchman <vn...@apache.org>.
See responses inline...
On Wed, Apr 29, 2020 at 8:55 AM Fabio Corsi <
fabio1299.discussionlists@gmail.com> wrote:
> Hi Nick,
>
> Sorry for my previous emails that kept sending before I was done… didn’t
> have access to my computer yesterday.
>
> My configuration is a bit different as I’m using openLDAP (libldap-2.4-2:amd64)
> on Ubuntu 18.04.
>
> My LDAP configuration in my guacamole.properties is:
>
> # LDAP properties
> ldap-hostname: configserver.my.domain
> ldap-port: 389
> ldap-user-base-dn: ou=users,dc=my,dc=domain
> ldap-username-attribute: uid
> ldap-user-search-filter:
> (&(objectClass=person)(memberof=cn=guacusers,ou=groups,dc=my,dc=domain))
> ldap-config-base-dn: ou=guac_config,dc=my,dc=domain
> ldap-group-base-dn: ou=groups,dc=my,dc=domain
>
>
> Which I’m expecting to allow login only to members of the group
> “guacusers”.
> However what I'm experience is that every user on my LDAP server is
> allowed to login, whether they are members of the guacusers group or not.
>
> I have previously used this same configuration when I was testing version
> 0.9.14 and it seemed to be working...
>
> I can use the same filter directly querying my LDAP server, e.g.:
>
> ldapsearch -x -LLL -H ldap:/// -b "ou=users,dc=my,dc=domain" -s sub
> "(memberof=cn=guacusers,ou=groups,dc=my,dc=domain)”
>
> And I get the expected result….
>
> I’ve also tried adding other specifiers to the filter, like
>
> (memberof=cn=guacusers,ou=users,dc=my,dc=domain)
>
>
> they all work when I query the LDAP server with ldapsearch, but don’t
> seem to have any effect when I use them in Guacamole.
>
> Here are the log entries on my LDAP server for a Guacamole access for a
> user (“user_in_guacusers”) that is in the guacusers group:
>
> slapd[904]: conn=9470 fd=48 ACCEPT from IP=10.16.33.12:52422 (IP=
> 0.0.0.0:389)
> slapd[904]: conn=9470 op=0 BIND
> dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
> slapd[904]: conn=9470 op=0 BIND
> dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
>
>
I think the relevant entries might actually be *above* this, because at
this point it is already accepting the bind as the user, which means it has
already bound as the search user, done the search for the user who is
logging in, and successfully located the entry.
> slapd[904]: conn=9470 op=0 RESULT tag=97 err=0 text=
> slapd[904]: conn=9470 op=1 SRCH base="ou=groups,dc=my,dc=domain" scope=2
> deref=0
> filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
> slapd[904]: conn=9470 op=1 SEARCH RESULT tag=101 err=0 nentries=5 text=
> slapd[904]: conn=9470 fd=48 closed (connection lost)
> slapd[904]: conn=9471 fd=48 ACCEPT from IP=10.16.33.12:52424 (IP=
> 0.0.0.0:389)
> slapd[904]: conn=9471 op=0 BIND
> dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
> slapd[904]: conn=9471 op=0 BIND
> dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
> slapd[904]: conn=9471 op=0 RESULT tag=97 err=0 text=
> slapd[904]: conn=9471 op=1 SRCH base="ou=users,dc=my,dc=domain" scope=2
> deref=0
> filter="(&(&(objectClass=person)(memberOf=cn=guacusers,ou=groups,dc=my,dc=domain))(|(uid=*)))"
> slapd[904]: conn=9471 op=1 SEARCH RESULT tag=101 err=0 nentries=6 text=
> slapd[904]: conn=9471 op=2 SRCH base="ou=groups,dc=my,dc=domain" scope=2
> deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(cn=*)))"
> slapd[904]: conn=9471 op=2 SEARCH RESULT tag=101 err=0 nentries=46 text=
> slapd[904]: conn=9471 op=3 SRCH base="ou=groups,dc=my,dc=domain" scope=2
> deref=0
> filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
> slapd[904]: conn=9471 op=3 SEARCH RESULT tag=101 err=0 nentries=5 text=
> slapd[904]: conn=9471 op=4 SRCH base="ou=guac_config,dc=my,dc=domain"
> scope=2 deref=0
> filter="(&(objectClass=guacConfigGroup)(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)(seeAlso=cn=
> group1,ou=groups,dc=my,dc=domain)(seeAlso=cn=group2
> ,ou=groups,dc=my,dc=domain)(seeAlso=cn=group3
> ,ou=groups,dc=my,dc=domain)(seeAlso=cn=group4
> ,ou=groups,dc=my,dc=domain)(seeAlso=cn=guacusers,ou=groups,dc=my,dc=domain)))"
> slapd[904]: conn=9471 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
>
>
> …and for the user (“user_not_in_guacusers”) that is not in the guacusers
> group:
>
> slapd[904]: conn=9478 fd=88 ACCEPT from IP=10.16.33.12:52430 (IP=
> 0.0.0.0:389)
> slapd[904]: conn=9478 op=0 BIND
> dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" method=128
> slapd[904]: conn=9478 op=0 BIND
> dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
>
>
Again, I think you need the log entries from slapd *above* this, because
the search has already succeeded, determined the user is okay, and is now
re-binding as that user.
-Nick
Re: ldap-user-search-filter problem
Posted by Fabio Corsi <fa...@gmail.com>.
Hi Nick,
Sorry for my previous emails that kept sending before I was done… didn’t have access to my computer yesterday.
My configuration is a bit different as I’m using openLDAP (libldap-2.4-2:amd64) on Ubuntu 18.04.
My LDAP configuration in my guacamole.properties is:
# LDAP properties
ldap-hostname: configserver.my.domain
ldap-port: 389
ldap-user-base-dn: ou=users,dc=my,dc=domain
ldap-username-attribute: uid
ldap-user-search-filter: (&(objectClass=person)(memberof=cn=guacusers,ou=groups,dc=my,dc=domain))
ldap-config-base-dn: ou=guac_config,dc=my,dc=domain
ldap-group-base-dn: ou=groups,dc=my,dc=domain
Which I’m expecting to allow login only to members of the group “guacusers”.
However what I'm experience is that every user on my LDAP server is allowed to login, whether they are members of the guacusers group or not.
I have previously used this same configuration when I was testing version 0.9.14 and it seemed to be working...
I can use the same filter directly querying my LDAP server, e.g.:
ldapsearch -x -LLL -H ldap:/// <ldap:///> -b "ou=users,dc=my,dc=domain" -s sub "(memberof=cn=guacusers,ou=groups,dc=my,dc=domain)”
And I get the expected result….
I’ve also tried adding other specifiers to the filter, like
(memberof=cn=guacusers,ou=users,dc=my,dc=domain)
they all work when I query the LDAP server with ldapsearch, but don’t seem to have any effect when I use them in Guacamole.
Here are the log entries on my LDAP server for a Guacamole access for a user (“user_in_guacusers”) that is in the guacusers group:
slapd[904]: conn=9470 fd=48 ACCEPT from IP=10.16.33.12:52422 (IP=0.0.0.0:389)
slapd[904]: conn=9470 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
slapd[904]: conn=9470 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
slapd[904]: conn=9470 op=0 RESULT tag=97 err=0 text=
slapd[904]: conn=9470 op=1 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
slapd[904]: conn=9470 op=1 SEARCH RESULT tag=101 err=0 nentries=5 text=
slapd[904]: conn=9470 fd=48 closed (connection lost)
slapd[904]: conn=9471 fd=48 ACCEPT from IP=10.16.33.12:52424 (IP=0.0.0.0:389)
slapd[904]: conn=9471 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" method=128
slapd[904]: conn=9471 op=0 BIND dn="uid=user_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
slapd[904]: conn=9471 op=0 RESULT tag=97 err=0 text=
slapd[904]: conn=9471 op=1 SRCH base="ou=users,dc=my,dc=domain" scope=2 deref=0 filter="(&(&(objectClass=person)(memberOf=cn=guacusers,ou=groups,dc=my,dc=domain))(|(uid=*)))"
slapd[904]: conn=9471 op=1 SEARCH RESULT tag=101 err=0 nentries=6 text=
slapd[904]: conn=9471 op=2 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(cn=*)))"
slapd[904]: conn=9471 op=2 SEARCH RESULT tag=101 err=0 nentries=46 text=
slapd[904]: conn=9471 op=3 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)))"
slapd[904]: conn=9471 op=3 SEARCH RESULT tag=101 err=0 nentries=5 text=
slapd[904]: conn=9471 op=4 SRCH base="ou=guac_config,dc=my,dc=domain" scope=2 deref=0 filter="(&(objectClass=guacConfigGroup)(|(member=uid=user_in_guacusers,ou=users,dc=my,dc=domain)(seeAlso=cn=group1,ou=groups,dc=my,dc=domain)(seeAlso=cn=group2,ou=groups,dc=my,dc=domain)(seeAlso=cn=group3,ou=groups,dc=my,dc=domain)(seeAlso=cn=group4,ou=groups,dc=my,dc=domain)(seeAlso=cn=guacusers,ou=groups,dc=my,dc=domain)))"
slapd[904]: conn=9471 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
…and for the user (“user_not_in_guacusers”) that is not in the guacusers group:
slapd[904]: conn=9478 fd=88 ACCEPT from IP=10.16.33.12:52430 (IP=0.0.0.0:389)
slapd[904]: conn=9478 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" method=128
slapd[904]: conn=9478 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
slapd[904]: conn=9478 op=0 RESULT tag=97 err=0 text=
slapd[904]: conn=9478 op=1 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_not_in_guacusers,ou=users,dc=my,dc=domain)))"
slapd[904]: conn=9478 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
slapd[904]: conn=9478 fd=88 closed (connection lost)
slapd[904]: conn=9479 fd=88 ACCEPT from IP=10.16.33.12:52432 (IP=0.0.0.0:389)
slapd[904]: conn=9479 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" method=128
slapd[904]: conn=9479 op=0 BIND dn="uid=user_not_in_guacusers,ou=users,dc=my,dc=domain" mech=SIMPLE ssf=0
slapd[904]: conn=9479 op=0 RESULT tag=97 err=0 text=
slapd[904]: conn=9479 op=1 SRCH base="ou=users,dc=my,dc=domain" scope=2 deref=0 filter="(&(&(objectClass=person)(memberOf=cn=guacusers,ou=groups,dc=my,dc=domain))(|(uid=*)))"
slapd[904]: conn=9479 op=1 SEARCH RESULT tag=101 err=0 nentries=6 text=
slapd[904]: conn=9479 op=2 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(cn=*)))"
slapd[904]: conn=9479 op=2 SEARCH RESULT tag=101 err=0 nentries=46 text=
slapd[904]: conn=9479 op=3 SRCH base="ou=groups,dc=my,dc=domain" scope=2 deref=0 filter="(&(!(objectClass=guacConfigGroup))(|(member=uid=user_not_in_guacusers,ou=users,dc=my,dc=domain)))"
slapd[904]: conn=9479 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text=
slapd[904]: conn=9479 op=4 SRCH base="ou=guac_config,dc=my,dc=domain" scope=2 deref=0 filter="(&(objectClass=guacConfigGroup)(|(member=uid=user_not_in_guacusers,ou=users,dc=my,dc=domain)))"
slapd[904]: conn=9479 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text=
Many thanks for your help,
Fabio
> On Apr 28, 2020, at 17:29, Nick Couchman <vn...@apache.org> wrote:
>
> On Tue, Apr 28, 2020 at 3:16 PM carlog <cgrossman@turlock.ca.us <ma...@turlock.ca.us>> wrote:
> Thank you for posting your working config. I, too, and using staging/1.2.0
> code. I matched mine up to yours, and made sure I had an appropriate line
> for each one of your lines, but still, no go. :(
>
> So far, I have the guacadmin account in AD, as well as in mysql. It's also
> using that account to bind to LDAP. When I log in as guacadmin, go to
> Users, there's only the guacadmin account. I can't add Admin access to any
> users because they aren't there.
>
>
> This is expected behavior - the guacadmin account, unless it also exists in LDAP, won't be able to see any of the LDAP users. The Guacamole LDAP extension, by design, only ever uses the search account from the guacamole.properties file to attempt to find a user who is logging in. It is not used as a generic query account to search for all items or users in LDAP. So, if the user logging in (guacadmin, for example), cannot authenticate to the LDAP directory, then you won't see any of the data for the LDAP directory with that user. You'll need to create an account in the JDBC module that matches one in your LDAP tree...
>
> ...which is possible! Now, you can't do it directly the way you can once you get an LDAP admin logged in, but all you have to do is create a new user in the JDBC module (using the guacadmin account) with a username that matches the LDAP user, and assign that account the correct permissions. You can leave the password field blank when you create this user, and Guacamole will auto-generate a password within the JDBC module. From that point, any time the user logs in and is authenticated with LDAP, the permissions from JDBC will match it.
>
> One thing to be aware of is that the JDBC module is case-sensitive with respect to users (and matching users from other modules), whereas most authentication systems tend to be case-insensitive. This has caused me some headaches in my environment when trying to assign users, because the LDAP module reads them in with the case they are entered (e.g. Nick_Couchman), but most people tend to log in with the simplest format (e.g. nick_couchman), and it can matter.
>
> -When I log in as my AD user, it will accept it, but I'm not an admin, so I
> only see limited menu options.
> -When I attempt to log in as another AD user that's not in the AD group
> specified in the search filter, it won't log in
> -When logged in as guacadmin, if I attempt to add a new user matching the
> name of an AD user account that should have access, I get an "internal error
> occured" message.
>
> This should not happen - something else is going on, here. You'll need to look at the log files for Tomcat and see what error it is throwing.
>
> -When I turn on debugging on my AD server, I see in the log that it matches
> my LDAP search filter (and appends sAMAccountName=*), and returns 60
> results, which are the 60 users that are in the AD group
>
> The same exact config on my Guac 1.0 server is running perfectly, so I'm
> confused why it isn't working for me in Guac 1.2.
>
>
> There were some pretty significant changes between 1.0.0 and 1.1.0 with regard to LDAP and how matching is done between the JDBC module and other modules. I would imagine you're hitting a variety of things, here.
>
> Best to work through the issues you're seeing systematically and solve them one-by-one.
>
> -Nick
Re: ldap-user-search-filter problem
Posted by carlog <cg...@turlock.ca.us>.
The guacadmin account does exist in Active Directory/LDAP. Shouldn't it be
able to see the rest of the users in the LDAP group?
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: ldap-user-search-filter problem
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Apr 28, 2020 at 3:16 PM carlog <cg...@turlock.ca.us> wrote:
> Thank you for posting your working config. I, too, and using staging/1.2.0
> code. I matched mine up to yours, and made sure I had an appropriate line
> for each one of your lines, but still, no go. :(
>
> So far, I have the guacadmin account in AD, as well as in mysql. It's also
> using that account to bind to LDAP. When I log in as guacadmin, go to
> Users, there's only the guacadmin account. I can't add Admin access to any
> users because they aren't there.
>
>
This is expected behavior - the guacadmin account, unless it also exists in
LDAP, won't be able to see any of the LDAP users. The Guacamole LDAP
extension, by design, only ever uses the search account from the
guacamole.properties file to attempt to find a user who is logging in. It
is not used as a generic query account to search for all items or users in
LDAP. So, if the user logging in (guacadmin, for example), cannot
authenticate to the LDAP directory, then you won't see any of the data for
the LDAP directory with that user. You'll need to create an account in the
JDBC module that matches one in your LDAP tree...
...which is possible! Now, you can't do it directly the way you can once
you get an LDAP admin logged in, but all you have to do is create a new
user in the JDBC module (using the guacadmin account) with a username that
matches the LDAP user, and assign that account the correct permissions.
You can leave the password field blank when you create this user, and
Guacamole will auto-generate a password within the JDBC module. From that
point, any time the user logs in and is authenticated with LDAP, the
permissions from JDBC will match it.
One thing to be aware of is that the JDBC module is case-sensitive with
respect to users (and matching users from other modules), whereas most
authentication systems tend to be case-insensitive. This has caused me
some headaches in my environment when trying to assign users, because the
LDAP module reads them in with the case they are entered (e.g.
Nick_Couchman), but most people tend to log in with the simplest format
(e.g. nick_couchman), and it can matter.
> -When I log in as my AD user, it will accept it, but I'm not an admin, so I
> only see limited menu options.
> -When I attempt to log in as another AD user that's not in the AD group
> specified in the search filter, it won't log in
> -When logged in as guacadmin, if I attempt to add a new user matching the
> name of an AD user account that should have access, I get an "internal
> error
> occured" message.
>
This should not happen - something else is going on, here. You'll need to
look at the log files for Tomcat and see what error it is throwing.
> -When I turn on debugging on my AD server, I see in the log that it matches
> my LDAP search filter (and appends sAMAccountName=*), and returns 60
> results, which are the 60 users that are in the AD group
>
> The same exact config on my Guac 1.0 server is running perfectly, so I'm
> confused why it isn't working for me in Guac 1.2.
>
>
There were some pretty significant changes between 1.0.0 and 1.1.0 with
regard to LDAP and how matching is done between the JDBC module and other
modules. I would imagine you're hitting a variety of things, here.
Best to work through the issues you're seeing systematically and solve them
one-by-one.
-Nick
Re: ldap-user-search-filter problem
Posted by carlog <cg...@turlock.ca.us>.
Thank you for posting your working config. I, too, and using staging/1.2.0
code. I matched mine up to yours, and made sure I had an appropriate line
for each one of your lines, but still, no go. :(
So far, I have the guacadmin account in AD, as well as in mysql. It's also
using that account to bind to LDAP. When I log in as guacadmin, go to
Users, there's only the guacadmin account. I can't add Admin access to any
users because they aren't there.
-When I log in as my AD user, it will accept it, but I'm not an admin, so I
only see limited menu options.
-When I attempt to log in as another AD user that's not in the AD group
specified in the search filter, it won't log in
-When logged in as guacadmin, if I attempt to add a new user matching the
name of an AD user account that should have access, I get an "internal error
occured" message.
-When I turn on debugging on my AD server, I see in the log that it matches
my LDAP search filter (and appends sAMAccountName=*), and returns 60
results, which are the 60 users that are in the AD group
The same exact config on my Guac 1.0 server is running perfectly, so I'm
confused why it isn't working for me in Guac 1.2.
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org
Re: ldap-user-search-filter problem
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Apr 28, 2020 at 10:54 AM Fabio Corsi <
fabio1299.discussionlists@gmail.com> wrote:
> I’m also still waiting to hear something about this problem. My post dated
> March 2, 2020 summarizes the problem and provides my LDAP log entries.
> Happy to repost if that makes it easier to find.
> Many thanks!
I'm using the staging/1.2.0 code with the following LDAP configuration:
ldap-hostname: ldap.example.com
ldap-port: 389
ldap-encryption-method: none
ldap-search-bind-dn: CN=Guac_Search_User,OU=IT,DC=example,DC=com
ldap-search-bind-password: T0p$ecret
ldap-user-base-dn: dc=example,dc=com
ldap-group-base-dn: ou=Guacamole_Groups,ou=Groups,ou=IT,dc=example,dc=com
ldap-username-attribute: sAMAccountName
ldap-user-search-filter:
(&(objectClass=user)(memberOf=CN=Guacamole_Users,OU=Guacamole_Groups,OU=Groups,OU=IT,DC=example,DC=com))
ldap-follow-referrals: false
This works fine for me - I'm authenticating against Active Directory, and
when I log in with my LDAP account I can see both the users and groups from
LDAP. Groups are only the ones listed in the ldap-group-base-dn search
base, above, and users are the only ones that are a member of the group
listed in the search filter.
-Nick
Re: ldap-user-search-filter problem
Posted by Fabio Corsi <fa...@gmail.com>.
I’m also still waiting to hear something about this problem. My post dated March 2, 2020 summarizes the problem and provides my LDAP log entries.
Happy to repost if that makes it easier to find.
Many thanks!
> On Apr 28, 2020, at 9:17 AM, carlog <cg...@turlock.ca.us> wrote:
>
> I turned on logging on the domain controller and I can see that it sends the
> proper LDAP search and returns 60 entries, like it should. I just can't see
> any of them in Guacamole.
>
>
>
> --
> Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
>
> ---------------------------------------------------------------------
> 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-user-search-filter problem
Posted by carlog <cg...@turlock.ca.us>.
I turned on logging on the domain controller and I can see that it sends the
proper LDAP search and returns 60 entries, like it should. I just can't see
any of them in Guacamole.
--
Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@guacamole.apache.org
For additional commands, e-mail: user-help@guacamole.apache.org