Come risolvere gli errori di autenticazione PAM su SUSE Linux Enterprise Server

Un messaggio di errore "Autenticazione PAM non sempre significa che la password sia errata. Su SUSE Linux Enterprise Server (SLES), i moduli di autenticazione plug-in (PAM) formano uno stack che verifica l'identità, l'accesso all'account, le modifiche della password e la configurazione della sessione. Un errore può derivare da un errore di battitura o da un account disabilitato, da un file PAM incluso danneggiato, da un servizio LDAP o Active Directory non disponibile, da un problema con l'orologio Kerberos o con il DNS, oppure da un problema di sessione desktop che si verifica dopo l'autenticazione.

La soluzione più sicura consiste nell'identificare quale servizio e quale fase PAM hanno causato l'errore prima di modificare la configurazione. Questa guida utilizza come riferimento la documentazione di SUSE Linux Enterprise Server 15 SP7. Se si utilizza un altro service pack di SLES o un'immagine appliance specializzata, verificare la documentazione SUSE corrispondente e le versioni dei pacchetti installati prima di applicare i comandi.

Innanzitutto, qual è il problema: un singolo servizio o tutti gli accessi?

Registra l'utente, l'ora esatta, l'host e il punto di ingresso in cui si è verificato l'errore: SSH, una console di testo locale, accesso grafico suo un'applicazione. Se possibile, esegui un test con un secondo account noto. Se solo l'accesso SSH fallisce mentre l'accesso tramite console funziona, concentrati sul /etc/pam.d/sshdservizio SSH. Se gli utenti locali funzionano ma gli utenti della directory falliscono, esamina SSSD, LDAP, Active Directory, Kerberos, DNS o i criteri di autorizzazione dell'host. Se l'accesso tramite console ha successo ma il desktop rifiuta l'utente o torna alla schermata di accesso, l'errore potrebbe risiedere nella sessione grafica o nella directory home anziché nell'autenticazione tramite password.

Durante la risoluzione dei problemi, mantieni aperta una shell root esistente. Se sei connesso da remoto, mantieni aperta una seconda sessione SSH e assicurati di avere accesso alla console o in modalità di ripristino prima di modificare il file PAM. Un errore di sintassi o un errore nel flag di controllo di un file PAM condiviso può bloccare i nuovi accessi a più servizi.

1. Leggi il diario relativo al tentativo fallito

La guida alla risoluzione dei problemi di SUSE consiglia di esaminare il registro di sistema alla ricerca di messaggi relativi al processo di accesso e a PAM. Eseguire una query su un breve intervallo di tempo in prossimità dell'errore, in modo che messaggi non correlati non oscurino la causa:

sudo journalctl -b --since "15 minutes ago"

Per un problema che riguarda esclusivamente SSH, restringete la visuale al demone SSH:

sudo journalctl -b -u sshd --since "15 minutes ago"

Cerca il nome del servizio, il nome del servizio PAM, il nome del modulo e se il messaggio fa riferimento a auth, account, password, o session. Lo stack di PAM authcontrolla le credenziali; accountcontrolla se all'utente è consentito accedere a quel servizio; sessionprepara l'ambiente utente. Un controllo della password riuscito seguito da un rifiuto dell'account indica un problema diverso rispetto a un utente sconosciuto o a una password errata. Evita di abilitare il debug dettagliato su un sistema di produzione a meno che non sia necessario; i log diagnostici possono contenere nomi di account e altri contesti sensibili.

Consulta la guida alla risoluzione dei problemi di SLES di SUSE per informazioni sul flusso di lavoro di autenticazione locale e di rete.

2. Confermare che SLES riesca a trovare l'utente

Prima di modificare PAM, verificare se il Name Service Switch del sistema è in grado di risolvere l'account:

getent passwd user_name
id user_name

