XRDP session login fails when kerberos ticket is expired

[mvsoliveira]

I am having a great experience using XRDP, it helps me a lot with running GUI-based tools remotely in several linux nodes. I REALLY APPRECIATE the work you guys have invested in xrdp.

I have an issue to keep sessions lasting for more than a couple of days. I noticed I could connect and disconnet from a session several times with no problems, but it always failed after a couple of days. After failing the first, all the attempts afterwards fail.

The issue seems to be related to the rfbauth file that is stored in the home folder. Here at CERN, our home folder is placed in a net-mounted file system that uses Kerberos for authentication. If the ticket expires, one loses access to the files at the home folder until the Kerberos ticket is renewed.

After the Kerberos ticket got expired, I get the following output when trying to log in:

Logging in via SSH to the machine and renewing the ticket does not help.

Xrdp is active but the following error messages are seen:

The Xvnc process is still running: msilvaol 11890 3.3 0.6 395032 101296 ? Sl Feb25 131:41 Xvnc :10 -auth .Xauthority -geometry 1920x1080 -depth 16 -rfbauth /afs/cern.ch/user/m/msilvaol//.vnc/sesman_passwd-msilvaol@pc-emf-rds-01:10 -bs -nolisten tcp -localhost -dpi 96

/afs/cern.ch/user/m/msilvaol/ is my net-mounted home folder.

/var/log/xrdp-semsman.log gives the following output:

[20220228-16:45:11] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 44156 [20220228-16:45:11] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 11882, ip ::ffff:137.138.77.204:51473 - socket: 12 [20220228-16:45:11] [ERROR] sesman_data_in: scp_process_msg failed [20220228-16:45:11] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans [20220228-16:45:11] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh

/var/log/xrdp.log gives the following output:

[20220228-16:45:11] [INFO ] connecting to sesman on 127.0.0.1:3350 [20220228-16:45:11] [INFO ] xrdp_wm_log_msg: sesman connect ok [20220228-16:45:11] [INFO ] sesman connect ok [20220228-16:45:11] [INFO ] sending login info to session manager. Please wait... [20220228-16:45:11] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 10 [20220228-16:45:11] [INFO ] login successful for user msilvaol on display 10 [20220228-16:45:11] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4 [20220228-16:45:11] [INFO ] VNC started connecting [20220228-16:45:11] [INFO ] VNC connecting to 127.0.0.1 5910 [20220228-16:45:11] [INFO ] VNC tcp connected [20220228-16:45:11] [INFO ] VNC security level is 2 (1 = none, 2 = standard) [20220228-16:45:11] [INFO ] VNC password failed [20220228-16:45:11] [ERROR] VNC error before sending share flag [20220228-16:45:11] [ERROR] VNC error before receiving server init [20220228-16:45:11] [ERROR] VNC error before receiving pixel format [20220228-16:45:11] [ERROR] VNC error before receiving name length [20220228-16:45:11] [ERROR] VNC error before receiving name [20220228-16:45:11] [INFO ] VNC error - problem connecting [20220228-16:45:11] [INFO ] some problem [20220228-16:45:11] [ERROR] xrdp_wm_log_msg: Error connecting to user session [20220228-16:45:11] [INFO ] Error connecting to user session [20220228-16:45:17] [ERROR] xrdp_sec_recv: xrdp_mcs_recv failed [20220228-16:45:17] [ERROR] xrdp_rdp_recv: xrdp_sec_recv failed [20220228-16:45:17] [ERROR] libxrdp_process_data: xrdp_rdp_recv failed [20220228-16:45:17] [ERROR] xrdp_process_data_in: xrdp_process_loop failed

To isolate the issue, I changed my home folder to a local disk in one of the nodes. After that, xrdp works seamlessly in this node. Sessions last until the machine is rebooted (several months).

So the issue seems to be really related to the access to the home folder after the Kerberos ticket expired. Everything works again if I restart xrdp or kill the Xvnc process. But the session is lost and a new one is created instead. So I loose any results obtained in the original xrdp session.

Can you please help me getting xrdp to work with the net-mounted home folder?

[matt335672]

Hi @mvsoliveira

Interesting problem.

Can you report your xrdp version? (xrdp -v). That may well help. Older versions of xrdp behaved differently. Also, we may need to put a source build together to fix this.

The sequence of events on a reconnect with a failed ticket seems to be this. Does this sound right to you? 1) xrdp-sesman authenticates user with PAM. 2) xrdp-sesman constructs shared VNC password and sends it back to the xrdp process. 3) xrdp attempts to connect to Xvnc using the shared password. 4) Xvnc checks the password against the home folder copy

My guess is that when the re-authentication happens, the kerberos ticket isn't being renewed.

Can you tell me how your PAM stack is interacting with the KDC?

Thanks.

[mvsoliveira]

Hi @matt335672, Yes sure, this is the output I have from xrdp -v:

