Re: Share drive suddenly disappears and it is recovered till RDP is reinitiated

[Nick Couchman]

On Sun, May 19, 2024 at 3:50 PM Gabriel Huerta Araujo
 wrote:

> Any comments?
>
>
>
>
>
> *De:* Gabriel Huerta Araujo
> *Enviado el:* martes, 7 de mayo de 2024 12:57 p. m.
> *Para:* user@guacamole.apache.org
> *Asunto:* Share drive suddenly disappears and it is recovered till RDP is
> reinitiated
>
>
>
> Is there a case where it has been reported what I mention next: There is a
> connection which is configured with a share drive by example (/tmp
> directory). When the user takes this connection they can see it as a disk
> unit in Windows where they can deposit files and interchange with their
> physical computer. But suddenly this disk unit is lost or dissapear and it
> is recovered till the RDP is reinitiated. This happens with  Guacamole v1.4
> and OS Debian 11. Any advice which we could follow in order to avoid the
> weird situation?
>
>
>

I use the Shared Drive feature routinely on my Guacamole install, and I do
not see this behavior.

Maybe look at your logs on both Windows and guacd and see if there's any
indication why the shared drive is being disconnected?

Also, this may be a simple point, and may seem obvious, but I'll make it,
anyway - the Shared Drive will only be connected so long as the RDP
connection from Guacamole is connected - if the Guacamole connection is
dropped or list, the Shared Drive will also get disconnected, because it is
tied to the RDP connection itself. However, while the RDP session is active
from Guacamole, the shared drive should consistently work.

-Nick

>

Re: RDP option in guacamole

[Nick Couchman]

On Fri, May 17, 2024 at 8:54 AM Nick Couchman  wrote:

> On Fri, May 17, 2024 at 8:51 AM Karim Hamrouni 
> wrote:
>
>> Hello team,
>>
>> I want to use the "*Alternate full address:s:server name*" option with
>> guacamole. Unfortunately, this doesn't work. only the "*full
>> address:s:server-name*" field is taken into account.
>> If I'm not mistaken, this option has worked in the past. Could you help
>> me? or is there another way to achieve this?
>>
>>
> I'm lost - these options do not look familiar to me in the context of
> Guacamole or even RDP. Could you please provide more detail on where these
> fields are and what you're talking about?
>
>
After some quick Google digging, I see that those are options in the RDP
file when you use the native client. Guacamole has never supported the
"Alternative full address" option (at least, not in recent history);
however, it does support specifying a connection gateway if your goal is to
be able to use that to connect through a gateway.

Perhaps you can share why you think you need the "Alternate full address"
option?

-Nick

>

Re: RDP option in guacamole

[Nick Couchman]

On Fri, May 17, 2024 at 8:51 AM Karim Hamrouni 
wrote:

> Hello team,
>
> I want to use the "*Alternate full address:s:server name*" option with
> guacamole. Unfortunately, this doesn't work. only the "*full
> address:s:server-name*" field is taken into account.
> If I'm not mistaken, this option has worked in the past. Could you help
> me? or is there another way to achieve this?
>
>
I'm lost - these options do not look familiar to me in the context of
Guacamole or even RDP. Could you please provide more detail on where these
fields are and what you're talking about?

-Nick

Re: Guacamole - Ubuntu Connection

[Nick Couchman]

On Tue, May 14, 2024 at 11:13 AM Viji Shankar 
wrote:

> Hi Team,
>
> We are using Linux (Ubuntu 22.04). We have rebooted Ubuntu after an update
> and also restarted the Guacamole Pod. We are using Guacamole 1.5.3.
> services are also running. We have checked guacamole container logs. We are
> getting this following error,
>
>
>
>
>
>
>
>
> *Exception in thread "Thread-886" java.lang.IllegalStateException: Message
> will not be sent because the WebSocket session has been closed at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:449)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:307)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:249)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:36)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.sendInstruction(GuacamoleWebSocketTunnelEndpoint.java:152)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.access$200(GuacamoleWebSocketTunnelEndpoint.java:53)*
>
>
The first thing to check, if you're proxying Guacamole behind Nginx or
Apache httpd, or any other reverse proxy, is that you've configured the
reverse proxy correctly. The parameters required are in the manual:

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

