login failed for display 0 xrdp

[kenanrustemlee]

No description provided.

[matt335672]

@kenanrustemlee

A couple of questions for you:-

• What is your platform (i.e. hardware + OS)?
• What is the output of xrdp -v
• Have you installed xorgxrdp?
• What are the contents of /home/xrdpshared/.xorgxrdp.10.log

Thanks.

[matt335672]

OK - thanks.

The X server is working fine, which is good, but for some reason your desktop isn't starting.

You may not have a desktop installed.

1. What does update-alternatives --query x-session-manager say?
2. What are the contents of /home/xrdpshared/.xsession-errors ?

[matt335672]

I'm getting confused here - not your fault. I don't think I read the initial logs clearly enough.

If you get login failed for display 0, it generally means exactly that - the login has failed. However, you're not getting that all the time.

The session log has some interesting lines in it:-

dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument
. . .
dus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-d5ucvfMZDz,guid=6f89cd1a2ade682facb4dd0762160ce2

These don't look right to me. Your DBUS_SESSION_BUS_ADDRESS is supposed to be unix:path=/run/user/1000/bus. If it isn't that would result in the other line. Also, XDG_RUNTIME_DIR isn't set. Both of these should be set during login by a component called pam_systemd.so.

We had something similar in neutrinolabs/pulseaudio-module-xrdp#72 that was never fully explained. This looks very similar.

I'll suggest what I added to that thread. Maybe we can get more information.

Can you create a file /home/xrdpshared/startwm.sh with the following contents:-

#!/bin/bash

# Create a log 
exec >/tmp/startwm.log 2>&1
echo "Start environment"
echo "-----------------"
env | sort

. /etc/profile

echo "Environment after profile"
echo "-------------------------"
env | sort

export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus
exec /etc/X11/Xsession

Make the file executable with chmod +x ~xrdpshared/startwm.sh. Then log in over xrdp and see what happens. The contents of /tmp/startwm.log will be interesting.

[matt335672]

I think getting a local logon working first is a good idea. AD can be a bit fiddly to get working, especially if you're using group policies to allow services.

That all looks fine, and consistent with a session starting properly. If authentication wasn't working you wouldn't get the log.

What's happening at this point. Are you getting a session?

If not, can you generate a system log for the last two minutes (just after the login attempt) with this command:-

sudo journalctl -S -2m

That should give us a bit more of a clue.

[matt335672]

Hmm, that's really not a useful log. The lines we need are all truncated.

Can you try again please, but this time redirect the log to a text file:-

sudo journalctl -S -2m >system.log.txt

Thanks.

[matt335672]

That's better - thanks :-)

The authentication messages can be found by grepping for xrdp-sesman in this log. Here are some significant ones:-

Feb 28 13:14:47 hostname xrdp-sesman[4092498]: pam_unix(xrdp-sesman:auth): check pass; user unknown
Feb 28 13:14:47 hostname xrdp-sesman[4092498]: pam_unix(xrdp-sesman:auth): authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost=

and:-

Feb 28 13:14:47 hostname xrdp-sesman[4092498]: pam_sss(xrdp-sesman:auth): authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=xrdpshared@hostname
Feb 28 13:14:47 hostname audit[4092498]: USER_AUTH pid=4092498 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="xrdpshared@hostname" exe="/usr/sbin/xrdp-sesman" hostname=? addr=? terminal=xrdp-sesman res=failed'
Feb 28 13:14:47 hostname xrdp-sesman[4092498]: pam_sss(xrdp-sesman:auth): received for user xrdpshared@hostname: 10 (User not known to the underlying authentication module)

However you're specifying your username, it isn't being recognised by pam_unix (local name) or pam_sss (AD).

My knowledge of sssd is a bit rusty these days (I used to be a RHEL admin), but I suspect you can solve this by setting default_domain_suffix in sssd.conf [linux.die.net] and then specifying an unqualified name on the login screen. Either that, or use an unqualified name for the login name, and a qualified name for AD.

Does that make sense?

[matt335672]

We'll need to work through the errors, one at a time.

Can we start by getting xrdpshared (the local user) with no domain name working?

When you try to log in with that, what does this command give you?

sudo journalctl -u xrdp-sesman -S -2m

[kenanrustemlee]

@matt335672 I appreciate for your help :) It was agreed since beginning that only ssh will be used. Administrator has blocked other tools somehow. Thanks for your time