This is a good opportunity for me to bring up several gotchas I had I'm running a new fully patched CentOS-7 system with standard repo installs of apache-2.4.6, tomcat-7, guacd and with the WAR file from guacamole-1.1.0, along with the jdbc-mysql, header and quickconnect extensions.
Apache is configured with mod_auth_mellon (SAML) and uses a header to pass the username to guacamole-auth-header, and the reverse-proxy part is configured as <Location /guacamole/> ProxyPass http://127.0.0.1:8080/guacamole/ flushpackets=on ProxyPass http://127.0.0.1:8080/guacamole/ ProxyPassReverseCookiePath /guacamole/ / </Location> <Location /guacamole/websocket-tunnel> Header set Connection Upgrade Header set Upgrade %{HTTP_UPGRADE}e ProxyPass ws://127.0.0.1:8080/guacamole/websocket-tunnel ProxyPassReverse ws://127.0.0.1:8080/guacamole/websocket-tunnel ProxyPassReverseCookiePath /guacamole/ / </Location> You will notice the WebSocket headers - I had real difficulties getting websocket to work - even though mod_proxy_wstunnel is loaded - so I hard-wired those two headers in and that seemed to fix things. As far as your "only admins should edit connections" comment goes, yeah I know that is how guacamole intends to do things, but "CoronaVirus". I am doing this as a POC with the intention to allow arbitrary staff remote access from their personal/home computers to their workstations - so I'm testing giving all users "create new connections" privs (because they would also use it to access Cloud systems that can only be accessed from work IPs, etc). Frankly it's not looking like a workable option, it's one thing to expect "guacamole admins" to have good working knowledge of the product, but not hundreds of engineers and other "normal" staff. Also, I think there'd need to be more global control over what is available in the "Connection" options. eg remove references to recording to disk or sharing drives, globally ignoring cert validation would be needed for quickconnect, etc. Great product - but I think I'm pushing beyond its target market On Sat, Mar 14, 2020 at 12:04 PM Mike Jumper <[email protected]> wrote: > On Fri, Mar 13, 2020 at 3:26 PM Jason Haar <[email protected]> wrote: > >> This is a CentOS7 system running the downloaded install of >> guacamole-1.1.0 - but using the yum install guacd >> (guacd-1.1.0-1.el7.x86_64). Even if I have an older version, the error msg >> you see (Log in failed. Please reconnect and try again) is also misleading. >> No amount of reconnecting is going to fix this :-) >> > > In your specific case, perhaps not. In general, the expectation would be > that entering invalid credentials could be resolved by reconnecting and > entering the correct credentials, or by the administrator resolving > whatever transient configuration issue is preventing credentials from being > accepted. Guacamole has an error code for invalid credentials which > produces that message, however there is no distinct error code for "your > credentials are invalid, but also the server will never accept any of that > type of credentials and reconnecting is pointless". > > There is an error code for when the remote desktop server is refusing the > connection. That might be more appropriate for the case that the server is > refusing to accept the credentials provided, but it does still advise the > user to try again. > > Shouldn't that error literally be what guacd was reporting in the logs? >> Way more useful to the end-user >> > > No, that level of specific internal details shouldn't normally be exposed > to the end-user. It needs to be exposed to the administrator, hence being > logged, but the full nature of internal failures should not be exposed to > users that wouldn't normally be aware of those failures. > > >> Oh yeah, it is behind an apache reverse proxy - so maybe that changes the >> error message? >> > > Not changing it per se, but it might be causing it. Can you share your > Apache configuration? Also, what browser and version is being used when > this occurs? > > In general, connection-specific error messages are passed through > Guacamole-specific status codes via the Guacamole protocol, independent of > the HTTP or WebSocket transport. The connection stability warning is > distinct from those messages in that it's produced on the client side, > based on whether the HTTP or WebSocket tunnels detect possible connection > instability. > > - Mike > > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
