[
https://issues.apache.org/jira/browse/GUACAMOLE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16742993#comment-16742993
]
Micha Kohl commented on GUACAMOLE-702:
--------------------------------------
I wouldn't call this a duplicate. It is certainly related, though:
GUACAMOLE-299 (which I have referenced in the issue description) explicitly
mentions the warning that was the original behavior in 0.9.14. This behavior
changed with 1.0.0, where the login process now fails completely. Of course,
resolving GUACAMOLE-299 would provide a solution to this problem. However,
what's the reasoning behind failing hard all of a sudden? If I understand
correctly, the authentication bind is completely unrelated to the wildcard bind
that triggers the problem and breaks the login. The latter seems to be used
only to be able to render a list of all directory users in the guacamole
interface. In my scenario, where user permissions are [handled separately via
the MySQL
database|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database],
this list is not essential as user permissions can be changed by creating a
new user with a corresponding user id, instead of locating the LDAP user in the
list. I cannot speak for LDAP based permission management, of course, where it
might make sense to fail hard instead of offering up an incomplete user listing.
In short, the change from warning to a hard fail is breaking LDAP
authentication for no apparent reason in this scenario.
> LDAP login impossible for large directories (large search results)
> ------------------------------------------------------------------
>
> Key: GUACAMOLE-702
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-702
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
> Affects Versions: 1.0.0
> Environment: I'm running guacamole in a docker environment using the
> official base images and a MySQL database. Users are authenticated against an
> Active Directory server in combination with the MySQL database. (Although if
> my assumptions are correct, all of this will be irrelevant)
> Reporter: Micha Kohl
> Priority: Major
>
> I'm running into an issue that prevents me from logging in with LDAP
> authentication configured, which I assume to be the actual source of
> -GUACAMOLE-687- as well (which is why I originally commented on the closed
> issue before I decided to create a new one in the end).
> The login page error message I'm facing is:
> {quote}Unable to query list of objects from LDAP directory.
> {quote}
> which I assume stems from
> [here|https://github.com/apache/guacamole-client/blob/801a5df9f1d7095c52e594dda1a5276fe8cf6524/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ObjectQueryService.java#L231]
> in the new {{ObjectQueryService}}. There is nothing in the log indicating
> the source of this error, a debug log shows the line produced
> [here|https://github.com/apache/guacamole-client/blob/801a5df9f1d7095c52e594dda1a5276fe8cf6524/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ObjectQueryService.java#L194]
> and nothing more.
> This seems to be a problem with the size of the result as limiting the
> potential results via a restrictive {{ldap-user-search-filter}} fixes the
> issue.
> After digging through the code to confirm that nothing has changed
> fundamentally about the way LDAP queries are performed, I noticed that in
> version 0.9.14, the same scenario triggered a warning via this [catch
> block|https://github.com/apache/guacamole-client/blob/1c5951b6ac322a0d1e87ab787803275438d53983/extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java#L180],
> allowing the login process to continue normally, while it appears that in
> 1.0.0, the exception will prevent a login altogether.
> I was unable to work around this by increasing {{ldap-max-search-results}},
> which might be related to a separate issue (GUACAMOLE-299). As it stands,
> this means that I will not be able to use version 1.0.0 without maintaining a
> continuously updated {{ldap-user-search-filter}}, unless I'm missing
> something here.
> If this change was by design, I must say that I do not agree with the
> decision as long as {{ldap-max-search-results}} is buggy, as I don't see any
> problems with the old behavior: As long as the user can be successfully
> authenticated against LDAP, the only shortcoming was that the user listing in
> the web interface was incomplete, which is an annoyance at best.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
