• [アーティクル]

特集 : Windows Server 2008

Active Directory ドメイン サービスの新機能

Gil Kirkpatrick

 

概要:

  • 新しいサーバー マネージャと ADDS を使用する
  • Server Core でドメイン サービスを実行する
  • 読み取り専用ドメイン コントローラ
  • パスワード、バックアップ、および監査に加えられた変更点

マイクロソフトは、Windows 2000 で Active Directory を世に送り出しました。その次のメジャー リリースである Windows Server 2003 では、Active Directory に大幅な機能強化が施されましたが、

抜本的な変更はありませんでした。現在の Active Directory® は、非常に成熟した堅牢なディレクトリ サービスです。しかし、Active Directory チームは、最新のバージョンでいくつかの大幅な機能強化を施し、この中核的なネットワーク サービスのセキュリティと管理の容易さを向上させています。

世紀が変わるころ、Active Directory の役割は、ユーザーをログイン時に認証すること、ユーザーとコンピュータにグループ ポリシーを適用すること、およびユーザーが探しているプリンタの検出を支援することでした。そのわずか数年後には、スタンドアロン版の Active Directory Application Mode (ADAM) がリリースされました。

2006 年までにこの状況は完全に様変わりし、Active Directory はもはや特定のテクノロジではなくなりました。今では、Windows® に付属する ID とアクセス制御サービスを表すブランドになっています。図 1 は、Active Directory ブランドを構成するテクノロジの概要を示しています。

Figure 1 Active Directory のコンポーネント

現在の Active Directory テクノロジ 旧称 説明
Active Directory ドメイン サービス (ADDS) Active Directory これまで Active Directory と呼ばれていたテクノロジです。ドメインのユーザーとコンピュータに Kerberos および NTLM ベースの認証を提供し、OU、ユーザー、グループ、グループ ポリシーなどを管理します。
Active Directory ライトウェイト ディレクトリ サービス (ADLDS) Active Directory Application Mode (ADAM) ADDS と同じソース コードに基づいて構築された高パフォーマンス LDAP サーバー。
Active Directory 証明書サービス (ADCS) 証明書サービス X.509 証明書を使用して強力な認証を提供します。
Active Directory Rights Management サービス (ADRMS) Rights Management Server 権利によって保護されたファイルやコンテナを作成して、ドキュメントや電子メールなどのデジタル資産が無許可で使用されないようにします。
Active Directory フェデレーション サービス (ADFS) Active Directory フェデレーション サービス WS-* に準拠した Web サービスに Web シングル サインオンと ID フェデレーションを提供します。

したがって、適切な言葉で言えば、この記事は "ドメイン サービス" についての記事です。ただし、間違えの無いように言っておきますが、これは 2000 年以降皆さんに愛用していただいている Active Directory と同じものです。

Windows Server 2008 のサーバー マネージャ

最初に取り上げる Active Directory の 2 つの機能強化は、実際には Active Directory ドメイン サービス (ADDS) の変更点というよりも、Active Directory の管理方法を変える Windows の変更点です。1 つ目は、Windows Server® 2008 サーバーの初回起動時に表示される新しいサーバー マネージャです (2 つ目は Server Core インストールです。これについては、この後すぐに説明します)。

サーバー マネージャは、おそらく Windows Server 2003 のサーバーの構成ウィザードに似ていると感じるのではないでしょうか。このウィザードは、既定では Windows Server 2003 のインストール後に表示されます。ただし、このウィザードは日々の管理にはそれほど役立つとは言えず、私の知り合いは全員が [ログオン時にこのページを表示しない] チェック ボックスをオンにしています。

一方、Windows Server 2008 のサーバー マネージャは非常に役立ちます (今月号の TechNet Magazine で Byron Hynes が執筆しているサーバー マネージャの概要についての記事を参照してください)。まず、サーバー マネージャは、Microsoft HTML アプリケーション (HTA) ではなく、Microsoft® 管理コンソール (MMC) スナップインになりました (図 2 参照)。つまり、カスタマイズしやすく使い慣れたフル機能のユーザー インターフェイスを備えているということです。特別な構成を行う必要なく、サーバー マネージャを使用して各サーバーの役割 (DNS、ADDS、IIS などの主要サービス) や機能 (Microsoft .NET Framework、BitLockerTM ドライブ暗号化、Windows PowerShellTM などのソフトウェア コンポーネント) を管理できます。サーバー マネージャを使用すると、ソフトウェアの追加および削除機能が提供されるだけでなく、診断ツール (イベント ビューアやパフォーマンス モニタ) とシステム構成ユーティリティ (デバイス マネージャやファイアウォール スナップイン) を一元的に実行できるようになります。Active Directory 用の MMC スナップイン (ユーザーとコンピュータ、ドメインと信頼関係、サイトとサービスなど) を追加すると、Windows Server 2008 ドメイン コントローラ (DC) の日々の管理に非常に役立つインターフェイスが提供されます。

