Comment résoudre les échecs d'authentification PAM sur un serveur SUSE Linux Enterprise

Un message d'« échec d'authentification PAM » ne signifie pas toujours que le mot de passe est incorrect. Sur SUSE Linux Enterprise Server (SLES), les modules d'authentification enfichables (PAM) forment une pile qui vérifie l'identité, l'accès au compte, les modifications de mot de passe et l'établissement de la session. Un échec peut provenir d'une faute de frappe ou d'un compte désactivé, d'une inclusion PAM corrompue, d'un service LDAP ou Active Directory indisponible, d'un problème d'horloge Kerberos ou de DNS, ou d'un problème de session de bureau survenant après l'authentification.

La solution la plus sûre consiste à identifier le service et l'étape PAM défaillants avant de modifier la configuration. Ce guide s'appuie sur la documentation de SUSE Linux Enterprise Server 15 SP7. Si vous utilisez un autre Service Pack SLES ou une image d'appliance spécifique, consultez la documentation SUSE correspondante et vérifiez les versions des paquets installés avant d'appliquer les commandes.

Premièrement, quel service est défaillant : un seul ou toutes les connexions ?

Notez l'utilisateur, l'heure exacte, l'hôte et le point d'entrée de l'échec : SSH, console locale, interface graphique suou application. Si possible, effectuez un test avec un second compte utilisateur connu. Si seul le SSH échoue alors que la connexion à la console fonctionne, concentrez-vous sur /etc/pam.d/sshdle service SSH. Si les utilisateurs locaux se connectent mais pas les utilisateurs du répertoire, examinez SSSD, LDAP, Active Directory, Kerberos, DNS ou la politique d'autorisation de l'hôte. Si la connexion à la console réussit mais que le bureau rejette l'utilisateur ou affiche l'écran de connexion, l'échec peut provenir de la session graphique ou du répertoire personnel plutôt que de l'authentification par mot de passe.

Gardez une session root ouverte pendant le dépannage. Si vous êtes connecté à distance, ouvrez une seconde session SSH et assurez-vous de disposer d'un accès console ou de secours avant de modifier le fichier PAM. Une erreur de syntaxe ou de paramètre de contrôle dans un fichier PAM partagé peut bloquer les nouvelles connexions à plusieurs services.

1. Lisez le journal relatif à la tentative infructueuse

Le guide de dépannage de SUSE recommande de consulter le journal système pour rechercher les messages relatifs au processus de connexion et à PAM. Interrogez-le sur une courte période proche de la panne afin que des messages sans rapport avec le problème ne masquent pas la cause.

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

Pour un problème lié uniquement à SSH, limitez votre analyse au démon SSH :

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

Recherchez le nom du service, le nom du service PAM, le nom du module et vérifiez si le message fait référence à auth[ nom du service], account[ nom du service], [nom du module password] ou [ nom du module]. La pile sessionPAM vérifie les informations d'identification, s'assure que l'utilisateur est autorisé à accéder au service et prépare l'environnement utilisateur. Un mot de passe validé suivi d'un refus d'accès indique un problème différent d'un utilisateur inconnu ou d'un mot de passe incorrect. Évitez d'activer le débogage détaillé sur un système de production, sauf en cas de nécessité ; les journaux de diagnostic peuvent contenir des noms de compte et d'autres informations sensibles.authaccountsession

Consultez le guide de dépannage SLES de SUSE pour connaître son flux de travail d'authentification locale et réseau.

2. Vérifiez que SLES peut trouver l'utilisateur

Avant de modifier le PAM, vérifiez si le commutateur de service de noms du système peut résoudre le compte :

getent passwd user_name
id user_name

Remplacez user_namepar l'identifiant de connexion concerné. Si ces commandes ne renvoient aucun compte pour un utilisateur d'annuaire, il est possible que PAM fonctionne correctement tandis que la recherche d'identité échoue. Vérifiez que le service d'identité configuré est en cours d'exécution, que l'hôte peut accéder à l'annuaire et que l'utilisateur est autorisé à se connecter sur cet hôte. Pour une configuration basée sur SSSD, examinez le démon et les journaux récents :

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

