Debugging sssd login: pam_sss [...] System error

Question

How does one properly debug the shell login in the following case?

Authentication is handled via sssd configuration and a krb5 authentication server. Logging in with the same .conf-file on Ubuntu 16.04 LTS works perfectly. Once one uses it with 17.04, logging in with everything other than root results in the getty shell being restarted - /var/log/syslog states

[email protected]: Service has no hold-off time, sheduling restert.
Stopped Getty on tty2.
Started Getty on tty2.

and in auth.log the following is noted:

pam_sss(login:account): Access denied for user <user>: 4 (System error)
System error

Executing login <user> results in

root@pctest# login <user>
password:

System error
root@pctest#

Using sssctl config-check results in no errors as expected from the working configuration on 16.04 LTS.

Every test I mentioned was performed on automatically configured and manually checked, freshly installed systems on formatted drives. Additional packages were installed via the ubuntu-standard metapackage (no desktop environment installed). Nevertheless the problem was also reproduced on a working 16.04 LTS system upgraded to 17.04.

I did neither find a verbose mode for login nor a reasonable way to execute the failing part of the login as standalone. So what would you do?

[Edit] Working workaround

A solution for the given problem is:

Workaround for us was to set ad_gpo_access_control = permissive in the [domain] section of file /etc/sssd/sssd.conf ...

Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859445

Answer 1

You need to add debug_level=10 into all sections in the sssd.conf file, restart sssd and re-run the login. Then look into /var/log/sssd. Also please read https://docs.pagure.org/sssd.sssd/users/troubleshooting.html

Answer 2

Just wondered why some fresh Active Directory connected Linux (Debian 9) systems reported system error on su while some older did not show this behavior. Setting ad_gpo_access_control = permissive indeed made it work but the root cause was that the new systems have IP addresses in a subnet that was not recorded in Active Directory Sites and Services. Once the subnet was added and assigned to a site (give AD some time to replicate) the system error was no longer reported.

Answer 3

same problem on Ubuntu 20.04, adding

• ad_gpo_ignore_unreadable = True
• ad_gpo_access_control = permissive

solved issues that does not exist on Ubuntu 18.04 (same M$ AD and RFC_2307 attributes mapping)

Looks that default values have changed : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-gpo

I still need to find correct settings to keep system secure

Answer 4

I had the exact same issue with 16.04LTS today.

I can confirm that your workaround worked for me as well.

To my domain section I added:

ad_gpo_access_control = permissive

It worked perfect after that. Seems like there is a bug in 16.04LTS and SSSD. Thank you thank you thank you for posting that workaround. I wasn't finding any information anywhere on this error.

Answer 5

This happened to me when I commented out the line for pam_slurm.so in /etc/pam.d/sshd. The solution for me was to restart ssshd service.

My server with Ubuntu 20.04 was using pam_slurm.so to limit access and I decided to disabled it. So I commented it out from /etc/pam.d/sshd

#account    required     pam_slurm.so

Then I got same problem. I checked the log and tried:

$ sudo systemctl restart sssd

Then problem solved.