Re: RDP Installation Issue

[Nick Couchman]

On Mon, Apr 29, 2024 at 11:47 AM Michael Grattan
 wrote:

> Hello,
>
>
>
> Thanks for the reply.
>
>
>
> I have tried dnf install freerdp-devel but it says no match.
>
>
>
> A dnf search freerdp turns up only the following:
>
>
>
> # dnf search freerdp
>
> Updating Subscription Management repositories.
>
> Last metadata expiration check: 0:30:11 ago on Mon 29 Apr 2024 11:03:34 AM
> EDT.
>
> == Name Exactly
> Matched: freerdp ==
>
> freerdp.x86_64 : Free implementation of the Remote Desktop Protocol (RDP)
>
> == Name
> Matched: freerdp
> ==
>
> freerdp-libs.x86_64 : Core libraries implementing the RDP protocol
>
> freerdp-libs.i686 : Core libraries implementing the RDP protocol
>
>
>
> Is there somewhere else I need to go to download the developer libraries?
>
>
>

Yeah, if you're using one of the later EL-based distros (Rocky 9, CentOS 9
Stream, or RHEL 9) you might need to enable additional repos. For example,
in Rocky 9, it's the "crb" repo:

$ sudo dnf list freerdp-devel
Last metadata expiration check: 0:00:13 ago on Mon 29 Apr 2024 01:25:03 PM
EDT.
Available Packages
freerdp-devel.i686
  2:2.4.1-5.el9
crb
freerdp-devel.x86_64
  2:2.4.1-5.el9
crb

-Nick

>

Re: RDP Installation Issue

[Nick Couchman]

On Mon, Apr 29, 2024 at 10:51 AM Michael Grattan
 wrote:

> Hello,
>
>
>
> I am trying to install Guacamole 1.5.5 on a new Red Hat version 9.3.
>
>
>
> When I run the configuration, it does not seem to find RDP as follows:
>
>
>
> checking for vorbis/vorbisenc.h... no
>
> checking for ogg_stream_init in -logg... no
>
> checking for vorbis_block_init in -lvorbis... no
>
> checking for vorbis_encode_init in -lvorbisenc... no
>
> configure: WARNING:
>
>   
>
>Unable to find libogg / libvorbis / libvorbisenc.
>
>Sound will not be encoded with Ogg Vorbis.
>
>   
>
> checking for pa_context_new in -lpulse... yes
>
> checking for pango... yes
>
> checking for pangocairo... yes
>
> checking for rfbInitClient in -lvncclient... no
>
> checking for freerdp2 freerdp-client2 winpr2... no
>
> configure: WARNING:
>
>   
>
>Unable to find FreeRDP (libfreerdp2 / libfreerdp-client2 / libwinpr2)
>
>RDP will be disabled.
>
>   
>
> checking for libssh2_userauth_publickey_frommemory in -lssh2... no
>
> checking for telnet_init in -ltelnet... no
>
> checking for webp/encode.h... yes
>
> checking for WebPEncode in -lwebp... yes
>
> checking for lws_create_context in -lwebsockets... no
>
> configure: WARNING:
>
>   
>
>Unable to find libwebsockets.
>
>Support for Kubernetes will be disabled.
>
>   
>
> checking whether LWS_CALLBACK_CLIENT_CLOSED is declared... no
>
> checking whether LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT is declared... no
>
> checking whether LCCSCF_USE_SSL is declared... no
>
>
>
> However, I have checked the linked libraries and I think FreeRDP is
> already installed as shown here:
>

Make sure you have the development libraries installed - depending on the
Linux distribution you're running, it may be something like
"freerdp-devel", "freerdp2-devel", or the like. The following page lists
dependency requirements for Debian and EL-based systems:

https://guacamole.apache.org/doc/gug/installing-guacamole.html#building-guacamole-server

-Nick

>

Re: Custom user-defined connection credentials

[Nick Couchman]

On Mon, Apr 29, 2024 at 10:11 AM Vieri  wrote:

>
> On Monday, April 29, 2024 at 03:01:06 PM GMT+2, Nick Couchman <
> vn...@apache.org> wrote:
> >
> > I think the closest thing to what you're looking for that is currently
> supported in Guacamole is the "vault" extension, which supports
> > pulling tokens from a credential vault. The only vault currently
> supported is Keeper Secrets Manager,
> > but support could certainly be extended to other types of vaults with
> some code writing.
>
> Thanks for that, but I was hoping not to store credentials in the cloud.
> In fact, I was wondering if the feature could be within Guacamole "core"
> (not even an extension). The credentials could be stored within the local
> guac DB (just like the user and connection data), and a relationship with
> the user ID could be set (guacamole_user.entity_id). Whenever a user tries
> to connect to a guac DB-defined connection/host the guacamole client could
> ask the user to pick any of its "credential sets" from the guac DB (or none
> for user input).
>
> I don't know if the "vault credential retrieval system" can be adapted to
> this simpler setup.
> Can the "vault" just be a table within guac DB?
>
>
Vieri,
Yeah, I totally understand, and it's why I mentioned that there are
probably ways to extend it into other areas. First, I'm not sure about
Keeper Security Manager, whether it's hosted locally or in the Cloud. There
are some other folks on here who could advise on that, I'm just not that
familiar with it.

Regarding the possibility of the vault being a table within the DB - I
would say that it is probably more complicated than that, but that there
should be ways to develop something to host it locally, within the
application, and not have to rely on another piece of software or Cloud
offering. But that capability does not exist today, it would need to be
developed.

-Nick

Re: Custom user-defined connection credentials

[Nick Couchman]

On Mon, Apr 29, 2024 at 6:35 AM Vieri  wrote:

> Hi,
>
> I set up guacamole with SAML SSO (no clearpass).
>
> The users log into the system and are assigned to RDP, ssh, vnc
> connections, as needed.
> In all of the connection settings (eg for RDP), the following are left
> blank:
>
> Under PARAMETERS, Authentication:
> Username, Password, Domain, Security mode
>
> So, for a given RDP connection, any SAML-authenticated user can
> potentially access that target host by entering user credentials again.
>
> I was wondering if it were possible for Guacamole to have an extra
> user-defined "object" for credential storage.
> For instance, a user could create "credentials1" with a set of RDP
> credentials, "credentials2", etc. in his/her profile.
> When connecting to an authorized host (guacamole "connection"), the
> guacamole client GUI could ask the user which "credentials" object to use
> for that connection.
>
>
I think the closest thing to what you're looking for that is currently
supported in Guacamole is the "vault" extension, which supports pulling
tokens from a credential vault. The only vault currently supported is
Keeper Secrets Manager, but support could certainly be extended to other
types of vaults with some code writing.

-Nick

Re: RDP issues in Guacamole 1.5.5

[Nick Couchman]

On Fri, Apr 26, 2024 at 6:50 AM Santiago Garcia Mantinan 
wrote:

> Hi!
>
> I can confirm this behaviour also on our setup (connecting against a Debian
> xrdp 0.9.21.1).
>
> > We started fiddling with the connection settings in Guacamole of one of
> our machines and noticed that if the "Enable audio input (microphone)"
> (Parameters -> Device Redirection) option was flagged, it started showing
> this behaviour.
> > Once disabled, we could RDP into the system.
>
> Alessio, thanks a lot for this report, this is the same issue we are having
> here and I believe the same one that other users have descrived on the
> thread "Cannot connect XRDP when migrate from 1.5.4 to 1.5.5" from the 8th
> of April.
>
> Like you, when we disable mic it works, if not, it gets stuck :-(
>
> If more info is needed to look at this, just let us know.
>
>
It's already resolved in Git, at the very least for the 1.6.0 release. We
have not decided if we'll do a 1.5.6 bugfix release or not.

-Nick

Re: How to get client IP address ?

[Nick Couchman]

On Fri, Apr 26, 2024 at 6:47 AM Molina de la Iglesia, Manuel
 wrote:

> Hello,
>
> After following the provided documentation, I cannot find a solution to
> get the real client IP.
>
> I have my application (PHP) on the same Guacamole Server, this application
> gets the user token:
>
> [image: image.png]
>
> The Tomcat log (after use the following pattern on the server.xml valve) I
> use: %{x-forwarded-for}i %l %u %t %r %s %b
>
> The log is OK (display the user IP)
>
> [image: image.png]
>
>
This does not look like the Tomcat log, this looks like a log for httpd or
Nginx, which means *that* is getting your client IP address. Do you have
your Proxy configured to pass the X-Forwarded-For header through to Tomcat?

-Nick

>

Re: Guacamole - Duo Web SDK v4

[Nick Couchman]

On Thu, Apr 25, 2024 at 12:51 PM Yumi chan  wrote:

> Hello.
>
>  I would like to know if anyone knows how to fix this problem with the duo
> in the guacamole.
> I'm using the version (Guacamole 1.5.5)
>

This is being worked under the following Jira issue and pull request:

https://issues.apache.org/jira/browse/GUACAMOLE-1289
https://github.com/apache/guacamole-client/pull/973

-Nick

Re: guacd and guac-client in different hosts

[Nick Couchman]

>
>
> Is there any way to make that SSL a mutual SSL / mutual TLS
> authentication? in that way, the client will authenticate the daemon, and
> the daemon will authenticate the client, and everybody should be happy
> (reference:
> https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/)
>
>
Today, no, but there is a feature our in Jira for it. Just hasn't been
implemented, yet:

https://issues.apache.org/jira/browse/GUACAMOLE-28


> Also, in general, which are the security implications of having a guacd
> serving request to incoming internet requests? Are there any docs you can
> share on that?
>
>
Without the mutual authentication implementation, you don't want to do this
- it would basically allow anyone with any sort of Guacamole client to
connect to guacd and attempt to open connections to all of your protected
systems.


> Finally, if having guacd exposed to the world is not a good idea, should
> we go with something like ssh tunnels or site-to-site VPNs to get the
> remote locations connected with the cloud deployed client? Any other
> options to consider?
>
>
Yes, you could either do site-to-site VPNs or SSH tunneling to protect the
traffic.

-Nick

Re: How to get client IP address ?

[Nick Couchman]

On Sun, Apr 21, 2024 at 5:18 PM Ivanmarcus 
wrote:

> Stephan,
>
> Having been around here for a while I'd be very surprised to find code
> contributions simply 'ignored'. If you look at Guacamole's development
> history I think you'd see that contributions are welcomed, and where
> they address a need and/or fit the project well they are incorporated.
>
> Naturally there would be discussion, and it *may* be that some
> contributions are not [immediately] accepted, however they would not be
> discarded out of hand for no reason. Perhaps this has been your
> experience of other projects but please don't anticipate it here.
>
>
Yes, completely agree. There is definitely scrutiny of changes and
discussion around it, and a rather robust review process. So, while changes
will not be discarded out of hand, for no reason, they will also not be
blindly accepted.


> Otherwise it's my view (and clearly that of many others) that Guacamole
> is not a 'mediocre' product. It has its flaws and no doubt could be
> improved, but being derogatory about something is not especially
> productive and rarely a good way to effect change.
>
> Thus I wonder if you might spend a little time looking closely at
> Guacamole's development and how/why it works the way it does presently?
> As an active project with good interaction and hard working developers,
> input from experienced coders would be gratefully received. However I
> suggest the usual way to go about changing something is first to become
> involved, become 'known' by your contributions, to gain better knowledge
> of the issues and direction facing the project, and thence be able to
> effect positive and cohesive change...
>
>
+1

I would love to see the community of active contributors, both developers
and supporters on the mailing list, grow to include a greater number and
more diverse population.

-Nick

Re: Installing Guacamole 1.5.5 tomcat listener failed to start

[Nick Couchman]

On Sun, Apr 21, 2024 at 9:56 PM My Data Belongs to Me! <
i...@mydatabelongsto.me> wrote:

> Hi Willy,
>
> TLDR:
> Many Many thanks for the crazy-fast reply - tomcat 9 to the rescue, so
> much easier this way :-)  I will SSL it up and go from there.
>
> Longer Version:
> Such a winding road related to balancing linux distro, certbot, java,
> tomcat and guacamole, but for better or worse, looks like I am close to
> crossing the finish line with Alma 8, Java 11, Tomcat 9 (thank you again),
> and Guacamole 1.5.5.
>
>
Running in Docker may be a route you could go if you find managing that too
complex. It has its own complexities, to be sure, but abstracts away at
least the build process.


> I was tempted to try the one-off Jakarta refresh in that ticket, tempted,
> but I didn't do it.
>
>
Yeah, I'm not sure it's quite ready for use, yet - I'd appreciate people
testing it, but wouldn't recommend it for any real use at the moment.

-Nick

Re: How to get client IP address ?

[Nick Couchman]

I'll keep this response shorter.

It seems unlikely we're going to come to an understanding or agreement on
how Guacamole should be implemented. The great thing is that Guacamole is
open source, and it sounds like you have some software development
experience, so you can fork the source code and modify it to suit your
needs and design philosophy, and even contribute that code back to the
community, if you're so inclined.

-Nick

On Sun, Apr 21, 2024 at 3:55 AM Stephan von Krawczynski 
wrote:

> On Sat, 20 Apr 2024 21:38:20 -0400
> Nick Couchman  wrote:
>
> > >
> > > Hello Nick,
> > >
> > > first of all, thank you for looking into the issue. So please let me
> ask
> > > this
> > > as a real question and no offence.
> > >
> >
> > None taken, perfectly fine to ask this.
> >
> >
> > > Why does the project _at all_ use a rather complicated API for
> > > authentication
> > > instead of "outsourcing" the function into a simple called hook (call
> it a
> > > script), and let this implement the wanted api to ldap, mysql, radius
> or
> > > just
> > > about anything that might be needed.
> >
> >
> > This is what we already do. Yes, the entire web-based application works
> > through a REST API, but, on the back-end, we take the REST API calls and
> > feed them, through a set of standard interfaces, to a back-end
> > authentication mechanism. The back-end authentication mechanisms are
> > standardized, interchangeable and stackable - you can use one or more in
> > combination, or you can write your own. The mechanisms can also
> "decorate"
> > other ones, so that you can use a back-end mechanism (like JDBC), but
> > extend its functionality to do something else.
> >
> >
> > > Still in the end an authentication is no
> > > more than giving parameters (like username, password, or client ip or
> > > whatever the caller (i.e. guacamole) has) and getting the simple
> answer:
> > > yes
> > > (authenticated) or no (login failed).
> > >
> >
> > This is really what the REST API does - it allows the front-end web
> > application to 1) receive a list of requirements from the back-end
> > authentication mechanism, 2) provide those requirements, either
> > automatically (client IP) or by user input (username and password), 3)
> get
> > an answer about whether authentication has succeeded or not, and 4)
> receive
> > and process data that the client has been authorized to receive (in our
> > case, connections, connection groups, users, groups, etc.).
> >
> >
> > > If you cut off the whole process at this point the whole story gets a
> lot
> > > more
> > > flexible, as anyone can then implement his needed hook (script) for his
> > > needs.
> > >
> >
> > As mentioned above, this is exactly how it works with the authentication
> > extensions.
> >
> >
> > > You may then distribute such hooks inside the project for standard APIs
> > > like
> > > ldap or the like - or leave it to the users to make/find their own.
> > >
> >
> > Yep, and Guacamole's design allows for exactly this - and the REST API
> does
> > not get in the way of that, in fact, it makes it possible to do that
> > without having to change the front-end web application at all.
> >
> > Also, none of the things you've mentioned actually address the issue
> you've
> > originally raised - no matter what method you use to communicate between
> > the web browser and the server, you still need to be able to provide the
> > data you're interested in providing - IP address, username, and password
> -
> > to the authentication system (LDAP you specifically mentioned). Unless
> your
> > solution is to have the client authenticate to LDAP directly and then
> > somehow tell the server that it is authenticated - which has a lot of
> > security risks to it (how does the server know to trust the client when
> it
> > says it authenticated successfully?) - I don't know of a way, with *LDAP*
> > specifically, to have the client IP address be part of the authentication
> > process, regardless of the language (PHP, ldapsearch, Java/JSP,
> > CGI/Perl...etc.). RADIUS, as a protocol, has those things built into it -
> > the NAS IP field within a RADIUS authentication request allows you to
> pass
> > the client IP on to the RADIUS server and then allow the RADIUS server to
> > make a determination about authentication success or failure based on
> that
> > in combination w

Re: How to get client IP address ?

[Nick Couchman]

>
> Hello Nick,
>
> first of all, thank you for looking into the issue. So please let me ask
> this
> as a real question and no offence.
>

None taken, perfectly fine to ask this.


> Why does the project _at all_ use a rather complicated API for
> authentication
> instead of "outsourcing" the function into a simple called hook (call it a
> script), and let this implement the wanted api to ldap, mysql, radius or
> just
> about anything that might be needed.


