On Tue, Apr 28, 2020 at 3:16 PM carlog <cgross...@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

Reply via email to