Le module PAM est inconnu : quel processus a réellement échoué

Lisez cette phrase comme une affirmation sur un objet partagé et un pointeur de fonction, pas sur un mot de passe. Les mêmes mots peuvent venir d’un OpenVPN greffon, d’une pile PAM chargée pour un seul service ou de l’intérieur du démon RADIUS, et ce sont trois enquêtes différentes. Choisissez d’abord le processus.

Les vérifications ci-dessous supposent que le message est apparu via une intégration Linux-PAM lors d’une connexion VPN. S’il provient de la configuration propre au serveur RADIUS, commencez par les preuves de ce démon.

Nommez le processus avant de nommer le paquet

Trois composants sont appelés module et aucun n’est interchangeable. Un greffon d’authentification OpenVPN est chargé par le démon VPN et implémente l’interface de rappel de ce démon. Un module PAM est un objet partagé que libpam charge pour un service nommé, et qui implémente des points d’entrée comme pam_sm_authenticate. Un module FreeRADIUS est un élément de la configuration propre à ce démon. Un message avec les mêmes mots peut venir de n’importe lequel des trois, donc la première question est quelle ligne de journal l’a produit.

Corrélez l’horodatage d’une tentative échouée entre le journal VPN et le journal d’authentification du système, puis lisez les lignes qui précèdent le résumé. Le message précis du chargeur s’y trouve généralement déjà.

Lisez l’erreur de chargement, puis le point d’entrée

PAM signale un module inconnu lorsqu’il ne peut pas charger l’objet partagé sélectionné, ou lorsque l’objet chargé ne fournit pas la fonction qu’exige cette entrée de la pile. Ce sont des réparations différentes : la première est un problème de chemin, d’empaquetage ou d’ABI, et la seconde un point d’entrée qui ne correspond pas. Une ligne d’authentification a besoin de pam_sm_authenticate tandis qu’une ligne de compte a besoin de pam_sm_acct_mgmt, et une bibliothèque qui n’implémente que l’une des deux échouera sur l’autre, comme l’illustre le code du répartiteur. Trouver le fichier sur le disque ne prouve ni l’un ni l’autre.

Prendre une bibliothèque au nom similaire dans une autre distribution ou architecture de processeur n’est pas une réparation, et cela peut laisser un processus charger un module qui n’a jamais été testé contre son libpam. Vérifiez le paquet propriétaire du chemin prévu et l’architecture réelle du fichier avant de changer quoi que ce soit.

Conservez les garanties que la pile offrait

Le moyen le plus rapide de faire taire cette erreur est aussi le pire : marquer un module obligatoire comme facultatif, supprimer l’étape de compte, ou insérer une autorisation inconditionnelle. Chacune transforme une vérification échouée en vérification absente, et la connexion réussit alors pour des raisons que personne n’avait prévues. Les réinitialisations de mot de passe et les changements de secret partagé ne fournissent pas non plus la fonction manquante, car l’échec survient avant qu’un identifiant n’atteigne un service dorsal.

Une pile à plusieurs modules a pu exécuter un autre service dorsal avant l’entrée en échec, donc l’erreur ne prouve pas qu’aucune requête RADIUS n’a été envoyée.

Vérifiez la connexion plutôt que le module

Une fois l’écart corrigé, testez le véritable chemin d’admission. Un compte valide doit réussir, des identifiants invalides doivent toujours échouer, et un compte interdit doit toujours être refusé. Confirmez aussi qu’une exigence de certificat ou de facteur supplémentaire reste appliquée, car une pile réparée qui saute une étape ressemble à un succès du point de vue du client.

Qu’un module se charge proprement est un progrès, pas un test terminé.

Notez quel nom de service, quels fichiers de stratégie et quels points d’entrée étaient impliqués, avec l’unique tentative que vous avez utilisée comme preuve. C’est cette note qui fait de la prochaine occurrence une recherche et non un exercice d’archéologie.