Windows の未来Windows Server "Longhorn" のディレクトリ サービス

Byron Hynes

このコラムは、Windows Server のコードネーム "Longhorn" のプレリリース版を基にしています。ここに記載されているすべての情報は変更される可能性があります。

次期バージョンの Windows Server (コードネーム "Longhorn") では、Active Directory に多数の改良が行われます。その中には、管理を容易にし、効率を上げることを期待できる重要な変更もあります。特に目立つ変更点は、機能名の変更です。ID 管理に関連する機能が、すべて Active Directory® の名前でまとめられます。Microsoft® Windows Server® 2003 で Active Directory と考えられていたサービスは Active Directory ドメイン サービス (ADDS) となり、その他に Active Directory フェデレーション サービス (ADFS)、Active Directory ライトウェイト ディレクトリ サービス (ADLDS、従来の Active Directory/Application Mode : ADAM)、Active Directory 証明書サービス (ADCS)、Active Directory Rights Management サービス (ADRMS) などのサービスがあります。

それぞれのサービスは、サーバーの役割を表しています。これは Windows Server "Longhorn" の新しい考え方であり、1 台のコンピュータにはサーバーの役割を 1 つまたは複数割り当てることができます。サーバーの役割は、図 1 に示す [Server Manager (サーバーの管理)] で管理できます。この画面で、役割の追加、ヘルプの検索など、必要な管理作業を実行できます。

図 1** Server Manager (サーバーの管理) **(画像を拡大するには、ここをクリックします)

見てのとおり、新しい方式では、日常の業務を論理的なグループとしてまとめて [Server Manager (サーバーの管理)] からアクセスできるようにしています。

機能レベル

Windows Server "Longhorn" には、フォレストとドメインの新しい機能レベルが導入されます。Windows Server "Longhorn" のフォレスト機能レベル (リリース時に名前が変更される予定です) はそれ自体に新機能は追加されません。しかし、この機能レベルのフォレストに含まれるすべてのドメインは、Windows Server "Longhorn" のドメイン機能レベルになります。ドメイン機能レベルには 2 つの機能強化が行われます。1 つ目の機能強化として、堅牢で効率が良く、細かい制御も可能な最新の分散ファイル システム (DFS) レプリケーション エンジンが SYSVOL 共有に採用されます。2 つ目として、Kerberos 認証プロトコルで使用する 256 ビット Advanced Encryption Services (AES) 暗号化のサポートが追加されます。最新の機能レベルを使用すると、最良のパフォーマンスを得ることができますが、Windows Server "Longhorn" に移行するときに、継続して従来の機能レベルで運用することもできます。

さまざまな機能をサポートするスキーマ拡張も多数導入されますが、すべて既存のスキーマと完全に互換性があります。Windows Server "Longhorn" を実行するドメイン コントローラと、Windows Server 2003 を実行するドメイン コントローラは、共存し、相互運用することが可能です。

Server Core のサポート

Active Directory ドメイン サービスは、Windows Server "Longhorn" の Server Core で動作するサーバーの役割の 1 つです。Server Core とは、詳細はこの記事では扱いませんが、サーバーの基本機能のみを含んだ、最小限のインストールを行うオプションです。Server Core は、Windows シェルがインストールされたり、グラフィカル ユーザー インターフェイスが使用されたりしないので、オーバーヘッドを大幅に節約できます。

読み取り専用ドメイン コントローラ

Windows Server "Longhorn" の ADDS の機能のうち、一部の環境で最も意味のある機能が、読み取り専用ドメイン コントローラ (RODC) です。RODC を使用すると、ドメイン データベースの読み取り専用レプリカをホストするドメイン コントローラを簡単に展開できます。ドメイン コントローラの物理的なセキュリティが保証されない場所や、サーバー管理者 (通常は Domain Admins グループのメンバでない) がメンテナンスするアプリケーションをドメイン コントローラで実行する必要がある場合に適しています。両方のシナリオとも、支社での展開では一般的です。

