guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <>
Subject Re: LDAP authentication - "Error while query user DNs"
Date Mon, 03 Apr 2017 00:26:22 GMT
On Sun, Apr 2, 2017 at 5:02 PM, Jonathan Hunter <> wrote:
> Having seen the latest release notes, I'm wondering if I should just
> use the new HTTP header based authentication (since I already have a
> working .htaccess file that works with LDAP).
> Is there much that the built-in LDAP authentication would offer, that
> HTTP header authentication wouldn't? I understand that both of them
> will allow a valid user to log in to Guacamole; and if using HTTP
> header authentication this wouldn't give the opportunity to store
> connection information in LDAP - but is there fundamentally anything
> else?

The two are pretty fundamentally different:

The LDAP authentication extension authenticates users against an LDAP
directory, using a provided username/password pair for credentials.
Users will see a username/password prompt if they aren't currently
logged in.

The HTTP header authentication extension trusts an arbitrary HTTP
header within the request. There is no verification whatsoever, no
validation of credentials. The user's identity is simply read from the

> I don't know why I'm getting the errors I am seeing (probably my
> inexperience with guacamole configuration) but the HTTP header
> authentication would seem to be a good way round this..

If your goal is to authenticate against LDAP, then I recommend
pursuing that. The HTTP header auth is not meant as a workaround in
case configuration of another authentication method fails; it's meant
to integrate with external auth systems which set trusted HTTP

Do you see anything in your Samba AD logs when Guacamole attempts (and
fails) to bind using LDAP?

Since you've verified via wireshark that Guacamole is successfully
querying the identity of the user, it may be the bind as that user
that's failing. When using a search DN, Guacamole will:

1) Bind using the search credentials
2) Query the DN of the user logging in
3) Attempt to bind at that queried user using their provided password

>From what you've said thus far, it sounds like #1 and #2 above are
working correctly, but #3 is not. The most likely explanation is that
the password is incorrect, but if the bind is being disallowed for
some other reason, the Samba logs might be revealing.

You mentioned that ldapsearch works correctly. Was this verified by
binding with the DN and password of the user in question?

- Mike

View raw message