Jason,
Like Mike I'm struggling a little to understand your particular
use-case, although I get the sudden interest in remote operation.
Is it that you want to reduce admin overhead by having users self-manage
multiple connections, or is there some other reason for letting them do
their own thing? Also, do you want them to connect just to a specific
desktop or two (from which I would have thought they'd ordinarily
connect to whatever further remote system was permitted), or directly to
other random systems within your network?
While I suspect you're really wanting to be able to provide a specific
reduced-privilege template to certain users (which isn't available that
I'm aware of) I wonder if there are other ways to achieve your goal?
For instance Guacamole does offer an ad-hoc connection facility
https://guacamole.apache.org/doc/gug/adhoc-connections.html which may go
a way towards simple self-management. Although I've not used it myself I
don't believe it would expose the recording options etc directly to the
user (although a savvy user might figure out how to do that I guess).
You could just provide a sample URI with requisite parameters to users
and explain how to make straightforward changes to that such as target
machine / user etc.
If you were further concerned about limiting connections (damage
control!) I guess you could get creative with iptables, and maybe run
several instances of Guacamole for different user classes, but perhaps
I've missed your point?
BTW, ex-UoC '90's?
On 16/03/2020 12:54 p.m., Jason Haar wrote:
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
<http://127.0.0.1:8080/guacamole/websocket-tunnel>
ProxyPassReverse ws://127.0.0.1:8080/guacamole/websocket-tunnel
<http://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] <mailto:[email protected]>> wrote:
On Fri, Mar 13, 2020 at 3:26 PM Jason Haar <[email protected]
<mailto:[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