図 2 に示すとおり、Installation Wizard (インストール ウィザード) でチェック ボックスを 1 つオンにするだけで、読み取り専用ドメイン コントローラがインストールされます。

図 2** 読み取り専用ドメイン コントローラのインストール **(画像を拡大するには、ここをクリックします)

Windows Server "Longhorn" のリリース前は、ユーザーが別の場所にあるドメイン コントローラで認証を行う場合、広域ネットワーク (WAN) リンクを越える必要がありました。WAN リンクはローカル エリア ネットワーク (LAN) 接続に比べて、低速でコストが高い場合が多く、サービスが中断しやすい性質があります。リモート サイトや支社に DC を展開するという解決法もありますが、そうすると、新たな問題として、レプリケーションのトラフィックが発生したり、支社の DC の物理的なセキュリティを管理する必要が出てきたりします。小規模で物理的に離れた支社ではこれらの問題に十分に対応できません。また、支社とハブ サイトを結ぶネットワーク帯域幅が狭いために、ログオン時間が長くなる場合もあります。

RODC には、アカウント パスワードを除き、書き込み可能なドメイン コントローラと同じ Active Directory ドメイン サービスのオブジェクトおよび属性が含まれます (ただし、別途特別な構成をした場合、アカウント パスワードもレプリケートされます)。しかし、ローカルで発生した変更を、RODC に保存されているレプリカに反映することはできません。変更は、書き込み可能なドメイン コントローラに反映され、そこから RODC にレプリケートされます。支社で行った変更がレプリケートされてフォレストが汚染または破損する可能性を減らし、攻撃の 1 つの手段を断ちます。

ドメイン ディレクトリ情報への読み取りアクセスが必要なローカル アプリケーションは、RODC から直接アクセス許可を取得できます。一方、書き込みアクセスが必要なライトウェイト ディレクトリ アクセス プロトコル (LDAP) アプリケーションは、LDAP 紹介の応答を受け取ります。LDAP 紹介の応答を受け取ったアプリケーションは、(通常、ハブ サイトにある) 書き込み可能なドメイン コントローラにリダイレクトされます。

RODC には変更が直接書き込まれないので、RODC で発生する変更はありません。したがって、そのレプリケーション パートナーである書き込み可能なドメイン コントローラは、RODC から変更をプルする必要がありません。その結果、ハブのブリッジヘッド サーバーの負荷と、レプリケーション監視作業が軽減されます。RODC の単方向レプリケーションは、ADDS と分散ファイル システム (DFS) レプリケーションの両方に適用されます。ADDS と DFS レプリケーションの変更は、RODC への通常のレプリケーションが行われます。

ドメイン データベース内の各セキュリティ プリンシパルは、資格情報と呼ばれるパスワードまたはシークレットをおよそ 10 個持っています。RODC には、そのコンピュータ自体のアカウントと各 RODC の "krbtgt" という特別なアカウント (Kerberos 認証に使用します) を除き、ユーザーやコンピュータの資格情報が保存されません。RODC はそのサイト (通常は支社) のキー配布センター (KDC) としてアドバタイズされます。RODC がチケット保証チケット (TGT) 要求に署名または暗号化を行うと、書き込み可能なドメイン コントローラの KDC とは異なる krbtgt アカウントとパスワードが使用されます。

あるアカウントを初めて RODC で認証するとき、ハブ サイトの書き込み可能なドメイン コントローラに認証要求が送信されます。認証が成功すると、RODC は適切な資格情報のコピーを要求します。書き込み可能なドメイン コントローラでは、RODC から要求が到着したことを認識すると、その RODC の有効な Password Replication Policy (パスワード レプリケーション ポリシー) を調査します。

RODC への資格情報のレプリケートおよび保存が許可されているかどうかは、パスワード レプリケーション ポリシーによって決まります。許可されている場合は、読み取り専用ドメイン コントローラのしくみの説明にあるとおり、書き込み可能なドメイン コントローラが RODC に資格情報を送信し、RODC にキャッシュします。

