Diagnoseer SLES PAM-aanmeldingsproblemen zonder uzelf buiten te sluiten.

Een foutmelding "PAM authentication failure" wijst niet op één universele oplossing. Identificeer eerst welke service en gebruikers de fout veroorzaken en controleer vervolgens het logboek op het betreffende tijdstip. Op SUSE Linux Enterprise Server (SLES) kunt u een bevestigd globaal PAM-probleem herstellen via de juiste procedure pam-configen een individueel servicebestand alleen wijzigen als de bijbehorende stack onjuist is. Houd tijdens het testen een werkende root- of beheerderssessie open; een defecte PAM-stack kan nieuwe SSH- en console-aanmeldingen blokkeren.

De huidige SLES 15 SP7 Security and Hardening Guide beschrijft PAM als een stapel van authenticatie-, account-, wachtwoord- en sessiemodules. Dat onderscheid is belangrijk: een correct wachtwoord kan de autheerste fase doorstaan ​​en toch later worden afgewezen door een accountbeleid of een servicespecifieke regel. Een algemene foutmelding alleen kan niet aangeven welke fase is mislukt.

Wat bewijst de fout wel, en wat bewijst ze niet?

PAM fungeert als tussenpersoon tussen een applicatie, zoals sshdde console-aanmelding, en de geconfigureerde authenticatiemethoden. Elke PAM-compatibele service heeft een bestand onder /etc/pam.d/. Het servicebestand kan algemene SLES-bestanden bevatten, zoals common-authen common-account, waardoor een storing die zich beperkt tot SSH een andere oorzaak kan hebben dan storingen bij alle aanmeldmethoden.

Geverifieerd: De gedocumenteerde SSH-stack van SUSE bevat pam_nologin.sode gebruikelijke PAM-bestanden. Indien /etc/nologinaanwezig, weigert de gedocumenteerde module aanmeldingen aan gebruikers anders dan root. Contextafhankelijk: lokaal bewerkte regels, directoryservices en MFA-modules van derden kunnen extra controles toevoegen. Niet vastgesteld door het bericht alleen: dat het wachtwoord onjuist is, dat de PAM-bestanden beschadigd zijn of dat het account is geblokkeerd. Begin met de betreffende service en het bijbehorende logboek in plaats van de stack te vervangen.

Welk inlogpad werkt niet?

Reproduceer de fout eenmaal en noteer de tijd, gebruikersnaam en methode: SSH, lokale tekstconsole, grafische aanmelding, sudoof su. Als u zich kunt aanmelden als beheerder, controleer dan recente systeemberichten:

sudo journalctl -e

De SUSE SLES-handleiding voor probleemoplossing raadt specifiek aan om het logboek te controleren op aanmeldings- en PAM-fouten. Zoek rond het exacte tijdstip van de poging naar de modulenaam of de reden, zoals een geweigerd account, een niet-beschikbare directoryservice, een ontbrekende module of een bestands-/toegangsfout. Deel logboeken niet openbaar zonder gebruikersnamen, hostnamen, adressen en andere gevoelige gegevens te verwijderen.

Als alleen SSH niet werkt, controleer dan het logboek van de SSH-daemon:

sudo journalctl -u sshd

Vergelijk vervolgens de toegangspaden. Als een gebruiker zich wel kan authenticeren via de lokale console, maar niet via SSH, richt u zich op /etc/pam.d/sshdhet SSH-toegangsbeleid of een SSH-specifieke module. Als meerdere services dezelfde lokale gebruikers weigeren, inspecteer dan hun gedeelde common-*bestanden. Als slechts één gebruiker wordt geweigerd, controleer dan de accountstatus en het wachtwoord voordat u de systeemwijde authenticatie wijzigt.

Is dit een lokaal account of een netwerkidentiteit?

Controleer voor een lokale gebruiker eerst de gebruikersnaam, toetsenbordindeling en Caps Lock. Als een reset van de inloggegevens nodig is, gebruik dan de door de beheerder goedgekeurde wachtwoordtool, zoals YaST Gebruikers- en Groepsbeheer, in plaats van /etc/shadowhandmatig te bewerken. Als alle niet-rootgebruikers via SSH worden geweigerd, controleer dan of er een gepland onderhoudsbestand /etc/nologinaanwezig is voordat u PAM wijzigt; verwijder dit alleen als is bevestigd dat het onderhoudsblok verouderd is en u daartoe bevoegd bent.

