SSTP はまずサーバーを認証し、その後にユーザーを認証する

SSTP クライアントは TLS を完了しても、その一秒後にユーザーを拒否することがあります。この順序は不具合ではなく、まずトランスポートの安全性、次にユーザー認証というプロトコルスタックの仕様です。二つの段階は異なるメッセージで失敗するため、修正も別々に必要です。どの段階がエラーを出したかを読むことが、診断の大部分です。

信頼された証明書が証明するのはエンドポイントであり、アカウントについては何も語りません。

TLS ハンドシェイクが確立するもの

クライアントはサーバーが提示した証明書を、自身のトラストストア、要求されたホスト名、有効期間、およびプラットフォームが適用する追加ポリシーに対して検証します。これにより、意図したエンドポイントへの接続が保護されます。特定のアカウントが有効で、期限切れでなく、リモートアクセスを許可されていることは証明しません。それらは後から別のコンポーネントが問い合わせる別個の質問です。

だからこそ、ログインプロンプトに到達するために証明書チェックを外すのは誤った修理です。検証できない接続でログインプロンプトが得られるだけです。証明書エラーはホスト名、時計、証明書チェーン、信頼設定のいずれかに属します。

SSTP と PPP が上に追加するもの

SSTP は HTTPS 上で動作し、接続の周囲に独自の制御交換を備えつつ内部に PPP を運びます。次に PPP がリンク段階と認証段階を実行し、認証方式はサーバーのポリシーとクライアントの能力に依存します。PAP、CHAP、MS-CHAPv2、EAP はいずれも PPP の認証オプションで、性質は大きく異なります。VPN のユーザー確認はその PPP 段階であり、その下の TLS 層ではありません。

したがってユーザー拒否は、資格情報、アカウント制限、方式の不一致のいずれかを意味し得ます。

サーバー側の理由は、プロファイル内のすべての秘密をリセットするよりはるかに有用です。アカウント無効化のイベントと方式ネゴシエーションの失敗は、クライアントでは似て見え、サーバーでは共通点がありません。

エラーを段階に紐づける

接続が TLS に達するか、次に SSTP の HTTP 交換、次に PPP 段階に達するかを確認します。再試行の間でログのタイムスタンプを揃え、以前の失敗を後の成功と取り違えないようにします。一つのウィンドウで二回の試行を記録するクライアントは、そうしないと到達した最後の段階で失敗したように見えます。最後の行ではなく、最初の関連するエラーを読んでください。

同じ整合はサーバー側でも重要で、認証記録とトランスポートログは別々の時計を持つ別々のファイルであることがよくあります。二分のずれで、明白な原因が不可能に見えてしまいます。

ログイン後も認可は別のまま

ログインの成功はすべてのプライベートリソースを許可しません。到達可能かはルートが決め、名前解決は DNS が決め、各サービスは依然として独自の権限を適用します。接続済みと表示されるセッションはトンネルについての表明であり、ファイル共有についてではありません。ユーザーが接続できて一つのホストに到達できないとき、トンネル段階はすでに終わっています。

これはハンドシェイクが示したのと同じ階層を、一段上から見たものです。

アカウント回復は、明示的なユーザー拒否に応じてトランスポート設定を変えるのではなく、運営者がサポートする手順に従ってください。無効化されたアカウントを直すためにトランスポートを変えるのは、無関係な理由でアカウントが再有効化されたときにうまくいったように見える種類の修理です。