第7回　強化されたActive Directoryサービス（後編）：Windows Server 2008の基礎知識（2/3 ページ）

　RODCは、デフォルトではパスワード情報を保持しない。ユーザーの認証要求をブランチ・オフィス内で受け取り、パスワード情報を保持するサーバへと要求を転送するサーバなので、拠点に置く認証ゲートウェイ・サーバのように見えるかもしれない。ただし、このままではユーザーの認証要求ごとに細い回線を利用することになり、回線のトラブルなどにも対応できない。そのためこれらを補う機能として、一度認証されたユーザーやコンピュータのパスワードをキャッシュする機能を持っている。これにより、同じユーザーの認証要求が何度も回線を経由することも、ブランチ・オフィスのドメイン・コントローラが全ユーザーのパスワード情報を保持することもなくなる。

　さて、Active Directoryをよく知る方はいくつか疑問もあるだろうから、パスワード複製に関してもう少し細かく見ていくことにしよう。

1. パスワード・キャッシュの許可と拒否
2. パスワードの事前配布（事前キャッシュ）
3. パスワード・キャッシュされたユーザーのリスト表示
4. パスワード・キャッシュされたユーザーのパスワード強制変更

1．パスワード・キャッシュの許可と拒否

　パスワードをキャッシュするかどうかは、ユーザーやグループ、コンピュータごとに設定可能である。次の画面を見ると、［Active Directory ユーザーとコンピュータ］管理ツールから見たRODCのプロパティの中に、［パスワード レプリケーション ポリシー］というタブが存在することが分かる。

パスワードのキャッシュ・ポリシーの設定
読み取り専用のドメイン・コントローラのプロパティでは、パスワード・キャッシュするかどうかを指定できる。指定されたユーザーやグループごとに、パスワードのキャッシュを許可するか（キャッシュさせるか）、それとも拒否するか（キャッシュさせないか）を選択できる。
　 （1）読み取り専用のドメイン・コントローラのプロパティには、このタブが表示される。
　 （2）キャッシュ機能に関する説明。
　 （3）キャッシュ対象のユーザーやグループの一覧。
　 （4）それぞれのエントリごとに［許可］か［拒否］を選択できる。

　この画面中では、分かりやすいように「山田 太郎」というユーザーに対して「許可」、「鈴木 花子」というユーザーに対して「拒否」という設定をしている。これにより、山田というユーザーのパスワードはキャッシュされ、鈴木のパスワードはキャッシュされなくなる。ほかにもネットワーク全体をセキュリティのリスクにさらさないよう、AdministratorsやServer Operatorsなど、いわゆる管理者のパスワードはデフォルトでキャッシュを拒否するようになっている。

　ただし多くの拠点を有する会社において、サイトごとにRODCの設定を編集するには多くの手間がかかる。そこで、Windows Server 2008のActive Directoryでは、「Users」コンテナ配下に以下の2つのドメイン・ローカル・グループが存在しており、RODCのパスワード・レプリケーション・ポリシーにデフォルトで登録されている。これらのグループを活用して（必要なユーザーやグループをこれらのローカル・グループへ登録する）、キャッシュ機能の許可／拒否を管理するとよい。

• Allowed RODC Password Replication Group（パスワード・キャッシュ許可用グループ）
• Denied RODC Password Replication Group（パスワード・キャッシュ拒否用グループ）

パスワード・キャッシュ機能の管理用グループ
Windows Server 2008のActive Directoryでは、パスワード・キャッシュを管理しやすくために、デフォルトで2つのドメイン・ローカル・グループが用意されている。これらのグループを活用して（必要なユーザーやグループをこれらのローカル・グループへ登録する）、キャッシュ機能の許可／拒否を管理するとよい。
　 （1）デフォルトで用意されている、パスワード・キャッシュを許可するためのドメイン・ローカル・グループ。
　 （2）デフォルトで用意されている、パスワード・キャッシュを拒否するためのドメイン・ローカル・グループ。

　通常の流れとして、RODC経由でログオンした場合にのみパスワード・キャッシュが行われることを考えると、ドメインのユーザー全員（もしくは全国のブランチ・オフィスに所属するユーザー全員）に対してパスワード・キャッシュ許可の設定をしておいたとしても、社内のユーザー全員のパスワードが1台のRODCにキャッシュされるようなことはない。よって、管理負荷を増やしてでも細かく制御をしたければRODCごとの設定を、管理負荷を減らしつつRODCのパスワード・キャッシュ機能を有効活用したければ上記の許可／拒否グループをうまく活用するというパターンが考えられる。もしくはその両方の組み合わせを選択する企業があるかもしれない。特に複雑な仕組みではないので、パスワード複製の運用設計については、企業における認証基盤の利用の仕方や運用ポリシーを考えればおのずと見えてくるだろう。