In particular, for Nginx, make sure buffering is disabled.

Beyond that, you'll need to dig into log files and do some additional
network troubleshooting to figure out why the WebSocket session is being
closed prematurely. If there's some web application firewall or SSL
inspection going on in the path between the browser and the Tomcat server,
it could be interfering with the WebSocket connection. You'll need to
figure out why.

-Nick

>

Re: Using LDAP to authenticate to balancing group

[Nick Couchman]

On Wed, May 15, 2024 at 6:20 AM David Lomas 
wrote:

> Hi,
>
> I've set up a balancing group in Guacamole which contains 3 test
> connections to individual machines. If I create test users in the web
> interface and assign them to the group (but _not_ to individual
> connections), I can see the balancing working—when each user logs in, they
> are assigned to an available connection.
>
>
If you're setting up a balancing group, then this means that you're using
the JDBC (DB) extension for storing connections, correct?


> But how can I 'target' a user who is authenticated via LDAP to this
> connection group? The documentation shows how to return a connection to a
> specific machine as part of the guacConfigParameter object (hostname: xyz,
> etc.) but I couldn't find anything about returning a connection group
> there. Is this possible? Is there some documentation I've missed?
>
>
There are two ways to do this:
* You can create a user account in the database that has the same user name
(generally case-sensitive) as the LDAP user, and assign permission for a
connection or connection group to the user. Note that this can also be
largely automated by enabling the auto account-creation capability. See:
https://guacamole.apache.org/doc/gug/ldap-auth.html#associating-ldap-with-a-database
,
https://guacamole.apache.org/doc/gug/jdbc-auth.html#auto-creating-database-users
* Instead of doing this based on username, you can do this with user groups
- if you enable group searching in LDAP, you can assign the permissions to
the groups, and, as long as the groups in the database have the same name
as the LDAP groups, Guacamole will associate those permissions.

-Nick

Re: Custom Front-end

[Nick Couchman]

On Thu, May 16, 2024 at 9:00 AM Tom Eaton  wrote:

> There is a comprehensive guide in the docs:
> https://guacamole.apache.org/doc/gug/writing-you-own-guacamole-app.html
>
> On Thu, 16 May 2024 at 13:56, Prakhar Jalan 
> wrote:
>
>> Hello,
>>
>> I am looking to create a custom front-end. Would really appreciate if
>> someone could guide me how to go about it?
>>
>>
I'll add to Tom's response that this greatly depends on what your end goal
is - if you just want to use the common bits (the Guacamole protocol) and
are looking to write everything else (authorization/access/accounting,
connection management, etc.) from scratch, then the guide that Tom linked
is exactly what you'll need. If you're talking about just customizing the
look and feel of the existing front-end, this is done using the extension
framework. And lots of options in between those two.

-Nick

>

Re: Specific permissions to Active Sessions / Kill Sessions

[Nick Couchman]

On Wed, May 15, 2024 at 2:35 PM Rasmus Hvitfeldt
 wrote:

> Hi all,
>
>
>
> Is there a way to give specific permissions to a user group so they can
> kill any active session? We have a privileged user group that would require
> that ability. But of course we don’t want to give them Administer system
> rights.
>
>
>

Currently the only way to assign a user permissions to view other user's
active sessions and to kill those sessions is to make them a system
administrator. Guacamole does actually support some finer-grain permissions
control, such as assigning administrative access for a specific connection
to a user or group, but there's no way to accomplish this in the web
interface at the moment.

-Nick

>

Re: multiple guacd

[Nick Couchman]

On Tue, May 14, 2024 at 7:52 AM Stefan Müller
 wrote:

> Hi all
>
>
>
> is there a way to specify the guacd host and port to be used in the
> connection settings?
>
> background is to use multiple guacd instances with only one webbackend &
> webfrontend.
>
> e.g. something like this?
>
>
>
> Connection1:
>
> protocol vnc
>
> host 10.0.0.10
>
> port 5900
>
> password xyz
>
> guacd-host localhost
>
> guacd-port 4822
>
>
>
> Connection2:
>
> protocol vnc
>
> host 10.0.1.10
>
> port 5900
>
> password xyz
>
> guacd-host 10.0.0.1
>
> guacd-port 4822
>
>
>

Yes, this is definitely possible, though at the moment I believe it only
works if you're using the JDBC authentication extension - there are a
couple of pull requests out there to add support for this to the LDAP and
JSON extensions, but right now you have to be using the JDBC extension in
order to do this. When you configure the connections in that extension,
there are three connection attributes in the "Guacamole Proxy Parameters"
section that allow you to specify alternate hostname, port, and encryption
settings for guacd.

-Nick

>

Re: GPU rendering

[Nick Couchman]

On Mon, May 13, 2024 at 7:56 PM Johnson, Nachay [USA]
 wrote:

> Recently deployed Guacamole, but was wondering if there’s anything
> additional required to get Nvidia GPU working when connecting from guac to
> my windows 2012 Server. Are there any additional steps required?
>
>
>

This depends a bit on which side the GPU rendering is on. If you're talking
about using a GPU with guacd on the server running Guacamole, this is not
currently supported - there is no direct support in guacd to take advantage
of GPUs attached to the system.

On the Windows Server side, you're probably looking for the GFX Pipeline
(also known as RemoteFX) extension to RDP, which is in the process of being
implemented. The code has been merged, but not released - it'll likely show
up in the 1.6.0 release, which we're working toward.

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

-Nick

>

Re: Noauth and intermediate password screen

[Nick Couchman]

On Mon, May 13, 2024 at 2:41 PM Hugh Barnard
 wrote:

> Hi folks
>
> I now (mis?)understand that noauth isn't in the latest releases 1.5.5 for
> example? This may explain why I couldn't get it working...
>
>
The noauth "authentication" extension was deprecated and removed quite a
while ago. I can't remember exactly when, but it's been years.


