SSTP authentifie d’abord le serveur, puis l’utilisateur

Un client SSTP peut terminer TLS puis rejeter l’utilisateur une seconde plus tard. Cette séquence n’est pas un défaut, c’est la pile de protocoles : d’abord la sécurité du transport, ensuite l’authentification de l’utilisateur. Comme les deux étapes échouent avec des messages différents, elles demandent aussi des corrections différentes. Lire quelle étape a produit l’erreur, c’est l’essentiel du diagnostic.

Un certificat de confiance prouve le point de terminaison ; il ne dit rien du compte.

Ce que la poignée de main TLS établit

Le client valide le certificat présenté par le serveur par rapport à son magasin de confiance, au nom d’hôte demandé, à la fenêtre de validité et à toute politique supplémentaire appliquée par la plateforme. Cela protège la connexion vers le point de terminaison prévu. Cela ne prouve pas qu’un compte donné est activé, non expiré ou autorisé à utiliser l’accès à distance. Ce sont des questions distinctes posées plus tard par un autre composant.

C’est pourquoi supprimer les contrôles de certificat pour atteindre l’invite de connexion est la mauvaise réparation. Vous obtenez une invite de connexion sur une connexion que vous ne pouvez pas vérifier. Une erreur de certificat relève du nom d’hôte, de l’horloge, de la chaîne ou de la configuration de confiance.

Ce que SSTP et PPP ajoutent par-dessus

SSTP fonctionne sur HTTPS et transporte PPP à l’intérieur, avec son propre échange de contrôle autour de la connexion. PPP exécute ensuite ses phases de liaison et d’authentification, et la méthode d’authentification dépend de la politique du serveur et des capacités du client. PAP, CHAP, MS-CHAPv2 et EAP sont toutes des options d’authentification PPP aux propriétés très différentes. La vérification de l’utilisateur par le VPN est cette phase PPP, pas la couche TLS en dessous.

Un rejet d’utilisateur peut donc signifier des identifiants, une restriction de compte ou une inadéquation de méthode.

La raison côté serveur est bien plus utile que de réinitialiser chaque secret du profil. Un événement de compte désactivé et un échec de négociation de méthode se ressemblent chez le client et n’ont rien en commun sur le serveur.

Faites correspondre l’erreur à l’étape

Vérifiez si la connexion atteint TLS, puis l’échange HTTP de SSTP, puis la phase PPP. Gardez les horodatages des journaux alignés entre les tentatives afin qu’un échec antérieur ne soit pas confondu avec un succès ultérieur. Un client qui journalise deux tentatives dans une fenêtre semblera sinon avoir échoué à la dernière étape atteinte. Lisez la première erreur pertinente, pas la dernière ligne.

Le même alignement compte côté serveur, où l’enregistrement d’authentification et le journal de transport sont souvent des fichiers distincts avec des horloges distinctes. Deux minutes de décalage suffisent à rendre une cause évidente impossible.

Après la connexion, l’autorisation reste distincte

Une connexion réussie n’accorde pas chaque ressource privée. Les routes déterminent ce qui est joignable, le DNS détermine ce qui se résout, et chaque service applique encore ses propres permissions. Une session affichée comme connectée est une affirmation sur le tunnel, pas sur le partage de fichiers. Quand un utilisateur peut se connecter et ne peut pas atteindre un hôte, la phase du tunnel est déjà terminée.

C’est le même empilement que celui montré par la poignée de main, un niveau au-dessus.

Gardez la récupération du compte dans le processus pris en charge par l’opérateur plutôt que de modifier les paramètres de transport en réponse à un refus explicite de l’utilisateur. Modifier le transport pour réparer un compte désactivé est le genre de réparation qui semble fonctionner lorsque le compte est réactivé pour une raison sans rapport.