SUSE indique que SSSD fournit des interfaces NSS et PAM et précise qu'il peut mettre en cache les données d'identité. En cas de défaillances intermittentes, comparez l'heure et la résolution DNS du système local avec celles de l'annuaire ou de l'environnement Kerberos. Kerberos dépend d'une synchronisation horaire précise ; une connexion réseau fonctionnelle ne garantit pas à elle seule la réussite de l'authentification.

Vérifiez également l'absence de conflits de noms. SUSE indique qu'un nom d'utilisateur existant localement et dans une source d'identité réseau peut être à l'origine de problèmes d'authentification réseau. Avant de modifier les règles PAM du compte, vérifiez quelle source d'identité est censée le posséder.

3. Examinez le fichier de service PAM et la pile partagée.

SLES conserve les fichiers PAM par service dans un répertoire /etc/pam.dspécifique. Un fichier de service, tel que ` /etc/services` /etc/pam.d/sshd, inclut généralement des fichiers partagés comme common-auth` common-account/ etc/services`, ` common-password/etc/services`, `/etc/services` et common-session`/etc/services`. Une ligne incorrecte dans un fichier partagé peut affecter plusieurs services ; une ligne incorrecte dans le fichier PAM d'une application peut n'affecter que cette application.

Veuillez lire les fichiers concernés et vérifier leurs liens avant toute modification :

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

Vérifiez l'orthographe des noms de modules, l'absence de fichiers, les options incorrectes, l'ordre inattendu des modules et les modifications apportées lors du déploiement récent d'un package ou d'une authentification. Les indicateurs de contrôle sont importants : requiredils enregistrent une erreur mais poursuivent l'exécution ; requisiteils peuvent interrompre immédiatement l'exécution ; sufficientils peuvent autoriser un retour au succès prématuré si aucun module requis n'a échoué. Ne copiez pas une pile PAM depuis une autre distribution ou version SLES sans comprendre ses modules et son flux de contrôle.

Avant toute modification, effectuez une sauvegarde du répertoire courant réservée à l'utilisateur root, en préservant les liens symboliques :

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

Vérifiez que la sauvegarde existe et notez précisément les fichiers modifiés. Si tous les utilisateurs sont bloqués, utilisez la procédure de récupération SLES standard et restaurez le système à partir d'une configuration fonctionnelle plutôt que d'improviser à l'invite de connexion.

4. Sous SLES, vérifiez si pam-config gère les fichiers partagés.

SUSE propose pam-configde gérer les fichiers PAM globaux et les configurations d'applications prises en charge. Cette méthode est généralement plus sûre que la modification manuelle des piles partagées générées lors de l'ajout ou de la suppression d'une méthode prise en charge. Commencez par examiner les modules disponibles et l'intégration SSSD actuelle :

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

Si le serveur utilise intentionnellement SSSD et que l'intégration est manquante, consultez la documentation SUSE sudo pam-config --add --ssspour savoir comment l'ajouter. Procédez à cette opération uniquement après avoir vérifié la conception de l'authentification par annuaire, examiné la pile logicielle actuelle, conservé une sauvegarde et vous être assuré de disposer d'une solution de récupération. N'utilisez pas cette méthode comme solution générique pour chaque « échec d'authentification ». Interrogez à nouveau la configuration et effectuez un test lors d'une seconde session.

La commande `sudo` est particulièrement risquée pam-config --create. SUSE indique qu'elle génère une configuration d'authentification Unix simplifiée et écrase les fichiers de configuration existants non gérés par `sudo` pam-config(tout en conservant des copies de sauvegarde avec un .pam-config-backupsuffixe `.sudo`). Elle ne constitue pas une solution de dépannage courante suite à un échec de connexion ponctuel. Utilisez-la uniquement si vous prévoyez de reconstruire la configuration et avez mis en place un plan de récupération.