Sostituire user_namecon l'account di accesso interessato. Se questi comandi non restituiscono alcun account per un utente della directory, PAM potrebbe funzionare correttamente mentre la ricerca dell'identità non riesce. Verificare che il servizio di identità configurato sia in esecuzione, che l'host possa raggiungere la directory e che all'utente siano consentiti gli accessi su tale host. Per una configurazione basata su SSSD, esaminare il demone e i log recenti:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE documenta SSSD come dotato di interfacce NSS e PAM e specifica che può memorizzare nella cache i dati di identità. Se gli utenti segnalano errori intermittenti, confrontare l'ora del sistema locale e la risoluzione DNS con la directory o l'ambiente Kerberos. Kerberos dipende dalla corretta sincronizzazione dell'ora; una connessione di rete funzionante da sola non garantisce il successo dell'autenticazione.

Verificate anche la presenza di conflitti di nomi. SUSE elenca un nome utente esistente sia localmente che in un'origine di identità di rete come possibile causa di problemi di autenticazione di rete. Prima di modificare le regole PAM, verificate quale origine di identità dovrebbe essere proprietaria dell'account.

3. Esaminare il file di servizio PAM e lo stack condiviso

SLES conserva i file PAM per servizio in /etc/pam.d. Un file di servizio come /etc/pam.d/sshdinclude comunemente file condivisi come common-auth, common-account, common-password, e common-session. Una riga errata in un file condiviso può influire su diversi servizi; una riga errata nel file di un'applicazione può influire solo su quell'applicazione.

Prima di apportare modifiche, leggi i file pertinenti e controlla i relativi collegamenti:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Verifica la presenza di nomi di moduli scritti in modo errato, file di moduli mancanti, opzioni errate, ordine inatteso e modifiche apportate durante un recente rilascio di pacchetti o di autenticazione. I flag di controllo sono importanti: requiredregistrano un errore ma continuano attraverso lo stack; requisitepossono arrestarsi immediatamente; sufficientpossono consentire il ritorno anticipato in caso di errore di un modulo richiesto in precedenza. Non copiare uno stack PAM da un'altra distribuzione o versione SLES senza comprenderne i moduli e il flusso di controllo.

Prima di apportare qualsiasi modifica, crea un backup della directory corrente contenente solo la directory root, preservando i collegamenti simbolici:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Verificate l'esistenza del backup e annotate con precisione quali file modificate. Se tutti gli utenti sono bloccati, utilizzate la procedura di ripristino SLES supportata e ripristinate il sistema da una configurazione funzionante, anziché improvvisare al momento dell'accesso.

4. Su SLES, verificare se pam-config gestisce i file condivisi

SUSE consente pam-configdi gestire i file PAM globali e le configurazioni delle applicazioni supportate. In genere, è più sicuro rispetto alla modifica manuale degli stack condivisi generati quando si aggiunge o si rimuove un metodo supportato. Innanzitutto, verificare i moduli disponibili e l'integrazione SSSD corrente:

sudo pam-config --list-modules
sudo pam-config --query --sss

Se il server utilizza intenzionalmente SSSD e l'integrazione non è presente, SUSE documenta sudo pam-config --add --sssla procedura per aggiungerla. Eseguire questa operazione solo dopo aver verificato la configurazione dell'autenticazione della directory, aver esaminato lo stack corrente, aver effettuato un backup e aver verificato di disporre di un piano di ripristino. Non utilizzare questa procedura come soluzione generica per ogni "errore di autenticazione". Verificare nuovamente la configurazione ed eseguire un test in una seconda sessione.

Un comando particolarmente rischioso è pam-config --create. SUSE afferma che questo comando genera una semplice configurazione di autenticazione Unix e sovrascrive i file di configurazione esistenti non gestiti da pam-config(mantenendo copie di backup con un .pam-config-backupsuffisso). Non è una riparazione di routine per un singolo accesso non riuscito. Usalo solo quando intendi deliberatamente ricostruire la configurazione e hai pianificato il ripristino.

