誰がダイヤルインできるのか？VPNアクセス前のmsNPAllowDialin監査

パスワードは正しく、アカウントはVPNグループに属しているのに、接続はどのポリシーにも触れていないメッセージとともに拒否される。Windowsのリモートアクセスサーバーでこれが起きたとき、私が最初に見るのはNPSの規則ではなく、誰も開かないActive Directoryの一つの属性である：msNPAllowDialin、つまりDial-inタブの背後にある値である。これには三つの状態があり、三つ目は静かに判断を別の場所へ渡す。ほとんどの場合、誰も意図的に変更していない。アカウントがテンプレートから複製されたか、何年も前に明示的な拒否を書き込んだスクリプトによって作成され、その後見直されていないのだ。

拒否はポリシーが読まれる前に起こりうる

Windowsは承認の判断を組み立てる最中にアカウントのダイヤルイン許可を確認するため、明示的な拒否は会話を早々に終わらせる。クライアントに見えるのは一般的な認証エラーで、証明書の交換が完了した後に出ることもあり、だからこそ人々は問題ではなかった資格情報のテストに半日を費やす。

逆のケースも同じくらい混乱する。フラグが一度も設定されていないアカウントが、ポリシーが許可していたために接続できることがあり、その後、誰かが無関係な理由でNPSの規則を編集すると同じアカウントが接続できなくなる。どちらの出来事も外から見るとダイヤルイン許可の変更には見えない。

三つの状態、そして三つ目は見えない

TRUE はダイヤルインを許可し、FALSE は拒否し、NULL はアカウントがリモートアクセスポリシーまたはNPS承認から答えを継承することを意味する。GUIはその第三の状態を"Control access through NPS Network Policy"と表示し、判断というより未チェックのチェックボックスのように読める。

だからコンソールから許可されたユーザーを数えてもほとんど何も分からない。継承されたアカウントは、触られないまま今日は許可され明日は拒否されることがあり、FALSE のアカウントはユーザーのダイヤルイン属性を無視するよう設定されたポリシーのサーバーでも接続できる。属性とポリシーを一緒に読まなければ、判断の半分しか監査できない。

継承されたアカウントを落とさずにフラグをエクスポートする

エクスポートはドメインコントローラー、またはActive Directoryモジュールを備えたワークステーションで実行し、要約を打ち直すのではなく生のファイルを証拠として残す：

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

単一のLDAPフィルターのほうが変更記録に貼り付けやすい。これは明示的な許可だけを返す：

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

次にダイヤルイン条件なしで再度クエリし、値が存在しないアカウントを探す。それが継承されたアカウントで、通常はドメインで最大のグループであり、これを飛ばすと監査は手作業で設定した数人だけの一覧になる。

フラグをグループアクセスとアカウントの健全性から切り離す

この属性が答えるのは一つの問いだけである。このアカウントはダイヤルインできるか。その人がまだここで働いているか、アカウントが有効か、ヘルプデスクのメモに共有パスワードが残っていないかは何も語らない。エクスポートを有効状態、最終ログオン日、サーバーへのアクセスを与えるグループメンバーシップと組み合わせる。

対応するのは組み合わせである。無効なアカウントで TRUE なのはノイズにすぎない。有効なアカウントで TRUE であり、一年間ログオンしていないものは削除の候補である。VPNグループ内の継承されたアカウントで誰も説明できないものこそが重要な発見である。なぜ付与されたのかを記録している単一の設定は存在しないからだ。

VPNサーバーが実際に認証を行うドメインコントローラーから読む。レプリケーションの遅延により、サーバーがすでに置き換えた値が表示されることがあり、古いDCの値を引用した監査は、誰かが再確認した瞬間に異議を唱えられる。

一つのアカウントを変更し、変更が届いたことを証明する

アクセスを外すには、属性を FALSE に設定する。クリアするのではなく。クリアするとアカウントはポリシーの継承に戻り、次の接続で再び許可される可能性があり、その変更は修正に見えても実際には別の判断である：

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

二行目は継承のリセットであり、二つの操作を混同しないよう意図的に分けてある。その後、別のセッションで確認し、属性を読み直し、コンソールの更新を信じるのではなく拒否についてNPSの課金イベントを確認する。

最後に、各リモートアクセスサービスについて、どの仕組みが判断を所有しているかを書き留める。ポリシーがユーザーのダイヤルイン属性を無視するなら、グループ条件が権威であり、属性はそのサービスに限って参考情報である。同じドメインの二つのサービスが正当に異なる答えを返すことはあり、レビュー記録はサービスごとに一行でそう書くべきである。

監査に耐える成果物は短い：誰が接続できるか、どの仕組みで、いつ見直され、誰によって。ダイヤルインのフラグが最初の二つの答えを与え、残りはポリシーのレビューだけが与える。