[jira] [Commented] (GUACAMOLE-717) LDAP authentication fails if search result count exceeds ldap-max-search-result
[ https://issues.apache.org/jira/browse/GUACAMOLE-717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753124#comment-16753124 ] Joel Best commented on GUACAMOLE-717: - You are correct, I believe it is a duplicate. Sorry I missed that. Should I close this one and resubmit my PR under that issue? > LDAP authentication fails if search result count exceeds > ldap-max-search-result > --- > > Key: GUACAMOLE-717 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-717 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Joel Best >Priority: Minor > > If the search results from an LDAP search exceed ldap-max-search-results, the > search will fail and the user will receive an error on login. The logs do not > show any indication of what the problem is. > After troubleshooting, I've determined that the LDAPSearchResults.next() > function returns an LDAPException "Sizelimit Exceeded". In > ObjectQueryService.search(), this is not handled within the immediate > try/catch block so the other valid results are not returned to the calling > function. The fix is to also catch LDAPException when catching > LDAPReferralException. > Pull request is incoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-717) LDAP authentication fails if search result count exceeds ldap-max-search-result
[ https://issues.apache.org/jira/browse/GUACAMOLE-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Best updated GUACAMOLE-717: Summary: LDAP authentication fails if search result count exceeds ldap-max-search-result (was: LDAP authentication fails if Sizelimit Exceeded exception sent as as search result) > LDAP authentication fails if search result count exceeds > ldap-max-search-result > --- > > Key: GUACAMOLE-717 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-717 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0 >Reporter: Joel Best >Priority: Minor > > If the search results from an LDAP search exceed ldap-max-search-results, the > search will fail and the user will receive an error on login. The logs do not > show any indication of what the problem is. > After troubleshooting, I've determined that the LDAPSearchResults.next() > function returns an LDAPException "Sizelimit Exceeded". In > ObjectQueryService.search(), this is not handled within the immediate > try/catch block so the other valid results are not returned to the calling > function. The fix is to also catch LDAPException when catching > LDAPReferralException. > Pull request is incoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-717) LDAP authentication fails if Sizelimit Exceeded exception sent as as search result
Joel Best created GUACAMOLE-717: --- Summary: LDAP authentication fails if Sizelimit Exceeded exception sent as as search result Key: GUACAMOLE-717 URL: https://issues.apache.org/jira/browse/GUACAMOLE-717 Project: Guacamole Issue Type: Bug Components: guacamole-client Affects Versions: 1.0.0 Reporter: Joel Best If the search results from an LDAP search exceed ldap-max-search-results, the search will fail and the user will receive an error on login. The logs do not show any indication of what the problem is. After troubleshooting, I've determined that the LDAPSearchResults.next() function returns an LDAPException "Sizelimit Exceeded". In ObjectQueryService.search(), this is not handled within the immediate try/catch block so the other valid results are not returned to the calling function. The fix is to also catch LDAPException when catching LDAPReferralException. Pull request is incoming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-715) Permission management based on LDAP groups not working as documented
[
https://issues.apache.org/jira/browse/GUACAMOLE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16752243#comment-16752243
]
Joel Best commented on GUACAMOLE-715:
-
{quote}The following works:
# User in both LDAP and database
# Permission granted to group only in database
# User added to group only in LDAP{quote}
I haven't been able to get this to work. In my testing I found the user had to
be a member of both the MySQL group and the LDAP group in order for the
connections to appear.
> Permission management based on LDAP groups not working as documented
>
>
> Key: GUACAMOLE-715
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-715
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc-mysql, 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.
>Reporter: Micha Kohl
>Priority: Major
>
> From the documentation on user groups in 1.0.0 I expected to be able to
> manage user permissions via LDAP groups like this (using LDAP for
> authentication and MySQL for configuration management as documented
> [here|https://guacamole.apache.org/doc/gug/ldap-auth.html#ldap-and-database]):
> # Create user group in MySQL with the name of a corresponding user group in
> the LDAP directory
> # Create connection in MySQL
> # Grant connection permission to the user group created in 1.
> # LDAP users that are part of the LDAP group (in the directory) are able to
> log in with their LDAP credentials and access that connection
> This does not work at all (the user does not even see the connection). In my
> attempt to narrow down the problem and ensure that I'm not just doing it
> wrong, I tested the following scenarios:
> # _Having just the LDAP group be mirrored in MySQL by creating an_
> _identically named one there_
> -> Login succeeds, but no associated connections are shown.
> # _Having both the LDAP group and the user be mirrored in MySQL by creating_
> _identically named entities there without manually linking the two (MySQL
> user is not part of MySQL user group)_
> -> Login succeeds and guacamole tries to auto-connect to the only available
> connection/shows all available connections and fails when trying to connect
> with a permission error.
> # _Having both the LDAP group and the user be mirrored in MySQL by creating_
> _identically named entities there and manually adding the MySQL user to the_
> _MySQL group_ _(MySQL user is part of MySQL user group)_
> -> Connections are established successfully.
> Either there seems to be a big misunderstanding regarding the way the new
> group system is supposed to work with LDAP, or there's something going wrong
> here. It goes without saying that scenario 3 completely eliminates the
> purpose of relying on existing LDAP groups. Scenario 1 is the configuration I
> outlined above that would allow managing connections based on LDAP groups
> without having to create any MySQL users whatsoever. Scenario 2 in
> combination with similar reports on the mailing list led me to believe that
> this is either based on a common misconception or there's a bug.
> Side-Note: While it has been suggested that this is already covered by
> GUACAMOLE-696, I think this could only be said if this turns out to be
> expected but poorly documented behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GUACAMOLE-716) Add all LDAP properties to Docker start script
Joel Best created GUACAMOLE-716: --- Summary: Add all LDAP properties to Docker start script Key: GUACAMOLE-716 URL: https://issues.apache.org/jira/browse/GUACAMOLE-716 Project: Guacamole Issue Type: Improvement Components: guacamole-docker Reporter: Joel Best There are still some LDAP properties that are not properly mapped in the start.sh script used for the Docker container: # ldap-group-name-attribute # ldap-dereference-aliases # ldap-max-referral-hops # ldap-operation-timeout # ldap-max-search-results I also noticed some of the set_optional_property calls are broken up over multiple lines but will be less than 80 columns if merged to one line. Finally, I plan to re-order the lines in the script to try to match the [LDAP authentication documentation|https://guacamole.apache.org/doc/gug/ldap-auth.html] as closely as possible. Pull request will be submitted shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-713) Add configuration setting for logback logging verbosity level
[
https://issues.apache.org/jira/browse/GUACAMOLE-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750201#comment-16750201
]
Joel Best commented on GUACAMOLE-713:
-
Okay, PR submitted: [https://github.com/apache/guacamole-client/pull/366]
> Add configuration setting for logback logging verbosity level
> -
>
> Key: GUACAMOLE-713
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-713
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-client
>Reporter: Joel Best
>Priority: Minor
>
> I've noticed during my troubleshooting process that it is cumbersome to
> enable debug logging for guacamole, especially when using docker. Currently
> to enable debug logging, I start the container and then replace the setting
> in the default logback.xml file with this command:
>
> {code:java}
> sed -i 's/level="info"/level="debug"/'
> /usr/local/tomcat/webapps/guacamole/WEB-INF/classes/logback.xml
> {code}
> I then restart the container. I know I can also copy logback.xml to
> GUACAMOLE_HOME but this is easier for the docker use case.
>
> I think it would be better if there was a guacamole.properties setting for
> the logback level. E.g.:
> logback-level: [trace|debug|info|warn|error]
> For my Docker use case, I think this is the best solution as I can then use
> set_optional_property in start.sh to populate this setting.
>
> Alternatively, I would propose that the Docker start.sh script checks for an
> environment variable (LOGBACK_LEVEL?) and copies and modifies the logback
> settings directly. E.g.
> {code:java}
> if [ -n "$LOGBACK_LEVEL" ]; then
> unzip -o -j /opt/guacamole/guacamole.war WEB-INF/classes/logback.xml -d
> $GUACAMOLE_HOME
> sed -i "s/level=\"info\"/level=\"$LOGBACK_LEVEL\"/"
> $GUACAMOLE_HOME/logback.xml
> fi
> {code}
> It's less elegant, but it works for my use case.
> Thoughts?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GUACAMOLE-713) Add configuration setting for logback logging verbosity level
Joel Best created GUACAMOLE-713:
---
Summary: Add configuration setting for logback logging verbosity
level
Key: GUACAMOLE-713
URL: https://issues.apache.org/jira/browse/GUACAMOLE-713
Project: Guacamole
Issue Type: New Feature
Components: guacamole-client
Reporter: Joel Best
I've noticed during my troubleshooting process that it is cumbersome to enable
debug logging for guacamole, especially when using docker. Currently to enable
debug logging, I start the container and then replace the setting in the
default logback.xml file with this command:
{code:java}
sed -i 's/level="info"/level="debug"/'
/usr/local/tomcat/webapps/guacamole/WEB-INF/classes/logback.xml
{code}
I then restart the container. I know I can also copy logback.xml to
GUACAMOLE_HOME but this is easier for the docker use case.
I think it would be better if there was a guacamole.properties setting for the
logback level. E.g.:
logback-level: [trace|debug|info|warn|error]
For my Docker use case, I think this is the best solution as I can then use
set_optional_property in start.sh to populate this setting.
Alternatively, I would propose that the Docker start.sh script checks for an
environment variable (LOGBACK_LEVEL?) and copies and modifies the logback
settings directly. E.g.
{code:java}
if [ -n "$LOGBACK_LEVEL" ]; then
unzip -o -j /opt/guacamole/guacamole.war WEB-INF/classes/logback.xml -d
$GUACAMOLE_HOME
sed -i "s/level=\"info\"/level=\"$LOGBACK_LEVEL\"/"
$GUACAMOLE_HOME/logback.xml
fi
{code}
It's less elegant, but it works for my use case.
Thoughts?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
