Protected Users のノート PC がサインイン前に VPN を必要とする理由

ノート PC、使えるアカウント、ホテルのネットワークがそろうと、何度やり直しても破れないサインインのループが生まれます。アカウントは Protected Users に入っており、これが Windows に、ユーザーをオフラインで認証するために必要な検証子を保存させません。「先にサインインし、後からトンネルを接続する」形の計画は順序が逆であり、保護は約束どおりに動作しています。以下は、サポート対象の Windows ホスト上の従来の Active Directory アカウントを前提とします。

保護が実際に取り除くもの

通常、Windows は検証子をキャッシュし、ドメイン コントローラーに到達できない間もドメイン アカウントでサインインできるようにします。Protected Users はこれをアカウントに対してブロックするため、オフラインのドメイン サインインは不確実になるのではなく、可能性として消えます。

これはよくある古いキャッシュの問題ではなく、いつもの対処は当てはまりません。オンラインでのサインインを繰り返すこと、パスワードをもう一度変更すること、キャッシュされたログオン数を増やすことは、この機能を復元しません。これらの行為はいずれも、ポリシーが保存を拒む検証子を作らないからです。アカウントは設計どおりに動いており、その設計は Windows が要求する時点でネットワークがあることを前提にしています。症状をキャッシュの不具合として扱うと、壊れてもいないプロファイルを作り直すことになります。

トンネルがデスクトップより前に存在しなければならない理由

デバイスは、Windows が要求した瞬間、つまりどのユーザー セッションも存在しない前に、ドメイン認証へ到達しなければなりません。デスクトップが表示されてから起動する VPN クライアントでは、新しいサインインが決して来ない経路を待ち続けます。この依存はマシンに属するもので、まだサインインしていないユーザーに属するものではありません。

エンドポイントと ID の担当者と合意した、サポート対象のサインイン前の仕組みを使ってください。コンピューター証明書で認証する Always On VPN のデバイス トンネルは、管理対象デバイスがその展開の前提条件を満たす場合に適します。ベンダーがサポートするサインイン画面の統合も選択肢です。自動トリガー付きの通常のユーザー プロファイルはどちらでもありません。クライアント画面でどれほど似て見えても同じではありません。

その経路に必要なのは、ドメインの名前解決、到達可能なドメイン コントローラー、アカウントが使える認証プロトコルであり、「接続済み」の表示はそのどれも提供しません。そのルートとフィルターは ID サービスだけを運び、不要なものは運ぶべきではありません。このプレフィックス一覧こそ、誰かがサインインする前に盗まれたノート PC が得る表面だからです。ユーザー トンネルで決めたスプリット トンネルの判断はデバイス トンネルには引き継がれないため、二つを別々に確認してください。

到達可能性は認証の互換性ではない

トンネルがパケットを完全に運んでいても、ドメイン認証は失敗することがあります。試みられている仕組みが、アカウントに使えないものだからです。グループの制限を適用するドメインでは、メンバーに NTLM は使えず、Kerberos には AES 互換のアカウントと構成が必要です。パケットの経路はそのどちらも修復できません。だからドメイン コントローラーへのきれいな ping は、サインインが成功する証拠になりません。

二つの資格情報システムが関与することもあります。VPN は ID プロバイダーに対して認証し、Windows は別にドメイン ログオンを必要とすることがあり、前者の受け入れは後者について何も語りません。「VPN が接続した」と「ユーザーがサインインした」は別の観察であり、一方を直しても他方を意味しません。

認証の証拠を読む

同じ試行について、片側だけでなくクライアントとドメイン コントローラーの両方からイベントを集めてください。Protected Users のログは Applications and Services Logs\Microsoft\Windows\Authentication の下にあり、何かを記録する前に管理者がログを有効にする必要があるかもしれません。タイムスタンプをトンネル自身の接続ログと突き合わせてください。順序の誤りはどちらの側から見ても資格情報の障害のように見えるからです。

下の最初のコマンドは、デバイスが公開するすべての認証ログを一覧するので、ブログ記事が名指ししたものではなく実在するものを読みます。二番目は名前がわかった後で最近のエントリを読みます。認証パッケージ、アカウント、失敗条件を探してください。ネットワーク経路の欠如と拒否された仕組みは異なる証拠を残し、VPN の問題であるのはそのうち一方だけです。試行の後にトンネルが上がったのなら、それらのエントリが何を言おうと順序が誤っています。

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

コールド ブートから境界を証明する

サインアウトした状態、または起動直後の状態で、制限付きアカウントを使ってテストを実行し、特権ユーザー向けに何かを変更する前に承認済みの復旧経路を開いておいてください。すでに動作中のデスクトップでのテストは、重要なコード経路をまったく通らないため、次の再起動まで持った修正という報告の多くはこれで説明できます。そのうえで、四つの手順をこの順に進めてください。

1. 誰かがサインインする前にデバイスがドメイン コントローラーを見つけられることを、nltest /dsgetdc:corp.example.com で確認します。
2. ドメイン サインインを試み、その後 klist でチケットが取得できたかどうかを確かめます。
3. デバイスが記録する認証ログを上の二つのコマンドで読み、パッケージと失敗条件を記録します。
4. 承認済みの復旧資格情報がサインイン画面から今も機能することを確認します。境界テストが失敗したときの唯一の戻り道だからです。

提供された資格情報でファイル共有を開いても、オフラインの対話型ログオンは作成されないため、上のどの手順の代わりにもなりません。組織が本当に接続なしのサインインを必要とするなら、答えは意図的に選ばれた互換性のあるアカウントとエンドポイントの設計です。アカウントをグループから外すこと、あるいはすべてのノート PC に制限なしの緊急ログインを一つ残すことは、VPN の変更が代わりに決められる ID ポリシーの判断ではありません。

Protected Users のドキュメント は、検証子の動作と、この設計が依存するドメインの制限の両方を説明しています。誰かが旅立つ前に復旧プロセスを計画してください。コールド ブートのテストは、それが実際に試される唯一の場所だからです。