図 2 Windows Server 2008 のサーバー マネージャ

図 2** Windows Server 2008 のサーバー マネージャ **(画像を拡大するには、ここをクリックします)

Windows Server 2008 の Server Core

Windows の Server Core は、Windows の新しいインストール オプションの 1 つであり、特定の主要なサーバーの役割 (Active Directory ドメイン サービスなど) の実行に必要なコンポーネントのみから構成されたコンパクトな Windows を展開できます (図 3 は Server Core でサポートされている役割の一覧です)。Server Core インストールではグラフィカルな UI が 1 つ提供されますが、Windows デスクトップ シェルは実行されず、Windows を管理および構成するためのグラフィカル ツールがほとんど提供されません (図 4 参照)。代わりにコマンド ウィンドウが提供されますが、使い方がわからず胃が痛くなるような思いをすることでしょう。コンピュータ名を変更するにはどうしたらよいでしょうか。また、静的 IP アドレスを構成するにはどうしたらよいでしょうか。

図 4 簡素な Server Core の UI

図 4** 簡素な Server Core の UI **(画像を拡大するには、ここをクリックします)

Server Core インストールを前にすると、最初のうちは落ち着かないかもしれません。しかし、少しだけ時間をとって WMIC、NETSH、および NETDOM の使い方を覚えてしまえば、難なく通常のセットアップや構成作業をすべてこなせるようになります。また、グラフィカル ツールが必要な皆さんのために、レジストリ エディタやメモ帳は Server Core でも提供されます。

Server Core の最大の利点は、通常の Windows インストールで提供されているコードから、主要なサーバーの役割には必要ないと思われるコードの多くが削除されていることです。これにより、マルウェアの攻撃対象となり得る範囲が縮小され (良い点)、修正プログラムの適用と再起動を DC 上で実行する回数が減少します (さらに良い点)。使用するディスク領域も大幅に減少するため、今までよりも容易にハード ドライブの要件を満たすことができます。これは通常は大きな問題になりませんが、仮想化サーバー環境では役立つ場合があります。

グラフィカルなユーティリティがなければ、ADDS の管理は困難でしょうか。そんなことはまったくありません。ワークステーションからユーティリティを実行し、ネットワーク経由でドメイン コントローラに接続することによって、ほぼすべての管理作業をリモートで実行できます。いずれ DC の大半で Server Core インストールが実行されるようになるのではないでしょうか。

DCPROMO の変更点

ADDS 自体で最初に気が付く変更点は、新しい DCPROMO です。この DCPROMO は Windows Server 2003 の DCPROMO と同じように機能しますが、より使いやすくなるようにコードが全面的に書き換えられています。たとえば、ドメイン管理者の資格情報を入力する必要がありません。DCPROMO は、現在のログインの資格情報を使用してサーバーを昇格します。また、DCPROMO の詳細モード オプションを有効にするために「DCPROMO /ADV」と入力する必要もありません。DCPROMO の最初のダイアログ ボックスで、このオプションを有効にするためのチェック ボックスが提供されます。詳細モードでは、レプリケート元として既存のドメイン コントローラを選択することもできます。つまり、DCPROMO のレプリケーションによって運用 DC に負荷をかけずに済みます。

DCPROMO では、DC を新しいドメインまたはフォレストに昇格するときに、フォレストとドメインの機能レベルを設定できるため、後からこの作業を行う必要がなくなります。また、この昇格プロセスの実行中に、DC を配置する Active Directory サイトを指定できます。これは、無人で DCPROMO を実行するときに非常に役立ちます。さらに DCPROMO は、DC の IP アドレスに基づいて、その DC に最適なサイトの候補を提示します。

新しい DCPROMO では、すべての構成オプションが 1 つのページにまとめられています。このページで、新しい DC をグローバル カタログ (GC)、DNS サーバー、読み取り専用 DC のどれに設定するかを選択できます。このため、DC を GC に設定するために、Active Directory サイトとサービス スナップインを使用してわかりにくい場所にアクセスする必要はありません。

しかしおそらく、新しい DCPROMO の最も便利な機能は、昇格プロセスを開始する直前に DCPROMO のすべての設定を応答ファイルに保存できる機能です。これは手動で応答ファイルに設定を入力するよりもはるかに簡単で、エラーの発生も抑えられます。この応答ファイルは、別のサーバーで DCPROMO を無人で実行するときに使用できます。また、コマンド ラインから DCPROMO のすべてのオプションを利用できるようになったため、スクリプトの作成にも役立ちます。

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

Active Directory が登場したころ、多くの企業は、ユーザーがログインするサイトごとにドメイン コントローラを展開していました。たとえば、銀行では支店ごとに DC を配置することが一般的でした。これは、WAN に障害が発生した場合でも、支店のユーザーがローカル ネットワークにログインしてリソースにアクセスできるようにするためでした。