[root@pc-emf-rds-01 ~]#  xrdp -v
xrdp 0.9.18
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --build=x86_64-redhat-linux-gnu
      --host=x86_64-redhat-linux-gnu
      --program-prefix=
      --disable-dependency-tracking
      --prefix=/usr
      --exec-prefix=/usr
      --bindir=/usr/bin
      --sbindir=/usr/sbin
      --sysconfdir=/etc
      --datadir=/usr/share
      --includedir=/usr/include
      --libdir=/usr/lib64
      --libexecdir=/usr/libexec
      --localstatedir=/var
      --sharedstatedir=/var/lib
      --mandir=/usr/share/man
      --infodir=/usr/share/info
      --enable-fuse
      --enable-pixman
      --enable-painter
      --enable-vsock
      --enable-ipv6
      --with-socketdir=/run/xrdp
      --with-imlib2
      build_alias=x86_64-redhat-linux-gnu
      host_alias=x86_64-redhat-linux-gnu
      CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic -Wno-error=deprecated-declarations -Wno-error=missing-braces
      LDFLAGS=-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
      PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig

  Compiled with OpenSSL 1.0.2k-fips  26 Jan 2017

I have to confess that I don't understand the details behind the authentication process. I installed xrdp out-of-the-box and I don't know many details.

I am running xrdp on Centos 7 and the client-side is the Microsoft RDP running in macOS.

Concerning to "My guess is that when the re-authentication happens, the kerberos ticket isn't being renewed." Afterward I logged in with SSH and renewed the kerberos ticket. Should this have been enough to guarantee that Xvnc has access to the home folder?

Concerning "Can you tell me how your PAM stack is interacting with the KDC?" I don't know, unfortunately.

Is there any set of commands that I can run to get the information you need?

[matt335672]

As long as the file system is working, I think Xvnc should be able to access the file. Does an ssh login allow you to reconnect with xrdp? My thinking is that it should do, but maybe more is going on here than is obvious.

Do you know what invocation of authconfig was used to join the box to the Kerberos realm? Maybe we can trace things back from there.

[mvsoliveira]

Hi @matt335672,

I am sorry for taking very long to reply, I got sick, but now I am back. Unfortunately, the ssh login does allow me to reconnect to xrdp.

I don't know how the authconfig was invoked to join the realm. I know that we use the file /etc/krb5.conf to store our kerberos settings. In this webpage, we have more details on how kerberos is configured at CERN and an example of our configuration file.

Is there a command I can type to get the information you are looking for? Alternatively, we can also have a video meeting and debug the issue together. The machine mentioned here is still in the same state, i.e. reachable via ssh but not via xrdp.

[mvsoliveira]

Hello @matt335672,

Would you like to have a look at the issue together using a video meeting ?

[matt335672]

Not keen on a video meeting - not my thing.

What happens when you do the following:-

1. Connect over xrdp
2. Wait for ticket to expire (or use kdestroy to remove it)
3. Disconnect
4. Log in over ssh (same user)
5. Check file system is available on command line
6. Try reconnecting over xrdp
7. After the reconnect attempt, what are the recent contents of xrdp-sesman.log?

[mvsoliveira]

Hi @matt335672,

All right, no problem. This is the output I get.

[20220315-17:03:44] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 44354
[20220315-17:03:44] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 11882, ip ::ffff:194.12.148.24:63858 - socket: 12
[20220315-17:03:44] [ERROR] sesman_data_in: scp_process_msg failed
[20220315-17:03:44] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220315-17:03:44] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh
[20220315-17:03:57] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 44364
[20220315-17:03:57] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 11882, ip ::ffff:194.12.148.24:63858 - socket: 12
[20220315-17:03:57] [ERROR] sesman_data_in: scp_process_msg failed
[20220315-17:03:57] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220315-17:03:57] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh

Do you see anything suspicious? If not, is the AF_INET6 related to ipv6, and is it relevant? I am asking that because we learned in the past that kerberos does't work with ipv6 for the ecosystem we have here, so we disabled ipv6 in our network database for some machines including the one I am using here. Kerberos is working fine for us using ipv4.

[matt335672]

Thanks. Covering the AF_INET6 - it's related to a strangeness in our IPC code, which we're working on removing. I don't think it's relevant here, as xrdp doesn't provide any kind of Kerberos SPN for the users to use.

The log is telling us that authentication is successful, and the reconnect has been attempted. The ERROR messages are (I think) normal as once the reconnection is made, sesman is no longer required. xrdp will connect directly to the Xvnc server, and pass over the VNC password. At that point it looks like the X server is having trouble accessing the file system. That's a worry, as you should have a valid user ticket at that point.

Your Kerberized file system (afs?) needs to access the Kerberos ticket cache to obtain the new TGT. Assuming AFS, the kernel needs to do what's called an 'upcall' to find the cache. We could have a problem here if users having independent caches for each session, or the PAM module you're using is not updating the right cache.

A couple of questions for you:-

• What is the environment variable KRB5CCNAME set to in your xrdp session?
• I'm guessing you're on Scientific Linux 7 from the above. If I'm wrong, please tell me what you are running. If I am right (there's a first time for everything, they tell me), can you tell me what the contents of /etc/pam.d/xrdp-sesman and /etc/pam.d/password-auth are?

