Fix RDP Login Failures for AD Users

The issue with RDP connections failing for domain users (e.g., tony) on Ubuntu servers joined to AD often stems from xrdp session management and PAM configuration. xrdp uses a session manager (sesman) that relies on PAM for authentication. Domain users may fail if their accounts lack proper home directories, permissions, or if SSSD/PAM isn’t fully integrated for graphical sessions.

Why It Fails for Domain Admin tony

• Session Manager Rejection: The “login failed for display 0” error indicates sesman can’t authenticate or create a session for the domain user. This happens because xrdp defaults to local authentication, and domain users require SSSD integration.
• Permissions Needed: The domain user needs:
  • A valid home directory (auto-created via pam_mkhomedir if configured).
  • Membership in groups allowing RDP access (e.g., tsusers or xrdp on some setups).
  • SSSD must cache the user’s credentials properly for PAM to recognize them in graphical sessions.
• Common Causes: Missing PAM modules for SSSD in xrdp configs, Kerberos ticket issues, or firewall blocking ports (e.g., 3389 for RDP).

How to Fix and Troubleshoot

Step 1: Ensure Home Directory Creation

Confirm pam_mkhomedir is enabled in /etc/pam.d/common-session. Test SSH login as tony first to create the home dir.

Login to pxd-ubuntu-devtop using vagrant

vagrant ssh pxd-ubuntu-devtop

Login as tony

ssh tony@pxd-ubuntu-devtop  # password Supersecret!

Check the home directory

pwd

/home/tony@c2.org

Step 2: Configure xrdp for Domain Users

Install xrdp if not already: sudo apt install xrdp. Add the domain user to allowed groups: sudo adduser tony xrdp sudo (or sudo adduser "tony@C2.ORG" xrdp if using fully qualified names).

root@pxd-ubuntu-devtop:~# usermod -a -G sudo,xrdp tony
root@pxd-ubuntu-devtop:~# sudo su - tony
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

tony@pxd-ubuntu-devtop:~$ groups
domain users sudo xrdp domain admins denied rodc password replication group
tony@pxd-ubuntu-devtop:~$

Edit /etc/xrdp/xrdp.ini and ensure autorun points to a valid desktop. We currently have:

tony@pxd-ubuntu-devtop:~$ cat /etc/xrdp/xrdp.ini | grep autorun
autorun=

Since pxd-ubuntu-devtop has ubuntu-desktop installed and it works for local user vagrant, you typically don’t need to specify it explicitly for tony in xrdp.ini if the desktop is available system-wide. xrdp should prompt for session selection (e.g., Xorg or Xvnc) during login, and Ubuntu Desktop (GNOME) will be used if it’s the default DE. However, for domain users, ensure /etc/xrdp/sesman.ini allows the session type.

If needed, set autorun=xorg in [globals] of xrdp.ini to default to Xorg, which supports GNOME. Test and restart xrdp after changes. If issues persist, install a lighter DE like XFCE and set it as default in xrdp.ini for better compatibility with domain auth.

Step 3: Update PAM for xrdp

Ensure /etc/pam.d/xrdp-sesman includes SSSD auth: Add lines like auth include sssd if missing.

The current version of my file has:

root@pxd-ubuntu-devtop:~# cat  /etc/pam.d/xrdp-sesman
#%PAM-1.0
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
@include common-account
@include common-session
@include common-password

Changed to

#%PAM-1.0
auth required pam_env.so readenv=1
auth required pam_env.so readenv=1 envfile=/etc/default/locale
auth    sufficient      pam_sss.so
auth    required        pam_deny.so
@include common-auth
@include common-account
@include common-session
@include common-password

To integrate SSSD properly for xrdp authentication, you may need to ensure that SSSD is included in the common-auth file, but if it’s not sufficient, modify /etc/pam.d/xrdp-sesman directly. Add the following before the @include lines if SSSD auth is not working:

