Secure Remote Access Gateway - Running Guacamole on Ubuntu Instead of WSL 2.0

Products Privilege Secure Show & Tell
1

Overview

Privilege Secure for Access Management’s Secure Remote Access Gateway requires WSL 2.0 for running Guacamole in a docker container on the Gateway server itself. However, only Windows Server 2022 and higher support WSL 2.0. This means those running Windows Server 2019 would need to upgrade to at least 2022, which can be very costly.

:information_source: Secure Remote Access (SRA) was previously known as Remote Access Gateway (RAG). You may still see references to RAG in file names, script outputs, etc.

If you’d rather keep running your Windows Server 2019 box for the SRA Gateway, you can do so by outsourcing the Guacamole Docker container to a dedicated Ubuntu Linux box.

:warning: Only Ubuntu 22.04 or later are supported. For reference, this article was prepared using Ubuntu 24.04.2 LTS.

:information_source: We still need a Windows Server image to run the actual SRA Gateway; in this guide we’re simply delegating Guacamole duties to Ubuntu. For reference, this article was prepared using Windows Server 2022.

The diagram illustrates a high-level architecture of a Netwrix Secure Remote Access deployment
The diagram illustrates a high-level architecture of a Netwrix Secure Remote Access deployment1036×754 53.7 KB

The diagram illustrates a high-level architecture of a Netwrix Secure Remote Access deployment using an Ubuntu Linux host to run guacd in Docker.
The diagram illustrates a high-level architecture of a Netwrix Secure Remote Access deployment using an Ubuntu Linux host to run guacd in Docker.1531×761 58.7 KB

Windows Server Installation: Secure Remote Access Gateway

On the Windows Server intended to be the Gateway, copy the NPS.RagGateway.exe file from the Secure Remote Access distribution ZIP file to the desktop of the target SRA Gateway server. Right-click the NPS.RagGateway.exe file and Run as Administrator. Complete the installation.

Ubuntu Docker & Guacamole Installation

On the Ubuntu box intended to handle the SRA Gateway’s Guacamole duties, run the following series of commands to spin up the Guacamole Docker container.

:warning: You will need sudo permission in order to complete this process.

First, run the following command to get the packages and sources needed to fetch Docker and Guacamole:

sudo apt -y install curl && \
curl https://packages.microsoft.com/config/debian/stretch/multiarch/prod.list > ./microsoft-prod.list && \
sudo cp ./microsoft-prod.list /etc/apt/sources.list.d/ && \
curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg && \
sudo cp ./microsoft.gpg /etc/apt/trusted.gpg.d/ && \
sudo apt -y update && \
sudo apt -y install chrony python3-pip moby-engine moby-cli

Next, run the following commands to actually pull and run the Guacamole image as well as get systemd ready:

sudo docker pull guacamole/guacd:1.5.3 && \
sudo mkdir /sys/fs/cgroup/systemd && \
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd && \
sudo docker run --name guacd --restart unless-stopped -v /etc/guacamole -d guacamole/guacd:1.5.3

:information_source: You can confirm systemd is in good shape by running the following command. If it returns systemd, you’re good. If it returns anything else, then systemd needs to be investigated on that system:

sudo ps --no-headers -o comm 1

Restart the guacd container in Docker, then check to make sure it’s running:

sudo docker restart guacd && sudo docker logs guacd

The output of the logs command should look similar to this:

guacd[1]: INFO: Guacamole proxy daemon (guacd) version 1.5.3 started
guacd[1]: INFO: Listening on host 0.0.0.0, port 4822
guacd[1]: INFO: Guacamole proxy daemon (guacd) version 1.5.3 started
guacd[1]: INFO: Listening on host 0.0.0.0, port 4822

Configure the SRA Gateway & Import Certificates to Guacamole

Now that Guacamole is up and running on the Linux host, go back to the Windows Server where you installed NPS.RagGateway.exe.

From PowerShell running as Administrator, run:

& "C:\Program Files\Stealthbits\PAM\NPS.RagGateway\Configure-Gateway.ps1"

You will be prompted for 2 parameters:

  • NPSGuacdHost = IP address for Ubuntu host running Guacamole
  • NPSHost = FQDN of the NPS server in the format: https://FQDN:6500 (use IP address only for non-prod using self-signed cert)

For example:

>> & "C:\Program Files\Stealthbits\PAM\NPS.RagGateway\Configure-Gateway.ps1"