This is what we already do. Yes, the entire web-based application works
through a REST API, but, on the back-end, we take the REST API calls and
feed them, through a set of standard interfaces, to a back-end
authentication mechanism. The back-end authentication mechanisms are
standardized, interchangeable and stackable - you can use one or more in
combination, or you can write your own. The mechanisms can also "decorate"
other ones, so that you can use a back-end mechanism (like JDBC), but
extend its functionality to do something else.


> Still in the end an authentication is no
> more than giving parameters (like username, password, or client ip or
> whatever the caller (i.e. guacamole) has) and getting the simple answer:
> yes
> (authenticated) or no (login failed).
>

This is really what the REST API does - it allows the front-end web
application to 1) receive a list of requirements from the back-end
authentication mechanism, 2) provide those requirements, either
automatically (client IP) or by user input (username and password), 3) get
an answer about whether authentication has succeeded or not, and 4) receive
and process data that the client has been authorized to receive (in our
case, connections, connection groups, users, groups, etc.).


> If you cut off the whole process at this point the whole story gets a lot
> more
> flexible, as anyone can then implement his needed hook (script) for his
> needs.
>

As mentioned above, this is exactly how it works with the authentication
extensions.


> You may then distribute such hooks inside the project for standard APIs
> like
> ldap or the like - or leave it to the users to make/find their own.
>

Yep, and Guacamole's design allows for exactly this - and the REST API does
not get in the way of that, in fact, it makes it possible to do that
without having to change the front-end web application at all.

Also, none of the things you've mentioned actually address the issue you've
originally raised - no matter what method you use to communicate between
the web browser and the server, you still need to be able to provide the
data you're interested in providing - IP address, username, and password -
to the authentication system (LDAP you specifically mentioned). Unless your
solution is to have the client authenticate to LDAP directly and then
somehow tell the server that it is authenticated - which has a lot of
security risks to it (how does the server know to trust the client when it
says it authenticated successfully?) - I don't know of a way, with *LDAP*
specifically, to have the client IP address be part of the authentication
process, regardless of the language (PHP, ldapsearch, Java/JSP,
CGI/Perl...etc.). RADIUS, as a protocol, has those things built into it -
the NAS IP field within a RADIUS authentication request allows you to pass
the client IP on to the RADIUS server and then allow the RADIUS server to
make a determination about authentication success or failure based on that
in combination with the other information asked and provided (RADIUS
secret, username, password, one-time-password, etc.).

So does Kerberos - in fact, Kerberos actually does exactly what is
mentioned above - establishes a trusted relationship between KDC,
Server/Service, and Client, such that the client can authenticate and then
reliably tell the server that it should trust the client because they share
information that makes it trustworthy. And so Kerberos also has a way of
factoring the client system into the authentication process, in addition to
the username and password. At some point I will probably take a crack at a
Kerberos extension or configuration that does this, which also allows for
doing very seamless authentication with no need for entering credentials if
you're already logged into a client where you have a valid Kerberos ticket.

If you're also just looking for a way to factor a client IP address into
the authentication process, but it doesn't have to be linked directly to
the username or password, there are ways to do that, as well:
* Have a front-end proxy or Web Application Firewall filter based on IP
address.
* The 1.6.0 version of Guacamole Client will have an extension that allows
for banning IP addresses that repeatedly fail authentication. This can be
done, today, using something like fail2ban, but it'll be a bit more
integrated and easy with the extension.
* Write another authentication extension that either allows or disallows
authentication based on IP address or CIDR range.
* The 

Re: How to get client IP address ?

[Nick Couchman]

>
>
> > I believe the issue that Stephan is describing is that, when the user
> logs
> > in to Guacamole, and the remote LDAP server that is authenticating the
> user
> > logs a client IP address, it should log the IP address of the browser
> (far
> > end client) and not the IP address of the Guacamole Client (tomcat)
> system.
> > I'm just trying to get clarity from Stephan on whether this is what he's
> > actually trying to do and why.
> >
> > -Nick
>
> Yes, Nick, you are exactly on the right track here. And I am really not in
> a
> logging question, but truely in the authentication process where I want to
> know the far end client.
>
>
After looking at this a bit more, I cannot find a way, at least in the
Apache LDAP API that we use, to configure a client IP or send any sort of a
message that will pass that information through to the client, so I'm not
sure how feasible this actually is. RADIUS uas the NAS IP designed
specifically for this type of scenario, but I'm not finding any sort of
feature similar to NAS IP that allows for this kind of messaging.

-Nick

Re: guacd and guac-client in different hosts

[Nick Couchman]

On Sat, Apr 20, 2024 at 7:14 AM Robert Dinse 
wrote:

>
>   Really should port to the most recent since other projects may not
> remain
> in the stone age.
>

1. "Stone age" is not a fair assessment - Tomcat 9 is still actively
maintained with current releases (April 16, 2024 was the latest - 9.0.88),
as is Java 8.
2. There's already an effort to do this:
https://issues.apache.org/jira/browse/GUACAMOLE-1325
https://github.com/apache/guacamole-client/pull/972

-Nick

Re: change recordings path

[Nick Couchman]

On Mon, Apr 15, 2024 at 3:11 AM Molina de la Iglesia, Manuel
 wrote:

> Hi,
>
> Yes, the problem is the folder permissions, but if I change the owner of
> the folder the previous files are reachable from the history tab, but not
> new videos. I tried to modify the umask but I don't know how to do it
> properly, and I think that it could not be the best solution, I would like
> to create a "guacd" user and add it to the tomcat group. Does it make
> sense? How can I specify the user that runs guacamole?
>
>
Yes, you can either create a user like guacd and add to the Tomcat group,
or you can create a "guacamole" group and add both the tomcat user and the
guacd user to that group. Also, if your underlying filesystem supports
POSIX ACLs, you can use ACLs to allow both users to read and write from the
folders.

-Nick

>

Re: How to get client IP address ?

[Nick Couchman]

On Thu, Apr 18, 2024 at 10:00 AM Molina de la Iglesia, Manuel
 wrote:

> Hi,
>
> Similar situation, I have an application that authenticates the user, the
> a connection ID and "build" the URL with the token that is where the user
> goes. The IP that appears on the log is the address of the server where the
> intermediate application is.
>
>
I think this is a different issue - what you're describing is that the IP
address that is logged for a user login or connection within Guacamole is
the IP address of either the proxy (Nginx, httpd, etc.) or the Guacamole
Client system, rather than the actual client (browser) IP address. This is
covered in the manual under this section:

https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve

I believe the issue that Stephan is describing is that, when the user logs
in to Guacamole, and the remote LDAP server that is authenticating the user
logs a client IP address, it should log the IP address of the browser (far
end client) and not the IP address of the Guacamole Client (tomcat) system.
I'm just trying to get clarity from Stephan on whether this is what he's
actually trying to do and why.

-Nick

>

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

n Thu, Apr 18, 2024 at 10:05 AM Maciej Konigsman
 wrote:

> Has this issue been resolved in v1.5.5?
>

Yes; however, a new issue was introduced where a lock is not correctly
checked/opened, and having microphone support enabled can result in RDP
connections failing. We haven't decided, yet, if we're going to do a 1.5.6
bugfix release to correct that and anything else that pops up, or just move
on to 1.6.0.

-Nick

Re: How to get client IP address ?

[Nick Couchman]

On Thu, Apr 18, 2024 at 8:24 AM Stephan von Krawczynski 
wrote:

> Hello all,
>
> I have a setup of guacamole where the user authentication is done by ldap
> (openldap slapd). Is there an easy way to hand the client IP over to ldap
> bind
> requests?
>
>
Maybe you can provide a little more detail on what you're trying to
accomplish? I'm sure it's possible, but probably not without modifications
to the code. Also, it'd be interesting to know why this is a desired or
required configuration?

-Nick

Re: Pod auto-scaling for guacamole

[Nick Couchman]

On Thu, Apr 18, 2024 at 1:30 AM Viji Shankar 
wrote:

> Hi Team,
>
> We are enabling auto-scaling for the Guacamole pod which contains 3
> containers(guacamole, guacd and ngnix). After giving load to the container,
> the pod got autoscaled but we are getting the following error when we
> connect VM using guacamole.
>
>
>
> ERROR: *An error has occurred and this action cannot be completed. If the
> problem persists, please notify your system administrator or check your
> system logs.*
>
>
>

You'll need to check the logs further, and possibly enable some additional
debugging, to see what's going on, here. Look at container logs for both
guacamole and guacd containers.


> Please give me some suggestions to enable pod auto-scaling for guacamole.
>

Because Guacamole currently does not have any built-in HA capabilities (for
synchronizing session and such), in a configuration like this you will need
to insure that:
* The front-end load balancer uses some sort of session tracking or
"stickiness" to make sure that the client gets sent to the same Guacamole
Client (guacamole) container. Otherwise, the client will log in to one of
the guacamole containers, but then on the next request, potentially be
redirected to another guacamole container, which won't "know" about the
login.
* The guacamole containers need to be configured to use a consistent guacd
container for the connection. If any load balancing is configured such that
it might send traffic to multiple back-end guacd containers, this will
likely cause problems and result in errors.

-Nick

Re: Weird discrepency between main and 1.5.5

[Nick Couchman]

On Tue, Apr 16, 2024 at 11:46 AM Nick Couchman  wrote:

> On Tue, Apr 16, 2024 at 11:38 AM Demarteau Benjamin
>  wrote:
>
>> Hello,
>>
>> I was looking to get the code written in 2022 for GUACAMOLE-1372 [1] and
>> [2] and somehow don't see it in the 1.5.5 release from 2 weeks ago.
>>
>> I'm really weirded out by this. If you look at the diff between 1.5.5 and
>> main [3], there are 436 commits since 1.5.5 while there were only 16 or so
>> if you look at the commits from main [4].
>>
>> Does the team have any insight into this ?
>>
>>
> Yes - we do not necessarily place all of the commits in our git repo in
> the latest release.
>
> The 1.5.5 release was a bug fix release for the 1.5.x series, so the only
> Jira issues and commits included in it are ones that were specifically
> designed to address bugs in the 1.5.x code, and not any that would
> introduce new functionality or features. As such, the staging/1.5.5 branch,
> which contained the changes for the 1.5.5 release, really comes out of the
> 1.5.0 release back in early 2023, which was started in 2022.
>
> The pull requests you referenced, and their associated Jira issues, are
> going into the main branch (formerly the master branch), and will target
> (mostly) the 1.6.0 version. We also have a couple of issues out there that
> will go into the next branch, instead of the main branch, because they are
> targeted at the next major release of Guacamole, likely 2.0.0.
>
>
Here's the Jira issue, for reference - you can see it marked for the
"1.6.0" release:

https://issues.apache.org/jira/browse/GUACAMOLE-1372

>

Re: Weird discrepency between main and 1.5.5

[Nick Couchman]

On Tue, Apr 16, 2024 at 11:38 AM Demarteau Benjamin
 wrote:

> Hello,
>
> I was looking to get the code written in 2022 for GUACAMOLE-1372 [1] and
> [2] and somehow don't see it in the 1.5.5 release from 2 weeks ago.
>
> I'm really weirded out by this. If you look at the diff between 1.5.5 and
> main [3], there are 436 commits since 1.5.5 while there were only 16 or so
> if you look at the commits from main [4].
>
> Does the team have any insight into this ?
>
>
Yes - we do not necessarily place all of the commits in our git repo in the
latest release.

The 1.5.5 release was a bug fix release for the 1.5.x series, so the only
Jira issues and commits included in it are ones that were specifically
designed to address bugs in the 1.5.x code, and not any that would
introduce new functionality or features. As such, the staging/1.5.5 branch,
which contained the changes for the 1.5.5 release, really comes out of the
1.5.0 release back in early 2023, which was started in 2022.

The pull requests you referenced, and their associated Jira issues, are
going into the main branch (formerly the master branch), and will target
(mostly) the 1.6.0 version. We also have a couple of issues out there that
will go into the next branch, instead of the main branch, because they are
targeted at the next major release of Guacamole, likely 2.0.0.

So, the behavior you're seeing is entirely normal and intended.

-Nick

Re: Assistance installing guacamole in kali

[Nick Couchman]

>
> I am trying to install guacamole in kali VM.
>
> Specs of VM:
>
> $ uname -a
> Linux kali 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1
> (2024-01-08) x86_64 GNU/Linux
>
>
> I tried to use this script, but seems to do not find tomcat.
> https://github.com/MysticRyuujin/guac-install
>
>
> So i used this other:
> https://github.com/itiligent/Guacamole-Install
>
>
If you haven't, already, please familiarize yourself with the Guacamole
User Guide:
https://guacamole.apache.org/doc/gug/

specifically, the installation chapter:
https://guacamole.apache.org/doc/gug/installing-guacamole.html

Whether you use the script(s) or not, it'll help you understand the issues
you're running into.

>
> It installed Tomcat10, Is it tomcat10 supported?
>
> No, Tomcat 10 is not supported - you must use Tomcat 9 or earlier. See:

https://issues.apache.org/jira/browse/GUACAMOLE-1325

-Nick

Re: Connect direct to a web page

[Nick Couchman]

On Fri, Apr 12, 2024 at 7:28 PM Henri Alves de Godoy <
henri.go...@fca.unicamp.br> wrote:

> Hi all,
>
> Is there a way to create a connection directly to a web page http/https
> with guacamole server? Today only support ssh, vnc, rdp.
>
>
No. This has been discussed as a potential feature,
with...strong...opinions on multiple sides. But it is not possible, today.

See: https://issues.apache.org/jira/browse/GUACAMOLE-1659

-Nick

>

Re: Guacamole upgrades and db schema changes

[Nick Couchman]

On Fri, Apr 12, 2024 at 5:02 PM Salatiel Filho 
wrote:

> Hello everyone, when new guacamole patching (minor) versions are released,
> is there any changes to the database scheme? May I upgrade and downgrade
> without needing to revert the database?
>
>
There have not been any schema changes to the database since version 1.0.0.
So, if you're running that version or later then you do not need to do
anything with the schema between upgrades, and you can safely use previous
versions with the same database.

-Nick

>

Re: change recordings path

[Nick Couchman]

On Fri, Apr 12, 2024 at 9:46 AM Molina de la Iglesia, Manuel
 wrote:

> Hello,
>
> I would like to store session recordings on a different disk (let's say
> /dev/sdb),
>
> I tried the following two configurations without success:
>
> 1)
> guacamole.properties => recording-search-path: /recordings-disk
> disk/partition => /dev/sdb1
> mounting point => /recordings-disk
> Path => ${HISTORY_PATH}
> Name => ${HISTORY_UUID}
>
> 2)
> guacamole.properties => nothing defined
> disk/partition => /dev/sdb1
> mounting point => /var/lib/guacamole/recordings
> Path => ${HISTORY_PATH}
> Name => ${HISTORY_UUID}
>
> In both cases, the recording is properly stored on the disk, but on the
> session row that appears on the history tab doesn't have a link to watch
> the session.
>
>
Does the user account running *Tomcat* have read access to the recording
locations and the recording files?

-Nick

>

Re: Why did I not install guacd as systemd

[Nick Couchman]

On Thu, Apr 11, 2024 at 4:53 PM Johnnie W Adams  wrote:

> Hi, folks,
>
>  I'm comparing my installation to the one I inherited, and I noticed
> that the one I inherited has guacd installed as a systemd unit file, but
> the one I built does not. Did I do something wrong in the configuration?
> Both installations are 1.5.4 to the best of my knowledge. (I'm not entirely
> certain how to determine it on the one I inherited.)
>
>
There's an option in the configure script for enabling systemd:

  --with-systemd-dir=
  install systemd units to the given directory

You'll need to run that and provide a path to the directory you'd like to
install the systemd unit files in (/etc/systemd/system is common).

Also, depending on your system configuration, you may need to change the
user that guacd runs under. The default one in the systemd file included
with the distribution is "daemon", however, on many systems this user does
not have a writable home directory (RHEL and variants use /sbin as the home
directory), and RDP connections will likely fail due to the inability of
the user to write out the FreeRDP known_hosts file. So, you may also want
to create a user account and change the systemd file such that guacd runs
under its own user account.

-Nick

>

Re: [ANNOUNCE] Apache Guacamole 1.5.5 released

[Nick Couchman]

On Tue, Apr 9, 2024 at 8:02 AM Jason Keltz  wrote:

> On 4/8/24 16:08, Michael Jumper wrote:
> > On 4/8/24 10:03 AM, Jason Keltz wrote:
> >> It's great to see yet another new Guacamole release ... thanks Mike
> >> and Guacamole team!
> >>
> >> I went to look at installing Guacamole 1.5.5, and I usually update my
> >> tomcat to the latest 9.0 series, and JDK to the latest OpenJDK8.
> >>
> >> When I tried to install the newest version of tomcat, 9.0.87, I see
> >> an error: "Java version 17 or newer is required ".
> >>
> >> I vaguely remember at some point there being an issue possibly with
> >> later JDK and Guacamole, so I wanted to check first what is the
> >> latest JDK I should be using with Guacamole?
> >>
> >
> > I'm not sure why you're seeing such an error, but neither Guacamole
> > nor Tomcat 9 require Java 17. Guacamole requires Java 8 or later. I
> > believe the same is true for Tomcat 9:
> >
> > https://tomcat.apache.org/whichversion.html
> >
> > If you're seeing this when attempting to install/update Tomcat 9 (not
> > within the Tomcat logs when Guacamole starts up), it may be that your
> > distribution is enforcing its own requirements on top of the minimal
> > Java that Tomcat 9 technically requires.
>
> Hi Mike,
>
> If I look in the build.xml file, I see the following:
>
>
>
>
>
>
>
>
Yes, I see the same in the Git repo:

https://github.com/apache/tomcat/blob/0970fbaa12a45b31117b94e2781f8b7fa5c37f07/build.xml#L106-L110

However, even with the build version changed to 17, it still says the
"minimum" version is 8. The commit message for this change just indicates
that they are changing the build version from 8 to 17:

https://github.com/apache/tomcat/blame/bfb6ffcad7cea76712f5e398fb4c19a5d10248ac/build.xml#L110

-Nick

Re: Cannot connect XRDP when migrate from 1.5.4 to 1.5.5

[Nick Couchman]

On Tue, Apr 9, 2024 at 2:24 AM Víctor J. Sánchez E. 
wrote:

> Hi all,
>
> yesterday I've upgraded my both Docker containers guacd and guacamole from
> 1.5.4 to 1.5.5
> I've put new JDBC connectors releases to connect to MariaDB to store
> Guacamole user settings.
> Also I use TOTP.
>
> Everything works fine when I connected via RDP in 1.5.4 but in 1.5.5 I log
> succesfully to Guacamole and I can use SSH sessions but RDP screens gets in
> black with "Connecting to Guacamole. Waiting for response ..." (translated
> into spanish "Conectando a Guacamole. Esperando respuesta ...") and never
> shows XRDP session screen.
>
> I can do XRDP session succesfully outside Guacamole.
>
> xrdp.log and xrdp-sesman.log don't show any error or issue.
>
> The log showed by guacd container:
>
>
>
>
>
>
>
> *guacd[1]: INFO:Creating new client for protocol "rdp"guacd[1]:
> INFO:Connection ID is "$756c6373-53b0-4740-b396-55785d32a4e6"guacd[174]:
> INFO:No security mode specified. Defaulting to security mode negotiation
> with server.guacd[174]: INFO:Resize method: display-updateguacd[174]:
> INFO:No clipboard line-ending normalization specified. Defaulting to
> preserving the format of all line endings.guacd[174]: INFO:User
> "@0fe23d1e-0e3d-49d8-ae2a-43f39c38dc07" joined connection
> "$756c6373-53b0-4740-b396-55785d32a4e6" (1 users now present)guacd[174]:
> INFO:Loading keymap "base"guacd[174]: INFO:Loading keymap "es-es-qwerty"*
>
> The log showed by guacamole container:
> *06:15:21.521 [http-nio-8080-exec-10] INFO
>  o.a.g.tunnel.TunnelRequestService - User "victor" connected to connection
> "3".*
>
> I've also re-created RDP connection in Guacamole without success.
>
> In summary everything works fine with RDP in 1.5.4 but not in 1.5.5
>
>
I've also upgraded from 1.5.4 to 1.5.5 and routinely use Guacamole to
connect to both Windows RDP and xrdp servers, and I have not had any issues
at all with the newer version. Is this a single xrdp server you're seeing
issues with, or multiple ones that all behave the same?

I'm building guacd in a native environment, not using the Docker
containers, so not sure if there's some difference with that - I guess
we'll see if anyone else reports similar issues with the containers.

-Nick

Re: Getting around SSO

[Nick Couchman]

On Fri, Apr 5, 2024 at 3:44 PM Chris Jordan  wrote:

> Johnnie,
>
> In your guacamole properties, you can configure the extension priority so
> that you can hit the guacamole login screen without being automatically
> redirected to your IdP. This should allow you to still log in guacadmin (or
> any non-SSO account), while preserving your SSO functionality. You will set
> the priority according to the method used for SSO. I've provided two
> examples below with links to the documentation.
>
> extension-priority: *, saml
> extension-priority: *, openid
>
>
> https://guacamole.apache.org/doc/gug/saml-auth.html#presenting-unauthenticated-users-with-a-login-screen
>
> https://guacamole.apache.org/doc/gug/openid-auth.html#presenting-unauthenticated-users-with-a-login-screen
>
> On Fri, Apr 5, 2024 at 3:13 PM Tom Eaton  wrote:
>
>> I created a guacadmin account in the IDP, this works and let's you use
>> the guacadmin account as normal.
>>
>> On Fri, 5 Apr 2024, 19:59 Johnnie W Adams,  wrote:
>>
>>> Hi, folks,
>>>
>>>  I've inherited a single instance of Guacamole which is behind SSO.
>>>
>>>  This is unfortunate, because I can't log in as guacadmin. How do
>>> you folks set up to go around SSO with admin logins?
>>>
>>>
It's worth noting that the functionality that Chris mentions was added in
version 1.4.0, so if this inherited instance is an earlier version, you'll
need to upgrade to get this functionality.

-Nick

Re: high availability deployment

[Nick Couchman]

On Mon, Apr 8, 2024 at 3:38 AM Molina de la Iglesia, Manuel
 wrote:

> Hello,
>
> During the last months I was using Apache Guacamole on some environments
> without any problem, then now I would like to deploy the solution on
> another environment where we have a high number of users.
>
> In this new environment, I would like to deploy a couple of servers behind
> a load balancer but I cannot find a lot of information about how to
> configure these servers.
>
> My plan is to deploy two apache guacamole servers and configure mysql
> servers like master-master. Does it make sense? Should I consider any other
> changes?
>
>
The configuration you mentioned should work reasonably well overall - it
will allow multiple servers to provide a single configuration and users to
be spread across those servers. That said, there are some limitations to it
that you should be aware of:
* Session information - both logins and connections - is only stored
in-memory, and cannot currently be shared across Guacamole instances. This
means that you'll want to make sure to enable some sort of session tracking
or "stickiness" on your load balancer so that clients are directed to the
same back-end server consistently. If you don't do this, then you'll get
unexpected behavior from the clients - they'll be redirected to the login
screen or get errors from Guacamole.
* The lack of shared information about active connections also means that
limitations on the number of concurrent sessions for a given connection
will be largely meaningless - if you set the limit of concurrent sessions
on a connection to 10, and you have 3 x Guacamole Client servers, then you
actually could have up to 30 connections (10 per server x 3 servers).
There's not really any way around this at the moment - until we implement
some sort of mechanism for sharing connection information between
instances, this won't be fixed.
* Also related, connection sharing will be spotty, if it works at all.
Again, because active connection information is only stored in-memory, and
not shared across servers, if you try to share a connection, there's a
reasonably high chance that the user who tries to access the link for the
connection will be redirected to a different back-end server, and the
sharing link will be invalid. There isn't much that can be done about this
until we do some cross-node connection sharing.

Finally, it's important to keep in mind that there are two components to
Guacamole - the client (Tomcat + WAR), and guacd. Most of what I've
mentioned has to do with the client/Tomcat side; however, it's also
important to consider if and how you'll load-balance the guacd side of
things:
* You could run a guacd instance locally on each of your client servers, in
which case you shouldn't have to do anything special.
* You could also separate out the guacd instances and run them on their own
servers, and point each of the front-end/client servers to its own back-end
server.
* Or, you could run guacd behind a load balancer, and point all of the
client/front-end servers to a single hostname/IP, and then have a
load-balancer take care of assigning the client -> guacd connections. If
you go this route, you'll need to make sure the guacd load-balancer also
has some session tracking/stickiness on it so that connections don't get
unexpectedly redirected away from the guacd instance they've been assigned
to initially. And, doing this will not help at all with any of the
client-side issues mentioned above in terms of lack of connection tracking,
etc.

There's a Jira issue related to this, as well:
https://issues.apache.org/jira/browse/GUACAMOLE-283

-Nick

>

Re: Issue with Windows 10 RDP

[Nick Couchman]

On Thu, Apr 4, 2024 at 7:58 PM Jon Gerdes  wrote:

> Dear all
>
> Whatever that random internet link says, I have quite literally set up a
> Guacamole connection to a Windows 2022 server ... today.
>
> Please don't fiddle with your registry unless you now what you are doing -
> you will probably end up less secure and without a solution.
>
>
Tend to agree, here - I use Guacamole on a daily basis to log in to Windows
10 and 11, and Windows Server 2003 - 2022, and I do not have to make
special registry modifications to get it to work. Most of the servers use
NLA. That said, I am not using FIPS mode.

-Nick

>

Re: Error Message: double free detected in tcache 2

[Nick Couchman]

On Thu, Apr 4, 2024 at 11:48 AM Colin Fodor  wrote:

> Hello together,
>
> I’m currently facing the problem that I can’t start RDP Sessions.
>
> Looking in the syslog of the system I can see the following message:
>
> Apr  2 21:00:04 guacamole guacd[709]: free(): double free detected in
> tcache 2
>
> Apr  2 21:00:04 guacamole guacd[456]: Connection
> "$54633721-ed2b-41ba-af1f-269c53f212b2" removed.
>
>
>
> I’ve found a Bug that should be fixed in 1.5.4:
> [GUACAMOLE-1259] Son of immediate double-free upon connecting to Windows
> RDP - ASF JIRA (apache.org)
> 
>
>
>
> I’m currently running 1.5.4.
>
> I updated a few weeks ago (dist-upgrade and Gucamole) and after that
> everything worked fine, but I think this might still be related?
>
>
Yeah, that bug should be long fixed. For sanity check, can you post the
output of "guacd -v" (/path/to/guacd -v)?

-Nick

>

Re: How to use saml-strict?

[Nick Couchman]

On Tue, Apr 2, 2024 at 9:03 AM Jesus Malena  wrote:

> Hi Nick,
>
> Thanks for the quick response. I should have added my NginX configuration
> here as well so that this information would be more complete. Below is my
> NginX config.
>
> # HTTPS server
>
> upstream guacservice {
> server 127.0.0.1:8080;
> }
>
> server {
> listen   443 ssl http2;
> server_name  guactest.mytestserver.com;
> server_tokens off;
>
> access_log  /var/log/nginx/ssl_access.log  main;
>
> ssl_certificate  ssl/guactest_mytestserver_com.pem;
> ssl_certificate_key  ssl/guactest_mytestserver_com.pem;
> ssl_session_timeout  5m;
>
> ssl_protocols TLSv1.2 TLSv1.3;
> ssl_ciphers
> ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:!aNULL:!MD5:!DSS;
>
> ssl_prefer_server_ciphers   on;
> gzip on;
> gzip_types  text/javascript;
> gzip_proxiedno-cache no-store private expired auth;
> gzip_min_length 1000;
>
> location / {
> add_header Front-End-Https on;
> add_header Strict-Transport-Security "max-age=1600;
> includeSubDomains; always;";
> proxy_pass http://guacservice;
> proxy_hide_header X-Powered-By;
> proxy_set_header X-NginX-Proxy true;
> proxy_set_header Host $http_host;
> proxy_set_header X-Real-IP $http_true_client_ip;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_cookie_path ~(.*) "$1; secure; SameSite=None";
>
> proxy_redirect   default;
> proxy_redirect   http://$host https://$host;
> proxy_redirect   http://hostname https://$host;
> }
> location = /404.html {}
> location = /50x.html {}
> }
>
> server {
> listen  80;
> server_name  _;
> server_tokens off;
>
> location / {
> rewrite ^(.*)  https://$http_host$1 redirect;
> }
>
> location /nginx_status {
> stub_status on; access_log off;
> allow 127.0.0.1;
> deny all;
> }
> }
>
> There are some settings which you have suggested which I do not have
> which deal with websockets so I will have to look into those and implement
> them once I validate from the documentation. I will also have to go over
> some of my settings in this section and update some of these accordingly,
> like the proxy_set_header Host $http_host to just proxy_set_header Host
> $host as this is cleaner based on NginX documentation, but the
> X-Forwarded-Proto one is one that I do have set. There may be some
> additional cleanup that may need to be done on the above configuration, but
> this above configuration does work. If you see any glaring configuration
> issues above please let me know.
>
>
I would say just add the additional headers that I mentioned - it is a more
complete list than is in the manual (manual needs some updating in that
respect).

-Nick

>

Re: How to use saml-strict?

[Nick Couchman]

On Tue, Apr 2, 2024 at 12:29 AM Jesus Malena  wrote:

> Hi all,
>
> Currently I'm working on setting up Guacamole with SAML. I have gone ahead
> and was able to get things working with Okta. My settings are as follows
> (removing private data):
>
> saml-idp-metadata-url:
> https://mytestidp.okta.com/app/th!$isn0Tm&@pp/sso/saml/metadata
> saml-entity-id: https://guactest.mytestserver.com/
> saml-callback-url: https://guactest.mytestserver.com/
> saml-debug: false
> saml-strict: false
> saml-group-attribute: groups
> skip-if-unavailable: saml
>
> As you can see, saml-strict is set to false. I want to set saml-strict to
> true, but when I do my connections break with the following error:
>
> guacamole  | 17:39:37.776 [http-nio-8080-exec-3] WARN
>  o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted
> with an invalid SAML response: SAML response did not pass validation: The
> response was received at
> http://guactest.mytestserver.com/api/ext/saml/callback instead of
> https://guactest.mytestserver.com/api/ext/saml/callback
>
>
This is likely because you need a couple of extra proxy headers set.
Depending on what software you're using to proxy Guacamole through https,
this will vary a bit. For example, Nginx should have the following:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;

I would imagine your particular issue is because the X-Forwarded-Proto
header is not being set.

-Nick

>

Re: just to report a possible problem: tunnel?write:null status code 500 (old version 1.3.0)

[Nick Couchman]

On Wed, Mar 27, 2024 at 2:01 PM fed  wrote:

> Hi,
>
> As I wrote in the object I am running an old version, 1.3.0, I just want
> to report this problem that I found from some requests in the logs, sorry I
> don’t know if it is a false problem or if it was resolved in a newer
> version.
>
> What I found is a request to guacamole_endpoing/tunnel?write:null, this
> will generate a:
>
> HTTP Status 500 – Internal Server Error
> Type Exception Report
> Message String index out of range: 42
> Description The server encountered an unexpected condition that prevented it 
> from fulfilling the request.
> Exception
> java.lang.StringIndexOutOfBoundsException: String index out of range: 42
>  java.lang.String.substring(String.java:1963)
>  
> org.apache.guacamole.servlet.GuacamoleHTTPTunnelServlet.handleTunnelRequest(GuacamoleHTTPTunnelServlet.java:251)
>  
> org.apache.guacamole.servlet.GuacamoleHTTPTunnelServlet.doGet(GuacamoleHTTPTunnelServlet.java:137)
>  javax.servlet.http.HttpServlet.service(HttpServlet.java:626)
>  javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
>  
> com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:263)
>  
> com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:178)
>  
> com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
>  
> com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:62)
>  
> com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
>  com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
> Note The full stack trace of the root cause is available in the server logs.
>
> Thanks for the help.
>
Can you elaborate on what the problem is - how and when you encounter it -
and what you're expecting to get help with? It seems like writing "null" to
the tunnel endpoint is not something that one would normally do? Is there
some situation you're encountering where you expect this to happen, and
expect a different result?

Regarding the older version, I'd certainly encourage you to try out one of
the newer versions and see if it still exists - if it does turn out to be a
bug, either in 1.3.0 or in all versions, it would be fixed in a newer
release - we will not go back and patch 1.3.0.

-Nick

>

Re: Guacamole in Docker on ARM

[Nick Couchman]

On Thu, Mar 21, 2024 at 11:28 PM Nathaniel Belles <
mon99keymon99...@gmail.com> wrote:

> Hello,
>
> I have been interested in getting Guacamole working in Docker on ARM for
> running on Raspberry Pi’s. Although the Raspberry Pi isn’t my primary use
> case, it does have the unique advantage of being cheap and ultra-low power
> (albeit at degraded performance compared to full-on desktops). I have a
> Raspberry Pi installed at all my remote locations so even when my servers
> are rebooting or having connectivity issues, I can still at least access
> devices on the local network through Guacamole (mostly SSH and the
> occasional VNC). I looked around and only found pre-compiled versions that
> claimed to be compatible with Raspberry Pi’s but were tragically old
> versions of Guacamole.
>
> I have gone through the (surprisingly not painstaking) process of
> modifying the Dockerfile’s for guacamole-server and guacamole-client. I
> could create a pull request if that is what is wanted to integrate it to
> the main codebase. For now, I felt I should at least share the changes I
> made here for others looking to do the same.
>
>
This is great, thank you! I would think a pull request would be a great
thing.


> guacamole-server/Dockerfile changes:
> --DWITH_SSE2=ON \
> +-DWITH_SSE2=OFF \
>
(SSE2 doesn’t compile on ARM, I don’t have any windows computers on this
> network to verify that FreeRDP still works with this option disabled)
>
>
I'm not terribly familiar with Dockerfiles, but hopefully there's a way we
could set/disable this option based on the architecture?


