You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@guacamole.apache.org by "Micha Kohl (JIRA)" <ji...@apache.org> on 2019/01/15 09:52:00 UTC

[jira] [Updated] (GUACAMOLE-702) LDAP login impossible for large directories (large search results)

     [ https://issues.apache.org/jira/browse/GUACAMOLE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Micha Kohl updated GUACAMOLE-702:
---------------------------------
    Description: 
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.

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

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.


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