当時は、DC の物理的なセキュリティの必要性が十分に理解されておらず、ドメイン コントローラはデスクの下に押し込まれていました。これでは、通りがかりの人物が簡単にアクセスできてしまいます。しかし数年もたたないうちに、DC が保護されていないことによるセキュリティ リスクを Active Directory のアーキテクトが十分に理解し、IT 組織はより集中化されたデータセンターに DC を統合し始めました。ブランチ オフィスのユーザーは WAN 経由で認証を行う必要がありましたが、これはセキュリティが強化されることを考えれば妥当なトレードオフでした。

Windows Server 2008 の Active Directory では読み取り専用ドメイン コントローラ (RODC) が導入されたため、ブランチ オフィスに展開される DC の割合に変化がもたらされます。これは、Windows Server 2008 のドメイン サービスで加えられた最大の変更点です。

Active Directory チームは、RODC の設計にあたりブランチ オフィス シナリオの要件を重視し、"ブランチ オフィスで起きることはブランチ オフィスで処理する" ことを目標としました。DC を物理的に安全でないブランチ オフィスに展開した場合、最終的には DC (およびこの DC を信頼しているコンピュータ) への攻撃を防ぐ手立てはありませんが、このブランチ オフィスからドメインの他の部分に攻撃が及ばないようにすることはできます。

RODC は、ADDS インフラストラクチャにとって大きな変更点ですが、実装は非常に簡単です。ドメインの機能レベルは Windows Server 2003 フォレストである必要があります。また、ドメイン内には少なくとも 1 つの Windows Server 2008 DC が必要です。RODC は、単なるブランチ オフィス ソリューションとしてではなく、インターネットに接続されている環境や、DC がネットワーク境界に配置されている状況でも役立ちます。

DC が無断で持ち出された場合

ブランチ オフィスでは、何種類かの脅威が発生する可能性があります。まず 1 つは "DC が盗難にあう" シナリオで、だれかが DC 自体または DC のディスクを持ち去る場合です。この場合、ローカルのサービスが中断されるだけでなく、攻撃者が最終的にそのドメインに属するすべてのユーザーの名前とパスワードにアクセスして、それを基に攻撃者の特権を昇格して保護されたリソースにアクセスしたり、サービス拒否攻撃を仕掛けたりする可能性があります。RODC は、この脅威に対処するために、既定ではパスワード ハッシュを RODC のディレクトリ情報ツリー (DIT) に格納しません。したがって、ドメインに対してユーザーを認証する場合は、ユーザーが特定の RODC に対して初めて認証を行うときに、その RODC が認証要求をドメインのフル ドメイン コントローラ (FDC) に渡します。FDC が認証要求を処理し、その処理が成功した場合、RODC はパスワード ハッシュのレプリケーション要求を発行します。

攻撃を受けた RODC から、サービス アカウントのパスワード ハッシュが要求される可能性があります。これを防ぐために、ドメイン管理者は RODC ごとにパスワード レプリケーション ポリシーを構成できます。パスワード レプリケーション ポリシーは、RODC コンピュータ オブジェクトの 2 つの属性から構成されます。msDS-RevealOnDemandGroup 属性には、RODC にパスワードをキャッシュするグループ、ユーザー、またはコンピュータ アカウント (通常は RODC と同じサイトにあるユーザーとコンピュータ) の識別名が格納されます。msDS-NeverRevealGroup には、RODC にパスワードをキャッシュしないグループ、ユーザー、またはコンピュータ アカウントの識別名が格納されます (たとえば、ドメイン管理者のアカウントのパスワード ハッシュは RODC 上にキャッシュされないようにする必要があります)。RODC が特定のアカウントのパスワード ハッシュを要求すると、FDC がパスワード レプリケーション ポリシーを基にその要求を評価し、パスワード ハッシュを RODC にレプリケートするかどうかを判断します。これにより、DC が盗難にあった場合でも、知られるパスワードの範囲は、その RODC がネットワークから除外された時点でキャッシュされていたパスワードにとどめることができるため、最も重要なパスワードを知られずに済みます。

RODC のコンピュータ オブジェクトには、どのアカウントのパスワードをキャッシュするかを正確に判断するのに役立つ属性が他に 2 つあります。msDS-AuthenticatedAtDC 属性には RODC の認証を受けているアカウントの一覧が格納されており、msDS-RevealedList 属性には現在 RODC にパスワードが格納されているアカウントの名前が格納されます。

DC に格納される機密情報は、ユーザーとコンピュータのパスワード ハッシュだけではありません。KrbTGT アカウントには、各ドメイン コントローラ上で実行される Kerberos キー配布センター (KDC) サービスのキーが格納されています。通常のシナリオでは、ドメイン内の各 KDC は同じ KrbTGT アカウントを共有するため、攻撃者は盗んだ DC からキーを入手し、これらのキーを使用してドメインの他の部分を攻撃する可能性があります。しかし、RODC はそれぞれに固有の KrbTGT アカウントとキーを使用するため、このような攻撃を受ける可能性はなくなります。