> guacamole-client/Dockerfile changes:
> -ARG TOMCAT_VERSION=8.5
> -ARG TOMCAT_JRE=jdk8
> +ARG TOMCAT_VERSION=9
> +ARG TOMCAT_JRE=jdk21
>
-FROM maven:3-eclipse-temurin-8-focal AS builder
> +FROM maven:3-eclipse-temurin-21 AS builder
>
>
We might want to consider changing this across the board for all
architectures, assuming it doesn't break things. Would need some testing,
but seems like a good direction to head.

-Nick

Re: Kerberos support in Guacamole for RDP

[Nick Couchman]

On Thu, Mar 21, 2024 at 3:46 PM Shawn Southern 
wrote:

> Where can I find information at where the project is with implementing
> Kerberos support with Guacamole and FreeRDP?
>
>
>

You've come to the right place.


> It’s a best practice to eliminate NTLM, and NTLM is officially being
> deprecated and eventually removed from Windows anyway, so we’re building
> our roadmap to completely eliminate NTLM from our infrastructure.+  RDP
> works well without NTLM, but things like Guacamole still apparently need it.
>
>
>

Yes, we need to do it; however, I believe this depends on also adding
support for FreeRDP 3.x, because I do not believe that FreeRDP 2.x includes
Kerberos support (if it does, it's beta/unstable). I suspect that, after
FreeRDP 3 support is added, enabling Kerberos support in Guacamole will be
(relatively) easy.

-Nick

>

Re: Reverse engineering the guacamole database

[Nick Couchman]

On Tue, Mar 19, 2024 at 4:00 PM Johnnie W Adams  wrote:

> Hi, folks,
>
>  I've got a small guacamole installation that's fallen into my hands
> to maintain. It's set up to do SSO via SAML but to get all its
> authorization from a MySQL database. It's far from clear to me exactly how
> this database is set up. I'm poking around in the guacamole_db database but
> not getting any clarity on what does what.
>
>  Can someone point me to its documentation?
>

I think this will help you:
https://guacamole.apache.org/doc/gug/jdbc-auth.html#modifying-data-manually

Also, the schema file is located, here:
https://github.com/apache/guacamole-client/tree/main/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-mysql/schema

-Nick

>

Re: Just built and installed guacamole, but no guacamole.properties found

[Nick Couchman]

On Fri, Mar 15, 2024 at 3:33 PM Johnnie W Adams  wrote:

> Hi, folks,
>
>  I've built guacamole on Red Hat 9 and cannot find a
> guacamole.properties file anywhere.
>
>
You have to create it and populate it yourself - there is no
default/template that gets generated or installed.

-Nick

>

Re: Unexpected error in REST endpoint

[Nick Couchman]

On Fri, Mar 15, 2024 at 9:20 AM Vieri  wrote:

>
>
> On Friday, March 15, 2024 at 11:48:26 AM GMT+1, Nick Couchman <
> vn...@apache.org> wrote:
>
> > Can you get the full trace of this NullPointerExecption?
>
> It's the same as in my previous post:
>
> 2024-03-15 07:34:08,879 [https-openssl-apr-8543-exec-8] DEBUG
> o.a.g.rest.RESTExceptionMapper - Unexpected error in REST endpoint.
> java.lang.NullPointerException: null
> at java.io.Reader.(Reader.java:78)
> at java.io.InputStreamReader.(InputStreamReader.java:97)
> at
> org.apache.guacamole.rest.patch.PatchRESTService.readResourceAsString(PatchRESTService.java:69)
> at
> org.apache.guacamole.rest.patch.PatchRESTService.getPatches(PatchRESTService.java:113)
> at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
>

...
Sorry about that, didn't go back and look at the original. It looks like
the expected data isn't making it to the input stream, which seems to
indicate that the data is getting dropped before it hits the Tomcat server.
This seems to me to be something outside of the Guacamole stack itself -
something system-related, or perhaps a firewall or Web Application Firewall
(WAF) that might be blocking the traffic?

-Nick

Re: Unexpected error in REST endpoint

[Nick Couchman]

On Fri, Mar 15, 2024 at 5:44 AM Vieri  wrote:

> Hi,
>
> After quite a while without any problems I am now hitting this issue again
> (no tampering with extensions or anything at all -- system untouched):
>
> 2024-03-15 07:34:08,879 [https-openssl-apr-8543-exec-8] ERROR
> o.a.g.rest.RESTExceptionMapper - An internal error occurred, but did not
> contain an error message. Enable debug-level logging for details.
> 2024-03-15 07:34:08,879 [https-openssl-apr-8543-exec-8] DEBUG
> o.a.g.rest.RESTExceptionMapper - Unexpected error in REST endpoint.
> java.lang.NullPointerException: null
>
>
Can you get the full trace of this NullPointerExecption? You may have to
bump up the logging level of the web application, as documented, here:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html#logging-within-the-web-application

This should give you more details on where the error is actually happening
and we can troubleshoot further from there.

-Nick

Re: Edit connexion groups ?

[Nick Couchman]

On Thu, Mar 14, 2024 at 6:28 AM Alexandre Cariage 
wrote:

> Forgot to specify : I'm testing with *Balancing* connection groups.
>
> Le 14.03.2024 à 11:23, Alexandre Cariage a écrit :
> > Once a connexion is added to a group, it seemingly can't be edited
> > anymore.
> >
> > I just can't find it anywhere, clicking the "+" next to the Connexion
> > Group only shows options to add more connexions.
> >
> > Note I'm still on latest 14.X.
>

There's nothing about adding a connection to a connection group that would
prevent you from editing it.

The only thing I can think of is that you're logged in as a user that does
not have admin rights and only has access to the Balancing Group - in this
case, you'd be able to see the balancing group, but not the connections.
Make sure you're logged in as an admin user.

Beyond that, you might try upgrading to the 1.5.4 release and see if that
helps.

-Nick

Re: Checking for open connections ?

[Nick Couchman]

On Wed, Mar 13, 2024 at 11:43 AM Alexandre Cariage 
wrote:

> I need to automatically give a free connection to a given user upon
> connection, and depending on the connection they requested.
>
>
If I understand your question correctly, you're looking for the
Balancing-type connection group, which will load balance (and optionally
weight) the connections to any Connection objects that are members of that
connection group. In addition to load balancing, you can also enable
"Session Affinity", which will remember which connection a logged in user
was previously connected to and attempt to send the user back to that same
connection.

See the following page in the User's Guide for more information:
https://guacamole.apache.org/doc/gug/administration.html#connection-organization-and-balancing

-Nick

Re: Passing OpenID credentials through RDP

[Nick Couchman]

On Mon, Mar 11, 2024 at 8:10 AM Alexandre Cariage 
wrote:

> Thank you for the quick response and clarifications.
>
> For the second part, I was thinking of a way to pass the 'username' and
> 'password' as parameters, not actually edit them, although that might be
> the next best solution.
>

If you leave the username and password blank in the connection properties,
it will prompt the user at connection time, and pass them through. It will
*not* permanently save these values for the connection, so every user that
accesses that connection will be prompted each time that they use it.


> If not, would it be possible for the username only ? Better than nothing
> in our case. (-> So that the user is prompted for a password, but his
> username is recognized and pre-filled).
>

Yes, if you leave the password blank, and use ${GUAC_USERNAME} for the
username, the username will be pre-filled with the user's Guacamole
username, and the user will be prompted for the password.

-Nick

>

Re: Passing OpenID credentials through RDP

[Nick Couchman]

On Mon, Mar 11, 2024 at 7:45 AM Alexandre Cariage 
wrote:

> Hi all,
>
> Quickly :
>
> I'm looking to allow users to connect through OpenID Connect, and use the
> same credentials *inside the connection itself*, to open a Windows
> session with RDP.
>
> I.e., the Guacamole authentication is made by OpenID, and, through RDP,
> the Windows session open with the OpenID credentials too, allowing for a
> seamless login with the creation of an OpenID user only.
>
> Can Guacamole pass credentials this way ?
>

No, not quite this simply, anyway - this is a "limitation" of OpenID - but
really more of a design feature. One of the key purposes of SSO is that
there is no need for the sensitive credentials to be passed around from
application to application. Because of this, OpenID, once it authenticates
the user, does not provide any way for those credentials - the password,
specifically - to be retrieved, which means Guacamole doesn't even know the
password to be able to pass them on. The username should be known, and,
assuming the OpenID username matches the RDP username, that part should
work.


> If not, is there any other way to edit credentials on the fly (in other
> words, pass "Username" and "Password" fields of an RDP Connection in
> Guacamole as the connection is launched) ?
>

Yes, if you leave the username and/or password fields blank, Guacamole will
prompt you for the missing credentials at the time the connection is
launched.

The other option is to use a kev vault - currently Keeper Secrets Manager
is the only one supported - to retrieve secrets on-the-fly, but that
requires that you have that up and running in your environment, or that you
implement another key vault.

-Nick

Re: Simple modification to Event Listener example throwing runtime errors

[Nick Couchman]

On Sat, Mar 9, 2024 at 6:34 PM Nathaniel Belles 
wrote:

> Thanks for the quick response!
>
> The only output I get is:
>
> guacamole_guacamole  | 22:39:55.184 [http-nio-8080-exec-9] INFO
> org.apache.guacamole.event.Notifier - failed authentication for user null
> guacamole_guacamole  | 22:39:55.186 [http-nio-8080-exec-9] ERROR
> o.a.g.rest.RESTExceptionMapper - Unexpected internal error:
> 'org.apache.guacamole.net.auth.AuthenticationProvider
> org.apache.guacamole.net.event.AuthenticationFailureEvent.getAuthenticationProvider()'
>
> As for the pom.xml, the only thing I changed was the name of the
> artifactId produced to `guacamole-notifier`.
>
>
What version of Guacamole are you running, and what version(s) are
specified in the pom.xml for pulling in the guacamole-ext dependency?

-Nick

Re: Simple modification to Event Listener example throwing runtime errors

[Nick Couchman]

On Sat, Mar 9, 2024 at 6:08 PM Nathaniel Belles 
wrote:

> Hello,
>
> I’m currently trying to write a simple extension for guacamole that allows
> for push notifications through web hooks. The extension of course relies a
> lot on guacamole's event listeners. The documentation shows a very simple
> example (TutorialListener.java) of these event listeners which I have added
> to the `guacamole-client/extensions/` folder, compiled and then added the
> extension jar to the extensions folder of my guacamole instance. This
> example runs just fine and produces debugging output as expected. But when
> I try to extend the functionality, even just to store a copy of the
> `AuthenticationProvider` object from the event after including the
> `import org.apache.guacamole.net.auth.AuthenticationProvider;` line at the
> top of the file, I am able to compile the extension but then at runtime I
> get the following: `Unexpected internal error:
> 'org.apache.guacamole.net.auth.AuthenticationProvider 
> org.apache.guacamole.net.event.AuthenticationFailureEvent.getAuthenticationProvider()'`.
>
>
Could you share the full output of the runtime error or Java stack trace?


> I started looking through the code and I have found that there is a
> `.getAuthenticationProvider()` function in the
> `AuthenticationFailureEvent.java` file so I know that I’m using the write
> function. I also found similar instances of the
> `AuthenticationFailureEvent` being used in the `EventLoggingListener.java`
> file and tried to replicate the imports and logic used for the
> guacamole-client. Do I need to do something special to get proper access to
> the object types?
>
>
Aside from the import, are you including the required dependencies, and the
correct version(s) of them, in your pom.xml file?

-Nick

Re: Quick flash of a "Yellow Dialog Box"

[Nick Couchman]

On Thu, Mar 7, 2024 at 9:58 AM Brad Turnbough <
bturnbo...@backlundinvestment.com> wrote:

> It has been reported to me that some of my users have seen a yellow dialog
> like box that quickly shows up on our guacamole browser sessions and then
> disappers – not even up long enough to be seen / read.
>
>
Doesn't sound familiar to me.


>
>
> Does anyone know what this is and if so, what is it?  Is there a log file
> that will tell us what this yellow dialog box is stating?
>
>
The two places I would check are:
1) The user's browser console (Developer Console) logs.
2) The Tomcat catalina.out file, or wherever your Tomcat instance logs
things.

-Nick

>

Re: Replacement for MS terminal server

[Nick Couchman]

On Thu, Mar 7, 2024 at 11:04 AM Mansour Al Akeel 
wrote:

> Hello all,
>
> We have a legacy Java application (thick client). Currently, users connect
> to MS terminal server, to access the application, where some driver's must
> be installed. The platform is windows. We are hoping to replace TS with an
> open source alternative to avoid licensing costs. I believe this should be
> a simple process.
>
>
I'll answer your other questions below; however, for a Java-based thick
client, if it will run on platforms other than Windows (that's kind of one
of the points of Java, right?), you might be able to get rid of Windows and
run on Linux + xrdp or something like that. If drivers have to be
installed, and there aren't any available for Linux, then, well, you might
be out-of-luck.


> My questions:
> - Can guacamole replace MS terminal server, or is it just an HTML5 adapter
> ?
>

No, Guacamole is not a replacement for the actual terminal server, it is a
Remote Desktop gateway/client that runs in a browser (with a couple of
back-end components).


> - If it is a replacement, can it be installed on windows ?
>

Not really, at least, not fully. You can definitely install the client-side
bits on Windows (Tomcat 9.x). However, at the moment, guacd only runs on
Linux. You could run it in WSL, though, if you absolutely must run Windows.
But, why not just run Linux ;-)?


>
> - Looking at this page
> https://guacamole.apache.org/doc/gug/guacamole-architecture.html I can
> see that a user connects to guacd which in truns connects to the RDP
> server. Does it open a session for each user ? In other words, do we need a
> license for each user or does it require multiple connections ?
>

Kind of - not quite. Depending on how you leverage it, there are several
components:
* Guacamole Client, which is the web application, manages access control,
etc. If you use this (rather than writing your own web application), the
user will log in to the Guacamole Client web page, which is hosted by a
Tomcat server (or other JavaEE-compatible application server), and then
they can open connections from that client interface.
* Part of the stock Guacamole Client is the HTTP(S)+WS(S) tunneling
functionality, which provides the link between the user's web browser and
guacd, allowing for data (images, keystrokes, mouse movement, sound, etc.)
to be transferred between the client and guacd.
* guacd takes care of the translation between the Guacamole protocol and
the remote server protocols (RDP, SSH, Telnet, Kubernetes, and VNC).

>  Does it open a session for each user

Your question, here, is a bit vague. Does what open a session for each
user? What users are you talking about? What sessions?

>  In other words, do we need a license for each user or does it require
multiple connections ?

Again, I'm not entirely sure what you're referring to, here, when you ask
about licensing. Guacamole is freely-available, licensed under the Apache
2.0 license. There's nothing you have to license or buy for that.

For Windows, all of your normal Microsoft EULA licensing applies. I won't
go into detailed examples, but using Guacamole is not going to let you have
the same number of users accessing the application on the Terminal Server
and somehow reduce your Terminal Server/RDS licensing numbers/costs.
Microsoft has very, very good legal folks writing their EULAs, and they've
already dealt with the use of gateways end between actual end users/devices
and terminal servers in the terms of those EULAs. If your only reason for
trying to use Guacamole is to reduce the number of terminal server licenses
you're purchasing, IMHO, you might as well quit, now.


>
> - For docker installation, all I need is the server ( guacamole/guacd ),
> but my guess is Linux image, and not for windows. Is this correct ?
>
>
No, you need both guacamole/guacamole (the client side) and
guacamole/guacd. And, yes, those are Linux-based images, not Windows.

-Nick

>

Re: Order of extensions/datasource

[Nick Couchman]

On Tue, Feb 27, 2024 at 9:53 AM ITS SkillsUSA 
wrote:

> Hi There
>
> I had a question about the order of authentication providers in
> guacamole-client. I have been using the official docker container with the
> postgresql authentication extension for years, and it has been quite
> stable. I developed some API programs outside the container and was able to
> call them using postgres as my datasource (ie
> /guacamole/api/session/data/postgres/...) This has worked well.
>
> I then decided I wanted to add my own guacamole-ext to do some light css
> theming. I created my own extension (named rfoo).  This broke all of my API
> calls, as the datasource needed to be updated to rfoo. (ie
> /guacamole/api/session/data/rfoo/...) I then spent some time trying every
> permutation of EXTENSION_PRIORITY, but was unable to get the API url to
> change back to postgres.
>
> My questions:
>
> 1. Even though I'm just doing css changes, is the guacamole-ext /
> authentication provider the best way to accomplish this?
>

For CSS changes, you do need guacamole-ext, and a Guacamole Extension;
however, you need not implement an authentication provider class unless
you're doing some sort of integration between the authentication provider
and the CSS - like a custom attribute that controls the CSS in some way. If
all you're doing is changing the look and feel of the Guacamole Client web
application through CSS, you just need the guac-manifest.json file and the
actual CSS files. No need for any Java classes at all.