Thanks.

[mvsoliveira]

All right.

About having a valid ticket, refreshing the token on a new ssh session should also give file access to other sessions started in the past, like the xrdp session?

Yes, we are using afs. FYI, to get the information from the session, given that I cant reconnect to my session yet, I started a new session by choosing a different color setting. Maybe it is a useful information by itself as well. I didn't restart the xrdp or anything, I am able to create a new session, but not able to go back to the previous one.

msilvaol@pc-emf-rds-01:/afs/cern.ch/user/m/msilvaol$ echo $KRB5CCNAME
FILE:/tmp/krb5cc_27865_AHDtt5

We are using CERN Centos 7.

msilvaol@pc-emf-rds-01:/afs/cern.ch/user/m/msilvaol$ cat /etc/pam.d/xrdp-sesman
#%PAM-1.0
# Generic Fedora config
auth       include      password-auth
account    include      password-auth
password   include      password-auth
session    include      password-auth

# Gnome specific Fedora config
#auth       include      gdm-password
#account    include      gdm-password
#password   include      gdm-password
#session    include      gdm-password

msilvaol@pc-emf-rds-01:/afs/cern.ch/user/m/msilvaol$ cat /etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok

password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so

Thanks in advance.

[matt335672]

The answer to your question is 'it depends'.

Kerberos tickets, including the all-important TGT are stored in a 'ticket cache'

Applications locate the ticket cache by translating KRB5CCNAME. You can have multiple sessions sharing the same ticket cache, or having a separate cache each.

If you're using a Kerberized filesystem (NFS, CIFS, AFS), the kernel also needs access to the ticket cache. For NFS and CIFS, this is done with a 'kernel upcall'. It is assumed that all user sessions are sharing a ticket cache, otherwise the kernel may pick the wrong one.

I'm not familiar with AFS. I assume it uses a similar mechanism, but there's no information I can find on the web about it.

The value you've given me for KRB5CCNAME isn't a good sign. It looks like the output you've get in an ssh session when no other value is available.

To get any further with this, we're going to need to involve someone on your side who understands how AFS is integrated with the kernel on your site. We can blunder about with settings in /etc/krb5.conf but I don't know what other effects that might have in your setup.

Are you able to get access to that kind of knowledge?

[mvsoliveira]

Hi @matt335672,

Thanks, for the clarifications. Yes, sure I can get an AFS expert. Do you already have in mind some questions you would like to ask?

On the other hand, can we instruct xrdp to use a folder other than the user home folder?
If yes, we could make sure xrdp stores every file it needs in a private folder in the local disk, but not necessarily in the home folder. The local disk is always available regardless of any kerberos ticket.

[jmuf]

• the AFS 'kernel upcall' (ioctl) is done either via an executable (aklog, afs5log) or integrated into a library (there are different flavours of pam_krb5.so, some with AFS support..).
• AFS sessions are (by default) not shared, so having the fresh Kerberos credential come in via SSH (which also sets a per-session KRB5CCNAME) is not going to help
• instead it appears that there is a config directive AuthFilePath that allows to place the -rfbauth diretory elsewhere (i.e on a local disk, accessible only by the user)?

[matt335672]

Thanks both.

There's a bit more to this than just getting the Xvnc security file in a different location. Yes we could do this, but there's also the problem of getting the Kerberos TGT into both the Kerberos credentials cache and the AFS session. If we can't do that, there's little point in reconnecting anyway as the session will not be usable. Does that make sense? If you disagree, please say so as I could be over-thinking this.

From what I can see above, you've configured the system so that each session has a separate credentials cache and a separate AFS session. Is that right?

I'll step through the existing reconnection scenario. This is related to xrdp v0.9.18 which I see you are using. As it happens I'm try to make changes in this area for the next big release - there might be some scope for getting you a patch to solve some of this.

Scenario is:-

1) A reconnection attempt comes in to the xrdp process. 2) xrdp prompts for credentials if necessary. 3) xrdp passes the credentials on to xrdp-sesman. 4) xrdp-sesman invokes the PAM stack to authenticate the user. 5) (assuming authentication is successful) xrdp-sesman notices a session is already active. xrdp-sesman passes the session details back to xrdp, and simultaneously runs the session reconnection script as the logged-in user. The existing PAM session is ended.

The biggest problem I can see to start with is when xrdp-sesman calls down into the PAM stack, we don't pass anything useful down to pam_krb5.so which would allow it to find an existing credentials cache. So the existing xrdp architecture seems to be at odds with separate credentials caches for each session.

I hope that all makes sense.

A couple of questions at this point:- 1) Do you use machine consoles? If so, what is KRB5CCNAME set to for these? Are you using kernel keyrings (which I thought were the default for SL7). 2) you using the standard SL7 pam_krb5.so, or have you replaced it with a more functional alternative?

Thanks.

[jmuf]