auth sufficient pam_sss.so auth required pam_deny.so

This allows SSSD authentication and denies if it fails. Test carefully, as PAM changes can affect system auth. Restart xrdp after edits. If SSSD is already in common-auth (check /etc/pam.d/common-auth for pam_sss.so), this might not be necessary. -

Restart xrdp: sudo systemctl restart xrdp.

Step 4: Fix SSSD GPO Access Control Issues

Based on the SSSD log output showing “GPO-based access control failed” for the ‘xrdp-sesman’ service, this indicates that SSSD is enforcing Active Directory Group Policy Objects (GPOs), and the service is not mapped to an allowed rule. By default, unmapped services fall back to “Denied” (as per ad_gpo_default_right).

To fix this:

1. Edit /etc/sssd/sssd.conf and add or modify the following in the domain section (e.g., [domain/c2.org]) to map ‘xrdp-sesman’ to remote interactive logons, which are suitable for RDP:

   ad_gpo_access_control = enforcing  # Ensure this is set; default is enforcing
   ad_gpo_map_remote_interactive = +xrdp-sesman
   

   • The +xrdp-sesman adds the service to the remote interactive mapping, allowing GPO rules for remote desktop logins to apply.
   • If you want to disable GPO enforcement temporarily for testing, set ad_gpo_access_control = permissive or disabled, but this is not recommended for production as it bypasses security policies.

2. Restart SSSD: sudo systemctl restart sssd.

3. Verify with logs: Attempt login again and check /var/log/sssd/sssd_c2.org.log for successful access checks.

4. If your AD GPOs explicitly deny access, you may need to adjust them in AD (e.g., allow the user/group for “Allow log on through Remote Desktop Services”).

This mapping ensures ‘xrdp-sesman’ is treated as a remote interactive service, aligning with RDP use cases. For more details, refer to man sssd-ad.

Step 5: Troubleshooting Steps

• Check logs: sudo journalctl -u xrdp or /var/log/xrdp.log for errors.
• Test authentication: getent passwd tony@C2.ORG to verify SSSD sees the user.
• Kerberos check: kinit tony@C2.ORG and ensure a ticket is obtained.
• Firewall: sudo ufw allow 3389/tcp.
• If issues persist, enable debug in /etc/sssd/sssd.conf (add debug_level = 9 under [sssd] and [pam]), restart SSSD, and review /var/log/sssd/*.

After fixes, retry RDP with Remmina using the domain format C2\\tony or tony@C2.ORG and password. Local users like vagrant work because they bypass SSSD.

root@pxd-ubuntu-devtop:~# getent passwd tony@C2.ORG
tony:*:919801104:919800513:tony:/home/tony@c2.org:/bin/bash

In log file /var/log/sssd/sssd_c2.org.log I see the following:

   *  (2025-07-18  4:03:15): [be[c2.org]] [sdap_access_send] (0x0400): [RID#25] Performing access check for user [tony@c2.org]
   *  (2025-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x0400): [RID#25] Performing AD access check for user [tony@c2.org]
   *  (2025-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x4000): [RID#25] User account control for user [tony@c2.org] is [10200].
   *  (2025-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x4000): [RID#25] Expiration time for user [tony@c2.org] is [9223372036854775807].
   *  (2025-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_send] (0x0400): [RID#25] Configuration hint: PAM service 'xrdp-sesman' is not mapped to any Group Policy rule. If you plan to use this PAM service it is recommended to use the ad_gpo_map_* family of options to map this PAM service to a Group Policy rule. PAM services not present in any map will fall back to value set in ad_gpo_default_right, which is currently set to Denied (see manual pages 'man sssd-ad' for more details).
   *  (2025-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_send] (0x0400): [RID#25] service xrdp-sesman maps to Denied
   *  (2025-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_done] (0x0040): [RID#25] GPO-based access control failed.
********************** BACKTRACE DUMP ENDS HERE *********************************