cmdlet Configure-Gateway.ps1 at command pipeline position 1
Supply values for the following parameters:
NPSGuacdHost: 10.61.41.225
NPSHost: https://10.61.41.235:6500
Generating new Guacd certificate
Private key saved to:  C:\ProgramData\Stealthbits\pam\RagGateway\guacd.key
Certificate saved to:  C:\ProgramData\Stealthbits\pam\RagGateway\guacd.crt
Connecting to NPS at https://10.61.41.235:6500
Connected to NPS at https://10.61.41.235:6500 version 25.6.11002.0
Testing connection to Guacd at 10.61.41.225
Connected to Guacd at 10.61.41.225
Updating C:\ProgramData\Stealthbits\PAM\RagGateway\appsettings.json
Updated C:\ProgramData\Stealthbits\PAM\RagGateway\appsettings.json
Updating C:\ProgramData\Stealthbits\PAM\RagGateway\guacd.conf

In the output, you will see the location of a private key and certificate; these will need to be copied into Guacamole on the Ubuntu host, along with the associated .conf file.

On the Ubuntu host, create a temporary folder where you see fit (you can delete this folder once the key and certificate have been copied into Docker). In the case of this guide, a user’s /home folder was used: /home/my_admin

The aforementioned three files need to be copied from the Windows Server to the Ubuntu host:

C:\ProgramData\Stealthbits\PAM\RagGateway\guacd.conf
C:\ProgramData\Stealthbits\PAM\RagGateway\guacd.crt
C:\ProgramData\Stealthbits\PAM\RagGateway\guacd.key

In the same folder, create a file named docker-compose.yaml. You’ll also need to install the following package:

sudo apt -y install docker-compose-plugin

Add the following contents to docker-compose.yaml:

:warning: Be sure to change /path/to/guacd.conf, /path/to/guacd.crt, and /path/to/guacd.key to the paths to those files on your Ubuntu host. These files should all be in the same location, which is the same folder as docker-compose.yaml.

version: '3.8'

services:
  guacd:
    image: guacamole/guacd:1.5.3
    container_name: guacd
    restart: unless-stopped
    ports:
      - "4822:4822"
    volumes:
      - /path/to/guacd.conf:/etc/guacamole/guacd.conf:ro
      - /path/to/guacd.crt:/etc/guacamole/guacd.crt:ro
      - /path/to/guacd.key:/etc/guacamole/guacd.key:ro

Save docker-compose.yaml, and use the following command to use it to run the guacd container (first we need to stop the current guacd container):

:warning: This command needs to be run while your shell is in the same folder as docker-compose.yaml.

sudo docker stop guacd && sudo docker-compose up -d

Check the logs to ensure the service is now running with the Certificate installed:

sudo docker logs guacd

For example:

>> sudo docker logs guacd

2025-06-19T13:48:02.925545531Z guacd[1]: INFO:  Guacamole proxy daemon (guacd) version 1.5.3 started
2025-06-19T13:48:02.925579056Z guacd[1]: INFO:  Communication will require SSL/TLS.
2025-06-19T13:48:02.927138273Z guacd[1]: INFO:  Using PEM keyfile /etc/guacamole/guacd.key
2025-06-19T13:48:02.927277731Z guacd[1]: INFO:  Using certificate file /etc/guacamole/guacd.crt
2025-06-19T13:48:02.927440319Z guacd[1]: INFO:  Listening on host 0.0.0.0, port 4822

You now have SRA’s Gateway running on a Windows Server that doesn’t support WSL 2.0, by delegating Guacamole responsibilities to a dedicated Ubuntu host :thumbs_up:

If you only needed assistance with the Ubuntu host for Guacamole, you could get off at this stop. However, this guide will continue into SRA Portal configuration.

Windows Server Installation: Secure Remote Access Portal

On the Windows Server intended to be the Portal, copy the NPS.RagPortal.exe file from the Secure Remote Access distribution ZIP file to the desktop of the target SRA Portal server. Right-click the NPS.RagPortal.exe file and Run as Administrator. Complete the installation.

Next, open a PowerShell prompt as Administrator and run:

& "C:\Program Files\Stealthbits\PAM\NPS.RagPortal\Configure-Nginx.ps1" [NPS Gateway server]

:warning: For the script above, the [NPS Gateway server] argument should be the IP address of the Windows Server running the SRA Gateway, NOT the Ubuntu host running Docker/Guacamole.

For example:

>> & "C:\Program Files\Stealthbits\PAM\NPS.RagPortal\Configure-Nginx.ps1" 10.61.41.231