• each pam_session will get a separate Kerberos credential cache and AFS "process group" (PAG, i.e that thing that shares the AFS token).
• passing a Kerberos ticket between sessions is doable (e.g agree on a fixed name in a safe local directory, always copy "fresh" tickets from the new session into the fixed filename, have the main process always refer to that fixed filename by hardcoding KRB5CCNAME)
• however, getting a fresh AFS credential from that Kerberos credential for some already-running process requires cooperation from that process (or one of its children): it needs to occasionally run aklog. "Injecting" a fresh AFS token from outside of the process group does not work.

(please note that it is possible for AFS tokens to be based purely on UID, shared across all sessions by that user. For this to happen, no PAG must be created (no "setpag()" API call in anything above the login sequence: systemd/init, sshd, pam). This mode is generally discouraged ('root' trivially can then use these tokens, cannot change AFS identify on that machine etc))

(remaining questions depend on the exact setup of the users' machine - no idea, sorry)

[mvsoliveira]

You are welcome. If we manage to reconnect to the session, I think it will be usable because we can always get a new ticket using kinit to recover AFS access. This is in fact what I do for the other server at which the home folder is in a local disk. The problem is really being able to reconnect to the existing session when the home folder is in AFS.

As I see, we have the two following solutions: 1) Fixing the Kerberos ticket expiration problem 2) Saving the Xvnc security file in a different location.

Maybe we could start with solution number 2. Do you have in mind how it could be configured in xrdp? In addition to the AFS home folder, every user in this machine has already a local folder belonging only to the respective user. We could use this folder instead, but not sure how we could configure xrdp to use this.

[matt335672]

I'm happy with that approach if you are.

I'll knock up a quick patch so we can try something like /tmp for now. This will let you test with a single user. If that works, we can figure out a better engineered solution which will work for multiple users.

I'll re-post when I've got something. In the meantime, what is the local folder called? I assume it's parameterised by username or UID(?)

[matt335672]

I'm assuming you'll have enough in-house knowledge to build xrdp from a release tarball. I can give you a patch to apply to that.

[mvsoliveira]

Hi @matt335672,

That's great news. The local home folder is at /home/<username>/. Yes, I can build the xrdp from the tarball.

[matt335672]

Well, that was easier than expected - no rebuild necessary!

I've just found an undocumented feature which will let us do what we want.

1. In sesman.ini, under [Globals], make the following entry:-

AuthFilePath=/home/%s/xrdp-vnc-passwd

That specifies a VNC auth file path of /home/$USER/xrdp-vnc-passwd

On my system, with a user of xtestuser I had to create /tmp/xtestuser manually, and give it the right permissions. Then:-

$ ps -ef | grep Xvnc
xtestus+   22477   22475  4 19:27 ?        00:00:00 Xvnc :11 -auth .Xauthority -geometry 1550x1095 -depth 32 -rfbauth /tmp/xtestuser/xrdp-vnc-passwd -bs -nolisten tcp -localhost -dpi 96

If this works for you, I'll look at documenting this a bit better, and also making it more useful. It should probably be moved from the [Globals] section for a start.

[mvsoliveira]

The option works for me. I will let you know if the session will last longer this time. Thanks in advance.

msilvaol@pc-emf-rds-01:/afs/cern.ch/user/m/msilvaol$  ps -ef | grep Xvnc
msilvaol 10179 10173  2 20:50 ?        00:00:01 Xvnc :10 -auth .Xauthority -geometry 3840x1080 -depth 16 -rfbauth /home/msilvaol/xrdp-vnc-passwd -bs -nolisten tcp -localhost -dpi 96

[matt335672]

Great!

Give it a good testing, then get back to me so we can work out what to do additionally, both for you and for future releases.

[mvsoliveira]

Hi @matt335672,

It looks like the session survived longer, but after sometime around 6 days it presented the same issue.

This is the /var/log/xrdp-sesman.log