Also, none of those things should change anything about the API or how you
interact with data sources.


> 2. Is there a way to specify which authentication provider can be used in
> the API url, or better yet just generically send the API calls without a
> datasource?
>
>
That depends on what you're trying to do. If you're doing things like
creating and deleting connections, connection groups, users, and/or user
groups, you have to specify a data source, since all of those things happen
within the context of the data source.

Perhaps you could share what errors you're seeing, or how those API calls
"broke" after you added your extension?

-Nick

Re: Issue with VNC installation

[Nick Couchman]

On Tue, Feb 27, 2024 at 9:12 AM Devine, Harry (FAA)
 wrote:

> I have an Ansible role that installs Guacamole for me.  Been working very
> well.  The latest one that one of our users is testing doesn’t seem to have
> support for VNC.  I went back through the output and I find the following:
>
>
>
> configure: WARNING:
>
>   
>
>libvncserver appears to be built against
>
>libgcrypt, but the libgcrypt headers
>
>could not be found. VNC will be disabled.
>
>   
>
> configure: WARNING:
>
>   
>
>Unable to find libwebsockets.
>
>Support for Kubernetes will be disabled.
>
>   
>
>
>
> As well as:
>
>
>
> 
>
> guacamole-server version 1.5.4
>
> 
>
>
>
>Library status:
>
>
>
>  freerdp2  yes
>
>  pango ... yes
>
>  libavcodec .. yes
>
>  libavformat.. yes
>
>  libavutil ... yes
>
>  libssh2 . yes
>
>  libssl .. yes
>
>  libswscale .. yes
>
>  libtelnet ... yes
>
>  libVNCServer  no
>
>  libvorbis ... yes
>
>  libpulse  yes
>
>  libwebsockets ... no
>
>  libwebp . yes
>
>  wsock32 . no
>
>
>
>Protocol support:
>
>
>
>   Kubernetes  no
>
>   RDP ... yes
>
>   SSH ... yes
>
>   Telnet  yes
>
>   VNC ... no
>
>
>
>Services / tools:
>
>
>
>   guacd .. yes
>
>   guacenc  yes
>
>   guaclog  yes
>
>
>
>FreeRDP plugins: /usr/lib64/freerdp2
>
>Init scripts: /etc/init.d
>
>Systemd units: no
>
>
>
> How can I fix this so VNC is enabled?  I’m sure I’ll need to fix this
> installation manually, then add whatever needs to be done to the role to
> make future installations work.
>
>
>
Make sure you're installing the libgcrypt development package - depending
on what Linux distro you're using, it may be gcrypt-devel, libgcrypt-devel
grcypt-dev, or libgcrypt-dev.

-Nick

>

Re: History list empty after upgrade to 1.5

[Nick Couchman]

On Tue, Feb 27, 2024 at 9:11 AM Andrea Matthies 
wrote:

> After the upgrade from 1.4 to 1.5.4 (I also tried 1.5.3 ) the history list
> of the connection has only the column "duration" filled ou. All other
> columns are empty.
> But when I download the history , all columns in the csv file are also
> filled out
> Any suggestion?
>

Clear your browser cache and reload the page.

-Nick

Re: Failed connections RDP

[Nick Couchman]

On Tue, Feb 20, 2024 at 12:53 PM Andrea Miconi
 wrote:

> I understand what the problem is, quite stupid indeed.
> If Windows is configured with a Microsoft profile, the email and password
> of that profile must be used.
> That user has/had his own local name with a password, but now the
> Microsoft profile prevails.
>
> I then discovered that if the user is local, but has no password (I have
> test VMs with simple credentials, no password) Guacamole refuses to
> authenticate him.
> Then I also discovered that it is not enough to enable remote desktop on
> Windows, but also to authorize users to receive the connection.
> Using RDP is not exactly a walk in the park.
>
>
Glad you figured it out - thank you for posting the solution back to the
list.


>
> I take this opportunity to ask how do I close a connection from the
> browser?
> If I go back with the left arrow, I go back to Home and then I have the
> session open on the bottom right.
> Is there no way to close it right away?
>
>
There are a handful of ways to close the connection:
* Use the hidden Guacamole menu with the key combo Ctrl-Alt-Shift, and then
use the "Disconnect" option from the drop-down menu.
* Disconnect from the remote system.
* If you use the back arrow and you get the session in the bottom-right,
you should also see a red "X" in the corner you can use to close it.
* Close the tab that contains the session.

-Nick

>

Re: header authentication with BASE64 encoding

[Nick Couchman]

On Fri, Feb 23, 2024 at 7:48 AM  wrote:

> Thanks for the quick reply, Nick.
>
>
>
> Can you point out a justified reason for the LDAP module behavior you were
> mentioning? As far as I can think of, there shouldn’t be any practical
> reason for not being able to use the search user’s binding in order to
> query the logon user’s memberships in guacConfigGroup objects.
>
>
>

It's actually quite practical and quite intentionally designed to behave
that way. It allows for the LDAP extension to make use of the security
built in to the LDAP directory, so that you can restrict access to
connections by simply using LDAP ACLs to restrict what the user can see. I
would imagine that, at some point, we may provide alternatives within the
implementation to this - a configuration option that makes it behave
differently - but I would also expect we would retain this as the default
behavior.


> In any case, if this is how it is implemented I reckon that I could simply
> revert back to using the plain user-mapping.xml fie, hoping that header
> authentication works fine with it. So getting back to my original question,
> is there a known way I get access to the guacamole-auth-header source code,
> or alternatively get assistance from its authors in order to add support
> for base64 encoding?
>
>
>

The user-mapping.xml file will not work because it does not "layer" with
any of the other modules, for a couple of reasons. One is that it sort of
behaves like the LDAP module does, in one respect, where the ability to get
access to the connections defined in the file is based on you
authenticating with a valid username *and* password as defined in the file
- and if you're not entering a password, or entering a password that
doesn't match the one in the file, you're not going to get the connections
as defined in the file. The extension for storing connections that will
allow you to use Header, SSO, etc., is really the JDBC module - it's very
much designed to be a flexible back-end that works well with most of the
other modules.

The source code for guacamole-client can be found here:

https://github.com/apache/guacamole-client

with the header module, specifically, here:

https://github.com/apache/guacamole-client/tree/master/extensions/guacamole-auth-header

I was the original author of the header module, so I'm fairly familiar with
the code. Also, a quick Google search for "how to detect base64 encoding in
Java" turns up some options that should be pretty straight-forward:

String stringToBeChecked = "...";
boolean isBase64 = Base64.isArrayByteBase64(stringToBeChecked.getBytes());

(from
https://stackoverflow.com/questions/8571501/how-to-check-whether-a-string-is-base64-encoded-or-not
).

Should be easy enough to add that check into the Header module where it
gets the username, and then decode if it believes it is Base64 encoded.

-Nick

>

Re: header authentication with BASE64 encoding

[Nick Couchman]

On Fri, Feb 23, 2024 at 6:53 AM  wrote:

> Hi there!
>
>
>
> I’m new to Guacamole, and have successfully installed it (v1.5.4) in order
> to implement clientless VPN RDP access to our network. The Guacamole server
> is placed behind a corporate firewall which strongly authenticates users
> and then serves them the Guacamole web-app through its own native
> reverse-proxy engine.
>
>
>
> I installed the LDAP authentication extension, expanded our Active
> Directory Schema (adding the guacConfigProtocol and guacConfigParameter
> attributes along with the guacConfigGroup class), and everything is working
> fine in this aspect, I.e., connections and connection parameters are all
> managed within Active Directory.
>
>
>
> The last missing piece is header authentication – our firewall is able to
> pass on the authenticated username as a custom HTTP header, but after
> installing and testing out guacamole-auth-header-1.5.4.jar I stumbled into
> the following problem: Our firewall encodes the username header in BASE64,
> but the Guacamole header extension does seem to support it and seems to be
> expecting clear-text usernames. After investigating the issue, there is no
> way we can tweak our firewall to avoid encoding the username, it strictly
> enforces this behavior.
>
>
>
> Has anyone stumbled into this problem before? Is there some known way the
> header extension can support BASE64 encoding? If not, where can I find the
> header extension source code in order to try and add support for BASE64
> myself?
>
>
>

I've not hit this problem before, although I don't find it terribly
surprising - given the types of usernames (UPNs, for example -
u...@domain.com - or NT-style Windows domain - DOMAIN\USER), I can see why
a firewall would do this.

There's not currently any way for the extension to handle this directly -
it would take some code modifications to do it. It probably wouldn't be
terribly difficult to do and either have a configuration property to tell
it what to do, or maybe even auto-detect when something is Base64 encoded.

That said, I think you're going to run into an issue when you put this into
place if you're trying to couple the header authentication module with the
LDAP module, particularly if you're storing connection information inside
of LDAP (which you indicated above). The LDAP module relies on the username
*AND* password of the user logging in for the process of querying the LDAP
tree for accessible connections. So, the flow of the LDAP module is:
* User enters credentials.
* Guacamole connects with the search bind credentials and locates the user.
* Guacamole re-connects with the located user DN and the password the user
entered.
* Guacamole searches for available users, groups, and connections.

The key is that Guacamole *always* un-binds from the search user and
re-binds as the user who is logging in. This means, if you use Header (or
any of the SSO modules), Guacamole will not be able to query LDAP, so you
won't get any of that information.

-Nick

>

Re: Guacamole Menu

[Nick Couchman]

On Wed, Feb 21, 2024 at 8:08 AM  wrote:

> Sorry, maybe I wasn't clear.
>
> The legacy application uses the Ctrl + Alt + Shift key combination to
> perform a task.
>
>
I think that was clear and understood - Stefan's suggestion was to allow
you to send the key combo to the application.


> As we are only virtualizing the application, what we would like is to
> either disable the guacamole menu with this key combination, or change it,
> if possible.
>

There's no way to do this without modifying the source code.

-Nick

>

Re: Failed connections RDP

[Nick Couchman]

On Tue, Feb 20, 2024 at 10:39 AM Andrea Miconi
 wrote:

> I redid the entire installation, from scratch.
> I replaced Debian 12 with Ubuntu server 22.04.3.
> I also installed MySQL.
> I used the only user created at installation and using "sudo", so the
> rights are correct.
>
> So, now I have the installation complete and I'm configuring Guacamole
> from the GUI.
>
> Nonetheless, the situation is the same: a setup with SSH and VNC works
> straight away.
> With RDP, no!
>
>
I'll go back to the last question I asked:
* What account is guacd running under?
* Does that account have a writable home directory?

The FreeRDP libraries, when you connect to a server, *even when you tell it
to ignore the certificate*, store a copy of the certificate fingerprint in
a "known hosts" file, very similar to SSH. If the FreeRDP libraries are
unable to write this file, because the Linux user account lacks write
access to its own home directory, the connection *will fail.* I've run into
this when running guacd under the "daemon" user account on EL-based
platforms, as the "daemon" account generally has a home directory of /sbin,
and generally cannot write to that directory. Make sure the account running
guacd has a valid home directory, and write access to that directory.

There may be other issues that need to be addressed, but this is one of the
ones to verify.

-Nick

>

Re: Configuration from GUI

[Nick Couchman]

On Tue, Feb 20, 2024 at 10:47 AM Andrea Miconi
 wrote:

> I redid the entire installation, from scratch.
> I replaced Debian 12 with Ubuntu server 22.04.3 and My SQL.
> So, now I have the installation complete and I'm configuring Guacamole
> from the GUI.
>
> The funny thing is that while looking for documentation for Ubuntu I found
> a web page with the explanation for installing the JDBC connector for
> MariaDB in Debian.
>

Ubuntu is based on Debian, so there is a lot of overlap in instructions
between the two platforms. It is not uncommon to find instructions for
Ubuntu that are actually written for Debian, but work for both.

-Nick

Re: Failed connections RDP

[Nick Couchman]

On Mon, Feb 19, 2024 at 4:18 AM Andrea Miconi
 wrote:

> I tried enabling remote desktop on a VM Win11 Pro and a VM Win7 Pro.
> Same result, logs me out immediately.
>
>
What Linux account is guacd running under? Does that account have a
writable home directory?

-Nick

Re: Access to login page with HTTPS

[Nick Couchman]

On Sun, Feb 18, 2024 at 3:21 AM Andrea Miconi
 wrote:

> I've made some progress.
> I configured ha-proxy in my small personal laboratory.
> Listening to 0.0.0.0:443 and calling IP-LAN:8080
>
> Now if I type https://MyDomain.TLD/guacamole on a PC on the Internet, the
> Guacamole login page appears.
>
> However, I still have doubts.
>
> I now call the service with HTTPS and see the padlock marking the
> certificate with Let's Encrypt.
> However, I would like there to be the redirect from 80 to 443, but I think
> this is a problem with how the certificate is generated in the firewall.
>
>
This is entirely possible, but depends on what you're using for a reverse
proxy. Here are a couple of quick references for Nginx, Apache httpd, and
HAProxy:
https://serversforhackers.com/c/redirect-http-to-https-nginx
https://www.ssl.com/how-to/redirect-http-to-https-with-apache/
https://www.haproxy.com/blog/redirect-http-to-https-with-haproxy


> Furthermore, I didn't understand if I should also install the certificate
> on the PC on which guacamole runs.
> I generated a certificate for *.mydomain.tld and therefore it is also
> valid for the PC, but I don't know how to bring the certificate here.
> If I solve it I would have access to Guacamole via HTTPS also from the LAN
> and not just from the Internet.
> However, this is also not a HA Proxy problem.
>
>
If you're running the reverse-proxy for the Internet on a different system
from where Guacamole is installed, and want the HTTPS configuration with
that wildcard certificate in both places, then you'd need to install the
certificate on that system, as well. However, you don't need just the
generated certificate, you also need the private key that you used for that
certificate. Once you have that pair, you can copy them to the system where
Guacamole is installed and use them on it, as well.

As far as how to configure HTTPS on that system, it all depends on how you
want to do that. You could:
* Install HAProxy on that system, as well, and configure it with the same
certificate.
* Install Nginx or Apache httpd and configure one of them as a reverse
proxy using that certificate.
* Install the certificate into Tomcat and configure Tomcat for HTTPS, as
long as you're okay with it running on the non-standard port numbers. I
still don't recommend this approach.

-Nick

Re: Access Guacamole with another folder

[Nick Couchman]

On Sun, Feb 18, 2024 at 3:29 AM Andrea Miconi
 wrote:

> I access the login page with mydomain.tld/guacamole or with
> IP-PC/guacamole.
> I would like to be able to use another folder so as not to immediately
> make the type of service public.
> For example mydomain.tld/services or with IP-PC/services.
>
>
Two things you need to do:
* When you put the guacamole WAR file into the Tomcat webapps folder, name
it with whatever you want the URL to be. So, if you name the WAR file
"services.war", it will deploy at /services. The only special one is
"ROOT.war", which deploys it at the root, or /.
* If you're using a reverse proxy to enable SSL, make sure whatever change
you make to the WAR file, and whatever URL you expect to have on front-end
of that, is reflected in the configuration. So, if you deploy the WAR as
"services.war" and you're hoping to have it be "mydomain.tld/services",
make sure to change the /guacamole references in your reverse proxy
configuration to /services.

-Nick

Re: Configuration from GUI

[Nick Couchman]

On Sun, Feb 18, 2024 at 3:36 AM Andrea Miconi
 wrote:

> I am new with Guacamole and to configure it I used the xml file.
> Now I have to report any changes here.
>
> I had tried Guacamole years ago and I remember that as guacadmin I could
> configure it from the GUI, creating users, passwords, services to connect
> to, protocols, etc.
>
> Again if I remember correctly, I had also changed the logo and installed
> TOTP for two-factor authentication.
>
> Starting from this simple installation, how can I complete the
> configuration?
>
>
FIrst, make sure you have read through the manual and are familiar with its
contents. It covers a lot of these configuration topics:
https://guacamole.apache.org/doc/gug/.

To answer your questions a bit more specifically, though:
* The default authentication module included with Guacamole is the simple
user-mapping.xml file. It is not designed to be a long-term, scalable
authentication solution; instead, it's designed just to help you make sure
that Guacamole is functioning properly end-to-end.
* In order to be able to configure connections in the GUI, you'll need to
install one of the database modules and connect it to a database. This is
covered in the manual linked above, under the "Database authentication"
section.
* To configure TOTP, after you have the database authentication working,
you can add the totp module in. This is covered in the "TOTP two-factor
authentication" section.
* To customize the look-and-feel of Guacamole, you can generate your own
simple extension to overwrite the CSS and HTML of the interface. This is
covered at a high level in the "guacamole-ext" section of the manual, and
there's an example "branding" extension in the source repo:
https://github.com/apache/guacamole-client/tree/master/doc/guacamole-branding-example
.

-Nick

Re: Access to login page with HTTPS

[Nick Couchman]

