OpenVPN coupe une session OTP plus tard : ce dont la réauthentification a besoin

Du côté du client, cela ressemble à une déconnexion aléatoire une heure après le début d’une session qui fonctionne. L’icône de la zone de notification disparaît, le tunnel se reconstruit et le journal affiche un échec d’authentification plutôt qu’une erreur réseau. Ce qui s’est réellement passé, c’est que la session a renégocié et que la seconde poignée de main avait besoin d’identifiants dont le client n’avait plus de copie valide. Un code à usage unique qui a fonctionné à la connexion ne peut pas fonctionner de nouveau, donc le renouvellement de clé échoue exactement comme prévu.

Le correctif est une décision sur ce que la seconde poignée de main doit présenter, pas une minuterie de nouvelle tentative plus longue.

Suivez l’échange du point de vue du client

À la connexion, le client envoie le nom d’utilisateur, le mot de passe et un code du dispositif à jeton, et le serveur accepte la combinaison. La session tourne ensuite jusqu’à ce qu’un déclencheur de renégociation se déclenche, ce qui démarre une nouvelle poignée de main TLS à l’intérieur du tunnel existant. Cette poignée de main redemande une authentification. Si le chemin d’authentification du serveur attend un mot de passe plus un code à usage unique en cours, le client n’a pas de nouveau code à offrir, sauf si l’utilisateur est présent pour en saisir un.

La plupart des clients n’ouvrent pas d’invite au milieu de la session, donc la poignée de main expire et le tunnel tombe. L’utilisateur voit une reconnexion, pas une invite d’authentification, et c’est pourquoi le premier rapport accuse généralement le réseau.

auth-gen-token change qui répond à la seconde question

auth-gen-token est l’option qui permet au serveur d’émettre un jeton après une connexion réussie, et les renégociations ultérieures présentent ce jeton au lieu de répéter le mot de passe et le code. Le manuel documente sa durée de vie et son comportement de renouvellement, et le jeton doit être traité comme un identifiant ayant sa propre expiration. Dans le chemin par défaut, le serveur valide le jeton lui-même au lieu de rappeler l’authentificateur de mot de passe externe.

Avec une intégration d’authentification externe, cette répartition change. Le plugin doit comprendre l’état du jeton et appliquer ses propres contrôles, car le serveur n’est plus le seul composant à décider si la session continue. Traiter le jeton comme un autre code numérique à usage unique n’est pas une implémentation de la fonctionnalité.

Décidez ce qui arrive au statut du compte

Un jeton qui survit à l’accès d’un compte est un trou de politique. Décidez comment un compte désactivé, une appartenance à un groupe supprimée ou un appareil révoqué prennent effet alors que le jeton est encore valide. Des durées de vie courtes réduisent la fenêtre ; un chemin de révocation explicite la rend intentionnelle. Écrivez la réponse avant d’activer l’option, car le chemin par défaut ne consulte pas l’authentificateur externe à chaque renégociation.

Dans un déploiement multi-serveurs, le secret de signature des jetons doit être partagé, sinon le client peut être envoyé vers un nœud qui ne peut pas valider son jeton.

Testez l’expiration et la reconnexion, pas seulement la connexion

Réduisez l’intervalle de renégociation dans un profil de test pour que la seconde poignée de main se produise pendant que vous regardez, puis suivez les deux journaux. Confirmez que le jeton est émis à la connexion, présenté au renouvellement de clé et rafraîchi ou réémis selon la durée de vie configurée. Forcez ensuite une expiration de jeton et une reconnexion complète, car un client qui se reconnecte proprement peut encore échouer sur le chemin de renouvellement de clé.

Testez la suppression de compte en dernier. Ce cas vous dit si la politique que vous avez écrite est appliquée ou simplement documentée.

Ne le corrigez pas en désactivant le renouvellement

Mettre l’intervalle de renégociation à zéro des deux côtés supprime le symptôme et la rotation de clés avec lui. Cela cache un problème de réutilisation d’identifiants derrière un changement de politique que personne n’a relu. Gardez le renouvellement et choisissez entre un jeton émis par le serveur et un défi interactif neuf selon qu’un utilisateur est présent.

Une minuterie de nouvelle tentative plus longue ne rend pas un code épuisé de nouveau valide. Elle ne fait que retarder la déconnexion et rendre le journal plus difficile à lire.