Migrer un backend d'authentification VPN sans réutiliser les anciens hachages

Les noms d'utilisateur apparaissent dans le nouvel annuaire, la migration est déclarée terminée, et les connexions échouent quand même. La passerelle a toujours besoin d'un chemin d'authentification pris en charge et d'un résultat d'autorisation correct, et ni l'un ni l'autre ne découle d'un annuaire qui contient désormais les comptes. Un déplacement de backend est un basculement avec un cycle de vie, pas une tâche de copie. Le symptôme ci-dessous est celui qui révèle généralement la différence.

Le symptôme : les comptes existent, les sessions non

Le nouvel annuaire contient chaque nom d'utilisateur, une liaison de test réussit, et le client VPN renvoie toujours un échec d'authentification. Cette combinaison signifie que l'identité existe, mais que le chemin de vérification utilisé par la passerelle ne l'atteint pas, ou l'atteint avec une méthode qu'elle ne peut pas satisfaire. Les deux relèvent de la configuration, et ce sont des problèmes différents.

Le premier est de la plomberie : la passerelle pointe vers un backend qui ne répond pas, utilise un secret partagé que l'autre côté n'attend pas, ou demande un attribut que le nouveau service ne renvoie pas. Le second est cryptographique : la méthode exige le secret d'origine, et le nouveau magasin ne contient qu'un hachage de celui-ci. Le texte d'erreur se ressemble dans les deux cas, d'où la confusion entre les deux problèmes.

Séparer ces deux cas avant de toucher aux comptes fait gagner une semaine. L'un est une question de routage et de confiance, l'autre une décision de réinitialisation des identifiants, et les mélanger produit des changements que personne ne peut imputer.

Cartographiez la chaîne avant de déplacer qui que ce soit

Notez six éléments pour chaque profil client : la méthode d'authentification externe, une éventuelle méthode interne, l'identité de serveur attendue par le client, l'interface entre la passerelle et le backend, l'attribut que la passerelle associe à l'appartenance à un groupe, et la politique de ressources qui en résulte. Les lire dans l'ordre montre quel maillon n'a pas de propriétaire. Chaque élément a un responsable, et le basculement échoue sur celui que personne n'a vérifié.

Une connexion ordinaire à l'annuaire ne traverse presque rien de cette chaîne. Elle prouve que le compte existe et que le mot de passe fonctionne, soit précisément la partie qui n'a jamais été en doute.

Les hachages ne voyagent pas entre les méthodes

La compatibilité des identifiants doit être vérifiée une fois, avant qu'aucune cohorte ne bouge. FreeRADIUS documente clairement la séparation : une vérification CHAP que le serveur effectue lui-même exige le mot de passe réel, et MS-CHAP accepte ce mot de passe ou un matériel NT approprié. Un hachage produit dans un autre but ne convient à aucun des deux cas, quelle que soit sa robustesse.

La distinction porte sur qui calcule la preuve. Une méthode qui vérifie en s'appuyant sur l'annuaire laisse l'annuaire contrôler ce qu'il peut contrôler. Une méthode qui vérifie en recalculant une réponse au défi a besoin du secret lui-même, car le serveur doit effectuer le même calcul.

Là où la matière manque, les options honnêtes sont une réinitialisation prise en charge, un réenrôlement, un service de vérification externe ou un changement de méthode. Une exportation temporaire de mots de passe récupérables ne figure pas sur cette liste. Elle crée un magasin d'identifiants en clair pendant la semaine la plus chaotique du projet, et elle survit généralement à la migration.

Cohorte pilote, puis changements de cycle de vie

Déplacez une petite cohorte d'identités approuvées avec le vrai client, et testez quatre choses : une connexion neuve, un identifiant délibérément erroné, les ressources que la session peut atteindre, et celles qu'elle ne doit pas atteindre. Vérifiez aussi l'identité de serveur acceptée par le client, car une discordance de nom de certificat reste invisible jusqu'à ce que quelqu'un lise le journal du client.

Exercez ensuite les changements dont le déploiement dépend réellement. Changez un mot de passe, renouvelez ou réenrôlez un certificat, et retirez l'accès à un compte pilote. Après chacun, confirmez quel vérificateur a traité la tentative, car une session créée avant le basculement peut continuer à fonctionner et ne prouve rien sur la connexion suivante.

Séparez la distribution des profils du changement d'identité. Chaque cohorte a besoin de son profil prévu, de son état d'identifiant ou d'enrôlement, du service d'authentification qu'elle doit utiliser et d'un contact de support, et aucun de ces enregistrements ne doit contenir de secret.

Si les anciens et les nouveaux chemins coexistent, bornez-les par une date de fin. Un repli automatique peut admettre un compte avec un ancien identifiant après que le nouveau propriétaire a retiré l'accès, et c'est une régression de sécurité déguisée en disponibilité.

Un retour arrière ne peut pas restaurer un identifiant

Inverser le basculement laisse l'annuaire exactement dans l'état où il est maintenant. Un mot de passe réinitialisé reste réinitialisé, un certificat révoqué reste révoqué, et un format d'identifiant modifié reste modifié. Ce sont des événements dans l'annuaire, et la passerelle n'en a jamais été la source. La reprise doit être définie par événement, et rien de tout cela ne peut dépendre de la reconstruction d'un secret à partir d'un hachage incompatible.

Gardez un chemin administratif qui n'utilise pas la connexion migrée. Quand la nouvelle authentification échoue, mettez la cohorte en pause et utilisez son chemin de reprise documenté au lieu d'affaiblir l'authentification pour tout le monde afin de tenir une échéance.

Une fois les cohortes couvertes, retirez les anciens identifiants, profils et relations de confiance du backend via leurs propriétaires. Confirmez que l'ancien chemin n'admet plus d'utilisateurs, et conservez la correspondance identité-politique sans secret dont le support a encore besoin. Une migration est terminée quand le nouveau cycle de vie fonctionne et que plus personne n'entre par l'ancien chemin, pas quand la liste des comptes semble complète.