資格情報が RODC にキャッシュされた後は、資格情報が変更されるまで、そのユーザーがログオンするときの要求は RODC で直接処理されます。RODC 自体の krbtgt アカウントで TGT が署名されている場合、その RODC 自体に資格情報のコピーがキャッシュされていると RODC が認識します。別の DC が TGT に署名している場合、書き込み可能なドメイン コントローラに要求が転送されます。

RODC で認証済みのユーザーしか資格情報がキャッシュされません。その結果、RODC から不正に資格情報が漏れる可能性を抑えます。

既定では、RODC にユーザー パスワードがキャッシュされませんが、必ずしもこれがもっともの効率の良いシナリオとは限りません。ドメイン全体のユーザー数に比べると、RODC に資格情報をキャッシュする必要があるドメイン ユーザーは、通常はわずかです。パスワード レプリケーション ポリシーを使用すると、どのユーザー グループのキャッシュを許可するかを指定できます。たとえば、その支社に頻繁に在籍しているユーザーのみに RODC のキャッシュを制限したり、管理者などの重要な資格情報をキャッシュしないようにしたりすることで、情報が漏れる危険を減らします。

RODC が盗難に遭うなどして不正に使用される危険がある場合、キャッシュされている資格情報のみをリセットすればよく、後で説明するとおり、その対象になる資格情報は、図 3 に示すとおり正確に把握できます。

図 3** キャッシュされているアカウント情報 **(画像を拡大するには、ここをクリックします)

管理者の役割の分離

支社の多くは、ドメイン コントローラにファイル サーバー、プリント サーバーなど、他の役割を与えたり、他のタスクを実行させたりしています。また、基幹業務アプリケーションをやむなくドメイン コントローラにインストールしている場合があります。このような環境では、これらのアプリケーションやサーバーを管理するため、支社の従業員が管理者の資格情報を持つ必要があります。さらに、1 台の Windows Server 2003 ドメイン コントローラを管理できる人物は、ドメイン全体を管理できてしまいます。

Windows Server "Longhorn" では、特定の RODC のみを管理する権限を管理者に与えることができるので、他のドメイン コントローラまで管理できるアクセス許可を与えたり、不必要に Domain Admins セキュリティ グループのメンバにしたりする必要がありません。

ユーザー インターフェイスとツールの改善

図 4 に示すとおり、RODC の機能をサポートし、パスワード レプリケーションを監視しやすくするため、[Active Directory Users and Computers (Active Directory ユーザーとコンピュータ)] でドメイン コントローラのプロパティ ページを開くと、新しく [Password Replication Policy (パスワード レプリケーション ポリシー)] タブが表示されます。

図 4** [Password Replication Policy (パスワード レプリケーション ポリシー)] タブ **(画像を拡大するには、ここをクリックします)

このタブの [Advanced (詳細)] をクリックすると、図 5 に示すとおり、RODC に送信されたパスワード、保存されたパスワード、および RODC で認証済みのアカウントがわかります。この一覧には認証済みアカウントが含まれているので、このアカウントがパスワードをレプリケートするグループに属していなくても、一覧の情報からパスワード レプリケーション ポリシーの対象にするグループを判断できます。

図 5** パスワード レプリケーション ポリシーの詳細 **(画像を拡大するには、ここをクリックします)

正式には Active Directory Domain Services Installation (Active Directory ドメイン サービスのインストール) ウィザードと呼ばれる dcpromo ユーティリティにも、多数の変更が加えられています。オペレーティング システムをインストールした直後に表示される、Initial Configuration Tasks (ICT) (初期構成タスク) ページで [Add Roles (役割の追加)] を選択すると、このウィザードがグラフィカル アプリケーションとして起動します。[Add Roles (役割の追加)] を選択してから [Server Manager (サーバーの管理)] で ADDS を選択するか、コマンド ラインまたは [Run (ファイル名を指定して実行)] から dcpromo を呼び出します。

