xrdp, no login for AD users.

[henryH2Owho]

I have xrdp and sssd and realm all working..... xrdp to a point!
I can log in locally to the "remote" machine using local and AD accounts
I can ssh into the remote machine using local and AD user accounts
I can remote into the remote machine with xrdp using local accounts

I can NOT remote into the remote machine with xrdp using AD user accounts.

Been at this for more than 5 days.. Googled the crap out of it to no avail.

Debian 9
4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28)

using x11rdp and selecting XOG from the login screen.

auth log shows:
xrdp-sesman[1597]: pam_unix(xrdp-sesman:auth): authentication failure; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=death
xrdp-sesman[1597]: pam_sss(xrdp-sesman:auth): authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=death
xrdp-sesman[1597]: pam_sss(xrdp-sesman:account): Access denied for user death: 6 (Permission denied)

[moobyfr]

what is XOG ?
what is the content of /etc/pam.d/common-auth and f /etc/pam.d/xrdp ?
provide xrdp.ini at least

[tfischer77]

Can you post your /etc/sssd/sssd.conf? I have the same configuration running with out any bigger issues .

[henryH2Owho]

Sorry XORG.

Debian GNU/Linux 9 (stretch) with mate desktop

# here are the per-package modules (the "Primary" block)
auth    [success=3 default=ignore]      pam_unix.so nullok_secure
#auth   [success=2 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
# end of pam-auth-update config

/etc/xrdp/xrdp.ini
[Globals]
; xrdp.ini file version number
ini_version=1

; fork a new process for each incoming connection
fork=true
; tcp port to listen
port=3389
; regulate if the listening socket use socket option tcp_nodelay
; no buffering will be performed in the TCP stack
tcp_nodelay=true
; regulate if the listening socket use socket option keepalive
; if the network connection disappear without close messages the connection will be closed
tcp_keepalive=true
#tcp_send_buffer_bytes=32768
#tcp_recv_buffer_bytes=32768

; security layer can be 'tls', 'rdp' or 'negotiate'
; for client compatible layer
security_layer=negotiate
; minimum security level allowed for client
; can be 'none', 'low', 'medium', 'high', 'fips'
crypt_level=high
; X.509 certificate and private key
; openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365
certificate=
key_file=
; specify whether SSLv3 should be disabled
#disableSSLv3=true
; set TLS cipher suites
#tls_ciphers=HIGH

; Section name to use for automatic login if the client sends username
; and password. If empty, the domain name sent by the client is used.
; If empty and no domain name is given, the first suitable section in
; this file will be used.
autorun=

allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
#hidelogwindow=true
max_bpp=32
new_cursors=true
; fastpath - can be 'input', 'output', 'both', 'none'
use_fastpath=both
; when true, userid/password *must* be passed on cmd line
#require_credentials=true
; You can set the PAM error text in a gateway setup (MAX 256 chars)
#pamerrortxt=change your password according to policy at http://url

;
; colors used by windows in RGB format
;
blue=009cb5
grey=dedede
#black=000000
#dark_grey=808080
#blue=08246b
#dark_blue=08246b
#white=ffffff
#red=ff0000
#green=00ff00
#background=626c72

;
; configure login screen
;

; Login Screen Window Title
#ls_title=My Login Title

; top level window background color in RGB format
ls_top_window_bg_color=009cb5

; width and height of login screen
ls_width=350
ls_height=430

; login screen background color in RGB format
ls_bg_color=dedede

; optional background image filename (bmp format).
#ls_background_image=

; logo
; full path to bmp-file or file in shared folder
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50

; for positioning labels such as username, password etc
ls_label_x_pos=30
ls_label_width=60

; for positioning text and combo boxes next to above labels
ls_input_x_pos=110
ls_input_width=210

; y pos for first label and combo box
ls_input_y_pos=220

; OK button
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30

; Cancel button
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30

