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 <[email protected]> wrote: > > On Tue, Apr 28, 2020 at 3:16 PM carlog <[email protected] > <mailto:[email protected]>> 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