また、アプリケーションがパスワードやその他の機密情報を DIT に格納することも珍しくありません。攻撃者が DC を盗んだ場合、これらのアプリケーションのパスワードも盗み、そのパスワードを使用してアプリケーションにアクセスできる可能性があります。管理者はこのリスクを緩和するために、Windows Server 2008 ドメイン サービスを使用して、読み取り専用 DC で除外される属性セット (RO-FAS) を定義できます。RO-FAS に含まれている属性は RODC にレプリケートされないため、盗んだ DC からそれらの属性を取得することはできません。RO-FAS に属性を割り当てるには、スキーマ内で該当する attributeSchema オブジェクトの searchFlags 属性のビット 9 (0x0200) を設定します。

内部の攻撃者

ブランチ オフィスのドメイン コントローラに関するもう 1 つの脅威は、ローカル サーバーの管理者が DC の特権を利用して自身の特権を昇格し、他のドメイン リソースにアクセスしたり、サービス拒否攻撃を仕掛けたりすることです。この場合も、ローカル管理者がドメイン コントローラに物理的にアクセスできるため、攻撃を防ぐ手立てはほとんどありません。ただし、攻撃者がブランチ オフィスのドメイン コントローラを使用してドメイン内の他の DC を攻撃するのを防ぐことはできます。

ドメイン内のフル DC は、RODC をドメイン コントローラとして信頼しません。信頼という点では、FDC は RODC をドメイン内のメンバ サーバーとして扱います。RODC は、Enterprise Domain Controllers または Domain Controllers グループのメンバではありません。RODC アカウントを使用して実行できるディレクトリ内の更新操作は非常に限定されています。このため、攻撃者が RODC アカウントを使用できるようになったとしても、有効な特権を得ることはできません。

RODC は、通常の DS レプリケーション トポロジにも含まれていません。RODC はドメイン コントローラではなく通常のメンバ サーバーであると見なされるため、知識整合性チェッカー (KCC) が RODC から接続オブジェクトを作成することはありません。KCC は、各 DC 上で DS レプリケーション トポロジの計算を実行するプロセスです。フル DC も RODC も、RODC からのレプリケーションは実行しません。一方、RODC はフル DC からの入力方向のレプリケーション合意を表す接続オブジェクトを作成しますが、この接続オブジェクトは RODC のレプリカ内にしか存在しません。つまり、他の DC にはこの接続オブジェクトのコピーは格納されません。レプリケーションという点では、RODC はディレクトリ オブジェクト界のブラックホールです。つまり、オブジェクトのレプリケーション先にはなっても、レプリケーション元になることはありません。

RODC での管理に関する役割の分離

通常、ブランチ オフィスの DC はローカル サーバーの管理者によって管理されます。ローカル サーバーの管理者は、ドメイン コントローラのバックアップの実行からキーボードの掃除まで、すべての作業をこなします。しかし、リモート サイトの管理者にドメイン コントローラの一般的な保守作業に必要な権利を与えることはセキュリティ リスクになります。これは、そのサイト管理者がドメイン内で自身の特権を昇格できるためです。RODC では、管理に関する役割を 2 種類の方法によって分離し、この脅威を緩和できます。

1 つ目の方法では、ドメイン管理者が DCPROMO を使用して通常どおり RODC を昇格するか、2 段階のプロセスを使用して、ブランチ オフィス サイトの管理者にドメイン管理者の権利を与えることなく安全に実際の昇格プロセスを委任します。ドメイン管理者は、Active Directory ユーザーとコンピュータ MMC スナップインを使用して、RODC コンピュータ アカウントを事前作成します (図 5 参照)。

図 5 RODC コンピュータ アカウントの事前作成

図 5** RODC コンピュータ アカウントの事前作成 **(画像を拡大するには、ここをクリックします)

[読み取り専用ドメイン コントローラ アカウントの事前作成] を選択すると、DCPROMO の簡易版が実行されます。この DCPROMO を使用すると、コンピュータ アカウントの作成、サイトへの RODC の割り当て、DC の役割の指定、パスワード レプリケーション ポリシーの指定、RODC 上で DCPROMO 操作を完了するための権利を必要とするユーザーまたはグループの定義など、ドメインへの管理アクセスを必要とするすべての作業を行うことができます。委任された管理者またはグループは、RODC で管理されているコンピュータ オブジェクトの managedBy 属性に格納されます。

その後、委任された管理者はサーバー上で DCPROMO を実行できます。DCPROMO は事前に作成されたアカウントを検出し、そのサーバーを RODC に設定します。この方法で DCPROMO を実行する場合、ドメイン管理者の資格情報は必要ありません。