> I'd really like to remove the intermediate (brown background) password
> screen though. It feels as though (I'm using user-mapping.xml) the first
> login screen with user and password is 'enough'.
>
>
The "first" login screen is the Guacamole web application login. The second
(brown - black, maybe) screen is likely the authentication for the remote
connection (VNC, RDP, SSH, etc.). If you want to "bypass" this screen, then
you need to provide the required credentials for the remote connection
within the connection configuration. If you're using user-mapping.xml, this
would involve adding the XML entries for the username and password
parameters (unless it's VNC and only requires a password).

You can find some examples of this in the user manual:

https://guacamole.apache.org/doc/gug/configuring-guacamole.html#user-mapping-xml

-Nick

>

Re: Guacamole issue 1.5.4

[Nick Couchman]

On Sun, May 12, 2024 at 4:52 AM Niranjan A 
wrote:

> Hi Team,
>
> I am getting the below error on the guacamole server and please find the
> current configuration details
>
> Ubuntu 22
> AMD Processor
> Guacamole 1.5.4[Manual Installation]
>
>
Have you tried 1.5.5?


>
> *Error:*
>
> May 10 12:01:07  kernel: [180410.400804] guacd[3499490]: segfault at 18 ip
> 7089baa9a64c sp 708989ffaaa0 error 4 in
> libc.so.6[7089baa28000+195000] likely on CPU 1 (core 0, socket 0)
> May 10 12:47:48 kernel: [ 2745.489801] guacd[117195]: segfault at
> 7006fa406a70 ip 700aa97fe317 sp 700a61ffaae0 error 6 in
> libguac-client-ssh.so.0.0.0[700aa97f7000+b000] likely on CPU 0 (core 0,
> socket 0)
>
>
If you can locate the coredump files that are left from the segfault, it
would be nice to have a stack trace (backtrace, bt from gdb) on those core
files to figure out why the segfault is happening.


>
>
>
>  guacd[1550069]: File open refused (-2): "\desktop.ini"
> File open refused (-2): "\FromDelivery66244\desktop.ini"
> File open refused (-2): "\FromDelivery65878\desktop.ini"
> File open refused (-2): "\FromDelivery65701\desktop.ini"
>
>
Two things, here - first, make sure that the Linux account under which
guacd is running has access to the files/folders that you're sharing. Aside
from that, desktop.ini may not exist and these may actually be harmless
messages unrelated to your segfault issue.

-Nick

>

Re: Two guacd instances

[Nick Couchman]

On Sun, May 12, 2024 at 5:02 AM Hugh Barnard
 wrote:

> Hi folks
>
> I'm very new to guacamole,
>
> I've run up and instance with Tomcat and 1.5.5 on a Raspberry Pi. It works
> and I'm not trying to do multiuser vnc:
>
>- tigervncserver on user1 as :3
>- tigervncserver on user2 as :4
>- user-mapping.xml for user1 and user2
>
> This seems OK, but results in two instances of guacd, is this normal? I'm
> trying to do cleanup scripts etc.so at the moment I have sudo killall guacd.
>
>
Yes, this is perfectly normal - the guacd process forks when a new
connection is created, which starts a new process with the original guacd
process as the parent. If you have 2 active connections you should actually
see 3 guacd processes - the listening/original one, plus one for each
connection that is running.


> Also when I'm in the Pi desktop is there a clean way of leaving it? I'm
> trying to develop this for Pi students who haven't got a physical Pi yet,
> that's the context of all this.
>
> From the Guacamole perspective, there's nothing you necessarily need to do
to leave it "cleanly." From the VNC side, keep in mind that you need to
factor in security so that someone cannot come along and connect to the
available VNC port/session and get access to files, applications, etc.,
that someone else started.

-Nick

>

Re: Hebrew/English keyboard layout challenges

[Nick Couchman]

On Tue, May 7, 2024 at 6:05 AM  wrote:

> On 5/6/24 9:06 AM, Nick Couchman wrote:
>
> > On Mon, May 6, 2024 at 10:31 AM mailto:u...@alyn.org>>
> wrote:
>
> > ...
>
> >
>
> > To sum the long story short, two questions:
>
> >
>
> > 1.Is there a way to make the Guacamole client be aware of the
>
> > currently active Windows language, and define different layouts
>
> > correlating to their relevant languages?
>
> >
>
> >
>
> > I'll have to look at the FreeRDP source code, but I don't think
>
> > there's a feedback loop or callback for when the remote side changes
>
> > the keyboard layout - I think the expectation is that the client-side
>
> > keyboard is a fixed (physical) keyboard, so it will not dynamically
>
> > change, and that you'd want that to stay the same for the entire
>
> > remote session. I can't foresee a lot of situations where you'd want
>
> > the client-side keymap to change on-the-fly.
>
> >
>
>
>
> Sadly, this is simply not reported over RDP by the RDP server. I remember
> implementing the Guacamole side of this and wishing that such a mechanism
> existed.
>
>
>
> An RDP client can request a particular layout during the RDP connection
> process, but receives no information from the server if that layout is
> changed later after the RDP session has started.
>
>
>
> => As far as I understand, It doesn’t matter which layout is currently
> being selected on the remote RDP session. What does matter is the layout
> which is currently set on the client side, E.g., if the Guacamole client
> was able to be aware of the currently selected Windows keyboard language
> and pass it on to the server, it could have been fantastic to be able to
> extend the keymap file format to support such as the following:
>
>
>

When you say "currently selected Windows keyboard language," it sounds like
you mean the client-side, not the remote side. I think I assumed in my
original response that you meant the layout selected on the remote side,
but the above statement clarifies that you just mean on the client-side,
where the user is accessing Guacamole. It doesn't sound like it matters
much, though - there does not currently appear to be a way for the browser
to access the currently-selected keyboard layout.


> # Language independent mapping
>
> map -caps -shift 0x29 0x02..0x0D  ~ "`1234567890-="
>
>
>
> # English layout mapping
>
> map +lang:ENG -caps -shift  0x10..0x1B 0x2B ~ "qwertyuiop[]\"
>
> map +lang:ENG -caps -shift  0x1E..0x28  ~ "asdfghjkl;'"
>
> map +lang:ENG -caps -shift  0x2C..0x35  ~ "zxcvbnm,./"
>
>
>
> # Hebrew layout mapping
>
> map +lang:HEB -caps -shift  0x10..0x1B 0x2B ~ "/'קראטוןםפ[]\"
>
> map +lang:HEB -caps -shift  0x1E..0x28  ~ "שדגכעיחלךף,"
>
> map +lang:HEB -caps -shift  0x2C..0x35  ~ "זסבהנמצתץ."
>
>
>
> I tried playing around with the experimental Chromium supported
> navigator.keyboard KeyboardLayoutMap object, which returns key/value pair
> mapping from US standard JS key names to current keyboard layout keys, but
> this mapping does not seem to be sensitive to the currently selected
> (dynamic) keyboard language settings – it rather it always return EN-US
> keyboard layout mapping in our case, so I’m not optimistic this overall
> approach is feasible.
>
>
>
>
>
> > 2.Alternatively, on Windows machine scenarios (client + servers) the
>
> > whole back-and-forth conversion from client JS Key code (which is
>
> > equivalent to scancode) through generic keysym and then back to
>
> > scancode on server side, seems redundant when clients and servers
>
> > share the same keyboard layouts. Is there a way to configure the
>
> > client to avoid it, and hence implement direct mapping from client
>
> > JS Key code to server scancode?
>
> >
>
> >
>
> > Mike can probably comment more thoroughly on this, but my
>
> > understanding is that, no, this is not possible. Even in situations
>
> > where client and server keyboard layouts match, in order to properly
>
> > interpret the keyboard input, particularly for characters that require
>
> > modifiers, the key mapping needs to be done from JS to the Windows
> scancodes.
>
> >
>
>
>
> No, the keycode cannot be used for this (more on this below). There is a
> more recently introduced value that is directly related to the scancode and
> might be usable for cases where it's not poss

Re: Multiple Shared-drives showing in Guacamole

[Nick Couchman]

On Mon, May 6, 2024 at 7:38 AM Viji Shankar 
wrote:

> Hi Team,
>
> The issue occurs when initiating a single connection. We are not utilizing
> the multiple connection feature.
>

Thanks for confirming.


>
> ERROR in guacd container:
>
>
>
>
>
> *guacd[60]: ERROR:   File open refused (-2): "\desktop.ini"guacd[60]:
> ERROR:   File open refused (-2): "\Download\desktop.ini"guacd[60]:
> ERROR:   File open refused (-2): "\desktop.ini"guacd[60]: ERROR:
> File open refused (-2): "\Download\desktop.ini"guacd[60]: ERROR:   File
> open refused (-2): "\Download\desktop.ini"*
>
>
Hmmm...those files may not exist, but, if they do exist, can you make sure
that permissions are set correctly such that guacd (or the container) has
access to those files?


> We are currently utilizing Guacamole version 1.5.3, and we have opted for
> the official stock version without any modifications to its codebase.
> Despite dropping and recreating the database and restarting the Guacamole
> pod, the issue persists.
>
> Is there anything we have to check in the Windows machine as well?
>

I don't think so - I believe that the Shared Folder you're seeing in the
web menu is completely outside of the Windows connection. I don't know why
it would be showing up multiple times, but maybe there's some bug that
causes this when permissions are not correct?

-Nick

Re: Hebrew/English keyboard layout challenges

[Nick Couchman]

On Mon, May 6, 2024 at 10:31 AM  wrote:

> Hi there,
>
>
>
> We are using Guacamole 1.5.4 for Windows RDP, and are faced with a
> challenging keyboard layout mapping problem.
>
>
>
> Our clients and servers all use the same Hebrew keyboard layout which is
> based on standard US-qwerty, and is switchable on the Windows OS level
> (using a combined Alt+Shift keypress) between English and Hebrew layouts.
>
>
>
> While connected through Guacamole, as long as the client’s Windows
> language is set to ENG everything works fine, since the JS key events are
> translated by the Guacamole client to standard keysyms, which in turn are
> translated back on the server to the appropriate Windows scancode values.
> In this scenario it doesn’t matter which language is currently set active
> within the RDP session (on the target Windows session), since it receives
> the standard scancodes from Guacamole server and interprets them according
> to the active session language layout.
>
>
>
> The mess begins when the client’s selected Windows language is set to HEB
> (which happens every time the user intuitively presses Alt+Shift during
> work in the RDP session). In this case, the Guacamole client intercepts
> unmapped Hebrew key presses, so by default it sends them as Unicode to the
> server. This is sort of half a problem when both client and remote RDP
> session languages are set to HEB, but when client machine is set to HEB and
> RDP session set to ENG, unwanted results occur (Hebrew characters are typed
> instead of English).
>
>
>

Yes, this will be a problem if users are changing the keyboard layout on
the remote side without updating the client-side (Guacamole) keyboard
layout - you'll get a mis-match and odd character input.

The behavior for Unicode characters being sent when the keys are not mapped
is completely intentional - it's designed to give a "fail-safe" for
Guacamole in situations where the keymap is undefined.


> I was able to get over most of this effect by adding the following lines
> to *en_us_qwerty.keymap*:
>
>
>
> map -caps -shift  0x12..0x19  ~ "קראטוןםפ"
>
> map -caps -shift  0x1E..0x27  ~ "שדגכעיחלךף"
>
> map -caps -shift  0x2C..0x34  ~ "זסבהנמצתץ"
>
>
>
> map +caps +shift  0x12..0x19  ~ "קראטוןםפ"
>
> map +caps +shift  0x1E..0x27  ~ "שדגכעיחלךף"
>
> map +caps +shift  0x2C..0x34  ~ "זסבהנמצתץ"
>
>
>
> This maps client Hebrew key presses to their proper physical scancodes,
> but it only partly reduces the frustration since there are still
> problematic leftovers:
>
>
>
> ·   In Hebrew layout, the Slash (/) sign is located on the KeyQ key,
> while in English layout it’s on the ordinary Slash key
>
> ·   The Quote (‘) sign is located on the KeyW in Hebrew, and on
> ordinary Quote key in English
>
> ·   The Comma (,) sign is located on the Quote key in Hebrew, and on
> ordinary Comma in English
>
> ·   The Period (.) sign is located on the Slash key in Hebrew, and on
> ordinary Period in English
>
> ·   The Semicolon (;) sign is located on the Backquote key in Hebrew,
> and on Semicolon in English
>
>
>
> So at the moment, as you can gather, if client language is set to HEB and
> server Guacamole RDP session language is set to ENG, pressing ‘q’ will lead
> to a slash (/) sign pressing ‘w’ will lead to Quote (‘), etc., which really
> is a problem that our users can’t live with.
>
>
>
> To sum the long story short, two questions:
>
>
>
> 1. Is there a way to make the Guacamole client be aware of the
> currently active Windows language, and define different layouts correlating
> to their relevant languages?
>
>
>

I'll have to look at the FreeRDP source code, but I don't think there's a
feedback loop or callback for when the remote side changes the keyboard
layout - I think the expectation is that the client-side keyboard is a
fixed (physical) keyboard, so it will not dynamically change, and that
you'd want that to stay the same for the entire remote session. I can't
foresee a lot of situations where you'd want the client-side keymap to
change on-the-fly.


> 2. Alternatively, on Windows machine scenarios (client + servers) the
> whole back-and-forth conversion from client JS Key code (which is
> equivalent to scancode) through generic keysym and then back to scancode on
> server side, seems redundant when clients and servers share the same
> keyboard layouts. Is there a way to configure the client to avoid it, and
> hence implement direct mapping from client JS Key code to server scancode?
>
>
>

Mike can probably comment more thoroughly on this, but my understanding is
that, no, this is not possible. Even in situations where client and server
keyboard layouts match, in order to properly interpret the keyboard input,
particularly for characters that require modifiers, the key mapping needs
to be done from JS to the Windows scancodes.

Is there a reason that you would not want to just implement the Hebrew
keyboard layout in 

Re: Unable to get Pulseaudio to stream on FreeBSD

[Nick Couchman]

On Fri, May 3, 2024 at 3:26 PM Victor Tschetter 
wrote:

> Has anyone gotten Apache Guacamole to work with the built in support for
> streaming audio using pulseaudio?
>
> I have installed guacamole as a pkg inside a jail. This is the client.
>
> I have another jail running KDE as a desktop environment, with pulseaudio
> configured according the the Guacamole docs. It is listening on port 4713,
> and the module module-protocol-native-tcp is loaded with auth-anonymous=1 to
> allow any clients to connect.
>
> But when ever I try to connect, guacd fails to connect, seemingly because
> of authorization. Logs show
>
> Code:
>
> May  3 12:15:42 guacamole guacd[55774]: Connecting to PulseAudio...
> May  3 12:15:42 guacamole guacd[55774]: Authorizing PulseAudio connection...
> May  3 12:15:42 guacamole guacd[55774]: PulseAudio connection failed
>
>
>
Do you see anything on the KDE side, in the PulseAudio logs, that indicates
that 1) a connection is actually being attempted, and 2) that it is
rejecting authorization and why?

