Harry, you said you tried "modifying ldap-username-attribute to be
cn=users,cn=accounts,dc=example,dc=com" - just wanted to confirm.
Ldap-username-attribute should be an LDAP attribute name like cn. Could you
post your complete (redacted) guacamole.properties as you have it currently?

Also, I saw that on a previous attempt today you got the log message:

Nov 27 09:42:01 access server: 09:42:01.909 [http-bio-8080-exec-6] WARN
o.a.g.a.l.AuthenticationProviderService - Multiple DNs possible for user
"harry.devine": [uid=harry.devine,cn=users,cn=compat,dc=example,dc=com,
uid=harry.devine,cn=users,cn=accounts,dc=example,dc=com]

If you have two users under your search base with uid (or cn, or whatever
you are using for ldap-username-attribute) "harry.devine" you are going to
have to use a more specific search base or a more unique
ldap-username-attribute or a more restrictive search filter so that you
don't get multiple matches for the username you are typing into the
username field on the login page.

I.e., the attribute you match against has to uniquely identify the user
beneath your search base for your query.

-Jonathan Hankins

On Mon, Nov 27, 2017, 10:10 AM Nick Couchman <[email protected]> wrote:

> On Mon, Nov 27, 2017 at 10:02 AM, <[email protected]> wrote:
>
>> OK, so I tried that, including modifying ldap-username-attribute to be
>> cn=users,cn=accounts,dc=example,dc=com, and now I get a 403 error in the
>> Developer Tools, and the following error in /var/log/messages:
>>
>>
>>
>> Nov 27 10:00:34 access server: 10:00:34.766 [http-bio-8080-exec-8] WARN
>> o.a.g.r.auth.AuthenticationService - Authentication attempt from
>> xxx.xxx.xxx.xxx for user "harry.devine" failed.
>>
>>
>>
>> However, I know that the password is 100% correct.  Where to look now?  I
>> feel we’re getting very close.
>>
>>
>>
>
> What LDAP server are you running?  You probably mentioned it already
> somewhere in this thread, and I'm going to guess Active Directory, but just
> want to make sure?  If it's OpenLDAP then it is quite possible it is
> configured to disallow logins without some form of encryption (although I
> wouldn't expect the search bind to work in this case, but who knows).  AD
> doesn't usually have those restrictions, but depending on the environment,
> it actually might require encryption, as well.  Other than that, it would
> be useful to get a log from the LDAP server that indicates why it is
> failing authentication - if it believes the password is wrong, or if it is
> throwing some other sort of error.  I realize that you might be in an
> organization where you don't have access to that server or those logs, but,
> if you do, that would be helpful.
>
> -Nick
>

-- 
This e-mail is intended only for the recipient and may contain confidential 
or proprietary information. If you are not the intended recipient, the 
review, distribution, duplication or retention of this message and its 
attachments is prohibited. Please notify the sender of this error 
immediately by reply e-mail, and permanently delete this message and its 
attachments in any form in which they may have been preserved.

Reply via email to