On Fri, Feb 16, 2024 at 7:57 AM Andy Marden  wrote:

> That's what I do with everything. Reverse proxy with https coming in to
> nginx and then http to each device. Https is to much of a pain internally
> esp since Google decided to thing for us and decide that self signed certs
> are gonna give browser warnings.
>
>
There are ways to make sure that your systems don't give warnings - use an
enterprise CA, deploy the CA certificate to your internal systems. It
doesn't have to be a pain. Saying "HTTPS is too much of a pain" is setting
yourself up for security issues.


> The risk is low enough (if my lan is compromised I have way buffety
> problems).
>
>
Please forgive me while I go on a bit of a tangent about security, in
general...

I'd humbly suggest you reconsider this view of network security. If your
LAN is compromised, you may not know it. In fact, some of the most
successful attacks (outside of ransomware) on organizations have been ones
where attackers were able to get into the network and persist for years
without detection. If you think encryption is "too painful" or "too much
work", you're basically giving anyone that gets into your network (perhaps
already is in your network) free reign to collect information for as long
as they can, and making it really, really easy to do so. There's a saying
in security - there are two types of organizations: Those who have been
hacked, and those who know they've been hacked.

Also, keep in mind that many attacks are "insider attacks" - attacks
perpetrated by people who already have legitimate access to your network,
but who choose to abuse that access. There are many motivators for this -
greed, disgruntlement, dissatisfaction - but lack of relatively basic,
proper security can make this much easier for them, and increase the amount
of data they can get access to, and put you/the organization at risk.

Finally, if you're deciding that encryption is too painful/too much work,
it's indicative of a mentality toward security, in general, that says that
"proper security is too painful." So, what else, besides encrypting
traffic, are you sacrificing, because it is "too painful" or "too
difficult"? I'm going to avoid the temptation to continue building out my
argument, but, if your LAN is anything outside of your home network, you
probably have a responsibility to protect data that is valuable to someone
else.


>
> On 16/02/2024 at 12:31, Andrea Miconi 
> wrote:
>
> Thanks for your answers.
>
> Now I'm using guacamole in a LAN and I don't need a reverse proxy.
> When I have finished the configuration and everything is OK, I will
> connect from the Internet using the reverse proxy on the firewall (OPNsense
> with HA Proxy).
>
> If you assure me that it is already sufficient, then I will leave HTTP.
> Instead I would like to know if I can use another port from the Internet
> and let HAProxy redirect to 8080.
>
>
That's not what *I* said - I don't think HTTP is sufficient, and I would
install a reverse proxy and configure encryption *today.* I run Guacamole
in my $DayJob, and I encrypt both my production system and the
test/development system that I use. The return on the relatively small
investment is too great.

Please don't misunderstand me - I'm not saying that it's perfect or will
defeat any and all attacks, just that it's an easy enough thing to do to
make it sufficiently harder for someone on your network to intercept
traffic between systems.

-Nick

Re: Access to login page with HTTPS

[Nick Couchman]

I agree with both Alessandro and Robert's advice to just go ahead and
install a reverse proxy. There are several issues with running https
directly in Tomcat - one of them is that you either have to a) choose a
port above 1024 for the HTTPS traffic and then use port redirection magic
to move standard port 443 traffic to that port, or b) run Tomcat in such a
way that it has the privileges to open port 443 itself. In the past,
running Tomcat with privileges to operate on the standard HTTPS port (443)
meant running it as root, which is a Bad Idea; however, there are some
changes to at least Linux, maybe even some of the BSDs, recently, that
allow you to set a capability for the Tomcat user to open privileged ports
without having to elevate to root.

The thing is, the above are just the things you have to do to get Tomcat to
even listen or process traffic on 443, and you haven't even set up the
private key/certificate, yet. You're really better off just installing
either Nginx or httpd and going that route.

-Nick

On Fri, Feb 16, 2024 at 6:06 AM Alessandro Sironi 
wrote:

> Hi Andrea,
>
> it would be better to not expose directly Tomcat to internet, instead, you
> sohould use a reverse proxy such as NGINX or Apache and land there over
> HTTPS.
>
> Regards,
>
> Alessandro
> Il 16/02/2024 11:47, Andrea Miconi ha scritto:
>
> I'm new to guacamole and now I can access the login page with HTTP.
>
> I want to access it with HTTPS instead, but I can't figure out what I
> should do.
> Reading online I found a suggestion to install Nginx as a reverse proxy,
> but I would like to avoid it.
>
> Shouldn't it be enough to activate https on Tomcat?
> How to do it?
>
>

Re: Guacamole 1.5.3 - missing recordings

[Nick Couchman]

On Thu, Feb 15, 2024 at 8:11 AM Maciej Konigsman
 wrote:

> Hi,
>
> additional information. Each corrupted recording is 427 bytes and contains
> this error:
> "...5.error,15.Upstream error"
>
> Where can I find information about this error?
>

You'll need to look at your guacd logs and see if it's indicating any issue
with saving the recording. You may need to start guacd in debug mode to get
any additional logs.

-Nick

>

Re: [EXT] Re: server fails to compile

[Nick Couchman]

On Wed, Feb 7, 2024 at 12:22 PM Khoe, Yonathan 
wrote:

> Hi Nick,
>
> When will we be seeing the 1.6.0 release?  I am also experiencing this
> compile error that I rather not circumvent (per Vincent Sherwood’s method)
> if it would lead to further complication later down the line.
>
>
We don't have a date for it, yet - we're working the 1.5.5 bugfix release,
and then maybe/hopefully start closing things out for 1.6.0, but I would
say several weeks out at the very earliest.

-Nick

>

Re: REST API - Create URL connection (Permission Denied)

[Nick Couchman]

On Fri, Feb 9, 2024 at 6:46 AM i.no...@wp.pl  wrote:

> Hello,
>
> I've installed Apache Guacamole v.1.5.4 on Linux CentOS 8.5  - I'm able to
> login to GUI, create users, connection, etc.
> I installed database (MySQL) as well (to manage users, connection) with
> all needed *.jar files according to doc
> https://guacamole.apache.org/doc/gug/jdbc-auth.html
>
> After that, I'm able to login as ""guacadmin" user to GUI and manage
> connections etc.
>
> Now, I want to create URL to direct connection to my VM, but I found
> errors like below:
>
> --  SCRIPT
> -
> #!/bin/bash
>
> TOKEN=$(curl -s -X POST -H "Content-Type:
> application/x-www-form-urlencoded" -d
> "username=guacadmin=guacadmin"
> http://localhost:8080/guacamole/api/tokens | jq -r '.authToken')
>
> # Endpoint API Guacamole
> API_ENDPOINT="
> http://localhost:8080/guacamole/api/session/data/mysql/connections;
>
> CONNECTION_DATA='{
>   "name": "Connection name",
>   "protocol": "rdp",
>   "parameters": {
>   "hostname": "10.194.53.45",
>   "port": "3389",
>   "username": "user",
>   "password": "password"
>   }
> }'
>
> RESPONSE=$(curl -s -X POST -H "Content-Type: application/json" -H
> "Authorization: Bearer $TOKEN" -d "$CONNECTION_DATA" $API_ENDPOINT)
>
>
I don't think you're using the correct header, here for the Guacamole
authentication token - you should be passing a header called
"Guacamole-Token" with the Guacamole authorization token. Guacamole does
not generally use the "Authorization" header.


> CONNECTION_ID=$(echo $RESPONSE | jq -r '.identifier')
>
> if [ "$CONNECTION_ID" != "null" ]; then
>   URL="
> http://localhost:8080/guacamole/#/client/$CONNECTION_ID?token=$TOKEN;
>   echo "Connection ID: $CONNECTION_ID"
>   echo "URL: $URL"
> else
>   echo "Error creating connection."
> fi
>
>
Two issues, here:
* We've removed the ?token= parameter in recent versions in favor of a
model that prefers/uses a header, instead, so you should leave off the
token= part of this.
* Your path for the connection (/client/$CONNECTION_ID) won't work - the
client identifier is not the same as the connection ID, but is, instead, a
base 64 encoding of the type of connection (connection or connection
group), the data source (pgsql, mysql, etc.), and the connection
identifier. See:
https://github.com/apache/guacamole-client/blob/22fe53fde50fd139cb86091912e1ae50d348add8/guacamole/src/main/frontend/src/app/navigation/types/ClientIdentifier.js#L40-L71

-Nick

>

Re: `OPENID_SCOPE` environment variable in Docker not working

[Nick Couchman]

On Thu, Feb 8, 2024 at 12:34 PM Michael Jumper  wrote:

> On 2/8/24 03:17, Nick Couchman wrote:
> > On Thu, Feb 8, 2024 at 2:23 AM Mike Wyatt  > <mailto:wyatt.m...@gmail.com>> wrote:
> >
> > I'm trying to get my existing Guacamole installation working with
> > OpenID. I've got everything working correctly, but Guacamole is not
> > requesting the `groups` scope.
> >
> >
> > As you noted in the Jira issue you opened, this has been resolved in the
> > git master code but not yet released (it will go into version 1.6.0 when
> > that comes out, date TBD).
> >
>
> Perhaps we should re-merge the change to upcoming 1.5.5?
>
>
Sure, I'm good with that.

-Nick

Re: `OPENID_SCOPE` environment variable in Docker not working

[Nick Couchman]

On Thu, Feb 8, 2024 at 2:23 AM Mike Wyatt  wrote:

> I'm trying to get my existing Guacamole installation working with OpenID.
> I've got everything working correctly, but Guacamole is not requesting the
> `groups` scope.
>
>
As you noted in the Jira issue you opened, this has been resolved in the
git master code but not yet released (it will go into version 1.6.0 when
that comes out, date TBD).

-Nick

>

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

On Wed, Feb 7, 2024 at 6:40 AM Yannick Martin 
wrote:

> Hello
>
> About pthread_keys leak, I wonder if
>
> https://github.com/apache/guacamole-server/blob/master/src/libguac/client.c#L299
> and L300 is not a duplicate call of those done in:
>  guac_rwlock_init(&(client->__users_lock));
>  guac_rwlock_init(&(client->__pending_users_lock));
>
>  which call pthread_key_create too =>
>
> https://github.com/apache/guacamole-server/blob/master/src/libguac/rwlock.c#L52
>
>
Two issues with this:
* I'm not sure that duplicating a call to pthread_key_create() would/should
result in the behavior we're seeing - where TLS-based connections fail
after a certain, relatively well-defined number (58-60).
* This also would not explain why this only occurs in certain situations,
on certain platforms - that is, the same exact libguac code running on EL7
(RHEL, CentOS, etc.) does not result in the resource leak, whereas it does
on some other set of platforms (Debian, Alpine, EulerOS). Unless the
pthread library has been changed substantially between those versions to
not clean up after itself?

-Nick

Re: Activate TLS/SSL on server

[Nick Couchman]

On Tue, Feb 6, 2024 at 11:13 AM Döngi, T.  wrote:

> Hi all,
>
> is it possible to enable TLS/SSL encryption for the guacamole server?
>
>
This depends a bit upon where in the connection process you're trying to
activate it, but, yes. I suspect you mean for the web page, which is
usually done by proxying Guacamole through a reverse proxy (like Nginx or
Apache httpd):

https://guacamole.apache.org/doc/gug/reverse-proxy.html

-Nick

Re: guacamole can't communicate with guacd

[Nick Couchman]

On Wed, Jan 31, 2024 at 10:48 PM  wrote:

> Apparently there are two problems.
> The first is a ipv4 vs. ipv6 issue. If I use localhost in guacd.conf:
> [server]
> bind_host = localhost
> bind_port = 4822
>
> guacd binds to a ipv6 address  and guacamola never finds it. Change
> guacd.conf to
> [server]
> bind_host = 127.0.0.1
> bind_port = 4822
>
> and guacamola now finds guacd.
>
>
Yes, this is definitely a known issue with systems that support both IPv4
and IPv6. Glad you got that resolved.


> Second problem:
> guacd can't find its vnc plugin. Again, systemctl status guacd yields:
> Jan 31 18:10:22 pi4dev guacd[5518]: Creating new client for protocol
> "vnc"
> Jan 31 18:10:22 pi4dev guacd[5518]: Connection ID is
> "$4e2159ab-c7ff-4243-884f-267cd3bd8ad2"
> Jan 31 18:10:22 pi4dev guacd[5567]: Cursor rendering: local
> Jan 31 18:10:22 pi4dev guacd[5567]: User
> "@6c10f1d1-cf63-404a-8479-e16259dcccbe" joined connection
> "$4e2159ab-c7ff-4243-8>
> Jan 31 18:10:22 pi4dev guacd[5567]: ConnectClientToTcpAddr6: connect
> Jan 31 18:10:22 pi4dev guacd[5567]: Unable to connect to VNC server
> Jan 31 18:10:22 pi4dev guacd[5567]: Unable to connect to VNC server.
> Jan 31 18:10:32 pi4dev guacd[5567]: User
> "@6c10f1d1-cf63-404a-8479-e16259dcccbe" disconnected (0 users remain)
> Jan 31 18:10:32 pi4dev guacd[5567]: Last user of connection
> "$4e2159ab-c7ff-4243-884f-267cd3bd8ad2" disconnected
> Jan 31 18:10:32 pi4dev guacd[5518]: Connection
> "$4e2159ab-c7ff-4243-884f-267cd3bd8ad2" removed.


Actually, guacd is finding the VNC plugin - if it weren't, you'd receive a
very specific message about it being unable to load the VNC protocol. What
you have, here, is guacd being unable to connect to your VNC server:

Jan 31 18:10:22 pi4dev guacd[5567]: ConnectClientToTcpAddr6: connect
Jan 31 18:10:22 pi4dev guacd[5567]: Unable to connect to VNC server
Jan 31 18:10:22 pi4dev guacd[5567]: Unable to connect to VNC server.

The first message, with ConnectClientToTcpAddr6, is actually from
libvncclient, which is a good indication that 1) guacd _is_ actually
correctly loading VNC support, and 2) that the VNC library is attempting to
make the connection. What I'm not sure about is the Addr6 - this may
indicate that libvncclient is resolving your VNC server to an IPv6 address,
and is failing to connect to that.

Next things to check would be:
* Start guacd in debug log mode ("-L debug" on the command line or
("log_level = debug" in the "[daemon]" section of guacd.conf)
* Verify your Guacamole connection settings have the correct hostname or IP
address and the correct port number for your VNC server.
* If it's a hostname, verify that you can correctly resolve it to the
expected IP address from the system running guacd.
* Verify that you can connect to that IP  + Port combination from the
system running guacd, outside of Guacamole - you can do this by using
something like nc or telnet or tcping to attempt the connection and verify
that it works as expected.
* Verify that something like SELinux or AppArmor is not blocking guacd,
specifically, from making those outbound network connections.

-Nick

Re: Preventing a "double login" using SAML

[Nick Couchman]

On Wed, Jan 31, 2024 at 4:10 PM Barnhart, Steven 
wrote:

> SAML is our main authentication provider, and we wouldn’t mind using it
> with Guacamole to simplify things, unfortunately due to the way SAML works
> we don’t have access to the credentials to pass through to connections. I
> don’t suppose anyone has thought of ways around this?
>
>
>

Strictly speaking, no, there is no way around this, at least, not with
SAML, and not with things as implemented today in Guacamole. There are some
possibilities in the future - for example, SSL SSO (coming out in the
Guacamole 1.6.0 version) + Smartcard pass-through (not yet implemented at
all) could do the trick. It's also possible that implementing some sort of
Kerberos authentication mechanism for Guacamole (not implemented at all),
combined with FreeRDP 3.0's support for Kerberos authentication (also not
in Guacamole, yet) would, in certain situations, get rid of the
double-authentication requirement.

It's also worth noting that other remote access/VDI products that I use on
a regular basis - for example, Microsoft's Azure Virtual Desktop, and
VMware Horizon - behave exactly the same way and have the "double
authentication" requirement when accessing systems that require a username
and password.

-Nick

>

Re: Fw: Using SAML Authentication behind a Reverse Proxy (nginx)

[Nick Couchman]

On Tue, Jan 30, 2024 at 2:10 AM Oliver, Dario N 
wrote:

> Hi!
>
> *Note: I posted a similar topic some time ago, but that one was to use
> Guacamole behind a Proxy Server. This time, the issue is behind a Reverse
> Proxy.*
>
> I am using the Guacamole DockerHub image, behind an Nginx proxy, as
> documented in
> https://guacamole.apache.org/doc/gug/reverse-proxy.html#nginx.
> Guacamole is set up with the "saml" extension, as documented in
> https://guacamole.apache.org/doc/gug/saml-auth.html.
>
>
The documentation is actually missing a couple of headers that should be
set:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;

Make sure all of those are set - I think the X-Forwarded-Proto, in
particular, will resolve your issue.

-Nick

>

Re: Unhashed connection credentials

[Nick Couchman]

On Tue, Jan 30, 2024 at 2:23 AM Döngi, T.  wrote:

