Erreur 691 VPN sous Windows : quel contrôle a réellement échoué ?

Windows refuse un mot de passe qu’il a accepté ailleurs une minute plus tôt, si bien que le compte semble cassé alors que la tentative n’a jamais été évaluée. L’erreur 691 signifie que la connexion a été refusée pendant l’authentification, et le client affiche le même texte que le secret soit faux, que le nom de compte se résolve en une identité inattendue ou qu’une stratégie côté serveur refuse la connexion. Trois réparations différentes partagent un seul message, c’est pourquoi une réinitialisation aide parfois et parfois ne change absolument rien. Commencez par la partie que vous pouvez inspecter seul : la chaîne exacte soumise par le client et le magasin d’identifiants d’où elle provient. Demandez ensuite au serveur quelle décision il a enregistrée, car la boîte de dialogue est un refus et non un diagnostic.

Trois façons d’être refusé, une seule boîte de dialogue

Un mauvais secret n’est que la première façon d’atteindre cette boîte de dialogue. Le nom de compte peut se résoudre en une identité que vous n’aviez pas prévue, le compte peut ne disposer d’aucune autorisation d’accès à distance, ou une condition côté serveur peut refuser la connexion après acceptation du mot de passe. Chacun de ces cas produit le même texte côté client, et chacun a sa propre réparation.

C’est pourquoi une réinitialisation semble fonctionner le lundi et ne fait rien le mardi. Lisez la boîte de dialogue comme un refus et non comme un diagnostic, et notez le nom du profil ainsi que l’heure locale de l’échec avant de toucher au compte.

Les trois catégories échouent aussi à des couches différentes. Un mauvais secret fait échouer la preuve d’identité, une mauvaise forme de compte fait échouer la recherche, et une condition de stratégie fait échouer l’autorisation une fois l’identité prouvée. Seule la première se répare en changeant le mot de passe. Les deux autres exigent quelqu’un ayant accès au registre des décisions du serveur, c’est pourquoi l’étape suivante est une demande d’informations et non une nouvelle réinitialisation.

Ce que le client a réellement envoyé

Confirmez le format de compte accepté auprès de celui qui exploite la passerelle, car un nom d’utilisateur nu, un nom qualifié par domaine et un nom principal d’utilisateur peuvent se résoudre en contextes de compte différents. Un seul d’entre eux est peut-être l’identité qui détient l’autorisation. Demandez quel format la passerelle attend avant la première tentative plutôt qu’après la cinquième, et vérifiez si le client réutilise un identifiant stocké au lieu de celui que vous avez saisi.

Deux requêtes en lecture seule sur la machine Windows montrent le profil et tout identifiant mis en cache qui pourrait l’emporter sur la boîte de dialogue. Aucune des deux n’appelle le serveur :

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

Traitez le mot de passe comme une donnée et non comme un texte copié depuis un document. Une valeur passée par un script peut porter des caractères d’échappement qui n’ont jamais fait partie du secret, et un export de configuration l’a peut-être mise entre guillemets. Supprimer chaque caractère spécial pour la faire tenir est une modification différente de la recherche de la valeur réelle, établissez donc d’abord la valeur réelle.

Obtenez la décision de stratégie, pas une réinitialisation

Dans un déploiement d’accès à distance qui utilise un serveur de stratégie réseau, deux décisions s’exécutent successivement. L’authentification détermine quel compte demande, et l’autorisation décide si ce compte peut se connecter du tout. Les conditions et contraintes de stratégie sont évaluées selon leurs propres critères, un secret correct ne règle donc que la première moitié de la question. Le nom de la stratégie dans l’événement du serveur indique quelle décision s’est réellement exécutée.

Envoyez à l’administrateur le nom du profil, le compte tenté et l’horodatage. Demandez l’enregistrement de décision correspondant et son motif plutôt qu’une nouvelle réinitialisation de mot de passe, et demandez le nom de la stratégie que porte l’événement. La référence des codes d’erreur d’accès à distance de Microsoft classe le 691 parmi les échecs d’identifiants et d’authentification, et c’est précisément pourquoi la boîte de dialogue ne peut pas séparer les trois cas.

Convertir un compte en autorisation inconditionnelle transforme une décision d’autorisation en exception permanente. Cela supprime aussi la condition qui faisait un travail utile, et la prochaine personne à examiner la stratégie ne saura pas pourquoi elle a changé. Demandez plutôt au propriétaire de confirmer la stratégie voulue, afin que l’acceptation reste délibérée.

Réessayez une fois, puis comparez

Répétez le même profil après l’unique correction que vous avez identifiée. Si l’accès est accepté et que une ressource interne échoue encore, l’échec s’est déplacé vers une autre couche et ne dit plus rien du mot de passe. C’est le profil inchangé qui rend cette comparaison significative.

Résistez à la tentation de désactiver une famille d’adresses ou d’activer un traçage détaillé avant que le refus ait été expliqué. Le traçage produit du volume et non une décision, et le premier résultat utile reste le composant qui a refusé la tentative et le motif qu’il a enregistré. Une fois cela connu, la nouvelle tentative confirme la réparation ou produit un symptôme nouveau et plus étroit.