[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
; LogLevel and SysLogLevel could by any of: core, error, warning, info or debug

[Channels]
; Channel names not listed here will be blocked by XRDP.
; You can block any channel by setting its value to false.
; IMPORTANT! All channels are not supported in all use
; cases even if you set all values to true.
; You can override these settings on each session type
; These settings are only used if allow_channels=true
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true

; for debugging xrdp, in section xrdp1, change port=-1 to this:
#port=/var/run/xrdp/sockdir/xrdp_display_10

; for debugging xrdp, add following line to section xrdp1
#chansrvport=/var/run/xrdp/sockdir/xrdp_chansrv_socket_7210


;
; Session types
;

[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
#port=-1
port=/var/run/xrdp/sockdir/xrdp_display_10
code=20

[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
#xserverbpp=24
#delay_ms=2000
 
[console]
name=console
lib=libvnc.so
ip=127.0.0.1
port=5900
username=na
password=ask
#delay_ms=2000

[vnc-any]
name=vnc-any
lib=libvnc.so
ip=ask
port=ask5900
username=na
password=ask
#pamusername=asksame
#pampassword=asksame
#pamsessionmng=127.0.0.1
#delay_ms=2000

[sesman-any]
name=sesman-any
lib=libvnc.so
ip=ask
port=-1
username=ask
password=ask
#delay_ms=2000

[rdp-any]
name=rdp-any
lib=librdp.so
ip=ask
port=ask3389

[neutrinordp-any]
name=neutrinordp-any
lib=libxrdpneutrinordp.so
ip=ask
port=ask3389
username=ask
password=ask

; You can override the common channel settings for each session type
#channel.rdpdr=true
#channel.rdpsnd=true
#channel.drdynvc=true
#channel.cliprdr=true
#channel.rail=true
#channel.xrdpvr=true

# cat /etc/sssd/sssd.conf

[sssd]
domains = nmetec.zzz
config_file_version = 2
services = nss, pam

[domain/nmetec.zzz]
ad_domain = nmetec.zzz
krb5_realm = NMETEC.ZZZ
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/NMETEC/%u
access_provider = ad```

[henryH2Owho]

Not sure what good common-auth will be the auth log shows authentication was successful.
/etc/pam.d/xrdp-sesman
is the only xrdp file in there, it's contents are:
#%PAM-1.0
@include common-auth
@include common-account
@include common-session
@include common-password

[metalefty]

Please don't forget to quote when you paste config or logs. You can quote it by triple back quotations. Everything you input in the comment form is interpreted as Markdown unless quoted.

[tfischer77]

Change the last line of your sssd.conf to
access_provider = simple
AD logins will work then. Access_provider =ad needs some more configuration. Details can be found in the man page of sssd.conf.

[henryH2Owho]

AD logins work for ssh and local console as previously stated, why would xrdp work differently?

[moobyfr]

xrdp-sesman[1597]: pam_sss(xrdp-sesman:auth): authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=death
and
xrdp-sesman[1597]: pam_sss(xrdp-sesman:account): Access denied for user death: 6 (Permission denied)
There is something strange:
auth is ok, but account is denied.
As you include common-account , did you modify it ?
(I don't think this is a bug in xrdp)

[henryH2Owho]

It would be great to know WHAT is "denying permission".

/etc/pam.d/common-account
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account sufficient pam_localuser.so

[tfischer77]

xrdp_sesman is not registered as service provider in sssd, whereas ssh and local console is. You can either register it or switch to simple mode. Read the man page on how to register it. man sssd.conf or switch to simple mode as stated before.
Believe me, I was running into exactly the same problem.

[henryH2Owho]

Finally someone who looks like they know what they are doing.
The man page is confusing, I've no idea how to "register" xrdp_sesman.
The word register is not even in the manual. Can you help?

[henryH2Owho]

sssd.conf has a services entry but it only lists nss and pam
services = nss, pam

[moobyfr]

You are probably missing entries for ad_gpo_map_interactive in sssd.conf, there is a built-in list, complete it with xrdp-sesman.
This seems not to be a xrdp issue

[henryH2Owho]

built-in list??
AS xrdp is the only non-fuctioning part one would assume the issue existed there.
As I've said before ad users work for local GUI and console and ssh logins. sssd appears to be working fine.

[moobyfr]

I persist that you should read the sssd man page: man sssd-ad ad_gpo_map_interactive
https://jhrozek.fedorapeople.org/sssd/1.13.4/man/sssd-ad.5.html

ad_gpo_map_interactive (string)
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the InteractiveLogonRight and DenyInteractiveLogonRight policy settings.
Default: the default set of PAM service names includes:
login
su
su-l
gdm-fingerprint
gdm-password
gdm-smartcard
kdm
lightdm
lxdm
sddm
xdm

So, only this list of services are allowed to create sessions for users. you need to add xrdp-sesman

If you ask yourself where is sshd , this is available on the next entry ad_gpo_map_remote_interactive :)

[henryH2Owho]

The upgrade from Debian 8 to 9 has broken a LOT of things on my systems.
I've patched around this issue for now with the access_provider = simple, not perfect but gets me access for now.

It indeed appears to be an sssd thing, these boys need to work on their installer, it should ask a few questions and configure based on the responces.

Thanks to those who tried and those that did help.

[vitalykarasik]

access_provider = simple

you saved my day, many thanks!

[havilchis]

For those who are looking for an answer and found this page in Google. The issue is the lack of an sssd config, is not and xrdp bug.

Maybe you are using an Active Directory integration with sssd and Group Policy as authorization method (Like the official instructions from RHEL)

You have 2 choices:

Option 1: Use "simple" as access provider instead of Group Policy

You sssd.conf should look like this

[sssd]
domains = mydomain.corp
config_file_version = 2
services = nss, pam

[domain/mydomain.corp]
ad_domain = mydomain.corp
... a bunch of config not related ...
access_provider = simple

This makes useless the GPO Policy, but you can specify which users or groups are allowed to login with this commands in the workstation: (more info)
realm permit user@example.com
or
realm permit -g group@example.com.

Option 2: Keep Using Group Policy

This is the config that works for me in Centos 8

[sssd]
domains = mydomain.corp
config_file_version = 2
services = nss, pam

[domain/mydomain.corp]
ad_domain = mydomain.corp
... a bunch of config not related ...
access_provider = ad
ad_gpo_access_control = enforcing
ad_gpo_map_remote_interactive = +xrdp-sesman

[doush]

access_provider = simple

the exact solution i was looking for..
thanks

[jnjus]

For those who are looking for an answer and found this page in Google. The issue is the lack of an sssd config, is not and xrdp bug.

Maybe you are using an Active Directory integration with sssd and Group Policy as authorization method (Like the official instructions from RHEL)

You have 2 choices:

Option 1: Use "simple" as access provider instead of Group Policy

You sssd.conf should look like this

[sssd]
domains = mydomain.corp
config_file_version = 2
services = nss, pam

[domain/mydomain.corp]
ad_domain = mydomain.corp
... a bunch of config not related ...
access_provider = simple

This makes useless the GPO Policy, but you can specify which users or groups are allowed to login with this commands in the workstation: (more info) realm permit user@example.com or realm permit -g group@example.com.

Option 2: Keep Using Group Policy

This is the config that works for me in Centos 8

[sssd]
domains = mydomain.corp
config_file_version = 2
services = nss, pam

[domain/mydomain.corp]
ad_domain = mydomain.corp
... a bunch of config not related ...
access_provider = ad
ad_gpo_access_control = enforcing
ad_gpo_map_remote_interactive = +xrdp-sesman

THANK YOU - Saved me who knows how many hours. I'm in a pretty restrictive air-gapped environment bound to AD and I think that setting access_provider may have done more harm than good. Leaving it as is and explicitly defining ad_gpo_access_control and ad_gpo_map_remote_interactive did the trick for me. Thanks again!!

[worshach]

realm permit -g group@example.com

I always forget about that. Anyway, problem solved. Thanks!