SSTP authentifiziert zuerst den Server und erst danach den Benutzer

Ein SSTP-Client kann TLS abschließen und den Benutzer eine Sekunde später trotzdem ablehnen. Diese Reihenfolge ist kein Fehler, sondern der Protokollstapel: zuerst Transportsicherheit, danach Benutzerauthentifizierung. Da die beiden Stufen mit unterschiedlichen Meldungen fehlschlagen, brauchen sie auch unterschiedliche Korrekturen. Zu lesen, welche Stufe den Fehler erzeugt hat, ist der größte Teil der Diagnose.

Ein vertrauenswürdiges Zertifikat beweist den Endpunkt; über das Konto sagt es nichts.

Was der TLS-Handshake feststellt

Der Client prüft das vom Server vorgelegte Zertifikat gegen seinen Trust Store, den angefragten Hostnamen, das Gültigkeitsfenster und jede zusätzliche Richtlinie, die die Plattform anwendet. Das schützt die Verbindung zum vorgesehenen Endpunkt. Es beweist nicht, dass ein bestimmtes Konto aktiviert, nicht abgelaufen oder für den Fernzugriff zugelassen ist. Das sind getrennte Fragen, die später von einer anderen Komponente gestellt werden.

Deshalb ist es die falsche Reparatur, Zertifikatsprüfungen zu entfernen, um zur Anmeldeaufforderung zu gelangen. Sie erhalten eine Anmeldeaufforderung auf einer Verbindung, die Sie nicht verifizieren können. Ein Zertifikatsfehler gehört zum Hostnamen, zur Uhr, zur Kette oder zur Vertrauenskonfiguration.

Was SSTP und PPP obendrauf hinzufügen

SSTP läuft über HTTPS und trägt PPP in sich, mit einem eigenen Kontrollaustausch um die Verbindung herum. PPP führt dann seine Link- und Authentifizierungsphasen aus, und die Authentifizierungsmethode hängt von der Serverrichtlinie und den Clientfähigkeiten ab. PAP, CHAP, MS-CHAPv2 und EAP sind allesamt PPP-Authentifizierungsoptionen mit sehr unterschiedlichen Eigenschaften. Die Benutzerprüfung des VPN ist diese PPP-Phase, nicht die TLS-Schicht darunter.

Eine Benutzerablehnung kann daher Anmeldedaten, eine Kontoeinschränkung oder eine Methodenabweichung bedeuten.

Der Grund auf der Serverseite ist weitaus nützlicher als das Zurücksetzen jedes Geheimnisses im Profil. Ein Ereignis eines deaktivierten Kontos und ein fehlgeschlagenes Methodenaushandeln sehen auf dem Client ähnlich aus und haben auf dem Server nichts gemeinsam.

Fehler der Stufe zuordnen

Prüfen Sie, ob die Verbindung TLS erreicht, dann den SSTP-HTTP-Austausch, dann die PPP-Phase. Halten Sie die Zeitstempel der Protokolle über Wiederholungsversuche hinweg ausgerichtet, damit ein früherer Fehler nicht mit einem späteren Erfolg verwechselt wird. Ein Client, der zwei Versuche in einem Fenster protokolliert, wirkt sonst so, als sei er in der zuletzt erreichten Stufe gescheitert. Lesen Sie den ersten relevanten Fehler, nicht die letzte Zeile.

Dieselbe Ausrichtung zählt auf der Serverseite, wo der Authentifizierungsdatensatz und das Transportprotokoll oft getrennte Dateien mit getrennten Uhren sind. Zwei Minuten Abweichung genügen, um eine offensichtliche Ursache unmöglich aussehen zu lassen.

Nach dem Login bleibt die Autorisierung getrennt

Ein erfolgreicher Login gewährt nicht jede private Ressource. Routen bestimmen, was erreichbar ist, DNS bestimmt, was aufgelöst wird, und jeder Dienst wendet weiterhin seine eigenen Berechtigungen an. Eine Sitzung, die „verbunden“ anzeigt, ist eine Aussage über den Tunnel, nicht über die Dateifreigabe. Wenn ein Benutzer sich verbinden kann und einen Host nicht erreicht, ist die Tunnelphase bereits abgeschlossen.

Das ist dieselbe Schichtung, die der Handshake zeigte, eine Ebene höher.

Behalten Sie die Kontowiederherstellung beim unterstützten Verfahren des Betreibers, statt Transporteinstellungen als Reaktion auf eine ausdrückliche Benutzerablehnung zu ändern. Den Transport zu ändern, um ein deaktiviertes Konto zu reparieren, ist die Art von Reparatur, die zu funktionieren scheint, wenn das Konto aus einem unabhängigen Grund wieder aktiviert wird.