Faites tourner un compte VPN local sans perdre ses autorisations

Remplacer un mot de passe VPN qui fonctionne ressemble à une modification de deux lignes, jusqu'à ce que le compte reconstruit revienne avec les autorisations par défaut et que l'unique session d'administration ait disparu. La procédure sûre dépend de l'endroit où l'identifiant est stocké et du protocole qui le consomme, pas de la commande la plus courte. Comparez les deux approches avant de toucher à l'appareil. La rotation sur place conserve l'objet du compte ; la suppression puis la recréation le remplacent, et tout ce qui pointait vers lui s'en va avec lui.

Déterminez quel magasin authentifie réellement la session

Partez du profil de tunnel ou de connexion, pas de la base de données utilisateurs. Le profil nomme une méthode d'authentification et souvent un groupe de serveurs, et si ce groupe pointe vers RADIUS ou TACACS+, le nom d'utilisateur local sur l'équipement n'est que décoration. Lisez la liste d'authentification du profil et le groupe AAA auquel il renvoie avant de planifier quoi que ce soit. Ce n'est que lorsque le profil indique local que le compte de l'équipement compte. Trompez-vous et vous ferez tourner un identifiant que personne n'utilise, tandis que l'entrée réelle de l'annuaire reste exactement telle qu'elle était.

Le même appareil héberge généralement deux populations : les administrateurs qui s'y connectent et les utilisateurs VPN qui terminent un tunnel. Elles peuvent partager un magasin, et il ne faut pas présumer qu'elles le font.

Mise à jour sur place contre suppression et recréation

La rotation sur place modifie un seul attribut d'un objet existant. Le niveau de privilège, l'appartenance aux groupes, les attributs d'autorisation et toute politique qui référence le compte survivent, car rien n'a été supprimé. La suppression puis la recréation reconstruisent l'objet depuis une ligne de commande, si bien que chaque champ que vous n'avez pas répété revient à sa valeur par défaut. Sur un appareil où les attributs par utilisateur portent des affectations de tunnel divisé ou de pool d'adresses, cette différence est tout le risque.

La reconstruction a un usage légitime : lorsque le format stocké lui-même doit changer et que la plateforme n'offre aucune conversion. Même alors, enregistrez d'abord l'entrée existante, car la configuration en cours est le seul inventaire exact de ce que portait le compte. Une copie de cette configuration prise avant le changement vaut mieux qu'un plan de retour arrière écrit de mémoire.

Pourquoi le hachage dont vous disposez n'est peut-être pas le secret dont il a besoin

Les formats de stockage diffèrent d'une manière qui décide de la réponse. Un hachage à sens unique peut vérifier un mot de passe lorsque le serveur le reçoit en clair dans le tunnel, mais une méthode défi-réponse a besoin du secret partagé lui-même pour calculer l'empreinte. Convertir chaque compte au format à sens unique le plus fort peut donc casser CHAP ou MS-CHAP précisément pour les utilisateurs qui en dépendent.

Décidez par protocole, pas par slogan. Là où la méthode exige un secret récupérable, cette exigence est une contrainte de conception et non un oubli à nettoyer.

Des sessions qui survivent à l'identifiant

Changer un identifiant ne met pas fin aux sessions déjà authentifiées. Un pair dont le tunnel est établi continue de fonctionner jusqu'au renouvellement de clé, à la réauthentification ou à une déconnexion explicite.

Planifiez cette partie séparément, et planifiez-la avant le changement. Si l'identifiant a fuité, laisser des sessions actives en cours annule la rotation. S'il a simplement expiré, forcer chaque pair hors ligne est une panne dont vous n'aviez pas besoin. Gardez un second chemin d'administration ouvert pendant votre travail, de préférence un qui ne dépend pas du compte en cours de modification, car le mode de défaillance ici supprime votre accès précisément au moment où vous en avez besoin. Vérifiez ensuite une nouvelle connexion et les ressources qu'elle peut atteindre.

Prouvez que les autorisations ont survécu

Connectez-vous en tant qu'utilisateur ayant fait l'objet de la rotation et vérifiez ce que la session accorde, pas seulement qu'elle s'est ouverte. Atteignez une ressource qui exige l'autorisation que le compte est censé porter, et essayez-en une à laquelle il ne devrait pas accéder. Une connexion réussie avec un accès réduit ou élargi est un changement raté.

Comparez les attributs d'autorisation de la configuration en cours avec la copie que vous avez prise au début. Regardez l'appartenance aux groupes, le pool d'adresses, les réglages DNS et de tunnel divisé, et tout objet de politique qui nommait le compte. Mettez ensuite à jour la trace de l'endroit où vit cet identifiant, car la prochaine rotation part de cette note. Une rotation que personne ne peut reproduire à partir de la documentation n'a été survécue qu'une fois.