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

getty@tty2.service: 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


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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.