Windows が VPN パスワードをファイルサーバーに提示する理由

Windows はトンネルを確立したあと、その存在を一度も聞いたことのないファイルサーバーに同じアカウントを提示することがある。ゲートウェイはログインを受け入れ、共有は受け入れなかった。パスワードを打ち直しても何も変わらない。コンピューター全体の資格情報の保存を無効にすれば解決しそうに見えるが、そうではない。ネイティブの RAS 接続にはプロファイル単位のスイッチがあり、まさにこの意図を表している。

どのアカウントが拒否されたかを特定する

プロンプトを閉じずに読む。ダイアログのサーバー名、ユーザー名の横に表示されたドメイン、トンネル確立の前と後のどちらで要求が出たか——それぞれが違う場所を指している。共有を名指しする失敗と、ホストを名指しする失敗は同じではない。

ID を論じる前に、リソースがそもそも応答するか確認する。ルートの欠落、サーバー名の誤記、共有アクセス許可のないアカウントは三つの異なる症状を生み、Windows が提示した ID に関わるのは最後の一つだけだ。拒否されたアカウントがゲートウェイのアカウントかどうかを確認する。VPN ログインがディレクトリのアカウントではなくゲートウェイが所有するリモートアクセスの ID なら、 ファイルサーバーがそれを認識する理由はない。同じパスワードを打ち直しても同じ拒否が繰り返されるだけだ。この区別が、次の節が自分の状況に当てはまるかを決める。

ひとつのプロファイルで UseRasCredentials を設定する

フィールドは UseRasCredentialsという名前で、値にゼロを設定すると、その接続が自身の RAS 資格情報をネットワーク リソースに提示しなくなる。変更はプロファイル単位に限定される。それが要点だ。文書化された意味は一つだけで、マシン上の他の何にも触れない。

保存された資格情報をネットワーク認証に使わせないセキュリティ ポリシーは逆で、コンピューター上のすべての接続に適用される。ここで使えば、ユーザーが来週開くすべてのリソースの挙動が変わる。だからこの修復の外に置く。 UseRasCredentials も RAS の機能なので、資格情報を独自に扱うサードパーティ クライアントはこれを無視する。そうしたクライアントでは、挙動を変更できるかどうかはベンダーの文書だけが根拠になる。そのクライアントが決して読まないファイルを編集する前に、どのクライアントが接続を所有しているか確認する。

接続を所有する電話帳を編集する

エディターを開く前に、接続を所有する電話帳を見つける。ユーザーが作成した接続はローミング アプリケーション データのパスにあり、すべてのユーザー用に作成した接続はプログラム データのディレクトリの下にある。二つのファイルは独立している。間違ったほうを編集しても何も変わらず、失敗は後から見ても同じに見える。

両方の場所を列挙し、編集するファイルの完全なパスを確認する。間違ったプロファイルの下のファイルは正しく変更しても無視され、二度目の失敗は一度目とまったく同じに見える。

Get-ChildItem "$env:APPDATA\Microsoft\Network\Connections\Pbk"
Get-ChildItem "$env:PROGRAMDATA\Microsoft\Network\Connections\Pbk"
Copy-Item "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk.bak"
Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials"

正確な接続名を持つセクションの内部で、スイッチは一行だ。その値だけを変更し、他のセクションはそのままにする。

UseRasCredentials=1   becomes   UseRasCredentials=0

電話帳のすべての接続に対してファイル全体を置換するのは単一プロファイルの変更ではなく、関係ないトンネルのデバッグ中に数週間後になって表面化する。変更が検証されるまでバックアップをファイルの隣に置いておく。デバイスが管理されている場合は、設定はユーザー プロファイルの下のファイルではなく、所有する展開で変更する。サポートされている Windows のバージョンは VPNv2 構成サービス プロバイダーを通じてプロファイル単位の同等機能を提供しており、そのバージョン要件はプロバイダー全体の要件とは別に確認する必要がある。

新しい試行で検証する

切断し、開いていたセッションを閉じて、もう一度試す。既存のマップ済みドライブや開いたファイル ハンドルは、すでに認証した ID を使い続けられる。だから古いセッションで動くものは変更の証拠にならない。まず編集した値を、それが属するセクションがわかる程度の文脈とともに確認する。

Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials=0" -Context 4,0

そのうえで、リソースが実際に受け取った ID を確認する。正しいアカウントでもアクセスを拒否する共有は承認の問題であり、その答えはファイルサーバー自身のログにある。 この設定の文書化された説明 は、VPN の ID がディレクトリの ID と異なる展開を扱っており、フィールドが自分のクライアントに当てはまると仮定する前に読む価値がある。変更、電話帳のパス、そしてリソースが今見ているアカウントを記録しておく。次にこれに当たる人は同じ混乱から始めるからだ。