Voor LDAP, Active Directory of een andere gebruiker met een directory als back-up, bewijst een werkend wachtwoord op een andere server niet dat deze SLES-host de identiteitsprovider kan bereiken. SUSE noemt netwerk- en DNS-problemen, Kerberos-klokafwijking, verkeerd geconfigureerde PAM-regels, hosttoegangsbeleid en niet-beschikbare thuismapmappen als mogelijke oorzaken. Test of een andere domeingebruiker kan inloggen en of de betreffende gebruiker kan inloggen op een andere host. Controleer vervolgens de geconfigureerde identiteitsservice en de serverconnectiviteit.

Als de host SSSD gebruikt, controleer dan de service en of PAM is geconfigureerd om deze te gebruiken:

systemctl status sssd
sudo pam-config --query --sss

SSSD kan gebruikersinformatie cachen en authenticatie toestaan ​​terwijl de directory tijdelijk onbereikbaar is, maar dat gedrag is afhankelijk van de configuratie en de gecachede referenties. Een verouderde of ontbrekende cache is daarom slechts één mogelijkheid, geen definitieve conclusie. Controleer DNS, tijdssynchronisatie voor Kerberos, de bereikbaarheid van de directory en de SSSD-logboeken voordat u de cache wist of modules wijzigt. Als de identiteitsprovider meldt 'Account geblokkeerd' of 'Account uitgeschakeld', laat de directorybeheerder dan het beleid van dat account controleren; PAM rapporteert de beslissing, maar creëert deze niet noodzakelijkerwijs zelf.

Hoe los je een vastgesteld PAM-configuratieprobleem op?

Bekijk het servicespecifieke bestand en de gedeelde regels die het bevat:

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

Op SLES pam-configworden globale bestanden beheerd onder /etc/pam.d/common-*; individuele servicebestanden, zoals , /etc/pam.d/sshdworden apart beheerd. Bewerk gegenereerde algemene bestanden niet handmatig, tenzij u dit bewust pam-configvoor die bestanden hebt uitgeschakeld. Als u bevestigt dat deze host SSSD zou moeten gebruiken en de SSSD PAM-regels ontbreken, raadpleeg dan de SUSE-documentatie sudo pam-config --add --sssom deze toe te voegen. Gebruik SSSD pas nadat u hebt bevestigd dat SSSD zelf is geconfigureerd en actief is. Test vervolgens een nieuwe aanmelding terwijl de werkende beheerderssessie open blijft.

Een veelvoorkomende maar riskante misvatting is dat dit pam-config --createeen onschadelijk reparatiecommando is. SUSE zegt dat het een basis Unix-authenticatieconfiguratie aanmaakt en bestaande bestanden overschrijft die het niet beheert, waarbij back-upkopieën behouden blijven. Dit kan aangepast MFA-gedrag of directory-authenticatie ongedaan maken. Voer het niet uit als een algemene herstelstap. Bij een typefout in een servicebestand, herstelt u de bekende, correcte en versie-geschikte configuratie van die service vanuit een betrouwbare back-up of wijzigt u de specifieke foutieve regel volgens de wijzigingsprocedure van uw organisatie.

Hoe kunt u de reparatie bevestigen?

Laat de oorspronkelijke root- of beheerderssessie open. Start een tweede sessie via dezelfde service die de fout veroorzaakte – bijvoorbeeld een nieuwe SSH-verbinding – en test het betreffende account. Controleer of het logboek niet langer dezelfde PAM-weigering registreert en of een andere geconfigureerde authenticatiemethode nog steeds werkt. Als de fout aanhoudt, noteer dan het exacte tijdstempel, de service, de naam van de PAM-module en de relevante geanonimiseerde logregels; deze details zijn nuttiger dan het algemene bericht 'authenticatie mislukt'.

Officiële referenties

• SUSE SLES 15 SP7 Beheerhandleiding: Veelvoorkomende problemen en hun oplossingen — Probleemoplossing voor lokale en netwerkaanmeldingen.
• SUSE SLES 15 SP7 Beveiligings- en beveiligingshandleiding: Authenticatie met PAM — PAM-fasen, SSH-stack en pam-config.
• SUSE SLES 15 SP7: Authenticatieclients instellen met YaST — SSSD-status en cachegedrag.
• SUSE SLES 15 SP7: Netwerkbewerkingen beveiligen met OpenSSH — sshd-logboekberichten bekijken.