グラフィック モードでウィザードを使用すると、関連項目がまとめて表示されるので、構成要素やオプションの適切な組み合わせがわかります。オプションは他にもあります。ドメイン ツリーの新規作成、メディアからのインストール (WAN を使用した最初のレプリケーションを減らすため)、最初のレプリケーションに使用する複製元ドメイン コントローラの選択などを行う場合、/adv スイッチを使用しないで UI から詳細モードにアクセスできます。

業務を円滑に進め、エラーを減らすための改善も行われています。たとえば、このウィザードを使用して、既存のドメインまたはフォレストに新しいドメイン コントローラを作成する場合、NetBIOS 名を入力しなくても、既存のドメインを参照できます。

DC をグローバル カタログ サーバー、DNS サーバー、および RODC として構成するオプションを指定するページが新しく追加されました。ウィザードでは他に、サイト選択の構成、機能レベルの設定、RODC のパスワード レプリケーション ポリシーの作成、および DNS 委任の構成が可能です。

コマンドライン ツールである dcpromo は完全に無人で実行できます。Windows Server 2003 の dcpromo とは異なり、無人インストールの際に、コンピュータの再起動が必要といった、ユーザー インターフェイスによるプロンプトに応答する必要がありません。このしくみにより、Windows Server "Longhorn" の Server Core で ADDS を使いやすくなります。

ADDS の監査

Windows Server "Longhorn" のディレクトリ サービスの監査機能が充実します。Windows Server 2003 でも、ディレクトリ アクセスの監視を有効にしたり無効にしたりすることはできますが、成功の監査をすべて有効にしても、監査記録には変更された情報が残りません。今回、その機能が追加されました。

Windows Server "Longhorn" では、ADDS の監査ポリシーが次の 4 つのサブカテゴリに分類されます。

• ディレクトリ サービスのアクセス
• ディレクトリ サービスの変更
• ディレクトリ サービスのレプリケーション
• 詳細なディレクトリ サービス レプリケーション

この変更について、IT プロにぜひ覚えておいていただきたい 2 つの重要な事実があります。まず、ディレクトリ サービスのアクセス監査は、Windows Server 2003 のときと基本的に同じ情報を提供しますが、イベント ID が 566 から 4662 に変更されます。ツールを使用してセキュリティ イベント ログを解析している場合は、この変更に注意してください。次に、新しいカテゴリである "ディレクトリ サービスの変更" では、変更前と変更後の属性の値が記録されます。

ADDS に監査を実装するには、グローバル監査ポリシー、システム アクセス制御リスト (SACL)、および ADDS スキーマを使用します。これらのコンポーネントが連携して、柔軟で包括的な監査フレームワークとして機能します。

グローバル監査ポリシーは、ADDS で監査を行うかどうかを指定するために使用します。監査を有効にする場合、グローバル監査ポリシーで、4 つのアクセス サブカテゴリ (上記) のどれを監査するかを指定します。通常、グローバル監査ポリシーは、既定のドメイン コントローラ グループ ポリシー オブジェクトで、ドメイン コントローラのディレクトリ全体に対して適用されます。

グローバル監査ポリシーはグループ ポリシー ツールで有効にしたり無効にしたりできますが、サブカテゴリの表示または構成を行うには Auditpol.exe コマンドライン ツールを使用する必要があります。サブカテゴリは、グラフィカル ユーザー インターフェイスに表示されません。

SACL はオブジェクトのセキュリティ記述子の一部です。SACL にエントリを指定して、注目する操作とユーザー (セキュリティ プリンシパル) をシステムに指定します。つまり、どのユーザーのどの操作をイベント ログに記録するかを指定します。Domain Admins が行ったユーザー オブジェクトへの変更は記録するが、ユーザー自身が行った変更は記録しない場合、SACL で制御できます。SACL はオブジェクトに適用されます (新しいオブジェクトに定義することも、コンテナ オブジェクトから継承することもできます)。

変更を監査する対象を特定の属性に限定する ADDS スキーマの構成も可能です。既定の SACL はオブジェクトに適用されるので、すべての属性へのアクセスや変更が記録されます。このままでは、大量の記録動作が発生します。すべての属性は必要ないという場合、変更を記録しないことを示すフラグを属性レベルで設定できます。

SearchFlags は属性を定義するクラスに定義される属性です。つまり、属性の属性です。1 バイトの値の各ビットがそれぞれオン/オフの設定を表すビットマスクになっています。属性のプロパティと考えるとわかりやすいかもしれません。Windows Server 2003 では、7 つの値がインデックス化、属性の GC レプリケーションなど、さまざまな設定に使用されています。Windows Server "Longhorn" では、変更をログに記録するかどうかを第 8 ビット (値 128) で指定します。このビットがオンになっている場合、属性が変更されても変更イベントは記録されません。この設定は、その属性を含むすべてのオブジェクトに適用されます。Beta 2 では、グラフィカル ユーザー インターフェイスで第 8 ビットを設定することはできません。

Windows Server "Longhorn" の既定では、グローバル監査ポリシーが有効になっていて、ディレクトリ サービスの変更に成功した変更が記録されます。

再起動可能な ADDS

Windows Server "Longhorn" の ADDS は再起動可能なサービスです。ドメイン コントローラを再起動しなくても、ADDS サービスを停止して開始することができます。したがって、サービスの実行中には行うことができない機能 (データベースをオフラインで最適化するなど) を、ディレクトリ サービス復元モードにすることなく、簡単に実行できます。

Windows Server "Longhorn" を実行するドメイン コントローラが取る状態は、ADDS 開始、ADDS 停止、ディレクトリ サービス復元モードのいずれかです。それぞれの状態について以下で説明します。

ADDS 開始 ドメイン コントローラは正常に稼動しています。

ADDS 停止 ディレクトリ サービス復元モードのドメイン コントローラと、ドメインに参加しているメンバ サーバーの両方の特性を持っています。

ディレクトリ サービス復元モードと同様に、ADDS データベース (Ntds.dit) がオフラインです。ログオン時、他のドメイン コントローラと通信できない場合に、ディレクトリ サービス復元モードのパスワードを使用してローカルにログオンできます。

メンバ サーバーと同様に、ドメインに参加しています。ユーザーは、対話型、または他のドメイン コントローラを使用してネットワーク経由でドメインにログオンできます。ただしこの状態は、ログオン要求を処理したり、他のドメイン コントローラとレプリケートを行ったりできないので、長時間この状態にしないようにしてください。

ディレクトリ サービス復元モード このモード (状態) は Windows Server 2003 から変わりません。

図 6 のフローチャートに、Windows Server "Longhorn" を実行しているドメイン コントローラがこの 3 つの状態をどのように遷移するかを示します。

図 6** 3 つの状態を遷移する Windows Server 'Longhorn' 上のドメイン コントローラ **

詳細情報

1 回の短い記事で Windows Server "Longhorn" の ADDS の新機能を深く説明するのは不可能です。しかし見てきたとおり、これまで避けて通ってきたり、放置したりしていた数々の問題が、Active Directory の新機能により解決されます。Windows Server "Longhorn" の最終版のリリースが近づくにつれ、情報収集に役立つドキュメントが続々公開されると確信しています。現時点で、ベータ フェーズの更新プログラムをお探しの場合、Windows Server "Longhorn" Web サイトが最適です。

Byron Hynes はマイクロソフトの Windows Server User Assistance グループに在籍しています。前職ではコンサルタント兼トレーナーとして、地区内インターネット バックボーンの運用、クライアント サーバー アプリケーションと Web アプリケーションのトラブルシューティング、データベース スキーマ、ネットワーク インフラストラクチャ、セキュリティ モデルのデザインなど、多岐にわたる実績を残しました。彼の連絡先は bhynes@microsoft.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.