[20220327-16:41:29] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 38806
[20220327-16:41:30] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 10173, ip ::ffff:137.138.44.254:53495 - socket: 12
[20220327-16:41:30] [ERROR] sesman_data_in: scp_process_msg failed
[20220327-16:41:30] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220327-16:41:30] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh
[20220327-16:41:49] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 38816
[20220327-16:41:49] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 10173, ip ::ffff:137.138.44.254:53495 - socket: 12
[20220327-16:41:49] [ERROR] sesman_data_in: scp_process_msg failed
[20220327-16:41:49] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220327-16:41:49] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh
[20220327-16:42:14] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 38826
[20220327-16:42:14] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 10173, ip ::ffff:137.138.44.254:53502 - socket: 12
[20220327-16:42:14] [ERROR] sesman_data_in: scp_process_msg failed
[20220327-16:42:14] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220327-16:42:14] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh
[20220327-16:42:31] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 38836
[20220327-16:42:31] [INFO ] Terminal Server Users group is disabled, allowing authentication
[20220327-16:42:31] [INFO ] ++ created session (access granted): username msilvaol, ip ::ffff:137.138.44.254:53508 - socket: 12
[20220327-16:42:31] [INFO ] starting Xvnc session...
[20220327-16:42:31] [INFO ] Starting session: session_pid 41659, display :11.0, width 3840, height 1080, bpp 32, client ip ::ffff:137.138.44.254:53508 - socket: 12, user name msilvaol
[20220327-16:42:31] [INFO ] [session start] (display 11): calling auth_start_session from pid 41659
[20220327-16:42:31] [ERROR] sesman_data_in: scp_process_msg failed
[20220327-16:42:31] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220327-16:42:32] [INFO ] Starting X server on display 11: Xvnc :11 -auth .Xauthority -geometry 3840x1080 -depth 32 -rfbauth /home/msilvaol/xrdp-vnc-passwd -bs -nolisten tcp -localhost -dpi 96  
[20220327-16:42:32] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220327-16:42:32] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220327-16:42:32] [INFO ] Session started successfully for user msilvaol on display 11
[20220327-16:42:32] [INFO ] Starting the xrdp channel server for display 11
[20220327-16:42:32] [INFO ] Session in progress on display 11, waiting until the window manager (pid 41664) exits to end the session
[20220327-16:42:32] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220327-16:42:32] [INFO ] Starting the default window manager on display 11: /usr/libexec/xrdp/startwm-bash.sh
[20220327-16:43:39] [INFO ] Socket 8: AF_INET6 connection received from ::1 port 38860
[20220327-16:43:39] [INFO ] ++ reconnected session: username msilvaol, display :10.0, session_pid 10173, ip ::ffff:137.138.44.254:53521 - socket: 12
[20220327-16:43:39] [ERROR] sesman_data_in: scp_process_msg failed
[20220327-16:43:39] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220327-16:43:39] [INFO ] Starting session reconnection script on display 10: /usr/libexec/xrdp/reconnectwm.sh

And this is the xrdp.log

