Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers. Visit Stack Exchange

Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.

Sign up to join this community

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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>
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
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.
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
                Nov 30, 2021 at 18:21