Si votre organisation gère intentionnellement les fichiers PAM manuellement, respectez cette méthode. SUSE indique que la configuration manuelle nécessite la désactivation pam-configde ces fichiers. Les piles personnalisées doivent conserver les modules de session nécessaires, y compris pam_systemd.soen tant que module de session optionnel le cas échéant.

5. Problèmes distincts liés à SSH, aux répertoires et au bureau

Si seul SSH rejette le compte

Comparez /etc/pam.d/sshdcette configuration avec une configuration SLES fonctionnelle et examinez le journal du démon SSH au moment de l'échec de connexion. Vérifiez que le compte est autorisé par les paramètres et contrôles d'accès SSH, ainsi que par PAM. Ne désactivez pas l'authentification SSH ni les contrôles de compte pour faire disparaître l'erreur.

Si seuls les utilisateurs de l'annuaire échouent

Confirmez la résolution du compte getent, vérifiez l'état et les journaux SSSD, ainsi que l'accessibilité du répertoire, le DNS, la synchronisation de l'heure, l'inscription à l'hôte et la politique d'accès de l'utilisateur. Si un autre utilisateur du répertoire réussit, comparez les groupes, le shell, le répertoire personnel et les règles d'accès spécifiques à l'hôte du compte concerné. Le guide du client d'authentification SUSE décrit SSSD géré par YaST et ses vérifications d'état.

Si la connexion console fonctionne mais que la session graphique échoue

Vérifiez les journaux de connexion et de session graphiques, la disponibilité du répertoire personnel, son propriétaire, l'espace disque libre et toute étape de déverrouillage du répertoire personnel chiffré. Une connexion réussie en mode texte indique que le mot de passe et l'authentification de base fonctionnent ; cela oriente l'attention vers la session de bureau ou l'environnement utilisateur. Évitez de supprimer les fichiers utilisateur dans un premier temps. Le guide de dépannage de SUSE recommande d'isoler méthodiquement les problèmes de configuration du bureau.

6. Vérifiez la réparation sans risquer de vous retrouver bloqué.

Après une modification, ouvrez une nouvelle session de test tant que l'environnement de récupération est accessible. Testez le service concerné avec le compte affecté, puis avec un second compte et un compte d'administrateur local. Pour l'authentification par annuaire, vérifiez la résolution du compte et l'état du service, ainsi que la réussite de la connexion. Consultez à nouveau le journal pour détecter d'éventuelles nouvelles erreurs PAM et supprimez les paramètres de débogage temporaires avec l' pam-config --deleteoption correspondante une fois les tests terminés.

Enfin, vérifiez que le résultat corrige bien le problème au lieu de le masquer. Une connexion corrigée doit authentifier l'utilisateur prévu, appliquer la politique de compte définie et créer une session normale. Conservez la sauvegarde jusqu'à ce que vous ayez vérifié ces résultats et documenté la configuration finale.

Quand faut-il s'arrêter et utiliser le mode de récupération ?

Cessez toute modification à distance si l'accès root est perdu, si plusieurs services tombent en panne simultanément, si la pile partagée a été écrasée ou si vous ne parvenez pas à identifier le gestionnaire de configuration propriétaire des fichiers. La documentation SLES explique comment utiliser l'accès root pour réparer la configuration et accéder au mode de récupération lorsque la connexion normale est impossible. Pour les systèmes de production gérés, contactez l'équipe en charge de l'identité ou de la plateforme avant de reconstruire une pile d'authentification partagée.

Pour connaître la structure exacte des fichiers PAM, les indicateurs de modules, pam-configle comportement et les procédures de récupération, consultez le guide PAM SUSE SLES 15 SP7 correspondant à votre version et le guide des problèmes courants SUSE . Les piles PAM constituent une politique de sécurité ; effectuez la moindre modification justifiée, puis vérifiez les accès et les restrictions.