guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hunter <>
Subject Re: LDAP authentication - "Error while query user DNs"
Date Mon, 03 Apr 2017 23:31:09 GMT
Thank you Mike - appreciated.

On 3 April 2017 at 01:26, Mike Jumper <> wrote:
> 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.
> 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
> headers.

Got it - thank you.

I think I probably expressed myself badly - and in most cases, using
the LDAP authentication extension would certainly be the right
solution - it was mostly a thought experiment borne from frustration
at not having managed to get the LDAP extension working, and
excitement at the news of the release of the HTTP auth extension :)

In my case, I already have a series of other web-facing services using
HTTP authentication; so in actual fact the HTTP auth extension would
probably fit in well for me, in that way at least - I'm not intending
on storing connection details in LDAP.

But, I'm sure that the LDAP authentication extension should still work
- thanks for responding below.

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

Unfortunately not - there are no errors logged; but wireshark does
(I'm pretty sure) record all the traffic that guacamole sends to the
LDAP server.

> 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.

I agree that #1 and #2 seem to be working fine; but unfortunately it
doesn't seem to get as far as #3 - there's just nothing in the packet
trace that shows it is even trying.

A complete wireshark trace runs as follows - no further packets past this point:
2066 15.499602 LDAP 231 bindRequest(7)
"cn=guacamole,cn=Users,dc=mydomain,dc=org" simple
2079 15.811743 LDAP 151 bindResponse(7) success
2080 15.827828 LDAP 247 searchRequest(8)
"dc=mydomain,dc=org" wholeSubtree
2204 16.138928 LDAP 319 searchResEntry(8)
"CN=Test User,OU=Users,OU=myou,DC=mydomain,DC=org"  | searchResRef(8)
| searchResRef(8)  | searchResRef(8)  | searchResDone(8) success  [1
2236 16.317141 LDAP 151 unbindRequest(9)

> You mentioned that ldapsearch works correctly. Was this verified by
> binding with the DN and password of the user in question?
> ("CN=testuser,OU=Users,OU=myou,DC=mydomain,DC=org").

I didn't try binding as the test user this time round (no LDAP utils
in the guacamole docker image by default, and I didn't install them);
however the user works fine for both UNIX and Windows logons, and does

Interestingly, however - I get the same result from guacamole whether
or not I supply the correct password for testuser. Either way (correct
p/w, or incorrect p/w), the exact same packet sequence as above is
captured - bind as guacamole user; search; unbind; nothing more.

I wondered if there was something database-related - so I turned on
MySQL query logging. I only saw one query:
SELECT user_id, username, password_hash, password_salt, password_date,
disabled, expired, access_window_start, access_window_end, valid_from,
valid_until, timezone FROM guacamole_user WHERE username = 'testuser'

This row does exist in the database - I added it manually - but I'm
not sure if the DB query would usually come after step #3 above or
not. Perhaps I added the database row incorrectly? Either way, I'd not
have thought that I'd get the "Cannot bind with LDAP server: Error
while query user DNs." error message if I hadn't added the DB row



"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein

View raw message