When migrating from Ubuntu 16.04 LTS to 17.04, many administrators encounter a peculiar authentication failure with SSSD (System Security Services Daemon) configurations that previously worked flawlessly. The symptoms manifest as:

• Failed logins with "System error" message
• Continuous Getty service restarts
• PAM_SSS reporting "Access denied" with error code 4

Before applying any fixes, thorough diagnostics are essential:

# Check SSSD configuration
sssctl config-check

# Examine debug logs (enable first in /etc/sssd/sssd.conf)
journalctl -u sssd -f

# Verify PAM stack configuration
cat /etc/pam.d/login

# Test authentication directly
sss_autofs -s user@domain -d yourdomain

The core issue stems from stricter GPO (Group Policy Object) enforcement in newer SSSD versions. The key indicators in logs:

pam_sss(login:account): Access denied for user user: 4 (System error)
getty@tty2.service: Service has no hold-off time, scheduling restart

The most reliable solution involves modifying SSSD configuration:

[domain/yourdomain]
ad_gpo_access_control = permissive

Alternatively, for more granular control:

# For specific users
ad_gpo_access_control = enforcing
ad_gpo_ignore_unreadable = True

After making changes:

# Restart SSSD
systemctl restart sssd

# Clear cache
sss_cache -E

# Test authentication
su - user@domain

For persistent issues, enable detailed logging:

[sssd]
debug_level = 9

[nss]
debug_level = 9

[pam]
debug_level = 9

Then analyze the output with:

journalctl -u sssd --since "5 minutes ago" | grep -i gpo

If the main solution doesn't work, consider:

1. Verify time synchronization (critical for Kerberos):

ntpdate -u timeserver.domain

2. Check DNS resolution:

host -t SRV _ldap._tcp.domain

Remember to restart services after any changes and verify with test logins.

---

When attempting non-root logins on Ubuntu 17.04 systems configured with SSSD and Kerberos authentication, users encounter an immediate return to the login prompt. System logs reveal:

getty@tty2.service: Service has no hold-off time, sheduling restart.
pam_sss(login:account): Access denied for user jsmith: 4 (System error)
System error

Before diving deeper, let's confirm basic SSSD health:

# Verify basic SSSD configuration
sudo sssctl config-check
sudo sssctl domain-status yourdomain.com

# Check Kerberos ticket availability
kinit jsmith
klist

The key observation is that this works on Ubuntu 16.04 but fails on 17.04. Let's examine the PAM stack:

# Capture detailed authentication logs
sudo tail -f /var/log/auth.log /var/log/sssd/*.log

# Alternative debugging method:
sudo pam-auth-update --force
sudo grep -ir sss /etc/pam.d/

Through debugging, we identified the issue stems from stricter GPO enforcement in newer SSSD versions. The critical setting that changed:

# /etc/sssd/sssd.conf
[domain/example.com]
ad_gpo_access_control = enforcing  # Default in 17.04

Here are three approaches to resolve this:

Option 1: Permissive Mode (Quick Fix)

# /etc/sssd/sssd.conf
[domain/example.com]
ad_gpo_access_control = permissive

Option 2: Proper GPO Configuration

# First install necessary tools
sudo apt-get install sssd-tools

# Then apply proper GPO mappings
sudo sss_override user-add jsmith -g "Allowed RODC Password Replication Group"

Option 3: Debug-Level Logging

# /etc/sssd/sssd.conf
[domain/example.com]
debug_level = 9

[sssd]
debug_level = 9

After making changes:

# Restart services
sudo systemctl restart sssd
sudo systemctl restart systemd-logind

# Test authentication
sudo ausearch -m USER_LOGIN -ts recent
getent passwd jsmith

For persistent cases, consider these diagnostics:

# Check SELinux contexts (if applicable)
ls -Z /usr/lib/x86_64-linux-gnu/security/pam_sss.so

# Verify PAM module loading
strace -f -e trace=openat login jsmith 2>&1 | grep sss