[jira] [Commented] (GUACAMOLE-944) LDAP broken in 1.1.0
[ https://issues.apache.org/jira/browse/GUACAMOLE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030401#comment-17030401 ] Ross commented on GUACAMOLE-944: Thanks [~mjumper]. Using the full LDAP DN seems to have resolved the issue. > LDAP broken in 1.1.0 > > > Key: GUACAMOLE-944 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-944 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 1.1.0 > Environment: Kubernetes 1.16.4 >Reporter: Ross >Priority: Major > > On upgrading our Guacamole container from 1.0.0 to 1.1.0, it fails to > authenticate. Error message in logs is: > 03-Feb-2020 13:37:15.136 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 3675 > ms13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider has > encountered an internal error which will halt the authentication process. If > this is unexpected or you are the developer of this authentication provider, > you may wish to enable debug-level logging. If this is expected and you wish > to ignore such failures in the future, please set "skip-if-unavailable: ldap" > within your guacamole.properties.13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.r.auth.AuthenticationService - Authentication attempt from > [1.20.211.22, 10.42.4.0] for user "rossg" failed. > Workaround is to switch back to 1.0.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GUACAMOLE-944) LDAP broken in 1.1.0
[ https://issues.apache.org/jira/browse/GUACAMOLE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ross closed GUACAMOLE-944. -- Resolution: Fixed > LDAP broken in 1.1.0 > > > Key: GUACAMOLE-944 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-944 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 1.1.0 > Environment: Kubernetes 1.16.4 >Reporter: Ross >Priority: Major > > On upgrading our Guacamole container from 1.0.0 to 1.1.0, it fails to > authenticate. Error message in logs is: > 03-Feb-2020 13:37:15.136 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 3675 > ms13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider has > encountered an internal error which will halt the authentication process. If > this is unexpected or you are the developer of this authentication provider, > you may wish to enable debug-level logging. If this is expected and you wish > to ignore such failures in the future, please set "skip-if-unavailable: ldap" > within your guacamole.properties.13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.r.auth.AuthenticationService - Authentication attempt from > [1.20.211.22, 10.42.4.0] for user "rossg" failed. > Workaround is to switch back to 1.0.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-944) LDAP broken in 1.1.0
[
https://issues.apache.org/jira/browse/GUACAMOLE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030155#comment-17030155
]
Mike Jumper commented on GUACAMOLE-944:
---
{quote}
- name: LDAP_SEARCH_BIND_DN
value: guacam...@agentdesign.co.uk
{quote}
I think this may be the issue. The changes from GUACAMOLE-234 effectively added
DN validation around the search bind DN. The 1.1.0 version of the LDAP support
is likely refusing to use this value as it isn't a DN, whereas there was no
such validation in 1.0.0 and older. There may be an error to that effect
earlier in the logs.
[~rossg], assuming there is an LDAP DN equivalent for that user, can you try
using the DN and see whether things start working?
{quote}
Not sure how to put it into debug mode. Do you have a link to some docs
explaining how to do this?
{quote}
It looks like the documentation for this is missing, but the variable to set
for the {{guacamole/guacamole}} Docker image would be {{LOGBACK_LEVEL}}
(GUACAMOLE-713). If you set that variable to "debug", you should start seeing
debug-level messages in your Docker logs.
> LDAP broken in 1.1.0
>
>
> Key: GUACAMOLE-944
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-944
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
>Affects Versions: 1.1.0
> Environment: Kubernetes 1.16.4
>Reporter: Ross
>Priority: Major
>
> On upgrading our Guacamole container from 1.0.0 to 1.1.0, it fails to
> authenticate. Error message in logs is:
> 03-Feb-2020 13:37:15.136 INFO [main]
> org.apache.catalina.startup.Catalina.start Server startup in 3675
> ms13:38:12.579 [http-nio-8080-exec-9] WARN
> o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider has
> encountered an internal error which will halt the authentication process. If
> this is unexpected or you are the developer of this authentication provider,
> you may wish to enable debug-level logging. If this is expected and you wish
> to ignore such failures in the future, please set "skip-if-unavailable: ldap"
> within your guacamole.properties.13:38:12.579 [http-nio-8080-exec-9] WARN
> o.a.g.r.auth.AuthenticationService - Authentication attempt from
> [1.20.211.22, 10.42.4.0] for user "rossg" failed.
> Workaround is to switch back to 1.0.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-945) Migrating away from libssh2 dependency?
[ https://issues.apache.org/jira/browse/GUACAMOLE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029804#comment-17029804 ] Nick Couchman commented on GUACAMOLE-945: - ...and, looks like RHEL8 ships with libssh (vs. libssh2), so not sure how much work it would be to support both of those options. > Migrating away from libssh2 dependency? > --- > > Key: GUACAMOLE-945 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-945 > Project: Guacamole > Issue Type: Improvement > Components: guacd >Reporter: Joonas Tuomisto >Priority: Minor > > It appears Red Hat / CentOS stopped shipping libssh2 in version 8 which makes > building Guacamole a hassle on those platforms - of course, this has nothing > to do with Guacamole as such, but would it make sense to consider other > libraries? > I didn't look into this in depth so not sure if there's major benefits > feature-wise and how much work this would entail... > > libssh seems to have undergone an external security audit recently so > security could be one consideration. > > re: CentOS, this is discussed here: https://bugs.centos.org/view.php?id=16492 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-945) Migrating away from libssh2 dependency?
[ https://issues.apache.org/jira/browse/GUACAMOLE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029801#comment-17029801 ] Nick Couchman commented on GUACAMOLE-945: - Interesting, and a shame. The power of libssh2 is that it's very simple and straight-forward to use - it does a few things very well, and that's pretty much all we need. We could look at adding support for or migrating to the OpenSSH library - I'm guessing that's the most available and popular one - it's just going to take some work to make the switch, and I don't know if there are any licensing issues, although that tends to be less of an issue with guacd since we don't distribute binary code. Thanks for submitting this - definitely good to know for our roadmap. > Migrating away from libssh2 dependency? > --- > > Key: GUACAMOLE-945 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-945 > Project: Guacamole > Issue Type: Improvement > Components: guacd >Reporter: Joonas Tuomisto >Priority: Minor > > It appears Red Hat / CentOS stopped shipping libssh2 in version 8 which makes > building Guacamole a hassle on those platforms - of course, this has nothing > to do with Guacamole as such, but would it make sense to consider other > libraries? > I didn't look into this in depth so not sure if there's major benefits > feature-wise and how much work this would entail... > > libssh seems to have undergone an external security audit recently so > security could be one consideration. > > re: CentOS, this is discussed here: https://bugs.centos.org/view.php?id=16492 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-945) Migrating away from libssh2 dependency?
[ https://issues.apache.org/jira/browse/GUACAMOLE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-945: Priority: Minor (was: Major) > Migrating away from libssh2 dependency? > --- > > Key: GUACAMOLE-945 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-945 > Project: Guacamole > Issue Type: Improvement > Components: guacd >Affects Versions: 1.1.0 >Reporter: Joonas Tuomisto >Priority: Minor > > It appears Red Hat / CentOS stopped shipping libssh2 in version 8 which makes > building Guacamole a hassle on those platforms - of course, this has nothing > to do with Guacamole as such, but would it make sense to consider other > libraries? > I didn't look into this in depth so not sure if there's major benefits > feature-wise and how much work this would entail... > > libssh seems to have undergone an external security audit recently so > security could be one consideration. > > re: CentOS, this is discussed here: https://bugs.centos.org/view.php?id=16492 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-945) Migrating away from libssh2 dependency?
[ https://issues.apache.org/jira/browse/GUACAMOLE-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-945: Affects Version/s: (was: 1.1.0) > Migrating away from libssh2 dependency? > --- > > Key: GUACAMOLE-945 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-945 > Project: Guacamole > Issue Type: Improvement > Components: guacd >Reporter: Joonas Tuomisto >Priority: Minor > > It appears Red Hat / CentOS stopped shipping libssh2 in version 8 which makes > building Guacamole a hassle on those platforms - of course, this has nothing > to do with Guacamole as such, but would it make sense to consider other > libraries? > I didn't look into this in depth so not sure if there's major benefits > feature-wise and how much work this would entail... > > libssh seems to have undergone an external security audit recently so > security could be one consideration. > > re: CentOS, this is discussed here: https://bugs.centos.org/view.php?id=16492 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-946) Russian layout in VNC to Linux
[ https://issues.apache.org/jira/browse/GUACAMOLE-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasilii Kuznetcov updated GUACAMOLE-946: Priority: Minor (was: Major) > Russian layout in VNC to Linux > -- > > Key: GUACAMOLE-946 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-946 > Project: Guacamole > Issue Type: Bug > Components: guacamole, VNC >Affects Versions: 1.0.0 > Environment: 3.10.0-957.12.2.el7.x86_64 guacamole host, virtualized > in vmware >Reporter: Vasilii Kuznetcov >Priority: Minor > Labels: bug, input, language, vnc > > Hello, dear support team! > What was expected: > Connecting to Linux host via VNC from guacamole, changing the language to > Russian (just to be sure that was made in the remote system and in the system > accessing to guacamole), trying to type some text and get all the > letters/symbols that I pressed on the text editor/console. > What went wrong: some keys do not type any sign. > Diving deep: > Tested on different OS (windows 8.1 and 10 and CentOS 7) from different > browsers (Google Chrome and Mozilla firefox) on guacamole 1.0 and staging-1.1 > (build of May 2019). As VNC hosts were used RedHat 7 and CentOS 8. Of course, > it was tested with VNC client (tigervnc) to test if this problems exist on > server side and there were no problem. > What is interesting that it's always 7 keys that are not working in the lower > case (In upper it is just one key). That is very interesting becasue in > cyrillic alphabet 33 letters and in english 26 and 7 makes the difference > between this numbers. The missing letters differs if the different layout of > russian were chosen so there can be an assumption that the problem is > something there. xev shows no key press when the missing letters are pressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GUACAMOLE-946) Russian layout in VNC to Linux
Vasilii Kuznetcov created GUACAMOLE-946: --- Summary: Russian layout in VNC to Linux Key: GUACAMOLE-946 URL: https://issues.apache.org/jira/browse/GUACAMOLE-946 Project: Guacamole Issue Type: Bug Components: guacamole, VNC Affects Versions: 1.0.0 Environment: 3.10.0-957.12.2.el7.x86_64 guacamole host, virtualized in vmware Reporter: Vasilii Kuznetcov Hello, dear support team! What was expected: Connecting to Linux host via VNC from guacamole, changing the language to Russian (just to be sure that was made in the remote system and in the system accessing to guacamole), trying to type some text and get all the letters/symbols that I pressed on the text editor/console. What went wrong: some keys do not type any sign. Diving deep: Tested on different OS (windows 8.1 and 10 and CentOS 7) from different browsers (Google Chrome and Mozilla firefox) on guacamole 1.0 and staging-1.1 (build of May 2019). As VNC hosts were used RedHat 7 and CentOS 8. Of course, it was tested with VNC client (tigervnc) to test if this problems exist on server side and there were no problem. What is interesting that it's always 7 keys that are not working in the lower case (In upper it is just one key). That is very interesting becasue in cyrillic alphabet 33 letters and in english 26 and 7 makes the difference between this numbers. The missing letters differs if the different layout of russian were chosen so there can be an assumption that the problem is something there. xev shows no key press when the missing letters are pressed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-944) LDAP broken in 1.1.0
[ https://issues.apache.org/jira/browse/GUACAMOLE-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029670#comment-17029670 ] Ross commented on GUACAMOLE-944: [~mjumper] - Configuration values... containers: - env: - name: GUACAMOLE_HOME value: /opt/guacamole - name: GUACD_HOSTNAME value: guacd - name: GUACD_PORT value: "4822" - name: LDAP_ENCRYPTION_METHOD value: none - name: LDAP_HOSTNAME value: 127.0.0.1 - name: LDAP_PORT value: "389" - name: LDAP_SEARCH_BIND_DN value: guacam...@agentdesign.co.uk - name: LDAP_SEARCH_BIND_PASSWORD value: nottellingyou - name: LDAP_USERNAME_ATTRIBUTE value: sAMAccountName - name: LDAP_USER_BASE_DN value: CN=Users,DC=agent,DC=local - name: MYSQL_DATABASE value: guacamole - name: MYSQL_HOSTNAME value: master.db - name: MYSQL_PASSWORD value: alsonottellingyou - name: MYSQL_USER value: guacamole image: guacamole/guacamole:1.0.0 It's an ActiveDirectory server, standard structure. I can't provide the logs right now, as there will be staff using it. I'll run it with the new version again one morning before anyone is using it and provide the full logs. [~vnick] - Not sure how to put it into debug mode. Do you have a link to some docs explaining how to do this? The JRE/JDK and Tomcat versions will be those built into the official 1.1.0 container... https://hub.docker.com/layers/guacamole/guacamole/1.1.0/images/sha256-333a7f40c145f2487166f63bea671d5708750875259515a38d34ad304755583a > LDAP broken in 1.1.0 > > > Key: GUACAMOLE-944 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-944 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 1.1.0 > Environment: Kubernetes 1.16.4 >Reporter: Ross >Priority: Major > > On upgrading our Guacamole container from 1.0.0 to 1.1.0, it fails to > authenticate. Error message in logs is: > 03-Feb-2020 13:37:15.136 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 3675 > ms13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.e.AuthenticationProviderFacade - The "ldap" authentication provider has > encountered an internal error which will halt the authentication process. If > this is unexpected or you are the developer of this authentication provider, > you may wish to enable debug-level logging. If this is expected and you wish > to ignore such failures in the future, please set "skip-if-unavailable: ldap" > within your guacamole.properties.13:38:12.579 [http-nio-8080-exec-9] WARN > o.a.g.r.auth.AuthenticationService - Authentication attempt from > [1.20.211.22, 10.42.4.0] for user "rossg" failed. > Workaround is to switch back to 1.0.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