Creating new certificates for NPS Rag Portal
Private key saved to:  C:\ProgramData\Stealthbits\pam\RagPortal\nginx.key
Certificate saved to:  C:\ProgramData\Stealthbits\pam\RagPortal\nginx.crt
Certificates created successfully
Updating nginx.conf

    Directory: C:\Program Files\Stealthbits\PAM\NPS.RagPortal\nginx\conf

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           6/17/2025 12:43 PM              0 nginx.conf
nginx.conf updated successfully
Restarting NPS Rag Portal
NPS Rag Portal restarted successfully

:information_source: For any firewalls between clients and the SRA Portal, you’ll also want to create an inbound firewall rule to allow TCP port 443.

The Remote Access Gateway is now ready to use with self-signed certificates. To access, point a browser at: https://[sra_portal_address.com]

:information_source: The SRA Portal does NOT require the use of the 6500 port.

Adding Certificates to the SRA Portal

Certificate Requirements:

  • The certificate should be issued by a trusted Certificate Authority (CA)
  • The certificate, with the private key, should be in the Trusted Root of the Remote Access Gateway Portal server
  • The certificate, without the private key, should be in the Trusted Root of all clients accessing the Remote Access Gateway Portal
  • The certificate should have the IP address and/or DNS name of the RAG Portal in the Subject Alternative Name (SAN)

Choose Authentication Method

Determine how users will authenticate to Secure Remote Access. Best practice security is federated login, and this is the default configuration. Active Directory and local authentication may also be enabled by modifying the appsettings.json file on the SRA Gateway server.

Enable Federated Authentication

In Netwrix Privilege Secure (Configuration > Authentication), select the desired authentication method and enable it for use with Secure Remote Access. In each authentication method, you’ll see a checkbox you can enable titled Use Remote Access Gateway.

The image displays a configuration interface of Netwrix Privilege Secure, highlighting authentication settings with a checkbox for using Remote Access Gateway.
The image displays a configuration interface of Netwrix Privilege Secure, highlighting authentication settings with a checkbox for using Remote Access Gateway.1261×497 89.5 KB

Enable Active Directory & Local Authentication

For security best practice, we strongly recommend using only federated authentication for the Remote Access Gateway, but we recognize that there are use cases where it is desirable to use AD or local NPS authentication.

By default, SRA is configured for federated login only. To enable AD/local NPS authentication, complete the following steps on the SRA Gateway server:

  • Edit the C:\ProgramData\Stealthbits\PAM\RagGateway\appsettings.json file
  • Change AllowedLoginMethods from 0 to 2
  • Save the file

Troubleshooting Common Problems

The Website Does Not Display

  • Verify the SRA Gateway is running by navigating to the following URL: https://[gatewayIPaddress]:6550/api/v1/version - if running, the version will be displayed in the top left
  • Verify the SRA Portal web server firewall is allowing incoming traffic on https. If necessary, initially disable the Guest/Public networks firewall to verify.
  • Look for errors in the SRA Portal log: C:\ProgramData\Stealthbits\PAM\Logs

Federated Authentication Method Does Not Show Up

  • In the Netwrix Privilege Secure admin interface, verify that the federated authentication method checkbox has been enabled for us with the Remote Access Gateway.

Active Directory/Local Authentication Does Not Show Up

  • On the RAG Gateway, verify the AllowedLoginMethods is set to 2 in the C:\ProgramData\Stealthbits\PAM\RagGateway\appsettings.json file.

When selecting a session, SSH or RDP opens a blank window

  • On the Ubuntu server running guacd, run sudo docker logs guacd to verify that the guacd service is running and listening for requests.
  • If your NPS server is using self-signed certificates, verify on the SRA Gateway in the NPS section of the C:\ProgramData\Stealthbits\PAM\RagGateway\appsettings.json you have set InsecureSkipVerify to true from the default of false.

Error Related to “cgroup” When Attempting to Run guacd

  • On the Ubuntu host that houses the guacd Docker container, if you experiencing an error related to cgroup when attempting to run the guacd container then consider uninstalling moby-engine and moby-cli.
  • In their place, install Docker via the following commands:
    sudo apt -y install ca-certificates curl gnupg lsb-release && \
sudo mkdir -m 0755 -p /etc/apt/keyrings && \
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg && \
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null && \
sudo apt -y update && \
sudo apt -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
  • Continue where you left off configuring the guacd Docker container; the cgroup error should no longer occur when you pull and run the guacd image.
3 Likes