Reconnecter un VPN Windows sans mettre le mot de passe dans la tâche
Une tâche rasdial fonctionne jusqu’à ce que vous lisiez ses arguments. Comparez les trois conceptions qui évitent un secret en clair, et choisissez selon la prise en charge du serveur et le mode d’ouverture de session.
Chaque recette de reconnexion sans surveillance finit par poser la même question : où vit le mot de passe. La réponse populaire est l’action de la tâche elle-même, qui est aussi le pire endroit pour lui. Deux autres conceptions existent. Celle qui convient dépend de si la machine peut s’authentifier sans personne et de si le serveur accepte les certificats.
Ce qu’une action de tâche laisse lisible
Les arguments d’une tâche planifiée font partie de sa définition, et non d’une valeur d’exécution cachée. Quiconque peut lire la tâche, restaurer une sauvegarde ou exporter son XML voit la chaîne exactement telle que vous l’avez saisie. Pendant une exécution, la même chaîne apparaît dans la liste des processus. Un agent de surveillance peut la copier dans un journal que vous ne consultez jamais.
schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list
Vérifiez avant de supposer le contraire. La première commande imprime la définition complète, y compris l’action et ses arguments. La seconde montre quels identifiants le compte actuel a mis en cache, ce qui compte pour les conceptions alternatives ci-dessous. Si le mot de passe apparaît dans le XML de la tâche, sa rotation n’est que la moitié de la réparation, car la tâche conserve encore l’ancienne valeur.
Ce qu’une clé pré-partagée stockée achète vraiment
Add-VpnConnection -L2tpPsk écrit la clé dans l’entrée de carnet d’adresses de la connexion plutôt que dans une tâche. C’est une surface d’exposition plus petite qu’une action de tâche. Cela reste un secret récupérable, car un administrateur de la machine peut lire le carnet d’adresses.
Pour une liaison de laboratoire entre deux machines que vous contrôlez, cet échange peut être acceptable. Pour un identifiant utilisateur sur un point de terminaison partagé, il ne l’est pas. L’appeler stockage chiffré ne change pas qui peut le lire. Le carnet d’adresses est un fichier de configuration. Planifiez pour la personne qui peut l’ouvrir, pas seulement pour celle qui peut se connecter en tant qu’utilisateur.
Les identifiants Winlogon suppriment le secret et ajoutent une dépendance
-UseWinlogonCredential prend un autre chemin. La connexion s’authentifie avec MSCHAPv2 contre les identifiants de l’utilisateur connecté. Rien de supplémentaire n’est stocké pour ce compte.
La dépendance qu’il ajoute est importante. Il doit y avoir une ouverture de session interactive à emprunter, ce qui exclut un compte de service et une tâche avant ouverture de session. La connexion hérite aussi de tout ce que les identifiants de cet utilisateur peuvent atteindre sur le serveur. Lisez le commutateur comme une déclaration sur l’origine de l’identifiant, non comme un réglage de sécurité. Il change la source, et rien à la façon dont le serveur autorise la session ensuite.
L’authentification par certificat passe à l’échelle parce que rien n’est stocké
Là où le serveur prend en charge EAP-TLS, un certificat de machine élimine entièrement le secret partagé, et la révocation se fait au niveau du certificat. Une tâche exécutée en tant que SYSTEM peut présenter ce certificat sans ouverture de session interactive. Confirmez que le serveur accepte l’authentification par certificat avant de bâtir dessus. Une conception qui dépend d’une méthode non prise en charge est un plan plutôt qu’une solution. Décidez ensuite où vit la clé privée : le magasin de la machine pour une identité d’appareil, le magasin de l’utilisateur pour une personne.
Là où un nom d’utilisateur et un mot de passe ne peuvent être évités, stockez-les dans Credential Manager en les limitant au compte propre de la tâche. Laissez le client les y lire plutôt que dans un argument. Un secret que la tâche peut récupérer sans l’imprimer est un problème plus petit qu’un secret écrit dans sa définition.
Examinez les artefacts avant la prochaine rotation
Regardez ce qui est stocké plutôt que ce que vous vouliez. Vérifiez le carnet d’adresses par utilisateur, la copie pour tous les utilisateurs, le XML de la tâche et tout script qui appelle la commande de numérotation. Confirmez ensuite que le certificat ou l’identifiant mis en cache est limité au compte utilisé par la tâche, car un identifiant stocké pour votre compte interactif est invisible pour SYSTEM.
Consignez la méthode d’authentification et le compte dans les notes de la tâche elle-même. La prochaine personne à modifier la stratégie du serveur doit savoir quelle conception est en jeu. Cette réponse n’est pas visible à partir du seul comportement de reconnexion. Écrivez-la là où la prochaine rotation regardera en premier.