Windows VPN エラー 691：どのチェックが実際に失敗したのか

Windows は、一分前に別の場所で受け入れたパスワードを拒否するため、試行が評価されていないのにアカウントが壊れているように見えます。エラー 691 は認証中に接続が拒否されたことを意味し、秘密が間違っていた場合、アカウント名が想定外の ID に解決された場合、サーバー側のポリシーが接続を拒否した場合のいずれでも、クライアントは同じ文言を表示します。三つの異なる修復が一つのメッセージを共有しているため、リセットが効くこともあれば、まったく何も変わらないこともあります。まず、自分だけで調べられる部分、つまりクライアントが送信した正確な文字列と、それを取り出した資格情報ストアから始めてください。次に、ダイアログは拒否であって診断ではないため、サーバーにどの判断を記録したかを尋ねてください。

拒否される三つの経路、一つのダイアログ

間違った秘密は、このダイアログに至る最初の経路にすぎません。アカウント名が意図しない ID に解決されることも、アカウントにダイヤルインのアクセス許可がないことも、パスワードが受け入れられた後にサーバー側の条件が接続を拒否することもあります。どれも同じクライアント文言を生成し、それぞれに独自の修復があります。

だからリセットは月曜日には効いたように見え、火曜日には何もしないのです。 ダイアログを診断ではなく拒否として読むアカウントに触れる前に、プロファイル名と障害が起きた現地時刻を記録してください。

三つの分類は、失敗する層も異なります。間違った秘密は ID の証明で失敗し、間違ったアカウント形式は検索で失敗し、ポリシーの条件は ID が証明された後の承認で失敗します。パスワードを変更して修復できるのは最初の一つだけです。残りの二つは、サーバーの判断記録にアクセスできる人の助けが必要であり、だからこそ次の手順は別のリセットではなく情報の要求です。

クライアントが実際に送信したもの

受け入れられるアカウント形式をゲートウェイの運用者に確認してください。裸のユーザー名、ドメイン修飾名、ユーザー プリンシパル名は、それぞれ異なるアカウント コンテキストに解決される可能性があり、そのうち許可を持つ ID は一つだけかもしれません。五回目の後ではなく最初の試行の前に、ゲートウェイがどの形式を期待するかを尋ね、クライアントが入力した資格情報ではなく保存された資格情報を再利用していないか確認してください。

Windows マシンでの二つの読み取り専用クエリは、プロファイルと、ダイアログを覆い隠す可能性のあるキャッシュされた資格情報を示しますが、どちらもサーバーにダイヤルしません。

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

パスワードは、ドキュメントからコピーしたテキストではなくデータとして扱ってください。スクリプトを通った値には、秘密の一部ではなかったエスケープ文字が含まれていることがあり、構成のエクスポートが引用符で囲んでいることもあります。合うようにすべての特殊文字を削除することは実際の値を見つけることとは別の変更なので、まず実際の値を確定してください。

リセットではなくポリシーの判断を入手する

ネットワーク ポリシー サーバーを使うリモート アクセスの展開では、二つの判断が順に実行されます。認証はどのアカウントが要求しているかを確定し、承認はそのアカウントがそもそも接続できるかを決めます。ポリシーの条件と制約は独自の基準で評価されるため、正しい秘密は問題の前半だけを解決します。サーバー イベントのポリシー名が、実際に実行された判断を示します。

管理者にプロファイル名、試行したアカウント、タイムスタンプを送ってください。別のパスワード リセットではなく、対応する判断記録とその理由を求め、イベントが持つポリシー名も尋ねてください。Microsoft のリモート アクセス エラー コードのリファレンスは、資格情報と認証の失敗の中に 691 を挙げており、まさにそのためダイアログは三つのケースを区別できません。

アカウントを無条件の許可に変えると、承認の判断が恒久的な例外になります。また、役に立つ働きをしていた条件を取り除くことになり、次にポリシーをレビューする人は、なぜ変わったのか分かりません。代わりに所有者に意図したポリシーを確認してもらい、受け入れが意図的なものにとどまるようにしてください。

もう一度だけ再試行し、それから比較する

特定した一つの修正の後に、同じプロファイルを再試行してください。アクセスが受け入れられ、内部リソースがまだ失敗する場合、障害は別の層に移っており、パスワードについてはもう何も語っていません。プロファイルを変えないことが、その比較を意味あるものにします。

拒否が説明される前に、アドレス ファミリを無効にしたり詳細トレースを有効にしたりする誘惑に抵抗してください。トレースが生むのは量であって判断ではなく、最初の有用な結果は、試行を拒否したコンポーネントとそれが記録した理由のままです。それが分かれば、再試行は修復を確認するか、新しくより狭い症状を生み出します。