XRDP is an open-source implementation of Microsoft's Remote Desktop Protocol (RDP) that allows you to enable RDP functionality on your Linux server. In this article, I will walk you through the installation process of XRDP on Linux, sketch out the necessary firewall settings, and explain how you can integrate XRDP with Active Directory.

System administrators frequently want an experience with their Linux server for remote application access that is similar to what Windows offers with Remote Desktop Protocol (RDP). However, many RDP solutions for Linux, such as NoMachine, TeamViewer, or X2Go, require a specific client, may not be free, and might not function with established backends, such as Citrix or Remote Desktop Services.

XRDP performance: XFCE4 vs. Gnome

In addition to installing XRDP, I recommend using a lightweight windowing system (for example, XFCE4). Note that you can use an accelerated desktop, such as Gnome over RDP, provided you have sufficient bandwidth. However, in low-bandwidth situations, such as connecting over VPN, animations will look bad and make the experience poor for the end user, as more parts of the screen need to be updated more frequently.

As you can see in the screenshots below, both are running the desktop at 4K over a VPN-like connection; however, the first one (Gnome desktop) has trouble updating the screen during full-screen animations, such as using the Activities panel. Thus, you get noticeable artifacts (see the gray box I circled) or a slide-show effect, as animations update remotely faster than your connection allows, and the whole system feels slower to work with as a result. The XFCE environment, on the other hand, feels snappy even in low-bandwidth environments.

An accelerated Gnome desktop in an RDP window with high latencylow bandwidth graphical artifacts

An accelerated Gnome desktop in an RDP window with high latencylow bandwidth graphical artifacts

The XFCE desktop in an RDP window using the same connection showing no artifact

The XFCE desktop in an RDP window using the same connection showing no artifact

Install XRDP

Open a terminal, and update your system to ensure you have the latest packages and dependencies.

XRDP and XFCE are present in the default repositories for Debian and Ubuntu, and most of their derivative repositories.

sudo apt update
sudo apt upgrade
sudo apt install xrdp xfce4 xfce4-goodies

Note that on Red Hat Enterprise Linux (RHEL), you should have the EPEL repositories configured prior and then do:

sudo dnf upgrade
sudo dnf install xrdp
sudo dnf install @xfce @base-x

Note that RHEL varies from version to version, and upstream distributions, such as Fedora or CentOS, may have different package names, so if you're not on RHEL:

dnf install @xfce-desktop-environment
dnf groupinstall ‘XFCE Desktop’

Then, make sure we start XRDP and enable it to start on boot automatically:

sudo systemctl start xrdp
sudo systemctl enable xrdp

To make changes to the desktop environment for all users (note that this affects both local consoles as well as remote users) on Ubuntu/Debian systems:

sudo update-alternatives --config x-session-manager
The update alternatives utility which changes default desktop environment selection

The update alternatives utility which changes default desktop environment selection

To override which desktop environment a specific user should use, create or edit the .xsession file in the user's home directory. Users can do this themselves as well. For example, to use XFCE for user jdoe:

echo "xfce4-session" > /home/jdoe/.xsession 

On RHEL, the administrator can override the default desktop setting for all users by copying the standard template and modifying it:

cp /usr/share/accountsservice/user-templates/standard \ 
nano /etc/accountsservice/user-templates/standard

You can view available sessions (gnome, xfce, etc.) by listing the contents of the /usr/share/xsessions directory:

ls /usr/share/xsessions/*

To override on a per-user basis (again, for user jdoe):

cp /usr/share/accountsservice/user-templates/standard \
A typical user template in Red Hat showing their session defaults for Gnome Desktop

A typical user template in Red Hat showing their session defaults for Gnome Desktop

Configure a firewall

If you have a firewall enabled on your Linux system, make sure to allow incoming connections on the RDP port (usually 3389). You can use the following command with ufw (Ubuntu's firewall of choice):

sudo ufw allow 3389/tcp

Or you can use firewalld (most RHEL distributions):

sudo firewall-cmd --permanent --zone=public --add-port=3389/tcp

Configure Active Directory integration

If you have followed my previous articles about using Active Directory for authentication on Linux, it comes as no surprise that you can integrate XRDP with Active Directory as well. To do so, edit your /etc/sssd/sssd.conf, and as we discussed in my previous article on PAM and GPO, map this third-party application, which uses a PAM module:

ad_gpo_map_remote_interactive: "+xrdp-sesman"

This maps XRDP's Session Manager (which handles RDP authentication) to the Allow log on through Remote Desktop Services GPO controls in your AD. As discussed in my previous article, if GPO enforcement is enabled, third-party modules that aren't listed in the configuration (like xrdp-sesman) will default to Deny.

Additionally, make sure outdated and unencrypted RDP protocols cannot be used. Depending on your environment, Windows clients may or may not be set up to allow a connection using an older protocol. Both Windows 10 and XRDP allow these older protocols to be used out of the box. The current recommendation for Windows clients and servers is that a GPO be set in Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Set client connection encryption level to Enabled with High Level selected.

To do the same with XRDP, make sure to enable a minimum level of TLS encryption in /etc/xrdp/xrdp.ini. Under the [Globals] section in the xrdp.ini file, set the security_layer to tls and (optionally) specify a signed certificate, signed by your Active Directory Certificate Authority or a third party, and the allowed protocols and ciphers.

port = 3389
security_layer = tls
crypt_level = high
certificate = /etc/letsencrypt/live/fqdn.example.com/fullchain.pem
key_file = /etc/letsencrypt/live/fqdn.example.com/privkey.pem
ssl_protocols = TLSv1.2, TLSv1.3
tls_ciphers = HIGH

And that's it. PAM and SSSD will handle authentication from here. You can log in either by specifying the username, password, and domain in the RDP client, or you can log in without them, in which case you will be prompted for that information when the connection is established.

RDP to Linux server

On your other Windows, Mac, or Linux machine, open the Remote Desktop client (Remote Desktop Connection, Microsoft Remote Desktop, or other solutions, such as Remmina, or Citrix), and enter the IP address or hostname of your Linux server. If you have used a signed certificate, use the FQDN of the system to make sure you don't get a warning about the certificate. Provide the username and password of the user with whom you want to log in to the application.

As you can see, unlike an RDP session on a Windows client, multiple users can connect simultaneously to their independent desktops in the same way Remote Desktop Services on Windows Server operates.

If you implement this solution on a workstation that is used both locally and remotely, and the same user logs in locally, doesn't log out, goes home, and tries to connect remotely, they may see some issues with the Gnome desktop, as some applications get confused that the same user has multiple sessions open. To fix that, add the line export $(dbus-launch) in the /etc/xrdp/startwm.sh file as follows:

export $(dbus-launch)
if test -r /etc/profile; then
   . /etc/profile                                                                                                            
test -x /etc/X11/Xsession && exec /etc/X11/Xsession
exec /bin/sh /etc/X11/Xsession

This line passes information about any existing D-Bus session for the user so that their messages (e.g., application notifications) can reach both sessions.

Additionally, you may receive a message on systems when logging in that "authentication is required to create a color profile." This happens because there is a policy in Ubuntu systems that doesn't allow remote users to change display color profiles. Users can simply ignore the message, but to remove the message completely, create the file /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf with the following content:

Subscribe to 4sysops newsletter!

polkit.addRule(function(action, subject) {
   if ((action.id == "org.freedesktop.color-manager.create-device" ||
   action.id == "org.freedesktop.color-manager.create-profile" ||
   action.id == "org.freedesktop.color-manager.delete-device" ||
   action.id == "org.freedesktop.color-manager.delete-profile" ||
   action.id == "org.freedesktop.color-manager.modify-device" ||
   action.id == "org.freedesktop.color-manager.modify-profile") &&
   subject.isInGroup("{users}")) {
    return polkit.Result.YES;


Setting up XRDP allows you to access a Linux desktop remotely, making system administration and remote work more convenient. This open-source solution ensures a smooth RDP experience from a Windows machine to Linux. By following the steps outlined in this article, you can easily install XRDP and enable remote access to your Linux system, making remote administration and collaboration a breeze.

  1. Avatar

    Great write-up. I’ve been installing xRDP for a long time so users can remotely access Linux-based VMs from their Windows computers and it works great!

  2. Avatar

    Hi Evi.

    XRDP is great, but…
    I wonder what you would recommend for those of us who have abandoned passwords. Some use SmartCards, some Windows Hello. What do they do if passwords are not allowed as logon method? https://github.com/neutrinolabs/xrdp/discussions/2625 says, it’s still work in progress with SmartCards. Didn’t search for windows hello support, yet – anyone else?


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account