2 つ目の方法では、管理に関するローカルの役割を RODC 自体に作成します。これらの役割はコンピュータのローカル グループに似ており、RODC のレジストリに格納され、RODC 上でのみ評価されます。また、ローカルの RODC の役割は、コンピュータの管理 MMC スナップインを使用して管理するのではなく、NTDSUTIL を使用して管理します。図 6 は、管理に関する RODC のローカルの役割の一覧です。これらの役割は、Windows の組み込みのグループにそれぞれ対応しています。

Figure 6 管理に関する RODC のローカルの役割

Account Operators
Administrators
Backup Operators
Certificate Service DCOM Access
Cryptographic Operators
Distributed COM Users
Event Log Readers
Guests
IIS_IUSRS
Incoming Forest Trust Builders
Network Configuration Operators
Performance Log Users
Performance Monitor Users
Pre-Windows 2000 Compatible Access
Print Operators
Remote Desktop Users
Replicator
Server Operators
Terminal Server License Servers
Users
Windows Authorization Access Group

RODC の予期しない動作

RODC は読み取り専用であり、他のドメイン コントローラは RODC からのレプリケーションを実行しないため、RODC では予期しない動作が見られます。たとえば、残留オブジェクト (すべての場所で削除されていても、特定の DC でフォレストの廃棄済みオブジェクトの有効期間内にレプリケートできなかったことが原因で、その DC 上に残っているオブジェクト) は、通常 DC の出力方向のレプリケーション パートナーによって検出されます。しかし、RODC は入力方向のレプリケーション パートナーを保有していないため、残留オブジェクトの検出対象にはなりません。

RODC では、LDAP の更新 (追加、変更、削除、名前の変更、移動) 操作は提供されず、エラーと共に、このような操作が提供されている書き込み可能 DC への LDAP 参照が返されます。LDAP 更新を発行したアプリケーションが参照操作を適切に処理できなかった場合、そのアプリケーションは失敗する可能性があります。

また、フォレスト内の別のドメインのユーザーが RODC に対して認証を行った場合、その RODC は自身が属するドメインのフル DC にアクセスして信頼パスワードを取得し、認証要求をそのユーザーのドメインに適切に渡すことができる必要があります。RODC とその RODC が属するドメインのフル DC との間のネットワーク接続が確立できなかった場合、認証は失敗します。

細かい設定が可能なパスワード ポリシー

ドメイン内で複数のパスワード ポリシーを定義できる機能は、おそらく最も多く要望が寄せられていた Windows Server 2008 の ADDS の機能です。おそらくご存知のとおり、Windows 2000 と Windows Server 2003 の Active Directory では、1 つのドメインにつき 1 つのパスワード ポリシーしかサポートされず、そのポリシーがドメイン内のすべてのセキュリティ プリンシパルに適用されます。特定のユーザー グループに別のパスワード ポリシーを適用する必要がある場合は、別のドメインを作成する必要があります。しかし、Windows Server 2008 の ADDS では、新機能の "細かい設定が可能なパスワード ポリシー" を使用して、1 つのドメイン内で複数のパスワード ポリシーを定義できるようになりました。

この新しい方法では、グループを使用して、細かい設定が可能なポリシーをユーザーに適用します。まず、新しい msDS-PasswordSettings オブジェクトを CN=Password Settings Container, CN=System, DC=<ドメイン> コンテナに作成して、細かい設定が可能なパスワード ポリシーを定義します。msDS-PasswordSettings オブジェクト (略して PSO) には、グループ ポリシーのパスワード ポリシーの設定に相当する属性があります (図 7 参照)。

Figure 7 mSDS-PasswordSettings オブジェクトの属性

属性 説明
mSDS-PasswordReversibleEncryptionEnabled 暗号化を元に戻せる状態でパスワードを暗号化するかどうかを示すブール値です。
mSDS-PasswordHistoryLength パスワード履歴内で保持するエントリの数です。
mSDS-PasswordComplexityEnabled パスワードの複雑さに関する制限を有効にするかどうかを示すブール値です。
mSDS-MinimumPasswordLength パスワードの最小文字数を定義する整数値です。
mSDS-MinimumPasswordAge パスワードを変更できるようになるまでの最短期間を示す INTEGER8 値です。
mSDS-MaximumPasswordAge パスワードを変更せずに使用できる最長期間を示す INTEGER8 値です。
mSDS-LockoutThreshold ロックアウトまでに許容されるログインの失敗回数を示す整数値です。
mSDS-LockoutObservationWindow ナノ秒単位の期間を示す INTEGER8 値です。この期間内で連続してログインに失敗すると、アカウントはロックアウトされます。
mSDS-LockoutDuration アカウントをロックアウトする期間を示す、ナノ秒単位の INTEGER8 値です。

