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>

System error

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

5 Answers 5


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


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.


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


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.


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.

  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Nov 30, 2021 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .