[jira] [Commented] (GUACAMOLE-952) Preconnection Blob Support Broken
[ https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034156#comment-17034156 ] Joachim Lindenberg commented on GUACAMOLE-952: -- "If you switch back and forth between a 1.0.0 build and 1.1.0 build, do things reliably work and reliably fail respectively?" clear yes. I only swith container versions of guacd and guacamole to 1.0 and it works, or to 1.1.0 and it fails. To the best of my knowledge, I specifiy port 2179, cert-ignore, and security NLA - I think that is required nowadays and it is also shown in the log attached. (cert-ignore btw. was not strictly required previously but newer versions of freerdp need it - now newer is relative, the wfreerdp I downloaded is a nightly build of 2000/02, the freerdp included in guacd 1.1. is probably ten months older). Whereas NLA is shown in guacd debug log, other values used to connect are not shown. What about adding all of them to ease debugging? And depending on who denies the connection: do you know of any Hyper-V log that might provide a hint? > Preconnection Blob Support Broken > - > > Key: GUACAMOLE-952 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-952 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 1.1.0 >Reporter: Nick Couchman >Priority: Minor > Attachments: guacd.log > > > After the switch to FreeRDP 2, support for setting the Preconnection Blob (to > connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP > 2.x code still supports it, but something about the detection on the > Guacamole side seems to detect it as missing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-950) segfault in guacd
[ https://issues.apache.org/jira/browse/GUACAMOLE-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034147#comment-17034147 ] Mike Jumper commented on GUACAMOLE-950: --- Yes, thanks, this is perfect. > segfault in guacd > -- > > Key: GUACAMOLE-950 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-950 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.1.0 > Environment: Guacamole 1.1.0 under Tomcat8 on Ubuntu 18.04, running > as virtual machine >Reporter: Toby Creek >Priority: Minor > Attachments: trace_connected.txt, trace_segfault.txt > > > Upgraded from 1.0.0 on Ubuntu 16.04 to 1.1.0 on Ubuntu 18.04. Moved from > Tomcat7 to Tomcat8. Config is largely unchanged. > Two Windows 10 Enterprise destinations and a third is 2012R2. One of the two > Windows 10 will cause guacd to segfault on connection. 2012R2 works fine. I > see a mouse pointer in the upper left very briefly and then I get > home/reconnect/logout. I have pared the config down to just domain, > username, password, NLA security, ignore-cert directives for all three > destinations. > Uploaded syslog traces, one of a normal connect to the other windows 10 > device, one as the segmentation fault I get when connecting to the other. > Have also tried rebuilding without webp and websockets to no effect. > I'm happy to build one for gdb and get a core, but I'll need a little help > doing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-950) segfault in guacd
[ https://issues.apache.org/jira/browse/GUACAMOLE-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034145#comment-17034145 ] Toby commented on GUACAMOLE-950: Am I getting closer to the data that will help? #0 0x in () #1 0x7fa2deb05f09 in fastpath_recv_update (fastpath=fastpath@entry=0x7fa2cc02b190, updateCode=, size=size@entry=4, s=s@entry=0x7fa2cc025050) at ./libfreerdp/core/fastpath.c:438 #2 0x7fa2deb06a12 in fastpath_recv_update_data (s=0x7fa2cc025050, fastpath=0x7fa2cc02b190) at ./libfreerdp/core/fastpath.c:538 #3 0x7fa2deb06a12 in fastpath_recv_updates (fastpath=0x7fa2cc02b190, s=s@entry=0x7fa2cc025050) at ./libfreerdp/core/fastpath.c:666 #4 0x7fa2deb014b6 in rdp_recv_fastpath_pdu (s=0x7fa2cc025050, rdp=0x7fa2cc016b00) at ./libfreerdp/core/rdp.c:1292 #5 0x7fa2deb014b6 in rdp_recv_pdu (rdp=rdp@entry=0x7fa2cc016b00, s=s@entry=0x7fa2cc025050) at ./libfreerdp/core/rdp.c:1300 #6 0x7fa2deb02113 in rdp_recv_callback (transport=, s=0x7fa2cc025050, extra=0x7fa2cc016b00) at ./libfreerdp/core/rdp.c:1446 #7 0x7fa2deb0a229 in transport_check_fds (transport=transport@entry=0x7fa2cc024b30) at ./libfreerdp/core/transport.c:1030 #8 0x7fa2deb025f8 in rdp_check_fds (rdp=0x7fa2cc016b00) at ./libfreerdp/core/rdp.c:1505 #9 0x7fa2deaed667 in freerdp_check_fds (instance=0x7fa2cc00bb20) at ./libfreerdp/core/freerdp.c:316 #10 0x7fa2deaee451 in freerdp_check_event_handles (context=0x7fa2cc011a30) at ./libfreerdp/core/freerdp.c:365 #11 0x7fa2dede5bba in guac_rdp_handle_connection (client=0x7fa2d800b350) at rdp.c:428 #12 0x7fa2dede60df in guac_rdp_client_thread (data=0x7fa2d800b350) at rdp.c:641 #13 0x7fa2e38f86db in start_thread (arg=0x7fa2d280f700) at pthread_create.c:463 #14 0x7fa2e339488f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 > segfault in guacd > -- > > Key: GUACAMOLE-950 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-950 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.1.0 > Environment: Guacamole 1.1.0 under Tomcat8 on Ubuntu 18.04, running > as virtual machine >Reporter: Toby >Priority: Minor > Attachments: trace_connected.txt, trace_segfault.txt > > > Upgraded from 1.0.0 on Ubuntu 16.04 to 1.1.0 on Ubuntu 18.04. Moved from > Tomcat7 to Tomcat8. Config is largely unchanged. > Two Windows 10 Enterprise destinations and a third is 2012R2. One of the two > Windows 10 will cause guacd to segfault on connection. 2012R2 works fine. I > see a mouse pointer in the upper left very briefly and then I get > home/reconnect/logout. I have pared the config down to just domain, > username, password, NLA security, ignore-cert directives for all three > destinations. > Uploaded syslog traces, one of a normal connect to the other windows 10 > device, one as the segmentation fault I get when connecting to the other. > Have also tried rebuilding without webp and websockets to no effect. > I'm happy to build one for gdb and get a core, but I'll need a little help > doing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GUACAMOLE-956) Migrate away from including auth token within REST API URLs
Mike Jumper created GUACAMOLE-956:
-
Summary: Migrate away from including auth token within REST API
URLs
Key: GUACAMOLE-956
URL: https://issues.apache.org/jira/browse/GUACAMOLE-956
Project: Guacamole
Issue Type: Improvement
Components: guacamole
Reporter: Mike Jumper
Guacamole's current REST API relies on including the user's auth token within
the {{token}} query parameter. Using a query parameter in this way is generally
regarded as bad practice, as other software between the user and the webapp may
log the content of URLs and GET requests insecurely, including these parameters.
We should instead leverage HTTP headers, allowing the {{token}} parameter to be
used only for compatibility's sake.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GUACAMOLE-956) Migrate away from including auth token within REST API URLs
[
https://issues.apache.org/jira/browse/GUACAMOLE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reassigned GUACAMOLE-956:
-
Assignee: Mike Jumper
> Migrate away from including auth token within REST API URLs
> ---
>
> Key: GUACAMOLE-956
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-956
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
>
> Guacamole's current REST API relies on including the user's auth token within
> the {{token}} query parameter. Using a query parameter in this way is
> generally regarded as bad practice, as other software between the user and
> the webapp may log the content of URLs and GET requests insecurely, including
> these parameters.
> We should instead leverage HTTP headers, allowing the {{token}} parameter to
> be used only for compatibility's sake.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GUACAMOLE-955) Untranslated error strings from extensions must not be interpreted as HTML
[ https://issues.apache.org/jira/browse/GUACAMOLE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reassigned GUACAMOLE-955: - Assignee: Mike Jumper > Untranslated error strings from extensions must not be interpreted as HTML > -- > > Key: GUACAMOLE-955 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-955 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Minor > > The translation system that we use alongside AngularJS (angular-translate) > suffers from an issue which allows interpretation of raw HTML if that HTML is > within a translation key that does not exist: > https://github.com/angular-translate/angular-translate/issues/1418 > This doesn't happen to have security implications in our case, as the > behavior is isolated to error message rendering (it cannot be stored, can > only be self-inflicted, and can only occur through manually interacting with > the UI), but it really should be addressed. The current behavior makes it too > easy for a carelessly-written extension to accidentally introduce an issue > that _does_ have security implications. > As untranslated errors are conveyed via JSON in a different way than > translated errors, the client-side code should render errors in a way that > avoids this entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GUACAMOLE-955) Untranslated error strings from extensions must not be interpreted as HTML
Mike Jumper created GUACAMOLE-955: - Summary: Untranslated error strings from extensions must not be interpreted as HTML Key: GUACAMOLE-955 URL: https://issues.apache.org/jira/browse/GUACAMOLE-955 Project: Guacamole Issue Type: Bug Components: guacamole Reporter: Mike Jumper The translation system that we use alongside AngularJS (angular-translate) suffers from an issue which allows interpretation of raw HTML if that HTML is within a translation key that does not exist: https://github.com/angular-translate/angular-translate/issues/1418 This doesn't happen to have security implications in our case, as the behavior is isolated to error message rendering (it cannot be stored, can only be self-inflicted, and can only occur through manually interacting with the UI), but it really should be addressed. The current behavior makes it too easy for a carelessly-written extension to accidentally introduce an issue that _does_ have security implications. As untranslated errors are conveyed via JSON in a different way than translated errors, the client-side code should render errors in a way that avoids this entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-846) tunnel.uuid not initialized if tunnel becomes UNSTABLE
[
https://issues.apache.org/jira/browse/GUACAMOLE-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-846:
--
Fix Version/s: 1.2.0
> tunnel.uuid not initialized if tunnel becomes UNSTABLE
> --
>
> Key: GUACAMOLE-846
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-846
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common-js
>Affects Versions: 1.0.0
>Reporter: avwx
>Priority: Major
> Fix For: 1.2.0
>
>
> We are operating a distributed system with a single MySQL server running in
> one geographical region and multiple Guacamole nodes running in many
> locations worldwide. We noticed that some Guacamole instances were not able
> to use the file upload feature. The POST request for the upload would always
> return a 404 error and after further inspection, we noticed that the tunnel
> id used in the post request was null (e.g.
> [https://myguacamole.com/api/session/tunnels/null/streams/1/filename.png?token=]...)
> After digging into the guacamole-common-js code some more, we noticed that
> the tunnel uuid is only set if the tunnel is in the CONNECTING state
> ([https://github.com/apache/guacamole-client/blob/master/guacamole-common-js/src/main/webapp/modules/Tunnel.js#L1018]).
> In our case, the round-trip to the MySQL server adds a significant latency
> to the tunnel opening and the tunnel switches into the UNSTABLE state before
> the tunnel UUID is transferred. Therefore, the tunnel UUID is never set and
> any file upload fails.
> I'm proposing to change the previously linked to condition to the following:
> {code:javascript}
> if (tunnel.state === Guacamole.Tunnel.State.CONNECTING || tunnel.uuid ===
> null) {
> {code}
>
> I'm happy to provide a PR if this sounds reasonable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-300) Support posixGroup in LDAP Authentication and Group-based Session Admission
[ https://issues.apache.org/jira/browse/GUACAMOLE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-300: -- Fix Version/s: 1.2.0 > Support posixGroup in LDAP Authentication and Group-based Session Admission > --- > > Key: GUACAMOLE-300 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-300 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap > Environment: Oracle Solaris 11.3.19.5.0, Apache Tomcat 8.5.9, > OpenLDAP 2.4.30, LDAP users are organized using the posixGroup scheme. >Reporter: Steffen Moser >Priority: Minor > Fix For: 1.2.0 > > Attachments: LDAP-posixGroup-support_SteffenMoser-20170514.patch > > > Recently, the auth-ldap module was extended by the ability to grant access to > remote terminal connections based on existing LDAP groups using the seeAlso > attribute in Guacamole's LDAP-based configuration settings. This is a great > feature if you've to manage a lot of users which are already organized in > LDAP groups. It works well as long as the groups are of the scheme > groupOfNames. As we have decided for posixGroup (due to other tools' > requirements), we currently cannot use the feature and still have to list all > users individually in the Guacamole remote service configuration. While this > could be scripted easily, it is still a work-around which makes the > administration work unnecessarily complex. > A better solution would be to support both schemes, posixGroup and > groupOfNames. > The attached patch will extend the user lookup code by the ability to search > not only through the groupOfNames but also through the posixGroup scheme. The > piece of code seems to work with both schemes in my tests successfully, I am > not sure if there are any pitfalls when just combining the possible results. > Maybe introducing a configuration flag to choose whether searching posixGroup > or groupOfNames would be a better approach. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-952) Preconnection Blob Support Broken
[
https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034080#comment-17034080
]
Mike Jumper edited comment on GUACAMOLE-952 at 2/11/20 2:10 AM:
I'm not seeing any difference between the values we're setting and the values
that xfreerdp/wfreerdp/etc. are using. If the client you're testing against is
using the same version of FreeRDP that Guacamole was built against, I'd expect
things to be working.
I do see some differences in the handling of other values when preconnection
IDs and blobs are in play:
* If FreeRDP's {{/vmconnect}} option is used, FreeRDP silently changes the
server port from 3389 to 2179. For Guacamole, if that's needed, you would have
to manually specify that port. Guacamole will always use 3389 unless told
otherwise.
* Guacamole sets {{rdp_settings->NegotiateSecurityLayer}} to {{FALSE}} whenever
a preconnection ID or blob is specified. For FreeRDP, this only occurs with
{{/vmconnect}} but will not occur with {{/pcb}} or {{/pcid}}.
[~jol], do either of the above apply in your case? If you switch back and forth
between a 1.0.0 build and 1.1.0 build, do things reliably work and reliably
fail respectively?
was (Author: mike.jumper):
I'm not seeing any difference between the values we're setting and the values
that xfreerdp/wfreerdp/etc. are using. If the client you're testing against is
using the same version of FreeRDP that Guacamole was built against, I'd expect
things to be working.
I do see some differences in the handling of other values when preconnection
IDs and blobs are in play:
* If FreeRDP's {{/vmconnect}} option is used, FreeRDP silently changes the
server port from 3389 to 2179. For Guacamole, if that's needed, you would have
to manually specify that port. Guacamole will always use 3389 unless told
otherwise.
* Guacamole sets {{rdp_settings->NegotiateSecurityLayer}} to {{FALSE}} whenever
a preconnection ID or blob is specified. For FreeRDP, this only occurs with
{{/vmconnect}} but will not occur with {{/pcb}} or {{/pcid}}.
Do either of the above apply in your case?
If you switch back and forth between a 1.0.0 build and 1.1.0 build, do things
reliably work and reliably fail respectively?
> Preconnection Blob Support Broken
> -
>
> Key: GUACAMOLE-952
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-952
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.1.0
>Reporter: Nick Couchman
>Priority: Minor
> Attachments: guacd.log
>
>
> After the switch to FreeRDP 2, support for setting the Preconnection Blob (to
> connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP
> 2.x code still supports it, but something about the detection on the
> Guacamole side seems to detect it as missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-952) Preconnection Blob Support Broken
[
https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034080#comment-17034080
]
Mike Jumper commented on GUACAMOLE-952:
---
I'm not seeing any difference between the values we're setting and the values
that xfreerdp/wfreerdp/etc. are using. If the client you're testing against is
using the same version of FreeRDP that Guacamole was built against, I'd expect
things to be working.
I do see some differences in the handling of other values when preconnection
IDs and blobs are in play:
* If FreeRDP's {{/vmconnect}} option is used, FreeRDP silently changes the
server port from 3389 to 2179. For Guacamole, if that's needed, you would have
to manually specify that port. Guacamole will always use 3389 unless told
otherwise.
* Guacamole sets {{rdp_settings->NegotiateSecurityLayer}} to {{FALSE}} whenever
a preconnection ID or blob is specified. For FreeRDP, this only occurs with
{{/vmconnect}} but will not occur with {{/pcb}} or {{/pcid}}.
Do either of the above apply in your case?
If you switch back and forth between a 1.0.0 build and 1.1.0 build, do things
reliably work and reliably fail respectively?
> Preconnection Blob Support Broken
> -
>
> Key: GUACAMOLE-952
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-952
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.1.0
>Reporter: Nick Couchman
>Priority: Minor
> Attachments: guacd.log
>
>
> After the switch to FreeRDP 2, support for setting the Preconnection Blob (to
> connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP
> 2.x code still supports it, but something about the detection on the
> Guacamole side seems to detect it as missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-952) Preconnection Blob Support Broken
[
https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034073#comment-17034073
]
Mike Jumper commented on GUACAMOLE-952:
---
Correct, the warning should have just been removed (caused by an [incorrect
change within commit
{{17d31d9}}|https://github.com/apache/guacamole-server/commit/17d31d94b77b3be71012b0bc6fcb1d1c3db88e5f#diff-80a865e7ad1fc02a8f94af9d313fb36bL800]),
but it shouldn't be having any effect other than log noise. If preconnection
blobs are not being sent since the migration to FreeRDP 2.0.0, this warning is
a red herring, and something else must be wrong.
> Preconnection Blob Support Broken
> -
>
> Key: GUACAMOLE-952
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-952
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.1.0
>Reporter: Nick Couchman
>Priority: Minor
> Attachments: guacd.log
>
>
> After the switch to FreeRDP 2, support for setting the Preconnection Blob (to
> connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP
> 2.x code still supports it, but something about the detection on the
> Guacamole side seems to detect it as missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-950) segfault in guacd
[
https://issues.apache.org/jira/browse/GUACAMOLE-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17034025#comment-17034025
]
Mike Jumper commented on GUACAMOLE-950:
---
Does your distribution provide a package containing the debug symbols for
libfreerdp? That should allow gdb to produce a backtrace that includes line
numbers, filenames, etc., for the FreeRDP portion of the stack. Since stack
frame #0 shows the instruction pointer as all zeroes, it looks like there must
be some function pointer FreeRDP is expecting to be assigned but is {{NULL}} in
our case.
> segfault in guacd
> --
>
> Key: GUACAMOLE-950
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-950
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.1.0
> Environment: Guacamole 1.1.0 under Tomcat8 on Ubuntu 18.04, running
> as virtual machine
>Reporter: Toby
>Priority: Minor
> Attachments: trace_connected.txt, trace_segfault.txt
>
>
> Upgraded from 1.0.0 on Ubuntu 16.04 to 1.1.0 on Ubuntu 18.04. Moved from
> Tomcat7 to Tomcat8. Config is largely unchanged.
> Two Windows 10 Enterprise destinations and a third is 2012R2. One of the two
> Windows 10 will cause guacd to segfault on connection. 2012R2 works fine. I
> see a mouse pointer in the upper left very briefly and then I get
> home/reconnect/logout. I have pared the config down to just domain,
> username, password, NLA security, ignore-cert directives for all three
> destinations.
> Uploaded syslog traces, one of a normal connect to the other windows 10
> device, one as the segmentation fault I get when connecting to the other.
> Have also tried rebuilding without webp and websockets to no effect.
> I'm happy to build one for gdb and get a core, but I'll need a little help
> doing that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) Add LDAP support for nested user groups
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Description: As described below, the current LDAP support will query user group membership, but only immediate membership. Unlike the database auth, nested user groups are not supported. Support for nested user groups should be added. Note that while Active Directory supports a specific filter for retrieving recursive group memberships, leveraging that would need to be done carefully. Other LDAP servers may not support that filter, and an alternative, standards-conforming mechanism would need to be used by default. If it is possible to automatically detect that the LDAP server supports this, that would be ideal. Another option might be to provide some mechanism for overriding the filter that Guacamole will use to determine membership. was: Using LDAP for authentication, MySQL to store connection information. Login works fine, however unable to share connections with other LDAP users without first explicitly creating these users in MySQL as well. Likewise for groups, if I share connections with a LDAP Group, users that are a member of this group will not see any connections that are shared with this group. I'm pretty sure that at some point, prior to the official 1.1.0 release, this was working. > Add LDAP support for nested user groups > --- > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-auth-ldap >Reporter: Nils >Priority: Minor > > As described below, the current LDAP support will query user group > membership, but only immediate membership. Unlike the database auth, nested > user groups are not supported. Support for nested user groups should be added. > Note that while Active Directory supports a specific filter for retrieving > recursive group memberships, leveraging that would need to be done carefully. > Other LDAP servers may not support that filter, and an alternative, > standards-conforming mechanism would need to be used by default. If it is > possible to automatically detect that the LDAP server supports this, that > would be ideal. Another option might be to provide some mechanism for > overriding the filter that Guacamole will use to determine membership. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Priority: Minor (was: Major) > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Minor > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Affects Version/s: (was: 1.1.0) > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Reporter: Nils >Priority: Minor > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Component/s: (was: guacamole-server) guacamole-auth-ldap > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Nils >Priority: Minor > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) Add LDAP support for nested user groups
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Issue Type: New Feature (was: Improvement) > Add LDAP support for nested user groups > --- > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-auth-ldap >Reporter: Nils >Priority: Minor > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-954) Add LDAP support for nested user groups
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-954: -- Summary: Add LDAP support for nested user groups (was: LDAP Authentication, users require explicit creation in MySQL for connection sharing.) > Add LDAP support for nested user groups > --- > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Nils >Priority: Minor > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reopened GUACAMOLE-954: --- > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[
https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033925#comment-17033925
]
Nils commented on GUACAMOLE-954:
OK, noted. Implementing support for nested groups is, at least in the world of
AD, relatively simple as per
[https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax]
I personally use this in several places (e.g. Apache) to support Nested Groups,
which in an organisation are very common. The way to configure the search
filter is like such:
memberof:*1.2.840.113556.1.4.1941:*=CN=whatever,OU=ou,dc=your,dc=lan
{{}}
|1.2.840.113556.1.4.1941|*LDAP_MATCHING_RULE_IN_CHAIN*|This rule is limited to
filters that apply to the DN. This is a special "extended" match operator that
walks the chain of ancestry in objects all the way to the root until it finds a
match.|
> LDAP Authentication, users require explicit creation in MySQL for connection
> sharing.
> -
>
> Key: GUACAMOLE-954
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-954
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-server
>Affects Versions: 1.1.0
>Reporter: Nils
>Priority: Major
>
> Using LDAP for authentication, MySQL to store connection information.
> Login works fine, however unable to share connections with other LDAP users
> without first explicitly creating these users in MySQL as well. Likewise for
> groups, if I share connections with a LDAP Group, users that are a member of
> this group will not see any connections that are shared with this group.
> I'm pretty sure that at some point, prior to the official 1.1.0 release, this
> was working.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033919#comment-17033919 ] Mike Jumper commented on GUACAMOLE-954: --- The LDAP support does not recursively query LDAP memberships. It's not so much that nested LDAP groups do not work as that's not a feature that's currently provided. > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033851#comment-17033851 ] Nils commented on GUACAMOLE-954: It seems the problem is that nested LDAP groups do not work. > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033836#comment-17033836 ] Nils commented on GUACAMOLE-954: What I am after is the functionality which was implemented as part of GUACAMOLE-715. Group exists in MySQL, User exists in LDAP but not in MySQL. > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033833#comment-17033833 ] Nils commented on GUACAMOLE-954: I noticed this issue was closed, due to it being marked as a duplicate of GUACAMOLE-708. However, even though this issue seems to be implementing what I am referring to, I'm still somewhat confused as to how this did work in the past – A while ago I raised GUACAMOLE-920, prior to the official 1.1.0 release, in which this functionality was in some shape of form available. > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
[ https://issues.apache.org/jira/browse/GUACAMOLE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-954. --- Resolution: Duplicate > LDAP Authentication, users require explicit creation in MySQL for connection > sharing. > - > > Key: GUACAMOLE-954 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-server >Affects Versions: 1.1.0 >Reporter: Nils >Priority: Major > > Using LDAP for authentication, MySQL to store connection information. > Login works fine, however unable to share connections with other LDAP users > without first explicitly creating these users in MySQL as well. Likewise for > groups, if I share connections with a LDAP Group, users that are a member of > this group will not see any connections that are shared with this group. > I'm pretty sure that at some point, prior to the official 1.1.0 release, this > was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GUACAMOLE-954) LDAP Authentication, users require explicit creation in MySQL for connection sharing.
Nils created GUACAMOLE-954: -- Summary: LDAP Authentication, users require explicit creation in MySQL for connection sharing. Key: GUACAMOLE-954 URL: https://issues.apache.org/jira/browse/GUACAMOLE-954 Project: Guacamole Issue Type: Improvement Components: guacamole-server Affects Versions: 1.1.0 Reporter: Nils Using LDAP for authentication, MySQL to store connection information. Login works fine, however unable to share connections with other LDAP users without first explicitly creating these users in MySQL as well. Likewise for groups, if I share connections with a LDAP Group, users that are a member of this group will not see any connections that are shared with this group. I'm pretty sure that at some point, prior to the official 1.1.0 release, this was working. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-953) Guacamole server error "The remote desktop server is currently unreachable" even RDP is working from default remote desktop connect
[ https://issues.apache.org/jira/browse/GUACAMOLE-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033740#comment-17033740 ] Mike Jumper commented on GUACAMOLE-953: --- RDP is definitely not fundamentally broken in 1.0.0, nor in the latest release. If you are having issues connecting and need help troubleshooting, please post to the u...@guacamole.apache.org mailing list. An issue as basic as being unble to connect is very unlikely to be a bug. https://guacamole.apache.org/support/#mailing-lists > Guacamole server error "The remote desktop server is currently unreachable" > even RDP is working from default remote desktop connect > --- > > Key: GUACAMOLE-953 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-953 > Project: Guacamole > Issue Type: Bug > Components: guacamole, guacd, RDP >Affects Versions: 1.0.0 > Environment: Ubuntu 18.04.2 LTS >Reporter: Kalimuthu >Priority: Blocker > Labels: Debian > > when we try to connect the client(to RDP) from third party app via guacamole > server. it say "The remote desktop server is currently unreachable. If the > problem persists, please notify your system administrator, or check your > system logs." but I am able to take the RDP for the same client from "Remote > Desktop Connection"(windows app) from same network. also I am able to connect > the same client from Guacamole login portal which shows the client details > configured in user-mapping.xml file. > when I check the guacamole syslogs. guacd socket is closing. > FYI, Apache is configured with SSL for port 443. > *Logs from guacamole syslogs:* > 2020-02-10 20:36:23,556 INFO [https-openssl-nio-443-exec-20] > o.a.g.e.LocalEnvironment [LocalEnvironment.java:124] GUACAMOLE_HOME is > "/etc/guacamole". > 2020-02-10 20:36:23,557 DEBUG [https-openssl-nio-443-exec-20] > o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:90] Connecting to guacd > at localhost:4822. > 2020-02-10 20:36:23,616 INFO [https-openssl-nio-443-exec-20] > o.a.g.t.TunnelRequestService [TunnelRequestService.java:225] User > "6009da25-a61a-4090-83ee-479879a34f30" connected to connection "2130868029". > 2020-02-10 20:36:23,666 INFO [https-openssl-nio-443-exec-18] > o.a.g.t.TunnelRequestService [TunnelRequestService.java:323] User > "6009da25-a61a-4090-83ee-479879a34f30" disconnected from connection > "2130868029". Duration: 50 milliseconds > 2020-02-10 20:36:23,666 DEBUG [https-openssl-nio-443-exec-18] > o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:122] Closing socket to > guacd. > 2020-02-10 20:36:23,667 DEBUG [Thread-971] > o.a.g.w.GuacamoleWebSocketTunnelEndpoint > [GuacamoleWebSocketTunnelEndpoint.java:274] Connection to guacd closed. > org.apache.guacamole.GuacamoleConnectionClosedException: Connection to guacd > is closed. > at > org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:183) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.io.ReaderGuacamoleReader.readInstruction(ReaderGuacamoleReader.java:195) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.read(FilteredGuacamoleReader.java:64) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:246) > ~[guacamole-common-1.0.0.jar:na] > Caused by: java.net.SocketException: Socket closed > at java.net.SocketInputStream.read(SocketInputStream.java:204) > ~[na:1.8.0_242] > at java.net.SocketInputStream.read(SocketInputStream.java:141) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > ~[na:1.8.0_242] > at java.io.InputStreamReader.read(InputStreamReader.java:184) > ~[na:1.8.0_242] > at > org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:169) > ~[guacamole-common-1.0.0.jar:na] > ... 5 common frames omitted** > *Getting guacd server status with error,* > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Parameter "gateway-port" > omitted. Using default value of 443. > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: User
[jira] [Closed] (GUACAMOLE-953) Guacamole server error "The remote desktop server is currently unreachable" even RDP is working from default remote desktop connect
[ https://issues.apache.org/jira/browse/GUACAMOLE-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-953. - Resolution: Invalid > Guacamole server error "The remote desktop server is currently unreachable" > even RDP is working from default remote desktop connect > --- > > Key: GUACAMOLE-953 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-953 > Project: Guacamole > Issue Type: Bug > Components: guacamole, guacd, RDP >Affects Versions: 1.0.0 > Environment: Ubuntu 18.04.2 LTS >Reporter: Kalimuthu >Priority: Blocker > Labels: Debian > > when we try to connect the client(to RDP) from third party app via guacamole > server. it say "The remote desktop server is currently unreachable. If the > problem persists, please notify your system administrator, or check your > system logs." but I am able to take the RDP for the same client from "Remote > Desktop Connection"(windows app) from same network. also I am able to connect > the same client from Guacamole login portal which shows the client details > configured in user-mapping.xml file. > when I check the guacamole syslogs. guacd socket is closing. > FYI, Apache is configured with SSL for port 443. > *Logs from guacamole syslogs:* > 2020-02-10 20:36:23,556 INFO [https-openssl-nio-443-exec-20] > o.a.g.e.LocalEnvironment [LocalEnvironment.java:124] GUACAMOLE_HOME is > "/etc/guacamole". > 2020-02-10 20:36:23,557 DEBUG [https-openssl-nio-443-exec-20] > o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:90] Connecting to guacd > at localhost:4822. > 2020-02-10 20:36:23,616 INFO [https-openssl-nio-443-exec-20] > o.a.g.t.TunnelRequestService [TunnelRequestService.java:225] User > "6009da25-a61a-4090-83ee-479879a34f30" connected to connection "2130868029". > 2020-02-10 20:36:23,666 INFO [https-openssl-nio-443-exec-18] > o.a.g.t.TunnelRequestService [TunnelRequestService.java:323] User > "6009da25-a61a-4090-83ee-479879a34f30" disconnected from connection > "2130868029". Duration: 50 milliseconds > 2020-02-10 20:36:23,666 DEBUG [https-openssl-nio-443-exec-18] > o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:122] Closing socket to > guacd. > 2020-02-10 20:36:23,667 DEBUG [Thread-971] > o.a.g.w.GuacamoleWebSocketTunnelEndpoint > [GuacamoleWebSocketTunnelEndpoint.java:274] Connection to guacd closed. > org.apache.guacamole.GuacamoleConnectionClosedException: Connection to guacd > is closed. > at > org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:183) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.io.ReaderGuacamoleReader.readInstruction(ReaderGuacamoleReader.java:195) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.protocol.FilteredGuacamoleReader.read(FilteredGuacamoleReader.java:64) > ~[guacamole-common-1.0.0.jar:na] > at > org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:246) > ~[guacamole-common-1.0.0.jar:na] > Caused by: java.net.SocketException: Socket closed > at java.net.SocketInputStream.read(SocketInputStream.java:204) > ~[na:1.8.0_242] > at java.net.SocketInputStream.read(SocketInputStream.java:141) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > ~[na:1.8.0_242] > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > ~[na:1.8.0_242] > at java.io.InputStreamReader.read(InputStreamReader.java:184) > ~[na:1.8.0_242] > at > org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:169) > ~[guacamole-common-1.0.0.jar:na] > ... 5 common frames omitted** > *Getting guacd server status with error,* > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Parameter "gateway-port" > omitted. Using default value of 443. > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: User > "@95ce06bd-0b70-400f-9a53-753ffda0b423" joined connection > "$7f579074-597d-40b3-9a9a-c0021a323700" (1 users now present) > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Client has not defined its > protocol version. > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Loading keymap "base" > Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]:
[jira] [Updated] (GUACAMOLE-953) Guacamole server error "The remote desktop server is currently unreachable" even RDP is working from default remote desktop connect
[
https://issues.apache.org/jira/browse/GUACAMOLE-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kalimuthu updated GUACAMOLE-953:
-
Description:
when we try to connect the client(to RDP) from third party app via guacamole
server. it say "The remote desktop server is currently unreachable. If the
problem persists, please notify your system administrator, or check your system
logs." but I am able to take the RDP for the same client from remote desktop
connect from local same network. also I am able to connect the same client from
Guacamole login portal which shows the client details configured in
user-mapping.xml file.
when I check the guacamole syslogs. guacd socket is closing.
FYI, Apache is configured with SSL for port 443.
*Logs from guacamole syslogs:*
2020-02-10 20:36:23,556 INFO [https-openssl-nio-443-exec-20]
o.a.g.e.LocalEnvironment [LocalEnvironment.java:124] GUACAMOLE_HOME is
"/etc/guacamole".
2020-02-10 20:36:23,557 DEBUG [https-openssl-nio-443-exec-20]
o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:90] Connecting to guacd
at localhost:4822.
2020-02-10 20:36:23,616 INFO [https-openssl-nio-443-exec-20]
o.a.g.t.TunnelRequestService [TunnelRequestService.java:225] User
"6009da25-a61a-4090-83ee-479879a34f30" connected to connection "2130868029".
2020-02-10 20:36:23,666 INFO [https-openssl-nio-443-exec-18]
o.a.g.t.TunnelRequestService [TunnelRequestService.java:323] User
"6009da25-a61a-4090-83ee-479879a34f30" disconnected from connection
"2130868029". Duration: 50 milliseconds
2020-02-10 20:36:23,666 DEBUG [https-openssl-nio-443-exec-18]
o.a.g.n.InetGuacamoleSocket [InetGuacamoleSocket.java:122] Closing socket to
guacd.
2020-02-10 20:36:23,667 DEBUG [Thread-971]
o.a.g.w.GuacamoleWebSocketTunnelEndpoint
[GuacamoleWebSocketTunnelEndpoint.java:274] Connection to guacd closed.
org.apache.guacamole.GuacamoleConnectionClosedException: Connection to guacd
is closed.
at
org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:183)
~[guacamole-common-1.0.0.jar:na]
at
org.apache.guacamole.io.ReaderGuacamoleReader.readInstruction(ReaderGuacamoleReader.java:195)
~[guacamole-common-1.0.0.jar:na]
at
org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81)
~[guacamole-common-1.0.0.jar:na]
at
org.apache.guacamole.protocol.FilteredGuacamoleReader.readInstruction(FilteredGuacamoleReader.java:81)
~[guacamole-common-1.0.0.jar:na]
at
org.apache.guacamole.protocol.FilteredGuacamoleReader.read(FilteredGuacamoleReader.java:64)
~[guacamole-common-1.0.0.jar:na]
at
org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:246)
~[guacamole-common-1.0.0.jar:na]
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.read(SocketInputStream.java:204)
~[na:1.8.0_242]
at java.net.SocketInputStream.read(SocketInputStream.java:141)
~[na:1.8.0_242]
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
~[na:1.8.0_242]
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
~[na:1.8.0_242]
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
~[na:1.8.0_242]
at java.io.InputStreamReader.read(InputStreamReader.java:184)
~[na:1.8.0_242]
at
org.apache.guacamole.io.ReaderGuacamoleReader.read(ReaderGuacamoleReader.java:169)
~[guacamole-common-1.0.0.jar:na]
... 5 common frames omitted**
*Getting guacd server status with error,*
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Parameter "gateway-port"
omitted. Using default value of 443.
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: User
"@95ce06bd-0b70-400f-9a53-753ffda0b423" joined connection
"$7f579074-597d-40b3-9a9a-c0021a323700" (1 users now present)
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Client has not defined its
protocol version.
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Loading keymap "base"
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Loading keymap "en-us-qwerty"
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: {color:#ff}Error
connecting to RDP server{color}
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: User
"@95ce06bd-0b70-400f-9a53-753ffda0b423" disconnected (0 users remain)
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Last user of connection
"$7f579074-597d-40b3-9a9a-c0021a323700" disconnected
Feb 10 20:25:32 ubuntu-VirtualBox guacd[25237]: Requesting termination of
client...
Feb 10 20:25:33 ubuntu-VirtualBox guacd[25076]: Connection
"$7f579074-597d-40b3-9a9a-c0021a323700" removed.
does anybody idea about this issue? Please help me to resolve this.
was:
when we try to connect the client(to RDP) from third party app via guacamole
server. it say "The remote desktop server is currently unreachable. If the
problem persists,
[jira] [Updated] (GUACAMOLE-918) Guacamole Display not visible under Shadow DOM
[
https://issues.apache.org/jira/browse/GUACAMOLE-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonas Zeiger updated GUACAMOLE-918:
---
Environment:
guacamole-common-js 1.1.0 on Chromium 78
org.apache.guacamole:guacamole-common:1.1.0 on OpenJDK 11
was:
guacamole-common-js 1.1.0 on Chromium 78
org.apache.guacamole:guacamole-common:1.0.0 on OpenJDK 11
> Guacamole Display not visible under Shadow DOM
> --
>
> Key: GUACAMOLE-918
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-918
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-common-js
>Affects Versions: 1.1.0
> Environment: guacamole-common-js 1.1.0 on Chromium 78
> org.apache.guacamole:guacamole-common:1.1.0 on OpenJDK 11
>Reporter: Jonas Zeiger
>Priority: Major
> Attachments: guacamole-display-under-shadow-root.png
>
>
> The Guacamole display doesn't show when inserted under shadow DOM.
> The display is attached like this:
> {code:javascript}
> const wrapper = this.shadowRoot.getElementById('console-screen-wrapper');
> wrapper.style.width = '' + 640 + 'px';
> wrapper.style.height = '' + 480 + 'px';
> this.display = wrapper.appendChild(client.getDisplay().getElement());
> {code}
> The display elements including canvas are present in the DOM (see DOM
> screenshot).
> The reason seems to be the explicit canvas/layer z-index setup here:
> guacamole-common.js, Guacamole.Layer()
> {code:javascript}
> // Explicitly render canvas below other elements in the layer (such as
> // child layers). Chrome and others may fail to render layers properly
> // without this.
> canvas.style.zIndex = -1;
> {code}
> Setting canvas.style.zIndex to 0 instead of -1 makes all layers visible under
> shadow DOM.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GUACAMOLE-883) Touch mouse emulation no longer works as of iOS 13
[ https://issues.apache.org/jira/browse/GUACAMOLE-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033439#comment-17033439 ] Thomas commented on GUACAMOLE-883: -- Yes I cleared the Safari Cache, but is no touch pointer working > Touch mouse emulation no longer works as of iOS 13 > -- > > Key: GUACAMOLE-883 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-883 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 1.0.0, 1.1.0 >Reporter: Thomas >Assignee: Mike Jumper >Priority: Minor > > With devices running iOS 13, it is no longer possible to interact with remote > desktops using touch-driven mouse emulation. The specific reason for this is > not yet known. Older releases of iOS work correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GUACAMOLE-952) Preconnection Blob Support Broken
[ https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17033422#comment-17033422 ] Joachim Lindenberg edited comment on GUACAMOLE-952 at 2/10/20 8:06 AM: --- from my email: "I just did a quick test of a nightly build (2.0.0-dev5 (245fc6014)) of wfreerdp and it supports preconnection blobs – doesn´t look like support was removed in general. Thus I´d assume it is more like guacamole does not recognize it, or the build options used by Debian do not support it." then looking at [https://github.com/apache/guacamole-server/blob/956c5f293e13c6916ae00431a9146c203e8b5912/src/protocols/rdp/settings.c l|https://github.com/apache/guacamole-server/blob/956c5f293e13c6916ae00431a9146c203e8b5912/src/protocols/rdp/settings.c]ines 804++ I´d conclude the warning is used whenever a preconnection blob is specified (settings->preconnection_blob is set in line 806 and tested in 812), and the warning does not reflect freerdp´s capabilities. as I switched to debug output anyway I am attaching a log. Connection obviously was attempted but failed. was (Author: jol): from my email: "I just did a quick test of a nightly build (2.0.0-dev5 (245fc6014)) of wfreerdp and it supports preconnection blobs – doesn´t look like support was removed in general. Thus I´d assume it is more like guacamole does not recognize it, or the build options used by Debian do not support it." then looking at [https://github.com/apache/guacamole-server/blob/956c5f293e13c6916ae00431a9146c203e8b5912/src/protocols/rdp/settings.c l|https://github.com/apache/guacamole-server/blob/956c5f293e13c6916ae00431a9146c203e8b5912/src/protocols/rdp/settings.c]ines 804++ I´d conclude the warning is used whenever a preconnection blob is specified (settings->preconnection_blob is set in line 806 and tested in 812), and the warning does not reflect freerdp´s capabilities. > Preconnection Blob Support Broken > - > > Key: GUACAMOLE-952 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-952 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 1.1.0 >Reporter: Nick Couchman >Priority: Minor > Attachments: guacd.log > > > After the switch to FreeRDP 2, support for setting the Preconnection Blob (to > connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP > 2.x code still supports it, but something about the detection on the > Guacamole side seems to detect it as missing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GUACAMOLE-952) Preconnection Blob Support Broken
[ https://issues.apache.org/jira/browse/GUACAMOLE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joachim Lindenberg updated GUACAMOLE-952: - Attachment: guacd.log > Preconnection Blob Support Broken > - > > Key: GUACAMOLE-952 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-952 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 1.1.0 >Reporter: Nick Couchman >Priority: Minor > Attachments: guacd.log > > > After the switch to FreeRDP 2, support for setting the Preconnection Blob (to > connect to Hyper-V, for example), appearst o be broken. Looks like FreeRDP > 2.x code still supports it, but something about the detection on the > Guacamole side seems to detect it as missing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