次に、PSO の複数の値を持つ mDS-PSOAppliesTo 属性にユーザー名またはグループ名を追加して、ユーザーまたはグループにパスワード ポリシーを割り当てます。OU にパスワード ポリシーを適用しないという考え方を一度理解すれば、これは非常に簡単です。ただし、他にもいくつか複雑な点があります。

通常、ユーザーはさまざまなグループに属しています。では、このように複数のグループに属していることが原因で、複数の競合するパスワード ポリシーがそのユーザーに関連付けられている場合はどうなるのでしょうか。この場合、ADDS は優先順位の評価を使用して、適用するパスワード ポリシーを特定します。このしくみを以下に示します。

  1. パスワード ポリシーが (グループ メンバシップを介してではなく) 直接ユーザー オブジェクトに関連付けられている場合は、そのパスワード ポリシーが適用されます。
  2. 複数のパスワード ポリシーが直接ユーザーに関連付けられている場合は、優先順位の値が最も低いポリシー (PSO の msDS-PasswordSettingsPrecendence 属性によって決定されます) が適用されます。
  3. 優先順位が同じ PSO が複数ある場合は、objectGUID の値が最も低い PSO が適用されます。
  4. ユーザーに直接関連付けられている PSO がない場合、ADDS はそのユーザーのグループに関連付けられている PSO を評価します。複数の PSO がある場合は、msDS-PasswordSettingsPrecedence の値が最も低い PSO が適用されます。
  5. 優先順位の値が同じ PSO が複数ある場合は、objectGUID の値が最も小さい PSO が適用されます。
  6. ユーザーに関連付けられている PSO がない場合は、ドメインのパスワード ポリシーが適用されます。

ユーザー オブジェクトには、ユーザーに適用する PSO を正確に特定できる msDS-ResultantPSO という新しい属性があります。この属性には、ユーザーのパスワードを管理する PSO の識別名が格納されます。

細かい設定が可能なパスワード ポリシーでは、これまでのニーズを満たすだけの柔軟性が十二分に得られますが、これらのポリシーは慎重に管理し、複雑にならないようにする必要があります。製品には、細かい設定が可能なパスワード ポリシーを定義するためのユーティリティは付属していません。このため、ADSIEdit を使用するか、サードパーティ製のユーティリティを使用する必要があります。

再起動可能な Active Directory サービス

DIT の保守作業を行うためにドメイン コントローラを停止するたびに、ネットワーク サービス レベルでなんらかの影響が発生します。Windows Server 2008 DC では、DC を完全にシャットダウンせずにディレクトリ サービスを停止できる新機能が提供されます。

NET STOP NTDS コマンドを使用すると、Windows Server 2008 DC の ADDS が停止します。このとき、DC 上のローカル セキュリティ機関 (LSASS) のプロセスは引き続き実行されますが、すべての ADDS 関連の DLL がアンロードされるため、ディレクトリ サービスは利用できなくなります。その後 LSASS は、DC にドメイン認証要求を転送することによって、実質的にはメンバ サーバー上で実行されているかのように動作します。ADDS を処理する DLL がアンロードされるため、ADDS 関連の修正プログラムを適用したり、オフラインで DIT のデフラグを実行したりできます。ADDS の起動は NET START NTDS と同じくらい簡単です。ただし、システム状態のバックアップから DIT を復元する場合は、やはりディレクトリ サービスの修復モードで起動する必要があります。

ディレクトリ サービスは完全な Windows サービスではないことを理解する必要があります。このサービスは LSASS の必須コンポーネントであるため、コンピュータをシャットダウンしなければ LSASS を停止することはできません。しかし、Windows Server 2008 で提供されるディレクトリ サービスの開始および停止機能は、便利な選択肢であると言えます。

バックアップと回復

Windows Server 2008 では、バックアップおよび復元メカニズムが全面的に改良されています。ここではすべての詳細には触れませんが、新しい Windows Server バックアップでは、ADDS に影響する変更がいくつか加えられています。

Windows Server バックアップはボリューム ベースのバックアップ ソリューションです。つまり、一度にディスク ボリューム全体をバックアップします。また、ディスク (またはディスクと同等の) デバイスにしかデータをバックアップできず、テープへのバックアップはサポートされていません。

WBADMIN コマンド ライン バックアップ ユーティリティでは、システム状態のバックアップ オプションが提供されます。WBADMIN START SYSTEMSTATEBACKUP コマンドを使用すると、ドメイン コントローラで Active Directory を復元するときに使用する必要がある重要なシステム ファイルがすべて含まれたバックアップ イメージを作成できます。バックアップ セットには最大 5 個のボリュームを含めることができますが、バックアップ セット内のボリュームには、システム状態の復元に必要なファイルのみが格納されます。さらに困ったことに、Windows Server 2008 RC0 では、ネットワーク共有にシステム状態のバックアップを作成できません。このため、システム状態のバックアップ イメージを格納するためのローカル ディスク ボリュームを用意する必要があります。また、そのボリュームはシステム状態のバックアップのボリューム セットには含めないようにします。場合によっては、システム状態のバックアップを実行する各ドメイン コントローラに新しいディスク ボリュームを追加する必要があります。

