Windows Server 2008 R2 ドメイン コントローラー: 入念に RODC を計画する
Paul Yu
物理的なセキュリティが欠如しているときには、データのセキュリティを高めることが必要不可欠です。Windows Server 2008 と Windows Server 2008 R2 には、物理的なセキュリティが厳密に確保されていないリモート オフィスなどの環境を対象とした、セキュリティを確保するための新しい方法が用意されています。読み取り専用ドメイン コントローラー (RODC) は、Windows Server システムの Active Directory ドメイン サービス (AD DS) の新しい機能です。RODC の登場により、ドメイン コントローラー (DC) の基本的な使い方が根本的に変わりました。
多くの RODC の新機能は、設計と展開プロセスの主要な部分に影響するため、ご使用の環境で RODC をどのように活用できるかを理解することが重要です。また、RODC を導入する前に考慮しなければならない設計と計画上の重要な考慮事項もあります。RODC は、完全な読み取り専用の Active Directory データベース パーティションのコピー、SYSVOL の読み取り専用コピー、書き込み可能な DC から特定のアプリケーション データの入力方向のレプリケーションを制限する RODC で除外される属性セット (FAS) をホストする DC です。
既定では、RODC は、ユーザー アカウントやコンピューター アカウントの資格情報を選択的に保持することはありませんが、そのように構成することは可能です。このように構成するだけで、データセンターのイントラネットと同じレベルの物理的なセキュリティが確保されていないリモート ブランチ オフィスや境界ネットワークで RODC を使用できるようになります。知名度はそれほど高くありませんが、RODC には、他にもセキュリティ機能が用意されています。たとえば、RODC 自体が危険にさらされるチケット ベースの攻撃に対応する特殊な Kerberos チケット保証アカウントなどがあります。
RODC を展開する一番の理由はセキュリティ上の問題ですが、企業における管理容易性とスケーラビリティなど、RODC を使用するメリットは他にも多数あります。一般的に、RODC は、ローカルで認証や承認を行う必要があっても、書き込み可能な DC を安全に使用するのに必要な物理的なセキュリティが欠如している環境を対象としています。そのため、RODC は、データセンターの境界ネットワークやブランチ オフィスで最も一般的に使用されます。
たとえば、RODC は、AD DS が必要であっても、セキュリティ上の制約から境界ネットワークで企業の AD DS フォレストを使用できないデータセンターで展開できます。この場合、RODC が、適切なセキュリティ要件を満たし、企業の AD DS 実装のインフラストラクチャ スコープが変化する可能性があります。このような状況が発生する頻度は高くなることが予想されます。また、拡張した企業のフォレスト モデルなど、境界ネットワークの現在の AD DS モデルのベスト プラクティスも反映しています。
RODC を使用するブランチ オフィス
今もなお、AD DS を使用する RODC の最も一般的な環境は、ブランチ オフィスです。一般的に、このような環境は、ハブ アンド スポーク型ネットワーク トポロジのエンド ポイントになっています。地理的に広い範囲に多数のブランチ オフィスが分散しています。また、各オフィスで個別に少数のユーザーをホストし、低速で不安定なネットワーク リンクでハブ サイトに接続し、多くの場合、各サイトには経験豊富な管理者がいません。
既に書き込み可能な DC をホストしているブランチ オフィスに RODC を展開する必要は、おそらくないでしょう。ただし、このシナリオで RODC を使用すると、既存の AD DS に関する要件を満たすだけでなく、セキュリティを強化し、管理容易性を向上し、アーキテクチャの簡略化と総保有コスト (TCO) の低下を実現できるというメリットがあります。セキュリティや管理容易性の要件により DC を使用できない場所では、RODC を使用すると、環境に DC を導入して、多数の便利なサービスをローカルで提供できるようになります。
RODC には評価に値する新機能とメリットがありますが、アプリケーションの互換性、サービスに影響する状況など、いくつか考慮しなければならないことがあります。このような要件により、RODC の展開を断念せざるを得なくなる場合もあります。
たとえば、多くのディレクトリに対応しているアプリケーションとサービスでは AD DS からデータを読み取りますが、このようなアプリケーションとサービスは RODC でも問題なく動作すると考えられます。ただし、書き込みのアクセス許可が常時必要なアプリケーションでは、RODC を使用することはできません。RODC で書き込み操作を行う際には、書き込み可能な DC へのネットワーク接続が必要になります。書き込み操作のエラーは、最も一般的なアプリケーションの問題の原因となる可能性がありますが、非効率的な読み取り操作や読み取り操作でのエラー、書き込み-再読み込み操作でのエラー、RODC 自体に関する一般的なアプリケーションのエラーなど、他にも考慮しなければならない問題があります。
アプリケーションの問題以外にも、書き込み可能な DC への接続が中断または切断されると、ユーザーやコンピューターによる基本的な操作に影響を及ぼすことがあります。たとえば、アカウントとパスワードの両方を RODC のローカルにキャッシュできない場合、基本的な認証サービスは機能しません。RODC のパスワード レプリケーション ポリシー (PRP) を使用してアカウントをキャッシュできるようにし、事前にパスワードを設定してパスワードをキャッシュすることで、この問題は簡単に軽減できます。この手順の実行にも、書き込み可能な DC への接続が必要になります。
認証に関する問題は他にもありますが、パスワードの有効期限やアカウントのロックアウトは、書き込み可能な DC に接続できない場合に大きな影響を受ける問題です。パスワードの変更を要求したり、ロックされたアカウントのロックを手動で解除しようとしても、書き込み可能な DC への接続が回復するまで、これらの操作はエラーになります。このような依存関係と運用上の動作の変化を理解することは、要件とサービル レベル アグリーメント (SLA) を確保するうえで重要です。
RODC を展開できる一般的なシナリオは、いくつかあります。RODC は、DC が展開されていない場所や新しいバージョンの Windows の DC に置換またはアップグレードされる予定の DC をホストしている場所で使用すると便利です。各シナリオ固有の包括的な計画に関する考慮事項はありますが、この記事では汎用的なアプローチを紹介します。ただし、これらのアプローチは RODC 固有のもので、従来の書き込み可能な DC には適用できないことに注意してください。
事前の計画
正式な RODC の計画を始める前に、AD DS に関する事前計画の適切かつ基本的な評価を適用する必要があります。これには、既存の AD DS の論理構造を評価したり、管理モデルや AD DS 物理構造が既存のビジネス要件と技術的な要件を満たすようにするなど、重要な作業を行うことも含まれます。ハードウェア要件、ソフトウェア アップグレードの戦略、該当するオペレーティング システムに関する既知の問題を考慮し、RODC の AD DS の前提要件を評価する必要があります。この情報は、計画と展開のプロセスで必要不可欠です。詳細な展開のチェック リストでは、これらの事項が適切に解説されています。
インストールと管理
RODC には、管理者の役割の分離 (ARS) と呼ばれる重要な管理機能が用意されています。この機能では、サービス管理者以外に、Active Directory の権限を与えることなく、RODC サーバーをインストールして管理する権限を委任します。これは、DC サーバーの設計、管理の委任、展開の手順という点に関して、従来の考慮事項から大きく変わった点です。この管理機能は、DC に直接インストールする必要がある重要なアプリケーションや、複数の役割を持ったサーバーをホストしている場所でますます重要になります。
追加のサーバーの役割
一般的に、RODC が機能するために必要ではない役割は、サーバーにインストールしないことをお勧めします。つまり、RODC サーバーに追加すべき役割は、DNS サーバーの役割とグローバル カタログ サーバーの役割だけです。書き込み可能な DC へのネットワーク接続が利用できないときに、ローカルの DNS クライアントが DNS 解決を実行できるようにするため、各 RODC には、DNS サーバーの役割をインストールする必要があります。ただし、Dcpromo.exe を使用して DNS サーバーの役割をインストールしていない場合は、この役割を後からインストールする必要があります。Dnscmd.exe を使用して、Active Directory に統合されているゾーンをホストしている DNS アプリケーション ディレクトリ パーティションに RODC を登録する必要があります。また、RODC はグローバル カタログ サーバーとして構成し、RODC を単独で使用して認証やグローバル カタログ クエリを実行できるようにする必要もあります。グローバル カタログ サーバーの役割をインストールできない場合、認証については、ユニバーサル グループ キャッシュを使用できます。突き詰めていくと、ユーザーが RODC で正常に認証されるには、RODC の PRP の構成が鍵を握っていると言えます。
RODC の交換
DC の展開は、RODC の PRP の導入により、大きく変化しました。同じドメインで Windows Server 2008 または Windows Server 2008 R2 を実行している書き込み可能な DC でしか、RODC の PRP を強制できないため、RODC では、このような DC のドメイン パーティションをレプリケートできる必要があります。適切なレプリケーションが行われるようにするには、RODC が配置されているサイトへのサイト リンクのコストが最も低い AD DS サイトに書き込み可能な DC を配置する必要があります。
この構成を実現できない場合、RODC のレプリケーションでは、"サイト リンクをすべてブリッジ" (つまり、サイト リンクの推移性) の設定を使用するか、RODC サイトと書き込み可能な DC のサイトを含むサイト リンク間のサイト リンク ブリッジを使用する必要があります。サイトの推移性やサイト リンク ブリッジを使用できない場合は、RODC サイトと書き込み可能な DC を直接接続する新しいサイト リンクを作成できます。
一般的なベスト プラクティスとして、RODC と同じ AD DS サイトには DC を配置しないことをお勧めします。このような構成にすると、クライアント側の動作に一貫性がなくなり、クライアント側の動作が予測不可能になります。認証、LDAP の読み込みと書き込み、パスワードの変更など、基本的な操作は、RODC のさまざまな構成、書き込み可能な DC で実行されている Windows のバージョン、他の書き込み可能な DC へのネットワーク接続が利用できるかどうかによって異なります。ですから、特定のドメインのユーザーとリソースは、同じ RODC サイトに集めることをお勧めします。RODC では、信頼パスワードを格納しないので、認証要求を各ドメインの書き込み可能な DC に転送するためにドメインを越えた承認が必要になります。書き込み可能な DC が個別のサイトに配置されていると、すべてのドメインを越える認証要求は、ネットワーク接続が必要になり、ネットワーク接続が利用できない場合は認証を行えなくなります。
スケーラビリティとレプリケーション
RODC には、より大規模で複雑な AD DS の実装に役立つスケーラビリティに関するメリットもあります。たとえば、RODC では、片方向のレプリケーションを行えます。RODC をブランチ オフィスに展開すると、通常、ブランチ オフィスの DC の入力方向のレプリケーションを処理するハブ サイトのブリッジヘッド サーバーのパフォーマンスの負荷が軽減します。TCO の観点では、RODC をブランチ オフィスに展開すると、作成および管理する接続オブジェクトの数が減ります。また、必要なハブ サイトの DC の数も削減できます。
RODC では、発信接続オブジェクトをハブサイト ブリッジヘッド サーバー間で自動的かつ均等に分散するのに役立つ負荷分散機能も強化されています。以前のバージョンの Windows で、この操作を行うには、定期的な手動による調整が必要でした。RODC の知識整合性チェッカー (KCC) では、ハブ サイトでブリッジヘッド サーバーが追加または削除されたことを検出すると、レプリケーション パートナーを新しいブリッジヘッド サーバーに切り替えるかどうかを判断します。この処理は、アルゴリズムと確率的な負荷分散を実行することで行っています。RODC がブランチ オフィスに追加されると、KCC では、既存のハブサイト ブリッジヘッド サーバー間で着信接続の負荷を分散します。
資格情報のキャッシュ
RODC の PRP では、特定の RODC にアカウントをキャッシュできるかどうかを判断します。既定では、PRP の許可リストは、アカウントのパスワードをキャッシュできない設定になっています。また、特定のアカウントがキャッシュされることを明示的に拒否しています。拒否の設定は、手動で構成した許可の構成に優先されます。既に説明したように、アカウントのパスワードをキャッシュできるように、各 RODC の PRP を構成しなければならないことがあります。
PRP の構成を変更すると、セキュリティとサービスの可用性の両方に影響を及ぼすので、この作業は慎重に行う必要があります。たとえば、どのアカウントもキャッシュされない既定のシナリオでは、セキュリティは高くなりますが、書き込み可能な DC へのネットワーク接続が利用できないときには、オフライン アクセスが許容されません。一方、ドメイン ユーザー グループなど、多数のアカウントをキャッシュできるようにすると、RODC が危険にさらされるとセキュリティが大幅に低下しますが、キャッシュされたアカウントについては、サービスの可用性のレベルが高くなります。インフラストラクチャ環境によって、ビジネス要件や技術的な要件は異なるので、PRP の設定は企業によって異なります。
PRP モデルを確立したら、各 RODC の PRP を構成して、適切なアカウントをキャッシュできるようにする必要があります。PRP を構成する際には、明示的な許可リストを使用し、既定の拒否リストは変更しないことをお勧めします。拒否リストは、AD DS サービスの管理者など、重要なアカウントの資格情報が RODC にキャッシュされないようにしているので、拒否リストは重要です。
PRP の設計では、キャッシュ可能なアカウントにパスワードを設定するかどうかも重要な検討事項です。既定では、キャッシュ可能なアカウントの資格情報は、RODC に初めてログオンするまでキャッシュされません。初回ログオン時に、認証要求が Windows Server 2008 または Windows Server 2008 R2 の書き込み可能な DC に転送され、資格情報が RODC にレプリケートされます。つまり、アカウントが RODC に対して認証される前に、書き込み可能な DC へのネットワーク接続が使用できなくなると、アカウントがキャッシュできるように構成されていても、正常に処理されるべきログオン操作でエラーになります。
この問題に対処するには、PRP の構成後すぐにパスワードを手動で設定して、アカウントをキャッシュ可能なアカウントとして指定します。この操作には、Windows Server 2008 または Windows Server 2008 R2 の書き込み可能な DC と RODC 間でネットワーク接続が必要になります。この処理は、展開時など、アカウントをアカウントをキャッシュできるように構成したユーザーが初めてログオンするよりかなり前に行えます。
この基本的なアーキテクチャの設計ガイドは、RODC の計画を立てる土台としてご利用いただけます。基本的な設計の考慮事項を紹介することで、この記事では、詳細で包括的な RODC のソリューションを設計するたたき台となる情報を提供しました。RODC の展開は、単純な作業ではなく、企業固有の環境や要件に基づいて新機能や設計上の考慮事項を調整するのには、かなり時間がかかることに注意してください。
Paul Yu (Paul.Yu@microsoft.com、英語のみ) は、Microsoft Consulting Services のシニア コンサルタントで、マイクロソフトに 10 年勤めています。一般企業や政府系機関にインフラストラクチャ ソリューションを提供しています。