> Hi all,
>
>
>
> RDP connection credentials are stored plain text in MariaDB. I consider
> that a big security risk for case of guac server getting compromised. For
> better understanding what’s the reason for that and is it planned to hash
> the credentials in near future?
>
>
>

The reasoning behind this is that, even if credentials are hashed, they
have to be stored in some sort of reversible hash in order to be sent to
the server, which means that the value of hashing them in the first place
is questionable. If an attacker gets access to your database server in such
a way that they can read the tables that contain the configuration value,
then they probably also can get to things like the Guacamole client
configuration (guacamole.properties), so they'd also be able to reverse any
hash values pretty easily. It really falls under the header of "security by
obfuscation", which isn't really good security.

I do not know of any plans to change this - we've discussed it before, and
the overall value is low. The better things to do are:
1) Make sure that you adequately protect your database, and the Guacamole
<-> Database communications. They should be treated as if they contain
sensitive information.
2) Avoid storing credentials for your connections in your database. Use
parameter tokens (${GUAC_USERNAME} and ${GUAC_PASSWORD}) to pass user
credentials through directly, have connections prompt for credentials, or
use the KSM Vault to handle credentials rather than storing them directly.

-Nick

>

Re: tomcat won't load guacamole

[Nick Couchman]

On Mon, Jan 29, 2024 at 11:17 AM Jim Ham  wrote:

> When tomcat10 tries to load guacamole-1.5.4.war it gives the following
> error:
> SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error
> configuring application listener of class [org.a
> pache.guacamole.GuacamoleServletContextListener]
> java.lang.NoClassDefFoundError:
> javax/servlet/ServletContextListener
>
> This in  is a RasperryPi 4 running rasperian stable. Tomcat10 installed
> from the rasperian repository. I have guacd running. I downloaded the war
> file from the guacamole.apache.org/releases/1.5.4/ website.
>
> I did find a bug about this same issue, but was marked as resolved about
> two years ago. Any suggestions?
>
>
Tomcat10 is not supported, currently:

https://issues.apache.org/jira/browse/GUACAMOLE-1325

-Nick

>

Re: Slack invite

[Nick Couchman]

On Mon, Jan 29, 2024 at 10:08 AM  wrote:

> Hello Everyone,
> Can you please provide slack invite, I am working on guacamole setup and
> have technical questions.
>
>
I would encourage you to ask your questions, here - the Slack channel isn't
all that active, and the benefit to the community will be greater having
those questions asked and (hopefully) answered, here.

-Nick

Re: server fails to compile

[Nick Couchman]

On Fri, Jan 26, 2024 at 6:40 PM Jim Ham  wrote:

> Guacamole 1.5.4, from the tar on the website. I did the ./configure and
> then ./make. Many files compile just fine, but the task ends with the
> following error:
>
> 
> CC   guacenc-video.o
> video.c: In function ‘guacenc_video_alloc’:
> video.c:64:22: error: assignment discards ‘const’ qualifier from pointer
> target type [-Werror=discarded-qualifiers]
> 64 | container_format = container_format_context->oformat;
>|  ^
> video.c:67:22: error: initialization discards ‘const’ qualifier from
> pointer target type [-Werror=discarded-qualifiers]
> 67 | AVCodec* codec = avcodec_find_encoder_by_name(codec_name);
>|  ^~~~
> cc1: all warnings being treated as errors
>
> <\code>
>
> I'm compiling on a Raspberry Pi 4. GCC gives me the following version:
>
> gcc (Raspbian 12.2.0-14+rpi1) 12.2.0
> Copyright (C) 2022 Free Software Foundation, Inc.
>
> Any suggestions?
>

This has already been fixed in the Git code in the master branch, targeted
for version 1.6.0:

https://issues.apache.org/jira/browse/GUACAMOLE-1714

You can back-port the patch to your source tree code if you'd like to fix
it immediately:

https://patch-diff.githubusercontent.com/raw/apache/guacamole-server/pull/399.patch

-Nick

Re: Log in to Gnome Shell RDP

[Nick Couchman]

On Fri, Jan 26, 2024 at 11:26 AM Horváth Csaba 
wrote:

> Hi,
>
> I have installed guacd from Debian's repos, and it runs by default in
> the name of user guacd.
>
> guacd3163019  0.0  0.1 246252 10376 ?SJan24   0:00
> /usr/sbin/guacd -b 127.0.0.1 -l 4822 -p /var/run/guacd/guacd.pid
>
> Ang guacd has no home by default (which is acceptable from security
> viewpoint, but affect usability :D maybe i need to file a bug to
> Debian team :D )
> guacd:x:998:996::/var/run/guacd:/bin/false
>

That user does have a home directory - /var/run/guacd - so you need to make
sure the guacd user has write access to that directory.

-Nick

Re: Log in to Gnome Shell RDP

[Nick Couchman]

On Fri, Jan 26, 2024 at 11:22 AM Horváth Csaba 
wrote:

> Hi,
>
> Thanks for clarification! How i specify the account for guacd? I mean,
> OK, i create the user, but how i specify that guacd should start in
> the account's behalf?
>

That depends on how you're starting guacd, now...
* If you're using systemd, edit the guacd systemd file and change the
"User=" line such that it specifies the user you've just created.
* If you're using init.d, change the init file such that it does a "sudo
-u" when executing the program.
* If you're starting manually, just do "sudo -u guacuser /path/to/guacd",
replacing guacuser with your user account and /path/to/guacd with the
actual path to the guacd program.

-Nick

Re: Log in to Gnome Shell RDP

[Nick Couchman]

On Wed, Jan 24, 2024 at 3:40 PM Horváth Csaba 
wrote:

> Hi,
>
> Tried with a Windows VM with NLA turned off; so simple RDP connection
> works with security=rdp . So the issue is that guacd cannot
> communicate with TLS and NLA security servers.


This means it likely has to do with the issue that David mentioned with the
home directory for the user running guacd.

Note that we're talking about the Linux/UNIX home directory for the Linux
user running guacd, not the GUACAMOLE_HOME directory. For example, if you
run guacd under the "daemon" account, and the daemon account has a home
directory of /usr/sbin (as is the case in RHEL8, for example), then the
"daemon" user does not have access to write to the /usr/sbin directory and
cannot create the host fingerprint file that is required for NLA and TLA
connections.

The easiest thing to do is just create a Linux user account for guacd to
run under, allowing Linux to create a home directory (useradd with "-m"
flag, for example), and then make sure guacd is being started under that
account. Then re-try the connection.

-Nick

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

CentOS 7
freerdp-libs 2.1.1-5.el7_9
openssl-devel 1.0.2k-26.el7_9

-Nick

On Wed, Jan 24, 2024 at 3:35 PM Weston Thayer 
wrote:

> I am repro'ing with the Docker image (slightly customized, otherwise I
> would've shared repro steps, working on that), so that helps.
>
> I did some research. alpine:3.17.6 through alpine:3.18.5 appear to all
> have the same version of openssl1.1-compat-dev
> <https://github.com/apache/guacamole-server/blob/a575af63ef5b4c8b1804999f211ebeb270992b5a/Dockerfile#L45>
> (1.1.1u-r1). I'm checking with `apk add --no-cache --simulate
> openssl1.1-compat-dev`, let me know if that's not to be trusted for some
> reason. No surprise that it repros when the image is built with something
> older, like alpine:3.18.2.
>
> Nick, even though you can't reproduce it, could you share your openssl
> version?
>
> On Wed, Jan 24, 2024 at 11:00 AM Barnhart, Steven 
> wrote:
>
>> Would be worth using the docker versions and seeing if is present in them
>> as that is then easy to point to dependencies not being updated.
>>
>> –Steve
>> --
>> *From:* Weston Thayer 
>> *Sent:* Wednesday, January 24, 2024 1:58:14 PM
>> *To:* user@guacamole.apache.org 
>> *Subject:* Re: Major bug message log in guacd 1.5.4
>>
>> Running with Nick's theory that it could be something to do with OpenSSL,
>> could folks who have reproduced it by upgrading ONLY guacd from 1. 5. 3 to
>> 1. 5. 4 share their OpenSSL versions? Since I can easily reproduce this, I
>> can employ some
>> Running with Nick's theory that it could be something to do with OpenSSL,
>> could folks who have reproduced it by upgrading ONLY guacd from 1.5.3 to
>> 1.5.4 share their OpenSSL versions? Since I can easily reproduce this, I
>> can employ some trial & error testing to try and identify the key variable.
>>
>> On Wed, Jan 24, 2024 at 9:15 AM Vieri 
>> wrote:
>>
>>
>>
>> On Wednesday, January 24, 2024 at 04:01:52 PM GMT+1, Nick Couchman <
>> vn...@apache.org> wrote:
>>
>> > When I say "underlying system" - I mean that I'm not running Docker
>> containers, I'm installing natively on CentOS7,
>> > and when I upgraded from 1.5.3 to 1.5.4, I did not update any of the
>> other dependencies (FreeRDP, SSH, kernel, openSSL, etc.).
>> > This indicates that the issue isn't guacd itself, but some issue
>> between guacd + FreeRDP and possibly some
>> > underlying library (OpenSSL) that is causing the leakage.
>>
>> Same here.
>> I am NOT using docker containers.
>> As I said, absolutely nothing has changed except for guacd 1.5.4 ->
>> 1.5.3. No other dependency has been updated or changed. OpenSSL is exactly
>> the same. All other libs are exactly the same. FreeRDP is left untouched.
>>
>> So it could be what you mentioned earlier: guacd 1.5.4 might be using
>> something in FreeRDP that 1.5.3 wasn't.
>> Assuming it's FreeRDP that's leaking.
>>
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
>> For additional commands, e-mail: user-h...@guacamole.apache.org
>>
>>

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

>
>
> I myself reported having problems with SSH and Telnet. I think at least
> one other person did too. However, in my case the number of RDP connections
> are by fr the most common. So, I got SSH / Telnet issues only *after*
> hitting the so-called freerdp major bug message. So it might be because of
> how guacd uses freerdp and hits that bug that subsequent SSH/Telnet
> connections also fail. No idea.
>

The FreeRDP message is probably due to some resource leakage, perhaps in
FreeRDP, perhaps in some specific aspect of FreeRDP that 1.5.4 started
referencing, that causes the resource to leak to the point where it can no
longer create connections, particularly TLS/SSL connections.


>
> So if my host running guacd 1.5.3 has no issues at all but does with guacd
> 1.5.4 (without absolutely any other software change), what do you mean by
> "underlying system"? Any other library dependency can be the culprit?
>
>
When I say "underlying system" - I mean that I'm not running Docker
containers, I'm installing natively on CentOS7, and when I upgraded from
1.5.3 to 1.5.4, I did not update any of the other dependencies (FreeRDP,
SSH, kernel, openSSL, etc.). This indicates that the issue isn't guacd
itself, but some issue between guacd + FreeRDP and possibly some underlying
library (OpenSSL) that is causing the leakage.

-Nick

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

On Tue, Jan 23, 2024 at 6:53 AM Vieri  wrote:

> Hi,
>
> Even if the error message in the log refers to freerdp code there is
> something in guacd-1.5.4 that makes the service "in need" of a restart (not
> just RDP connections are affected -- VNC, ssh, etc. are all concerned).
>
> I have observed for a long time now that on a host where NO software has
> been changed except for guacd being downgraded from 1.5.4 to 1.5.3 (even
> with guacamole-client still at 1.5.4), everything is working flawlessly.
>
> I'm not saying freerdp isn't somehow responsible, but it is likely that
> guacd 1.5.3 is handling "something" better than 1.5.4.
>

On the other hand, I have 1.5.4 on a system that was running 1.5.3 before
and the *only* change I made was to upgrade to 1.5.4, and I have not
encountered the issue.

So, it's got to be some nuance of interaction between guacd and the
underlying system. I don't know that it's limited to FreeRDP, either - I
think someone else responded at some point saying that they were seeing it
with SSH, as well.

-Nick

Re: Issue logging in locally as guacadmin on new install

[Nick Couchman]

On Mon, Jan 22, 2024 at 1:26 PM Devine, Harry (FAA)
 wrote:

> So I’m still fighting this.  I found an article where the user said they
> put the connector in the guacamole lib folder and all was good.  So I put
> the mysql-connector-j-8.2.0.jar file under
> /usr/share/tomcat/.guacamole/lib, changed ownership to tomcat:tomcat, and
> restarted Tomcat.  I don’t get the JDBC driver error any more, but I do get
> the following in /var/log/messages, and the web interface shows an error:
>
>
>
> Jan 22 13:21:46 guac-test server[416800]: 13:21:46.637 [main] INFO
> o.a.g.extension.ExtensionModule - Extension "MySQL Authentication" (mysql)
> loaded.
>
> Jan 22 13:21:46 guac-test server[416800]: 13:21:46.770 [main] WARN
> o.a.g.e.LanguageResourceService - Overlay language resource "de" does not
> exist.
>
> Jan 22 13:21:46 guac-test server[416800]: 13:21:46.772 [main] INFO
> o.a.g.extension.ExtensionModule - Extension "LDAP Authentication" (ldap)
> loaded.
>
> Jan 22 13:21:46 guac-test server[416800]: 13:21:46.792 [main] INFO
> o.a.g.extension.ExtensionModule - Extension "Guac-Test" (tsose) loaded.
>
> Jan 22 13:21:46 guac-test server[416800]: 13:21:46.863 [main] INFO
> o.a.g.t.w.WebSocketTunnelModule - Loading JSR-356 WebSocket support...
>
> Jan 22 13:21:47 guac-test server[416800]: 22-Jan-2024 13:21:47.534 INFO
> [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [/var/lib/tomcat/webapps/guacamole.war] has finished in
> [3,327] ms
>
> Jan 22 13:21:47 guac-test server[416800]: 22-Jan-2024 13:21:47.536 INFO
> [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
>
> Jan 22 13:21:47 guac-test server[416800]: 22-Jan-2024 13:21:47.553 INFO
> [main] org.apache.catalina.startup.Catalina.start Server startup in [3384]
> milliseconds
>
> Jan 22 13:22:00 guac-test server[416800]: Loading class
> `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is
> `com.mysql.cj.jdbc.Driver'. The driver is automatically registered via the
> SPI and manual loading of the driver class is generally unnecessary.
>
> Jan 22 13:22:00 guac-test server[416800]: 13:22:00.308
> [http-nio-8080-exec-7] WARN  o.a.g.e.AuthenticationProviderFacade - The
> "mysql" 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: mysql" within your
> guacamole.properties.
>
> Jan 22 13:22:00 guac-test server[416800]: 13:22:00.312
> [http-nio-8080-exec-7] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
>
> Jan 22 13:22:00 guac-test server[416800]: ### Error querying database.
> Cause: java.sql.SQLSyntaxErrorException: Table 'guacamole.guacamole_user'
> doesn't exist
>

If it's a brand-new install, have you imported the SQL schema into the
database? The indication is that it can connect, but the table(s) is/are
missing...

-Nick

>

Re: Options for hardware acceleration/vaapi for guacd

[Nick Couchman]

On Thu, Jan 18, 2024 at 2:20 PM Barnhart, Steven 
wrote:

> Hi there,
>
>
>
> We have some use cases where (unfortunatelty) users are reviewing videos
> from a remote machine and using Guacamole to connect. The viewing of videos
> is where the problem lies. A 720p sample video viewed through Guacamole is
> very laggy and the audio pops in/out. It is not reliable. During video
> playback, all other mouse movements or commands are delayed on the server
> as well. I see on the server side when viewing a video that a guacd process
> spikes to 80-100%. We are also using Docker.
>
>
>
>1. I assume Guacamole encodes the rdp and sends it as video in some
>way? Is there a way to use hardware accelertation such as intel
>vaapi/quicksync for this process and could it maybe help?
>
>
Not as video, as images. The Guacamole software/protocol does some
calculations to try to choose the best image format possible, but
video/visual data is transferred as images.

I do not know of any hardware acceleration that is currently supported. The
one thing that might help is support for GFX over RDP, which is in the
master branch and should be released in the 1.6.0 release, whenever that
happens (later this year).


>
>1.
>2. Is it believed Docker vs native would have any real difference in
>playing and streaming a video from an RDP session?
>
>
>

I doubt this would make a difference.

-Nick

>

Re: Token Management

[Nick Couchman]

On Thu, Jan 18, 2024 at 7:08 AM anoop yadav  wrote:

> Thanks for pointing that out, I will update the logic to update the user
> token when the user tries to connect to the Ubuntu instance rather than
> during account creation (I can also add the check if the last token was
> generated within 60 min so don't generate a new token etc), but I have a
> question if the user already has a previous connection active on a
> different instance with previous token and he connects to a new instance on
> a new tab and get the new token will his previous connection get
> disconnected automatically? (If he refreshes the page he will get the new
> token from the web app, but will his previous connection get force
> disconnected).
>
>
I'm not certain, but I do not believe that there is anything that prevents
a user from getting/using two tokens from the same system, so, no, this
should not result in a disconnect.

-Nick

>

Re: Re: 1.5.4 - The connection has been closed because the server is taking too long to respond.

[Nick Couchman]

On Thu, Jan 18, 2024 at 1:24 AM michael böhm  wrote:

> Hi Jimmy,
>
> it cannot be a general configuration issue at the ssh / sftp server as it
> works about 60 times in guacd daemon's lifetime. After restarting guacd
> container it works for another about 60 times until it stops working again.
>
>

Ah, this sounds like the issue that others were running into with RDP
connections - exhausting some limit, number of threads, something like that.


> Other users have the problem with 1.5.4 as well but I'm not aware of a
> solution yet.
>
> Is there anything else I can provide to help troubleshoot the problem?
>

You already gathered up quite a lot of information about the environment. I
think others who were running in Docker were seeing this same issue - I've
yet to encounter it on my native install of 1.5.4, so it seems like
something related to either the Docker image or the host platform.

Unfortunately I don't really know what to tell you to look for at the
moment - anything that indicates, at a system or container level, that
limits are being imposed on guacd that would cause it to not be able to
allocate the connections...

-Nick

Re: Guacamole server disconnect after 30 sec

[Nick Couchman]

On Thu, Jan 18, 2024 at 12:35 AM anoop yadav  wrote:

> Hi Daniel,
>
> You are right I changed the timeout for the load balancer to 2147483645
> (INT MAX - by default it was 30 sec), and now the issue is fixed, but I
> still don't understand why this timeout on the load balancer was causing
> the issue.
>
>
It will depend on what the load balancer sees as "activity" and how traffic
is routed. For example, if the load balancer doesn't see ongoing Websocket
communication as activity, and is expecting HTTP(S) commands from the
client-side, that may result in it timing out the connection. Or, if the
connection is timing out after 30 seconds because the user is not doing
anything (typing/moving mouse on client side), and the only traffic is
coming from the server-side, then it may want to close the connection. Or
it could be that the load balancer is seeing the repeated "NOP" commands
that go back-and-forth between client and guacd and deciding that those
represent a "keepalive" attempt by one end or the other, and is configured
to ignore attempts to keep connections alive.

You might dig into the load balancer configuration and see if there are
other parameters that can be adjusted to tweak how it identifies idle
connections, or just eliminate that functionality entirely for the
Guacamole traffic.

-Nick

Re: Token Management

[Nick Couchman]

On Thu, Jan 18, 2024 at 1:03 AM anoop yadav  wrote:

> I am trying to build a Web app where users can create multiple Ubuntu
> instances and use them through my web app. The domain for my web app is
> example-app.com which is written in reactjs. I have hosted guacamole
> clients on separate subdomains lab.example-app.com.
>
> In the reactjs app, I am using the Iframe (Not sure if there is any other
> way) to show lab.example-app.com (guacamole client app), since I don't
> want the user to do another login on the guacamole app. I am planning to
> use a token. My current logic is as follows:
>
> 1. When the user creates an account (the backend is in Django-python) I
> make a rest API request to create an account, get a token from guacamole
> and save it to the web app database.
> 2. When the user creates an Ubuntu instance, using the rest API I create a
> connection and associate the user with it. I save a URL like
> lab.example-app.com/guacamole/#/client/?token=
>
>
> Everything works fine, the user can access multiple connections but since
> the token has a lifetime, and after that time the URL is not working.
>
>
To be clear, the token does not have a lifetime, it has an *idle lifetime*
- that is, it times out after a certain period of inactivity. As long as
the Guacamole instance is being used - for an active connection, for
example - the token will remain valid.


>
> How do I manage the token so that it doesn't expire?
>

You can set the api-session-timeout property in guacamole.properties to
adjust the *idle lifetime* of the token - see
https://guacamole.apache.org/doc/gug/configuring-guacamole.html#guacamole-properties
.

That said, I don't think you really want it to never expire - at least,
from a security perspective, I would not recommend that, even if you're
doing some other cleanup of the tokens from your web application. You may
want to extend it such that it more closely fits in with your use case, but
setting it to either never expire (which isn't really possible) or even a
very long idle time just adds security risk to the application.

-Nick

Re: Guacamole 1.5.3 and recordings

[Nick Couchman]

On Thu, Jan 18, 2024 at 4:38 AM Morten Fahle 
wrote:

> Hi
> I have set up Guacamole 1.5.3 with recording and it’s working fine. But
> due to GDPR I have to delete recordings after a set time.
> Is there a way to set up Guacamole so it will delete the recording but not
> the session history automatically after a set number of days?
>
>
There's no way directly to do this in Guacamole, but it should be pretty
simple to manage on the system where guacd is running with a script and a
cron job. For example, to clean up after 7 days, you'd just need to run
something like:

find /var/lib/guacamole/recordings -type f -mtime +7 -exec rm -fv {} \;


> Also, sometimes we will need to store recordings for longer and would like
> to download the recording. Is there an easy way to connect a session
> history entry to the recording in /var/lib/guacamole/recordings?
>
>
Yes - there is an extension that connects the Guacamole Client interface
with the recordings:

https://guacamole.apache.org/doc/gug/recording-playback.html

-Nick

Re: Upgrade from 1.2 to 1.4 or 1.5 Scrolling content is overwriting itself

[Nick Couchman]

On Wed, Jan 17, 2024 at 5:54 PM Allen Chen 
wrote:

> Hi there,
>
> I try to figure it out between 1.3 and 1.4 by cloning the guacamole
> client, but the command failed:
>
> # git clone git://github.com/apache/guacamole-client.git
>
> Initialized empty Git repository in /squid/z/guacamole-client/.git/
> github.com[0: 140.82.113.3]: errno=Connection timed out
> fatal: unable to connect a socket (Connection timed out)
>
> Any idea?
>

I don't think git:// is a valid URL prefix - I think you can either use SSH
URLs (g...@github.com/apache/guacamole-client.git) or HTTPS URLs (
https://github.com/apache/guacamole-client).

-Nick

Re: Issue logging in locally as guacadmin on new install

[Nick Couchman]

On Wed, Jan 17, 2024 at 10:23 AM Vincent Sherwood
 wrote:

> We have  mysql-connector-j-8.0.32.jar  on our system and it works great
> with MariaDB 10.5.22
>
> Note: we didn't install from an RPM but rather just downloaded and copied
> the jar file directly into /etc/guacamole/lib/ - perhaps guacamole is not
> finding the jar file where the RPM installs it.
>

Yeah, depending on where the RPM drops the library, and how Tomcat has been
installed, the MySQL JDBC driver may not be found by default. Linking it in
/etc/guacamole/lib is definitely the best way to make sure Guacamole can
find it.

-Nick

>

Re: downloading file cause remote system disconnection

[Nick Couchman]

On Fri, Jan 12, 2024 at 12:09 AM Eby Mani  wrote:

>
>  It doesn't say webapp failing back to HTTP, but looks like Guacamole is 
> using HTTP tunnel instead of WebSocket, not sure if this is default.
>
>
The log below indicates that the connections are falling back to HTTP.


> Note " Using HTTP tunnel (not WebSocket). Performance may be sub-optimal."
> occur when initiating file transfer from remote system.
>
>
This does not happen at the time you transfer a file, this happens at the
time you make the connection. If you look at the log file you posted you'll
see that the message about the user joining the connection and the use of
HTTP vs. websocket occurs at the same second (09:32:17). Your connections
are using HTTP, not Websocket.


> Another question is, does ssh host verification play any role in
> transferring files ?.
>
>
No.


> I have restarted nginx, guacad and tomcat9, still no joy.
>
> nginx configuration support websocket.
>
>
Something else might be blocking Websocket supt on the connections - based
on the logs you've shared, it's definitely falling back to HTTP.

-Nick

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

On Thu, Jan 11, 2024 at 5:42 PM Weston Thayer 
wrote:

> Overall. Our test is just 1 user re-connecting to the same VM over RDP
> over and over.
>

Thanks for clarifying. FWIW, I'm running Guacamole 1.5.4 (native
build/install), on CentOS 7 (FreeRDP 2.2.0), and I've gone way past the
58th successive connection without hitting this issue.

-Nick

>

Re: I have an idea, how do I submit feature request?

[Nick Couchman]

On Thu, Jan 11, 2024 at 5:39 PM Aaron Meyer  wrote:

> I have a feature idea, how should I go about submitting a feature request?
>

You'll need to request an account on the ASF Jira site, and then you can
submit the Feature Request ticket:

https://issues.apache.org/jira/browse/GUACAMOLE


>
> Unfortunately I am in no way a Java developer so I'm not able to do this
> on my own, but I'm hoping the idea has enough value that it could be added
> by the team at some point.
>

That's okay - we still like for people to discuss things that would make
Guacamole better!


>
> Here's a quick rundown of the idea, does this sound like it would be
> valuable to others, or is this already possible?
>
> The idea is to add options to connections to have guacd or guacamole call
> a script on the host when a connection starts and ends. If it is not
> possible to call a shell script, maybe a webhook or some sort of event
> messaging to FaaS etc... I also imagine a boolean option to make the call
> blocking to the connection proceeding or not and if set to block a field to
> override a default timeout before failing. Some reasonable default would be
> set that could be overridden via guacamole.properties.
>
>
You're definitely not the first one to have this idea, and it's something
that should be pretty easily doable. Calling a script would be pretty
straight-forward - calling a webhook or API may be a bit more challenging
just because of the number of options you'd have to make available.


> Parameters would need to be sent to the script/event with: timestamp,
> connection title, hostname, port, username, ?password?,...
>
> What I can see this being used for:
> 1. To substantiate VDI containers or link-cloned VMs on demand and destroy
> after connection closes.
>

Yeah - and actually making a full-blown VDI platform from Guacamole is one
of those things that has been way down on my to-do list and that I
periodically get hopes of spending some time on. Hasn't happened, yet.


> 2. If using the Keeper Vault to rotate connection credentials and update
> the vault / remote system after each connection closes.
>

Rather than a script or web-hook, this actually might be better off being
added to the KSM vault module.


> 3. Integrate with any audit / notification backends to log when secured
> systems are accessed.
>

Makes sense.


> 4. Used with wake on LAN to power off resources when they're disconnected
> and WOL powered on when called.
>
>
Note that Wake-on-LAN is already supported within Guacamole, so there's no
need to call a specific script for this. It's also getting some additional
features/updates, such as better detection of hosts being already up, etc.

https://github.com/apache/guacamole-server/pull/470

-Nick

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

On Thu, Jan 11, 2024 at 5:13 PM Weston Thayer 
wrote:

> We can reliability reproduce it with the Docker image at
> https://github.com/apache/guacamole-server/commit/94a755c90a7511969884774dbca2ef2ab5958ba6
> on the 58th connection in the guacd container's lifetime. A bit annoying to
> reproduce manually, but you could write a little test script.
>
>
The 58th concurrent connection, or the 58th overall connection?

-Nick

Re: Guacamole 1.5.4

[Nick Couchman]

On Mon, Jan 8, 2024 at 5:21 AM Guillaume CHOLLIER <
guillaume.chollier@poweend.com> wrote:

> Hello all,
>
> I'd install Guacamole 1.5.4 but where i connect to my database = doesn't
> work !
> with a user-mapping is OK, but not with a DB , why ??
>
> my configuration
>
> Debian 12
> Tomcat 9.0.84
>
> *Guacamole 1.5.4*
> /etc/guacamole/lib >  mysql-connector-j-8.2.0.jar
> /etc/guacamole/extensions > guacamole-auth-jdbc-mysql-1.5.4.jar
>
> root@vps-123456:/opt/tomcat9/webapps# ls -l
> total 13440
> drwxr-x---  3 tomcat tomcat 4096 Jan  4 16:07 ROOT
> drwxr-x--- 16 tomcat tomcat 4096 Jan  4 16:07 docs
> drwxr-x---  7 tomcat tomcat 4096 Jan  4 16:07 examples
> drwxr-x--- 10 tomcat tomcat 4096 Jan  5 10:26 guacamole
> -rw-r--r--  1 tomcat tomcat 13734589 Dec  4 21:33 guacamole.war
> drwxr-x---  6 tomcat tomcat 4096 Jan  4 16:07 host-manager
> drwxr-x---  6 tomcat tomcat 4096 Jan  4 16:07 manager
>
> content of */etc/guacamole/guacamole.properties*
> # MySQL
> mysql-hostname: 127.0.0.1
> mysql-port: 3306
> mysql-database: guacadb
> mysql-username: 
> mysql-password: 
> mysql-ssl-mode: disabled
> #user-mapping:  /etc/guacamole/user-mapping.xml
> #auth-provider:
>  net.sourceforge.guacamole.net.basic.BasicFileAuthenticationProvider
>
> i ran all sql scripts, my user guacadmin is created
> all service are restarted : tomcat9 guacd mariadb
>
> How i can test/check otherwise ?
>

Check your Tomcat log files - in your case, likely
/opt/tomcat9/logs/catalina.out - and see what messages are being displayed.
This should tell you why it cannot connect to the MySQL DB.

-Nick

Re: Major bug message log in guacd 1.5.4

[Nick Couchman]

On Mon, Jan 8, 2024 at 6:07 AM Joonas Tuomisto  wrote:

> Hi,
>
> I also ran into this exact issue it seems, but we're not using the
> Guacamole Docker images, instead we're using custom built RPM packages
> on OpenSUSE Leap 15.5 as a native systemd service.
>
> To me this does indeed look like some kind of resource leak in guacd.
>
> Initially everything works, but eventually guacd stops being able to
> initiate new connections, and it's not limited to just one protocol,
> at least both RDP and SSH are impacted.
>
> I'm not entirely sure how forking processes interact with system
> limits and how to debug this to find what resource exactly is being
> leaked.
>
> I attached to guacd with strace after encountering this state and
> initiated a new RDP/SSH connection and it does appear to be failing
> after a connect() but I didn't notice anything weird.
>
> connect() goes -1 EINPROGRESS and poll, recvfrom() goes -1 EAGAIN.
>
> There's indeed a whole bunch of eventfd2() when trying an RDP connection.
>
> guacd logs (for RDP):
> > RDP server closed/refused connection: Security negotiation failed (wrong
> security type?)
>
> guacd logs (for SSH):
> > GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_key_create': Resource temporarily unavailable. Aborting.
>

Interesting. If you're able to track down how this is leaking, that'd be
really helpful. I'm running 1.5.4 on CentOS 7, and not seeing this at all.

-Nick

Re: Missing optional configuration options from docker

[Nick Couchman]

On Sat, Jan 6, 2024 at 3:23 PM Marc Schubert 
wrote:

> Hello,
>
> I can run guacamole in docker, unfortunately I can't set some properties
> via environment variables, because the start.sh script has no actions
> for it.
>
> I would like to set enable-environment-properties: true
> (
> https://guacamole.apache.org/doc/gug/configuring-guacamole.html#guacamole-properties)
>
> and an openid-scope with groups
> (https://guacamole.apache.org/doc/gug/openid-auth.html) according to the
> documentation both included in version 1.5.4.
>
> But my start.sh only contains the following section in the docker
> container of version 1.5.4.
>
> ```
>   # Update config file
>  set_property "openid-authorization-endpoint"
> "$OPENID_AUTHORIZATION_ENDPOINT"
>  set_property "openid-jwks-endpoint" "$OPENID_JWKS_ENDPOINT"
>  set_property "openid-issuer" "$OPENID_ISSUER"
>  set_property "openid-client-id" "$OPENID_CLIENT_ID"
>  set_property "openid-redirect-uri" "$OPENID_REDIRECT_URI"
>  set_optional_property "openid-username-claim-type"
> "$OPENID_USERNAME_CLAIM_TYPE"
>  set_optional_property "openid-groups-claim-type"
> "$OPENID_GROUPS_CLAIM_TYPE"
>  set_optional_property "openid-max-token-validity"
> "$OPENID_MAX_TOKEN_VALIDITY"
> ```
> a `set_optional_property "openid-scope" "$OPENID_SCOPE"` is not included
> there. The same applies to `enable-environment-properties: true`.
>
> The required code parts have been added to the master branch in february
> 2023 (https://github.com/apache/guacamole-client/pull/794
> GUACAMOLE-1733: Add missing optional configuration options from docke...
> ). Is there a forecast when this will be added to a release? Or a
> workaround to get it running in Docker
>
>
That Jira issue is slated for version 1.6.0, which we are working toward -
I think we'll have a 1.5.5 bug release, here, very soon, and hopefully
we'll be able to focus on finishing up 1.6.0 after that. There are about 30
open issues for 1.6.0, many of which I think are just documentation or
finishing up pull requests, or pulling them out of the release scope in
order to get 1.6.0 out.

As far as work-arounds, you can build the Docker container from the Git
repo and run it that way, and that should get you the newer options. Or you
can check out the current release from Git (tag: 1.5.4) and then back-port
the patch from 1733 and build that way if you want to make sure you don't
get all of the changes from the master branch.

-Nick