システム状態の復元は簡単に実行できます。単に DC をディレクトリ サービス復元モードで起動し、WBADMIN START SYSTEMSTATERECOVERY コマンドを実行するだけです。これにより、DIT の権限のない復元が実行されます。ただし、Windows Server 2003 の場合と同じように、NTDSUTIL を使用して特定のオブジェクトの権限のある復元も実行できます。

Windows Server バックアップについて、特に触れておくべきことが 1 つあります。それは、バーチャル ハード ディスク (VHD) 形式でバックアップ イメージが格納されるということです。これは、Microsoft Virtual Server 2005 が仮想ディスク イメージの格納に使用するものと同じ形式です。つまり、Windows Server バックアップを使用して作成したバックアップ イメージを、Microsoft Virtual Server で実行されているバーチャル マシンのディスク ドライブとしてマウントできます。マウントしたら、通常のディスク ドライブと同じように、バックアップ コンテンツを参照できます。

ADDS のバックアップに関するもう 1 つの変更点は、ボリューム シャドウ コピー サービスを使用して、Active Directory の特定の時点のスナップショットを作成できるようになったことです。NTDSUTIL を使用してスナップショットを作成すると、ボリューム シャドウ コピー サービスは、更新操作によって自身が上書きされる前に、DIT の各ディスク ブロックの更新前のイメージを保存します。ボリューム シャドウ コピー サービスは、この更新前のイメージと現在の DIT を組み合わせることで、DIT の完全なスナップショットをごくわずかなオーバーヘッドで構築できます。DIT のサイズにかかわらず、通常のスナップショットの作成には数秒しかかかりません。

これだけでは、興味深い機能ではあっても、それほど便利であるとは言えません。ただし、Windows Server 2008 の ADDS では、スナップショット イメージを読み取り専用モードでマウントできる DSAMAIN というユーティリティが提供されます。このユーティリティを使用すると、スナップショットを作成した時点のディレクトリの内容が格納された ADLDS インスタンスのようなスタンドアロンの LDAP サーバーが提供されます。LDP ユーティリティや他の LDAP ツールを使用してディレクトリを参照することによって、以前のある時点のディレクトリ オブジェクトを取得できます。

DFS-R を使用した SYSVOL レプリケーション

Windows Server 2003 R2 では、分散ファイル システム (DFS) が強化され、DFS-R という新しいファイル レプリケーション メカニズムが組み込まれました。DFS-R は、Remote Differential Compression (RDC) を使用して、ソース ファイルと同期を取るためにレプリケートする必要があるターゲット ファイルのブロックを特定します。このため、ファイル レプリケーションのトラフィックが大幅に減少します。ただし Windows Server 2003 R2 は、ドメイン コントローラ間の SYSVOL レプリケーションには依然として (DFS-R ではなく) ファイル レプリケーション サービスを使用します。このため、SYSVOL レプリケーションは引き続き Active Directory の管理者の悩みの種になっていました。

Windows Server 2008 は、Windows Server 2008 のドメイン機能レベルで実行されている場合、DFS-R を使用して SYSVOL をレプリケートします。その結果、SYSVOL レプリケーションの速度と堅牢性が向上します。また、SYSVOL にサイズの大きなファイルを格納して、それらをすべての DC 上で提供できるようになります。SYSVOL に DFS-R を使用するには、まず DFSRMIG ユーティリティを使用して古い SYSVOL データを DFS-R に移行する必要があります。これを行うには、次の 4 つの手順を実行します。

  • DFS-R に必要な Active Directory オブジェクトを作成します。
  • 各ドメイン コントローラ上で SYSVOL 用の新しいファイル構造を作成します。
  • 新しい SYSVOL を使用するようにすべてのドメイン コントローラの設定を切り替えます。
  • 古い SYSVOL を削除します。

SYSVOL のサイズと使用しているドメイン コントローラの数によっては、この作業は時間がかかる可能性がありますが、パフォーマンスと信頼性が向上することを考えると実行する価値はあります。

監査機能の強化

Windows Server 2003 の Active Directory の監査システムは、良くもあり、悪くもありました。確かに一方では、非常に包括的で、柔軟性が高く、安全なディレクトリの変更追跡ソリューションが提供されています。しかし、重大なユーザビリティの問題がいくつか存在することを主張する意見もあります。