Se la tua organizzazione gestisce intenzionalmente i file PAM manualmente, segui questa prassi in modo coerente. SUSE fa notare che la configurazione manuale richiede la disabilitazione pam-configdi tali file. Gli stack personalizzati devono preservare i moduli di sessione necessari, includendoli pam_systemd.socome moduli di sessione opzionali ove applicabile.

5. Separare i problemi relativi a SSH, directory e desktop

Se solo SSH rifiuta l'account

Confronta la /etc/pam.d/sshdconfigurazione con una configurazione SLES funzionante e analizza il registro del demone SSH al momento del tentativo di accesso fallito. Verifica che l'account sia autorizzato dalle impostazioni e dai controlli di accesso di SSH, nonché da PAM. Non indebolire l'autenticazione SSH né rimuovere i controlli dell'account solo per far scomparire l'errore.

Se solo gli utenti della directory falliscono

Conferma la ricerca dell'account con getent, controlla lo stato e i log di SSSD e verifica la raggiungibilità della directory, il DNS, la sincronizzazione dell'ora, la registrazione dell'host e i criteri di accesso dell'utente. Se un altro utente della directory riesce ad accedere, confronta i gruppi, la shell, la directory home e le regole di accesso specifiche dell'host dell'account interessato. La guida del client di autenticazione di SUSE descrive SSSD gestito da YaST e i relativi controlli di stato.

Se l'accesso alla console funziona ma la sessione grafica fallisce

Verifica i log di accesso e di sessione grafici, la disponibilità della directory home, la proprietà, lo spazio libero su disco e qualsiasi passaggio di sblocco della directory home crittografata. Un accesso tramite console testuale riuscito è una prova utile che la password e il percorso di autenticazione di base funzionano; sposta l'attenzione sulla sessione desktop o sull'ambiente utente. Evita di eliminare i file utente come primo passo. La guida alla risoluzione dei problemi di SUSE raccomanda di isolare i problemi di configurazione del desktop in modo metodico.

6. Verificare la riparazione senza rischiare di rimanere bloccati

Dopo una modifica, apri una nuova sessione di test mentre la shell di ripristino rimane disponibile. Testa il servizio interessato con l'account interessato, quindi testa un secondo account e un amministratore locale. Per l'autenticazione della directory, verifica la ricerca dell'account e l'integrità del servizio, nonché l'avvenuto accesso. Controlla nuovamente il registro per eventuali nuovi errori PAM e rimuovi le impostazioni di debug temporanee con l' pam-config --deleteopzione corrispondente al termine del test.

Infine, verificate che il risultato risolva il problema anziché nasconderlo. Un login corretto dovrebbe autenticare l'utente previsto, applicare i criteri di account desiderati e creare una sessione normale. Conservate il backup fino a quando non avrete verificato questi risultati e documentato la configurazione finale.

Quando è necessario fermarsi e attivare la modalità di soccorso?

Interrompete le modifiche remote se perdete l'accesso root, se più servizi si bloccano contemporaneamente, se lo stack condiviso è stato sovrascritto o se non riuscite a determinare quale gestore di configurazione è il proprietario dei file. La documentazione di SLES descrive come utilizzare l'accesso root per ripristinare la configurazione e come entrare in modalità di ripristino quando l'accesso normale non è disponibile. Per i sistemi di produzione gestiti, coinvolgete il team di identità o di piattaforma prima di ricostruire uno stack di autenticazione condiviso.

Per informazioni precise sulla struttura del file PAM, i flag dei moduli, pam-configil comportamento e le procedure di ripristino, consultare la guida PAM di SUSE SLES 15 SP7 e la guida ai problemi comuni di SUSE , entrambe corrispondenti alla versione in uso . Gli stack PAM rappresentano una policy di sicurezza; apportare la modifica più piccola giustificata, quindi verificare sia l'accesso che le restrizioni.