-Nick

Re: SSH session to remote server hanging due to stale NFS file handle

[Nick Couchman]

On Thu, May 2, 2024 at 8:03 PM Justin VanAbrahams 
wrote:

> Not Guacamole-related, but I have absolutely seen stale NFS mounts bog
> down Linux networking to uselessness.
>
>
>

Yeah, I'd agree that stale NFS mounts can be quite debilitating to doing
anything useful with a Linux system. That said, if it only happens when
connecting from Guacamole, I wonder if the Guacamole (= libssh2) session is
doing something additional that may be "catching" on the stale NFS mount -
either SFTP is enabled on the connection and it's trying to start that and
enumerate a filesystem, or something about the shell that libssh2 is
requesting is requiring a more thorough investigation of resources than the
"plain" SSH connection.

-Nick

>

Re: Multiple Shared-drives showing in Guacamole

[Nick Couchman]

On Fri, May 3, 2024 at 10:55 AM Viji Shankar 
wrote:

> Hi Team,
>
> I am encountering an issue when attempting to connect to the Virtual
> Machine via Guacamole. Multiple shared drives are appearing in the
> Guacamole File System. I have attached a screenshot for reference.
>
> Could you please assist in resolving this matter? We are utilizing a MySQL
> server. I would like guidance on identifying any duplicate entries within
> the Guacamole database.
>
>
I have a few questions and things you could share that might help track
down the issue:
* Are you using the feature where you can open multiple connections in the
same window/tab, and do you have multiple connections open? Or does this
happen when you open a single connection?
* Could you share a (sanitized) version of the connection configuration?
* Can you enable debug logging in guacd and share the output when you
connect?
* Can you confirm 1) what version of Guacamole you're using, and 2) that
you're using the official/stock version of it - that you haven't modified
the code at all?

-Nick

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
>>
>>