[20220327-16:41:29] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53493
[20220327-16:41:29] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:41:29] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:41:29] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:41:29] [ERROR] libxrdp_force_read: bad header length 3
[20220327-16:41:29] [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed
[20220327-16:41:29] [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed
[20220327-16:41:29] [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
[20220327-16:41:29] [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
[20220327-16:41:29] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53495
[20220327-16:41:29] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:41:29] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:41:29] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:41:29] [INFO ] Security protocol: configured [SSL|RDP], requested [SSL|HYBRID|HYBRID_EX|RDP], selected [SSL]
[20220327-16:41:29] [INFO ] Connected client computer name: Marcoss-MacBook
[20220327-16:41:29] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20220327-16:41:29] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20220327-16:41:29] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc008 is unknown (ignored)
[20220327-16:41:29] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000409]
[20220327-16:41:29] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20220327-16:41:29] [INFO ] TLS connection established from ::ffff:137.138.44.254 port 53495: TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA
[20220327-16:41:29] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor
[20220327-16:41:29] [INFO ] xrdp_process_offscreen_bmpcache: support level 0 cache size 0 MB cache entries 0
[20220327-16:41:29] [INFO ] xrdp_caps_process_codecs: nscodec, codec id 1, properties len 3
[20220327-16:41:29] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20220327-16:41:29] [WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file
[20220327-16:41:29] [INFO ] Module "CERN" specified by msilvaol from ::ffff:137.138.44.254 port 53495 is not configured. Using "Xvnc" instead.
[20220327-16:41:29] [INFO ] connecting to sesman on 127.0.0.1:3350
[20220327-16:41:30] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220327-16:41:30] [INFO ] sesman connect ok
[20220327-16:41:30] [INFO ] sending login info to session manager. Please wait...
[20220327-16:41:30] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 10
[20220327-16:41:30] [INFO ] login successful for user msilvaol on display 10
[20220327-16:41:30] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20220327-16:41:30] [INFO ] VNC started connecting
[20220327-16:41:30] [INFO ] VNC connecting to 127.0.0.1 5910
[20220327-16:41:30] [INFO ] VNC tcp connected
[20220327-16:41:30] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20220327-16:41:30] [INFO ] VNC password failed
[20220327-16:41:30] [ERROR] VNC error before sending share flag
[20220327-16:41:30] [ERROR] VNC error before receiving server init
[20220327-16:41:30] [ERROR] VNC error before receiving pixel format
[20220327-16:41:30] [ERROR] VNC error before receiving name length
[20220327-16:41:30] [ERROR] VNC error before receiving name
[20220327-16:41:30] [INFO ] VNC error - problem connecting
[20220327-16:41:30] [INFO ] some problem
[20220327-16:41:30] [ERROR] xrdp_wm_log_msg: Error connecting to user session
[20220327-16:41:30] [INFO ] Error connecting to user session
[20220327-16:41:49] [INFO ] connecting to sesman on 127.0.0.1:3350
[20220327-16:41:49] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220327-16:41:49] [INFO ] sesman connect ok
[20220327-16:41:49] [INFO ] sending login info to session manager. Please wait...
[20220327-16:41:49] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 10
[20220327-16:41:49] [INFO ] login successful for user msilvaol on display 10
[20220327-16:41:49] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20220327-16:41:49] [INFO ] VNC started connecting
[20220327-16:41:49] [INFO ] VNC connecting to 127.0.0.1 5910
[20220327-16:41:49] [INFO ] VNC tcp connected
[20220327-16:41:49] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20220327-16:41:49] [INFO ] VNC password failed
[20220327-16:41:49] [ERROR] VNC error before sending share flag
[20220327-16:41:49] [ERROR] VNC error before receiving server init
[20220327-16:41:49] [ERROR] VNC error before receiving pixel format
[20220327-16:41:49] [ERROR] VNC error before receiving name length
[20220327-16:41:49] [ERROR] VNC error before receiving name
[20220327-16:41:49] [INFO ] VNC error - problem connecting
[20220327-16:41:49] [INFO ] some problem
[20220327-16:41:49] [ERROR] xrdp_wm_log_msg: Error connecting to user session
[20220327-16:41:49] [INFO ] Error connecting to user session
[20220327-16:42:13] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53501
[20220327-16:42:13] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:42:13] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:42:13] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:42:13] [ERROR] libxrdp_force_read: bad header length 3
[20220327-16:42:13] [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed
[20220327-16:42:13] [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed
[20220327-16:42:13] [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
[20220327-16:42:13] [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
[20220327-16:42:13] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53502
[20220327-16:42:13] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:42:13] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:42:13] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:42:13] [INFO ] Security protocol: configured [SSL|RDP], requested [SSL|HYBRID|HYBRID_EX|RDP], selected [SSL]
[20220327-16:42:13] [INFO ] Connected client computer name: Marcoss-MacBook
[20220327-16:42:13] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20220327-16:42:13] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20220327-16:42:13] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc008 is unknown (ignored)
[20220327-16:42:14] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000409]
[20220327-16:42:14] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20220327-16:42:14] [INFO ] TLS connection established from ::ffff:137.138.44.254 port 53502: TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA
[20220327-16:42:14] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor
[20220327-16:42:14] [INFO ] xrdp_process_offscreen_bmpcache: support level 0 cache size 0 MB cache entries 0
[20220327-16:42:14] [INFO ] xrdp_caps_process_codecs: nscodec, codec id 1, properties len 3
[20220327-16:42:14] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20220327-16:42:14] [WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file
[20220327-16:42:14] [INFO ] Module "CERN" specified by msilvaol from ::ffff:137.138.44.254 port 53502 is not configured. Using "Xvnc" instead.
[20220327-16:42:14] [INFO ] connecting to sesman on 127.0.0.1:3350
[20220327-16:42:14] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220327-16:42:14] [INFO ] sesman connect ok
[20220327-16:42:14] [INFO ] sending login info to session manager. Please wait...
[20220327-16:42:14] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 10
[20220327-16:42:14] [INFO ] login successful for user msilvaol on display 10
[20220327-16:42:14] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20220327-16:42:14] [INFO ] VNC started connecting
[20220327-16:42:14] [INFO ] VNC connecting to 127.0.0.1 5910
[20220327-16:42:14] [INFO ] VNC tcp connected
[20220327-16:42:14] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20220327-16:42:14] [INFO ] VNC password failed
[20220327-16:42:14] [ERROR] VNC error before sending share flag
[20220327-16:42:14] [ERROR] VNC error before receiving server init
[20220327-16:42:14] [ERROR] VNC error before receiving pixel format
[20220327-16:42:14] [ERROR] VNC error before receiving name length
[20220327-16:42:14] [ERROR] VNC error before receiving name
[20220327-16:42:14] [INFO ] VNC error - problem connecting
[20220327-16:42:14] [INFO ] some problem
[20220327-16:42:14] [ERROR] xrdp_wm_log_msg: Error connecting to user session
[20220327-16:42:14] [INFO ] Error connecting to user session
[20220327-16:42:31] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53507
[20220327-16:42:31] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:42:31] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:42:31] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:42:31] [ERROR] libxrdp_force_read: bad header length 3
[20220327-16:42:31] [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed
[20220327-16:42:31] [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed
[20220327-16:42:31] [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
[20220327-16:42:31] [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
[20220327-16:42:31] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53508
[20220327-16:42:31] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:42:31] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:42:31] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:42:31] [INFO ] Security protocol: configured [SSL|RDP], requested [SSL|HYBRID|HYBRID_EX|RDP], selected [SSL]
[20220327-16:42:31] [INFO ] Connected client computer name: Marcoss-MacBook
[20220327-16:42:31] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20220327-16:42:31] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20220327-16:42:31] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc008 is unknown (ignored)
[20220327-16:42:31] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000409]
[20220327-16:42:31] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20220327-16:42:31] [INFO ] TLS connection established from ::ffff:137.138.44.254 port 53508: TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA
[20220327-16:42:31] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor
[20220327-16:42:31] [INFO ] xrdp_process_offscreen_bmpcache: support level 0 cache size 0 MB cache entries 0
[20220327-16:42:31] [INFO ] xrdp_caps_process_codecs: nscodec, codec id 1, properties len 3
[20220327-16:42:31] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20220327-16:42:31] [WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file
[20220327-16:42:31] [INFO ] Module "CERN" specified by msilvaol from ::ffff:137.138.44.254 port 53508 is not configured. Using "Xvnc" instead.
[20220327-16:42:31] [INFO ] connecting to sesman on 127.0.0.1:3350
[20220327-16:42:31] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220327-16:42:31] [INFO ] sesman connect ok
[20220327-16:42:31] [INFO ] sending login info to session manager. Please wait...
[20220327-16:42:31] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 11
[20220327-16:42:31] [INFO ] login successful for user msilvaol on display 11
[20220327-16:42:31] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20220327-16:42:31] [INFO ] VNC started connecting
[20220327-16:42:31] [INFO ] VNC connecting to 127.0.0.1 5911
[20220327-16:42:32] [INFO ] VNC tcp connected
[20220327-16:42:32] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20220327-16:42:32] [INFO ] VNC password failed
[20220327-16:42:32] [ERROR] VNC error before sending share flag
[20220327-16:42:32] [ERROR] VNC error before receiving server init
[20220327-16:42:32] [ERROR] VNC error before receiving pixel format
[20220327-16:42:32] [ERROR] VNC error before receiving name length
[20220327-16:42:32] [ERROR] VNC error before receiving name
[20220327-16:42:32] [INFO ] VNC error - problem connecting
[20220327-16:42:32] [INFO ] some problem
[20220327-16:42:32] [ERROR] xrdp_wm_log_msg: Error connecting to user session
[20220327-16:42:32] [INFO ] Error connecting to user session
[20220327-16:43:39] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53520
[20220327-16:43:39] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:43:39] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:43:39] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:43:39] [ERROR] libxrdp_force_read: bad header length 3
[20220327-16:43:39] [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed
[20220327-16:43:39] [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed
[20220327-16:43:39] [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed
[20220327-16:43:39] [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed
[20220327-16:43:39] [INFO ] Socket 12: AF_INET6 connection received from ::ffff:137.138.44.254 port 53521
[20220327-16:43:39] [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem
[20220327-16:43:39] [INFO ] Using default X.509 key file: /etc/xrdp/key.pem
[20220327-16:43:39] [WARN ] TLSv1.3 enabled by config, but not supported by system OpenSSL
[20220327-16:43:39] [INFO ] Security protocol: configured [SSL|RDP], requested [SSL|HYBRID|HYBRID_EX|RDP], selected [SSL]
[20220327-16:43:39] [INFO ] Connected client computer name: Marcoss-MacBook
[20220327-16:43:39] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc006 is unknown (ignored)
[20220327-16:43:39] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc00a is unknown (ignored)
[20220327-16:43:39] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER type 0xc008 is unknown (ignored)
[20220327-16:43:39] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000409]
[20220327-16:43:39] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20220327-16:43:39] [INFO ] TLS connection established from ::ffff:137.138.44.254 port 53521: TLSv1.2 with cipher ECDHE-RSA-DES-CBC3-SHA
[20220327-16:43:39] [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor
[20220327-16:43:39] [INFO ] xrdp_process_offscreen_bmpcache: support level 0 cache size 0 MB cache entries 0
[20220327-16:43:39] [INFO ] xrdp_caps_process_codecs: nscodec, codec id 1, properties len 3
[20220327-16:43:39] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20220327-16:43:39] [WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file
[20220327-16:43:39] [INFO ] Module "CERN" specified by msilvaol from ::ffff:137.138.44.254 port 53521 is not configured. Using "Xvnc" instead.
[20220327-16:43:39] [INFO ] connecting to sesman on 127.0.0.1:3350
[20220327-16:43:39] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220327-16:43:39] [INFO ] sesman connect ok
[20220327-16:43:39] [INFO ] sending login info to session manager. Please wait...
[20220327-16:43:39] [INFO ] xrdp_wm_log_msg: login successful for user msilvaol on display 10
[20220327-16:43:39] [INFO ] login successful for user msilvaol on display 10
[20220327-16:43:39] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20220327-16:43:39] [INFO ] VNC started connecting
[20220327-16:43:39] [INFO ] VNC connecting to 127.0.0.1 5910
[20220327-16:43:39] [INFO ] VNC tcp connected
[20220327-16:43:39] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20220327-16:43:39] [INFO ] VNC password failed
[20220327-16:43:39] [ERROR] VNC error before sending share flag
[20220327-16:43:39] [ERROR] VNC error before receiving server init
[20220327-16:43:39] [ERROR] VNC error before receiving pixel format
[20220327-16:43:39] [ERROR] VNC error before receiving name length
[20220327-16:43:39] [ERROR] VNC error before receiving name
[20220327-16:43:39] [INFO ] VNC error - problem connecting
[20220327-16:43:39] [INFO ] some problem
[20220327-16:43:39] [ERROR] xrdp_wm_log_msg: Error connecting to user session
[20220327-16:43:39] [INFO ] Error connecting to user session

I have two sessions running and their authentication files are in the local folder.

[root@pc-emf-rds-01 ~]# ps -ef |grep Xvnc
msilvaol 10179 10173  0 Mar21 ?        00:00:45 Xvnc :10 -auth .Xauthority -geometry 3840x1080 -depth 16 -rfbauth /home/msilvaol/xrdp-vnc-passwd -bs -nolisten tcp -localhost -dpi 96
msilvaol 41665 41659  0 16:42 ?        00:00:00 Xvnc :11 -auth .Xauthority -geometry 3840x1080 -depth 32 -rfbauth /home/msilvaol/xrdp-vnc-passwd -bs -nolisten tcp -localhost -dpi 96

Is there any other dependency on the home folder other than the rdp-vnc-passwd file ? Maybe two Xvnc sessions using the same rdp-vnc-passwd is the problem? I am starting a new test now with only one session to check this possibility.

[matt335672]

Your two X servers have a different colour depth. That will cause sesman to allocate two different sessions for the same user. To prevent this, you'll need to ensure all your clients are choosing the same colour depth on a connect or reconnect.

On Scientific Linux 7, you will have some problems with two sessions running as the same user, as they will be trying to share the same set of systemd --user services. This is a particular problem with GNOME. This could possibly be behind your problems. It's even worse on SL 8 - you'll not be able to start two sessions for the same user.

[WizeDomWisdom]

HI Matt, I'm working with Marcos at the CERN and we're both putting in some time to get xrdp fully working (as during all my tests, it lools the best Remote Desktop candidate out there). I've have been trying to compile ti from your latest build and it came up with the following 2 errors: make make all-recursive make[1]: Entering directory /root/xrdp' Making all in common make[2]: Entering directory/root/xrdp/common' CC base64.lo CC fifo.lo CC file.lo CC guid.lo guid.c: In function 'guid_new': guid.c:36:12: error: missing braces around initializer [-Werror=missing-braces] struct guid guid = {0}; ^ guid.c:36:12: error: (near initialization for 'guid.g') [-Werror=missing-braces] cc1: all warnings being treated as errors make[2]: [guid.lo] Error 1 make[2]: Leaving directory `/root/xrdp/common' make[1]: [all-recursive] Error 1 make[1]: Leaving directory `/root/xrdp' make: *** [all] Error 2

Cheers Dominique

[matt335672]

Hi @WizeDomWisdom

That's an SL/CentOS/RHEL 7 compiler issue - see #2156 and this review comment

HTH.

[WizeDomWisdom]

Cheers, Kudos for such fast answer Dominique

[matt335672]

@WizeDomWisdom - do you need any more input on this one?

[nw505]

I'm seeing a similar problem on RHEL 8.7 systems, in an environment where we're using sssd and Kerberos authentication against an Active Directory domain.

I've tracked the problem down to Kerberos cache files (/tmp/krb5cc_*) somehow having an SELinux type of tmp_t instead of user_tmp_t. This happens to files that previously has a user_tmp_t context, and I don't know what's causing it.

If the Kerberos cache files have the user_tmp_t context, xrdp logins work as expected. If they have tmp_t context than that user won't be able to log in until we remove the file or run a "chcon -t user_tmp_t" on the file.

I have not yet figured out what process keeps changing the SELinux context of these cache files to tmp_t, but it only seems to happen when users are logged in with xrdp. It seems like it could be related to some automatic ticket renewal.

As a temporary workaround, I've set an hourly cron job to run **/usr/bin/chcon -t user_tmpt /tmp/krb5cc***

[nw505]

An hourly cron job has been insufficient, and we're still seeing substantial user impacts from the incorrect SELinux context on /tmp/krb5cc_* files. The incorrect context seems to get set when users have disconnected xrdp sessions.

I've had to increase the frequency to fix this problem every minute.

echo " /usr/sbin/restorecon /tmp/krb5cc_ 2>/dev/null || /bin/true" >> /var/spool/cron/root

[matt335672]

@nw505 - here are some possible workarounds:- 1) Don't put Kerberos cache files in /tmp. I thought the default on RHEL 8.x was to use the kernel keyring(?) Does this not work for you? 2) Use ausearch -m avc to figure out which SELinux process context cannot access the tmp_t and add a rule so that it can.

[azersh]

Hi All, I have similar issue with xrdp, could someone help me? I am using xrdp version 0.9.16

[ERROR] libxrdp_force_read: bad header length 3 [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed

Status from xrdp.service: [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed [INFO ] Socket 12: AF_INET connection received from 127.0.0.1 port 39334 [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem [INFO ] Using default X.509 key file: /etc/xrdp/key.pem [ERROR] libxrdp_force_read: bad header length 3 [ERROR] [ITU-T X.224] Connection Sequence: CR-TPDU (Connection Request) failed [ERROR] xrdp_sec_incoming: xrdp_iso_incoming failed [ERROR] xrdp_rdp_incoming: xrdp_sec_incoming failed [ERROR] xrdp_process_main_loop: libxrdp_process_incoming failed