SSTP authenticeert eerst de server en daarna de gebruiker

Een SSTP-client kan TLS voltooien en de gebruiker een seconde later alsnog afwijzen. Die volgorde is geen bug, het is de protocolstack: eerst transportbeveiliging, daarna gebruikerauthenticatie. Omdat de twee fasen met verschillende berichten mislukken, hebben ze ook verschillende oplossingen nodig. Lezen welke fase de fout veroorzaakte, is het grootste deel van de diagnose.

Een vertrouwd certificaat bewijst het eindpunt; over het account zegt het niets.

Wat de TLS-handshake vaststelt

De client valideert het certificaat dat de server presenteert tegen zijn truststore, de gevraagde hostnaam, het geldigheidsvenster en elk extra beleid dat het platform toepast. Dat beschermt de verbinding met het beoogde eindpunt. Het bewijst niet dat een bepaald account is ingeschakeld, niet verlopen of toegestaan voor externe toegang. Dat zijn afzonderlijke vragen die later door een andere component worden gesteld.

Daarom is het verwijderen van certificaatcontroles om bij de inlogprompt te komen de verkeerde reparatie. Je krijgt een inlogprompt op een verbinding die je niet kunt verifiëren. Een certificaatfout hoort bij de hostnaam, de klok, de keten of de vertrouwensconfiguratie.

Wat SSTP en PPP er bovenop toevoegen

SSTP draait over HTTPS en draagt PPP erin, met zijn eigen controle-uitwisseling rond de verbinding. PPP voert dan zijn link- en authenticatiefasen uit, en de authenticatiemethode hangt af van het serverbeleid en de mogelijkheden van de client. PAP, CHAP, MS-CHAPv2 en EAP zijn allemaal PPP-authenticatieopties met heel verschillende eigenschappen. De gebruikercontrole van de VPN is die PPP-fase, niet de TLS-laag eronder.

Een gebruikersafwijzing kan dus inloggegevens, een accountbeperking of een methodemismatch betekenen.

De reden aan de serverkant is veel nuttiger dan elk geheim in het profiel resetten. Een gebeurtenis van een uitgeschakeld account en een mislukte methodeonderhandeling lijken op de client op elkaar en hebben op de server niets gemeen.

Koppel de fout aan de fase

Controleer of de verbinding TLS bereikt, dan de SSTP HTTP-uitwisseling, dan de PPP-fase. Houd logtijdstempels over nieuwe pogingen heen uitgelijnd, zodat een eerdere fout niet met een later succes wordt verward. Een client die twee pogingen in één venster logt, lijkt anders te zijn mislukt in de laatste fase die hij bereikte. Lees de eerste relevante fout, niet de laatste regel.

Dezelfde uitlijning is belangrijk aan de serverkant, waar het authenticatierecord en het transportlog vaak aparte bestanden met aparte klokken zijn. Twee minuten scheefstand is genoeg om een duidelijke oorzaak onmogelijk te laten lijken.

Na het inloggen blijft autorisatie apart

Een geslaagde login verleent niet elke privébron. Routes bepalen wat bereikbaar is, DNS bepaalt wat wordt omgezet, en elke dienst past nog steeds zijn eigen rechten toe. Een sessie die als verbonden wordt getoond, is een uitspraak over de tunnel, niet over de bestandsshare. Wanneer een gebruiker kan verbinden en één host niet kan bereiken, is de tunnelfase al afgerond.

Dat is dezelfde gelaagdheid die de handshake liet zien, één niveau hoger.

Houd accountherstel binnen het door de operator ondersteunde proces in plaats van transportinstellingen te wijzigen als reactie op een expliciete gebruikersweigering. De transportlaag wijzigen om een uitgeschakeld account te repareren is het soort reparatie dat lijkt te werken wanneer het account om een ongerelateerde reden opnieuw wordt ingeschakeld.