Windows Server 2003 のドメイン コントローラ上でディレクトリの変更の監査を有効にする場合、選択肢は有効か無効のみで細かい設定を行うことはできません。また、処理するデータの量が多い企業 DC での監査トラフィックの量を考えると、監査の実行は現実的でない場合もあります。個々のセキュリティ記述子に変更を加えて本当に必要なメッセージを生成できる監査システムを構成するには、非常に面倒で間違いも起きやすい作業を行う必要があります。通常、監査メッセージ自体は暗号化されており、多くの場合、変更された属性の変更前と変更後の値などの必要な情報は含まれていません。また、Windows に付属しているツールを使用しても、複数のドメイン コントローラのメッセージを収集、関連付け、およびアーカイブできるとは言い切れません。

Windows Server 2008 のディレクトリ サービス監査システムでは、これらの問題のいくつかが解決されています。まず、ディレクトリ サービスの監査に、DS Access (DS アクセス)、DS Changes (DS 変更)、DS Replication (DS レプリケーション)、Detailed DS Replication (詳細な DS レプリケーション) という 4 種類の監査サブカテゴリが追加されました。したがって、ディレクトリの変更のみを監査する場合に、すべての読み取りおよびレプリケーション イベントを確認する必要はなくなりました。しかし、監査ログにオブジェクトの削除に関する情報が記録されるようにするには、DS Access (DS アクセス) を有効にする必要があります。この場合、DS オブジェクトへのアクセスが発生するたびにメッセージが生成されるため、不要なメッセージが大量に生成されるという以前のような状態に戻ってしまいます。また、必要なオブジェクトの監査メッセージが生成されるようにセキュリティ記述子を構成する必要があります。

読みやすく、必要なデータのみが含まれるように、監査メッセージもかなり整理されています。特に、ディレクトリに変更が加えられたときに生成される監査ログ エントリには、変更された属性の変更前と変更後の値が含まれるようになりました。これは大きな進歩です。これについての唯一の欠点は、変更前の値と変更後の値が別々の監査ログ エントリに記録されることです。このため、変更の内容を完全に把握するには、エントリどうしを関連付ける必要があります。このような関連付けは、Microsoft Audit Collection Services などのさまざまな監査ログ収集アドオン製品でサポートされています。

UI の強化

Active Directory の管理には、これまでと同じように Active Directory ユーザーとコンピュータ、Active Directory サイトとサービス、および Active Directory ドメインと信頼関係 MMC スナップインを使用できます。Windows Server 2008 では、これらの基本的な管理ツールが整理され、便利な新機能がいくつか追加されています。拡張機能を有効にすると、各オブジェクトのプロパティ ダイアログ ボックスに [属性エディタ] というタブが追加されます。これは、ADSIEdit で使用される属性エディタのタブと同じものであり、オブジェクトのすべての属性を確認および編集できます。このタブ自体は、userAccountControl 属性など、エンコードされた属性のデコード機能が強化されています。図 8 は、シームレスに統合された属性エディタを示しています。

図 8 Active Directory ユーザーとコンピュータに統合された属性エディタ

図 8** Active Directory ユーザーとコンピュータに統合された属性エディタ **(画像を拡大するには、ここをクリックします)

まとめ

この記事では重要なポイントのみを説明しましたが、Windows Server 2008 の ADDS には、他にも多くの機能強化が施されています。たとえば、ドメインの機能レベルが Windows Server 2008 である場合、KDC では 256 ビットの Advanced Encryption Standard (AES-256) が使用されます。また、DS オブジェクトの [オブジェクト] タブにあるチェック ボックスをオンにして、オブジェクトを過失による削除から保護することもできます。データ管理サービスを提供する Extensible Storage Engine は、単一ビットのエラー修正によって強化されています。この機能を使用すると、DIT が破損したときにディスク サブシステムのハードウェアまたはソフトウェアでエラーが発生する可能性を低下させることができます。DNS サービスは、DNS データベースを完全に読み込む前に要求の処理を開始するようになりました。DC ロケータ モジュールは、目的のサイトで DC を見つけられない場合に、ドメイン内で見つかった DC を無作為に使用するのではなく、目的のサイトに近いサイトの DC を検出するように改良されています。NTDSUTIL では、RODC とボリューム シャドウ コピー サービスのスナップショットがサポートされるようになりました。

Windows Server 2008 では、Active Directory ドメイン サービスの機能が大幅に強化されていることは明らかです。これらすべての変更点により、ADDS のセキュリティと管理の容易さが大幅に向上します。しかし最大のメリットは、Windows Server 2008 を Active Directory 環境に導入するときに大規模な移行作業を実施する必要がなく、段階的なプロセスを使用して簡単に導入できることです。

Gil Kirkpatrick は NetPro 社の最高技術責任者であり、1996 年以来 Active Directory 用ソフトウェアの開発に取り組んできました。彼が HP 社の Guido Grillenmeier と共同で行う Active Directory の障害回復ワークショップは好評です。また、彼は Directory Experts Conference (www.dec2008.com) の発起人でもあります。

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