　なお、ユーザー個人に許可しつつ、そのユーザーをDenied RODC Password Replication Group（拒否用グループ）のメンバーに登録すると整合性が取れなくなりそうに思われる。だがWindows OSの一般的なルールでは、常に（許可権よりも）拒否権が優先されることになっているので、この場合はパスワード・キャッシュは拒否されることになる。

2．パスワードの事前配布（事前キャッシュ）

　パスワード・キャッシュの許可／拒否設定だけであれば、ユーザーのログオン時にキャッシュが行われるが、ネットワークのメンテナンス前に強制的にキャッシュしておきたい場合などは、事前に作業をしておくこともできる。次の画面を見ると、［パスワードの事前配布］という、事前キャッシュのための機能（ボタン）が用意されていることが分かる。

パスワードの事前配布機能
パスワードの事前配布機能を使うと、ネットワークのメンテナンスなどで通信が切断する前に、強制的にキャッシュしておくことができる。
　 （1）これをクリックすると、パスワードを強制的にキャッシュさせることができる。

　なお、事前配布の設定画面の中でも警告が出てくるが、Active Directoryの処理にはユーザー・アカウントに加えて、ユーザーがログオンするコンピュータ・アカウントのパスワードも必要になるので注意していただきたい。 もちろん、事前配布設定の画面からはユーザーだけでなくコンピュータのアカウントも指定可能である。

3．パスワード・キャッシュされたユーザーのリスト表示

　RODCやパスワード・キャッシュ機能を利用する場合、運用上、誰のパスワードがキャッシュされているかを知りたいことがある。Windows Server 2008の管理画面では、特定のRODCに対してパスワードがキャッシュされているアカウントや、パスワードがキャッシュされているかどうかに関係なく、RODCにて認証されたアカウントのリストを表示することができる。このリストを見て、意図していないユーザーによるログオンや、意図していないユーザーのパスワード・キャッシュなどを確認できる。

　このリスト（パスワードそのものは入らない）はCSVファイルなどにエクスポートできるので、定期的にRODCの利用状況を確認、保存しておくのもよいだろう。

パスワード・キャッシュされたユーザー・リストのエクスポート
パスワードがキャッシュされているユーザーや、このドメイン・コントローラで認証されたユーザーのリストをエクスポートしておくことができる。
　 （1）パスワードがキャッシュされ、この読み取り専用ドメイン・コントローラに保存されているユーザーの一覧を表示させるには、これを選択する。
　 （2）この読み取り専用ドメイン・コントローラで認証されたことのあるユーザーの一覧を表示させるには、これを選択する。
　 （3）表示されたユーザーの一覧リストを保存しておくには、これをクリックする。

4．パスワード・キャッシュされたユーザーのパスワードの強制変更

　最初に、RODCが利用されるブランチ・オフィスには物理的リスクが存在すると書いた（第1回参照）。本来安全に管理されるべき認証サーバが、営業所のカウンターの下や書棚の隣に置いてあることもある。サイズの小さなサーバが営業所の机の上に置かれ、「触るな」という張り紙がしてあるお客さまを見たこともある。日本では少ないだろうが、治安上の問題を抱える国などではサーバそのものが盗まれる可能性も否定できない。

　Active Directoryは海外拠点を含む全世界のネットワーク基盤として利用されることもあるため、セキュリティ上の課題を抱える拠点が1つでもあればネットワーク全体のリスクとなり得る。そこで、Windows Server 2008ではRODCがなくなってしまったときのリスクに対応する機能も提供している。管理ツールの［Active Directory ユーザーとコンピュータ］からRODCのコンピュータ・アカウントを削除しようとすると次のような画面が表示され、RODCにキャッシュされているユーザーやコンピュータ・アカウントのパスワードをすべてリセットしてくれる。

キャッシュされたパスワードの削除
読み取り専用のドメイン・コントローラを削除する場合、同時に読み取り専用ドメイン・コントローラにキャッシュされているユーザーのパスワードをすべてリセットできる（実際にはそれらのユーザーに対してランダムなパスワードが設定されるので、事実上、そのままではログオンできなくなる）。パスワードがリセットされると、一度、ドメイン管理者によるパスワードの再設定とユーザーへの通知が必要となる。そして、ユーザーは最初のログオン時に自分のパスワードを再入力しなければならなくなる。
　 （1）このチェック・ボックスをオンにしてからドメイン・コントローラを削除すると、キャッシュされているユーザーのパスワードをリセットできる。キャッシュされたデータを保持するドメイン・コントローラが盗難などのセキュリティ・リスクにさらされた場合は、安全のためにこの機能を利用して、パスワード情報をリセットするなどの対策を行うとよい。

　このような機能を利用することがないことを祈るばかりだが、もしものときのために、管理者が介在しなければネットワークにログオンできない状況をつくっておくこともできるわけだ。物理的リスクの高いサーバであればBitLockerドライブ暗号化機能を使い、フルボリュームの暗号化と同時に利用することをお勧めする。