Windows の管理

機能する OU 構造を設計する

Ken St. Cyr

概要:

• 適切な OU 設計の基本原則
• 一般的な OU 設計モデル
• OU 設計を文書化する

適切な組織単位 (OU) 構造を設計することの重要性と複雑さを過小評価しないでください。多くの IT 部門は、次のいずれかの方向に向かう傾向があります。

OU 構造を過度に重視するか、OU 構造が十分に考慮されないという 2 つのいずれかです。どちらの場合も、Active Directory® モデルに関する問題を引き起こす可能性があります。

OU 構造を過度に重視すると、Active Directory 設計以外の領域 (サイト トポロジの計画、ドメイン コントローラのサイズの検討など) が十分に考慮されないことがあります。また、OU 計画を後回しにすると、グループ ポリシー機能と委任機能が有効活用されません。

適切な OU 構造が設計されない理由の 1 つとしてよく挙げられるのは、OU 構造には柔軟性があるため適切でない場合は後から変更できる、というものです。確かに、OU 構造には柔軟性があります。しかし、多くの管理者は、OU 構造を後から変更することが、当初予想していたよりも難しいことに気付きます。新しい OU を追加することはできますが、古い OU を削除するのは容易な作業ではありません。

適切に計画されていない OU 構造は、独り歩きする傾向があります。新しいオブジェクトがディレクトリに作成されたときに、管理者がそのオブジェクトを配置する OU 構造の場所を把握していない場合、その管理者は、新しい OU を作成するか、不適切な場所にそのオブジェクトを配置することになります。いずれの場合にも、危険が伴います。新しい OU の作成は簡単に行うことができますが、このように対応すると、長期の運用において OU の管理が困難になります。過剰な OU の作成により、OU 構造が無秩序状態になり、ディレクトリに不正侵入されやすくなります。また、オブジェクトを、そのオブジェクトが実際には属さない既存の OU に追加すると、新しいオブジェクトに不適切なポリシーが適用されたり、そのオブジェクトへのアクセス許可が意図しないユーザーに委任されたりする場合があります。

OU 構造を設計する際には、"簡潔さ + 適応性 = 安定性" という基本的な方程式を念頭に置いておく必要があります。設計が簡潔すぎると、その設計には柔軟性が欠けることがあり、設計を頻繁に変更することが必要となります。設計に適応性がありすぎると、すべてが区分化されるため、その設計は複雑になりすぎます。

グループ ポリシー、委任、およびオブジェクト管理に関して、設計上の方針の指針となる 3 つの基本原則があります。これらの原則は、次の 3 つの質問に置き換えることができます。これらの質問を自問することで、作成している OU 構造に、長期運用と組織変更への適応性があることを確認できます。

1. この OU は、固有のグループ ポリシー オブジェクト (GPO) を適用できるように作成される必要がありますか。
2. 特定の管理者グループが、この OU 内のオブジェクトへのアクセス許可を持つ必要がありますか。
3. この新しい OU によって、この OU 内のオブジェクトの管理が容易になりますか。

上記のいずれかの質問の答えが "はい" の場合には、OU を作成することをお勧めします。3 つすべての質問の答えが "いいえ" の場合には、設計を再考し、より適切な別の設計を検討する必要があります。この 3 つの基本原則の適用方法を詳しく説明する前に、まず、これらの原則が重要である理由を説明します。

原則 1: グループ ポリシー

OU 設計の 1 つ目の原則は、OU に適用されるグループ ポリシー オブジェクトを考慮することです。GPO を使用すると、ユーザーとコンピュータの設定を、強制可能な形で構成できます。Active Directory では複数の GPO を定義し、それらの GPO をドメイン全体、さまざまな OU、またはドメイン内のサイトにも適用できます。GPO は、ユーザーとコンピュータという 2 つのカテゴリに分類されます。

コンピュータ ポリシーとユーザー ポリシーの両方を 1 つの GPO で定義できます。GPO のユーザーの構成のセクションでは、主に、ログイン時のユーザー操作が定義されます。このような設定は、コンピュータの構成のセクションにも存在しますが、このセクションには、コンピュータにローカルでログオンできるユーザーや、データの暗号化方法など、コンピュータのセキュリティに関する設定がより多く含まれます。

GPO をサポートするように OU を定義する際に留意する基本事項を挙げておきます。まず、ユーザー ポリシーとコンピュータ ポリシーの両方を 1 つの GPO で定義できますが、ユーザー オブジェクトとコンピュータ オブジェクトを同じ OU に配置することが適切であるというわけではありません。このように 2 種類のポリシーを 1 つの GPO で定義すると、GPO の適用に関するトラブルシューティングが困難になります。これは、ループバック ポリシーが有効になっている場合により顕著に現れます。

次に、忘れられがちなことですが、GPO はサイト レベルで適用できるため、GPO を適用するためにサイト構造をモデル化して OU 構造を設計できます。これは、OU 設計の一般的なモデルであり、地理的モデルと呼ばれます。このモデルについては、この後すぐに詳しく説明します。地理的モデルが OU 設計において適切な役割を持っていることは認めざるを得ませんが、後述するように、このモデルを実装する最大の理由は GPO を適用するためだけとは限りません。

また、GPO の観点では、OU 構造を検討する際の最終的な目標は、複雑さの軽減です。OU で GPO の継承をブロックしないようにしてください。OU に、他のサーバーと同じポリシーを必要とするサーバーが含まれる場合、これらのコンピュータ オブジェクトを上位の "サーバー" OU に配置し、"サーバー" OU の下に、サーバーの種類ごとに複数の OU を作成することを検討してください (図 1 参照)。この構成により、下位 OU 内の各コンピュータ オブジェクトには、"サーバー" OU に設定されているポリシーと、各サーバーの種類固有の他のポリシーを適用できるため、ポリシーの適用を簡略化できます。

Figure 1** Creating multiple OUs for different server types **(画像を拡大するには、ここをクリックします)

もう 1 つの基本事項は、複数の GPO を不必要に作成したりリンクしないようにすることです。1 つの GPO では、1 つのポリシーを作成し、作成したポリシーを複数の OU に適用できます。これは、役立つ場合もありますが、悪影響を及ぼす場合もあります。GPO の設定を変更する必要があるときに、複数の GPO がリンクされた過度に複雑なシステムである場合、変更を誤って不適切なオブジェクトに適用してしまう可能性があります。リンクを作成すればするほど、ポリシーの適用範囲を把握するのが困難になります。また、他のポリシーと同じ設定を持つポリシーを新たに作成しないようにすることをお勧めします。同じ設定のポリシーを何度も作成している場合は、新しい GPO 継承モデルを適用できるように OU 構造を変更することを検討してください。

最後に、ほとんどの場合、ユーザー オブジェクトとコンピュータ オブジェクト用に新しい OU を作成する必要があります。既定では、ユーザー オブジェクトとコンピュータ オブジェクトはコンテナに配置されますが、コンテナでは、オブジェクトに直接 GPO をリンクすることはできません。GPO は、ドメインの "ユーザー" コンテナと "コンピュータ" コンテナに適用できますが、継承をどこかでブロックしない限り、GPO はドメイン内のすべてのユーザーとコンピュータに適用されます。Windows Server® 2003 では、rediruser.exe ツールと redircomp.exe ツールを使用して、ユーザー オブジェクトおよびコンピュータ オブジェクトの既定の場所を、各オブジェクト用に作成した OU に変更できます。

原則 2: 委任

OU 構造は、ドメインでアクセス許可が委任される方法と整合性の取れた方法で作成することが重要です。Active Directory でアクセス許可が委任されるとき、アクセス許可の変更は、オブジェクトのみに対して加えられることに注意してください。そのため、ユーザーに特定のコンピュータ オブジェクトのフル コントロールのアクセス許可を与えた場合、そのユーザーは、そのオブジェクトの属性を変更することはできますが、コンピュータ自体の管理者特権は持ちません。

次に、委任に関して、OU 構造の設計時に推奨するいくつかの方法を示します。

アクセス許可の継承を考慮して設計する たとえば、第 1 層の管理者が、大部分のアカウントのパスワードを変更できるようにする必要があるとします。特別なユーザー グループがあり、そのパスワードについては、管理者が再設定できないようにする必要がありますが、そのアカウントの表示名については、管理者が変更できるようにすることが必要です。

この場合、2 つの選択肢があります。1 つは、類似した 2 つの OU を個別に作成し、特別なユーザーと一般ユーザーを分けることができます。しかし、この方法では、すべてのユーザーに対する委任の設定を変更する場合、アクセス許可を 2 つの異なる場所で変更する必要があります。また、この方法は複数のポリシーを不必要にリンクしないという基本事項に相反します (図 2 参照)。

Figure 2** Maintaining two separate parallel OUs **(画像を拡大するには、ここをクリックします)

もう 1 つの選択肢は、入れ子になった OU を作成して、特別なユーザーが含まれる OU でアクセス許可を明示的に拒否する方法です。委任について詳しい知識がある人は、明示的な拒否を設定することを推奨しません。しかし、この場合には、推奨されないものの中からより適切な方を選択する必要があります (図 3 参照)。類似した 2 つの OU を個別に作成して設定を別々に管理するか、OU の 1 つでアクセス許可を明示的に拒否する、といういずれかの方法を選択できます。実際の長期的な方針としては、明示的な拒否の方がより適切です。

Figure 3** Using an explicit deny permission **(画像を拡大するには、ここをクリックします)

AdminSDHolder に注意する この例は、すべての特別なユーザーが、管理グループのいずれか (Domain Admins、Schema Admins、Enterprise Admins、または Administrators) に属している場合を除いて有効です。これらのグループに属するアカウントのアクセス許可は異なる方法で処理されます。誤ってだれかに管理者アカウントへのアクセス許可を与えないようにする必要があります。

管理者用に個別の OU を作成すると、委任されたアクセス許可が失われていることがあります。これは、アクセス制御リストを指定の間隔ですべての管理者アカウントに適用する、特別なコンテナである AdminSDHolder による現象です。したがって、管理者アカウントに対して行った委任の変更は、AdminSDHolder コンテナに対しても同じ変更を行わないと、元に戻されます。そのため、委任のために、管理者アカウントとその他のアカウントを分けないようにする必要があります。ただし、グループ ポリシーの観点では管理者アカウントと一般ユーザー アカウントを分けることをお勧めします。これは、特に、複数のパスワード ポリシーを設定できる Windows Server 2008 に当てはまります。

原則 3: オブジェクト管理

OU により、オブジェクトの管理が容易になります。多くの場合、オブジェクトを同じ OU にグループ化することで、一括変更をより簡単に実行できるようになります。Active Directory ユーザーとコンピュータ スナップインを使用すると、複数のオブジェクトを選択して、その特定の属性を編集できます。したがって、あるオブジェクト グループの属性を定期的に変更する必要がある場合、すべてのオブジェクトが同じ OU に属していると変更作業が楽になります。

これは、スクリプトを使用して更新を行う場合に特に役立ちます。スクリプト言語を使用すると、OU 内のすべてのオブジェクトを列挙して、オブジェクトを 1 つずつ処理する作業が非常に簡単になります。また、各オブジェクトを個別に検索および変更する作業も簡単に行えます。管理目的で、オブジェクトを同じ OU に配置するだけで、一部の作業が不要になり、毎週何時間もの時間を節約できる場合があります。

オブジェクト管理に役立つ別の方法は、オブジェクトを種類ごとに異なる OU に分けることです。プリンタ オブジェクトや公開済みの共有用に個別の OU を作成すると、OU 内の他のオブジェクトを管理するときに、これらのオブジェクトを除外する必要がなくなります。この方法は、ユーザー アカウントとコンピュータ アカウントを同じ OU にまとめてグループ化しないという基本事項に従っています。

モデルを選択する

OU 設計の原則の説明が終わったところで、次に、いくつかの一般的な設計モデルについて詳しく見てみましょう。ここで取り上げるモデル以外にも多くのモデルがあることに注意してください。また、選択できるモデルは 1 つだけではありません。各モデルから必要な要素を選択し、特定のニーズに対応する独自の複合型モデルを構築できます。

どのモデルも、小規模企業では適切に利用することができます。しかし、企業が拡大するにつれ、環境の管理能力は低下します。そのため、まず、適切なラボ環境でモデルを徹底的にテストするようにしてください。また、OU 構造は、最初のうちは簡単に変更できますが、実装期間が長くなるほど変更が困難になることを忘れないでください。

浅部モデル

浅部モデルという名称は、その構造がほぼフラットであることに由来しています。このモデルでは、少数の上位レベルの OU に、大部分のオブジェクトが含まれます (図 4 参照)。このモデルは、多くの場合、IT 部門が小規模な企業、部門数が少ない企業、または各人が複数の任務を担う傾向にある企業など、小規模企業で使用されます。通常、私は、OU の階層構造でサブ OU が 10 個を超える深さにならないようにすることを推奨していますが、マイクロソフトが推奨するパフォーマンスの低下を防ぐためのサブ OU の制限は 15 です。

Figure 4** The Shallow Model has a few high-level OUs that contain the majority of objects **(画像を拡大するには、ここをクリックします)

人事担当者が給与管理も担当している場合、人事用と給与管理用に 2 つの異なる OU を作成することに意味はありません。浅部モデルでは、すべてのユーザー オブジェクトを、1 つの大きな "アカウント" OU にグループ化するか、既定の "ユーザー" コンテナに配置できます。少なくとも、ユーザー オブジェクトとコンピュータ オブジェクトを分ける必要があります。

このモデルでは、一歩先まで踏み込んで、ワークステーションとサーバーを分けることもお勧めします。このような構成にすると、少なくとも、Windows® Management Instrumentation (WMI) クエリを使用して、ワークステーションまたはサーバーをフィルタで除外する GPO を定義することなく、ワークステーションとサーバーに異なるグループ ポリシーを適用することができます。

OU 構造に深さではなく幅を持たせるメリットの 1 つは、Active Directory 検索を高速化できる点です。通常、私は、サブ OU が 10 個を超える深さにならないようにすることを推奨しています。このモデルでは、あまりきめ細かくオブジェクトを制御することはできませんが、小規模企業でオブジェクトを管理している場合には、それほどきめ細かい制御は必要ありません。つまり、このモデルは、大企業での使用には適していませんが、小規模企業での使用には最適なモデルだと言えます。

地理的モデル

地理的モデルでは、地域ごとに個別の OU を作成します。このモデルは、分散型の IT 部門を持つ企業で、複数ドメインの運用に伴うコストの発生を望まない場合に最適です (図 5 参照)。

Figure 5** The Geographic Model separates OUs by geographical region **(画像を拡大するには、ここをクリックします)

たとえば、アトランタ、ボルティモア、およびシアトルに支社があるとします。各拠点でそれぞれのユーザーとコンピュータを管理している場合、委任の観点から、このモデルが最適な場合があります。しかし、シアトル支社のユーザーが研修のためにボルティモア支社に行き、自分のアカウントをロックアウトした場合はどうなるでしょうか。ボルティモア支社の IT スタッフは、このユーザーのアカウントへのアクセス許可が委任されていない場合、このユーザーをサポートできない可能性があります。ボルティモアが午前 8 時であるとすると、シアトルは午前 5 時です。つまり、ユーザーは、シアトル支社のスタッフのサポートを得るまで数時間待たなければなりません。

一部の世界的企業では、"太陽追従" モデルを使用しています。その場合、ヘルプ デスクへの問い合わせは、その時点で、通常の業務時間中であるタイム ゾーン内の拠点に転送されます。つまり、企業は、各拠点のヘルプ デスクを 24 時間対応にしなくても、業務時間外でも必要なときに従業員にサポート (アカウントのロック解除など) を提供できます。

このような場合、地域ごとに個別の OU を作成することは、運用上のニーズに最も適した方法ではないでしょう。各地域の "ユーザー" OU に対する個別のアクセス許可を各地域のヘルプ デスクに委任する必要があります。しかし、各拠点に独立した IT 部門がある場合は、地理的モデルがその企業に適したモデルであることがあります。

また、地理的モデルは、ドメインの運用方法の性質上、単一のドメインでの利用は困難です。単一のドメインを運用している場合、他の複数のドメインを運用している場合とは異なるセキュリティ モデルを採用している傾向があります。これは、Microsoft® Exchange Server などの全社規模のアプリケーションを見るとより明らかです。

アトランタ支社で運用している Exchange Server で異なるメッセージ ポリシーを定義することは可能ですが、企業内のすべての Exchange Server には、おそらく同じ GPO が適用されています。この場合、地域ごとに Exchange Server を個別の OU に配置すると、同じ GPO が複数の OU に不必要にリンクされる原因となります。委任の観点から、Exchange Server の管理者が本当に Exchange Server のコンピュータ オブジェクトへの固有のアクセス許可を必要としているかどうかを確認する必要があります。ほとんどの場合、コンピュータ オブジェクトが地域ごとの OU に分けられるのは、委任のためではなく、グループ ポリシーのためです。

種類ベース モデル

種類ベース モデルでは、オブジェクトを目的ごとに分類します (図 6 参照)。前回ユーザー オブジェクトを作成したとき、それは、一般ユーザー アカウント、管理者アカウント、またはサービス アカウントのうち、どのアカウントとして作成したものでしょうか。種類ベース モデルでは、これらのオブジェクトの処理がそれぞれ異なります。

Figure 6** The Type-Based Model groups objects according to their functions **(画像を拡大するには、ここをクリックします)

通常、ポリシーを適用するには、ユーザー オブジェクトの分類を識別する必要があります。ほとんどの場合、ポリシーはユーザー アカウントの種類によって異なります。たとえば、ユーザーがサービス アカウントを使用してコンピュータにログオンできるようにすることは、業務上、一般的に適切ではありません。通常、サービス アカウントのパスワードは、多数のユーザー間で共有されるので、サービス アカウントを使用してログオンすると、そのユーザーは匿名ユーザーになります。何か問題が発生した場合、イベントの発生時にログインしていたユーザーの特定が困難になります。この例では、サービス アカウントに、対話型ログオンを防ぐポリシーを設定する必要があります。これは、図 3 の階層モデルに適しています。

ここで、GPO の継承を活用できます。たとえば、すべてのユーザー オブジェクトに設定されるポリシーを参照する、全ユーザー用ポリシーを適用できます。また、全ユーザー用ポリシーをベースに作成した、サービス アカウント用の個別の異なるポリシーを適用できます。この方法によって、サービス アカウントには、その他すべてのアカウントと同じ一連の基本ポリシーと、特定のログオンの制限を適用できます。

この方法は、GPO の継承ではなく、アクセス許可の継承を使用している委任でも有効です。たとえば、第 2 層の管理者が、第 3 層の管理者アカウントを除く、すべてのアカウントのパスワードを再設定できるようにする必要があるとします。フラットな OU 構造では、ユーザー アカウントが含まれる各 OU にアクセス許可を委任する必要があります。しかし、階層構造を持つ種類ベース モデルでは、第 2 層のグループに "アカウント" OU に対する "パスワードの再設定" アクセス許可を付与してから、第 3 層の OU で、単純にアクセス許可を継承しないようにするか、第 2 層に対してパスワードの再設定を明示的に拒否できます。

これは、コンピュータ オブジェクトの場合にも有効です。異なるポリシーを適用できるように、サーバーとワークステーションを分けることができます。さらに、"サーバー" OU を機能ごとに細分化できます (図 1 参照)。この設計では、すべてのサーバーに適用する上位レベルのポリシーを "サーバー" OU に設定して、下位レベルの OU ごとに個別のポリシーを設定できます。

たとえば、Microsoft Operations Manager (MOM) サービス アカウントがあるとします。この階層化モデルを使用すると、MOM 用の GPO を作成し、それを MOM OU に適用できます。そして、MOM 用の GPO で、サービスとしてログオンするための権限を MOM サービス アカウントに付与できます。この GPO は、MOM OU 内の MOM サーバーにのみ適用されます。MOM サーバーには、上位レベルの "サーバー" OU の全サーバー用ポリシーが適用されるだけでなく、MOM OU にリンクされている特別な MOM 用の GPO も適用されます。

設計を文書化する

Active Directory 環境で発生する多くの変更に対応できる OU 構造を設計することには、非常に大きな価値があります。しかし、動的な OU の特性を追跡する手段が必要です。追跡する手段がないと、すぐに環境を管理できなくなります。変更事項が発生し、OU の追加または削除が必要になったときには、処理方法に関する明確な指針が必要です。その指針によって、モデルが、3 つの基本原則を満たしながら継続して設計モデルに従うようにします。そのため、適切な解説が記載された設計書が必要です。

マイクロソフトは、Windows Server リソース キットで文書化のガイドを提供しています。このガイドは、あまり多くの変更が行われないことが予想される、安定した枠組みを持つ構造では有効です。しかし、ほとんどの企業で実装する構造は、頻繁に変更される非常に動的なものです。そこで、次に、OU 構造が適切に文書化され、動的な環境をサポートできることを確認するための、いくつかの重要なヒントを紹介します。

すべての情報が適切な情報であることを確認する 目的を持った文書には必ず価値があります。実務で使用する多くの文書には、余分な情報が大量に含まれているため、重要な情報を見つけるのが困難です。文書化の過程で、文書化という目的だけに固執して、本来の目的を忘れないようにしてください。各 OU に含まれるオブジェクトの数や、OU のアクセス制御リストのアクセス制御エントリ (ACE) の数などを記載する必要はありません。通常、OU の文書には、次の情報が含まれていれば十分です。

• OU 名
• 簡単な説明
• 作成者 (または詳細や変更に関する問い合わせ先)
• 作成日時

更新を困難にしない 複雑な Microsoft Word 文書を頻繁に更新する必要があるときによくある傾向は、更新作業を先延ばしにすることです。直近で大幅な更新作業をまとめて行うことがわかっているときに、小さな変更作業を留保することは問題ありません。残念ながら、多くの場合、そうした小さな変更は忘れられたり、いつまでも先延ばしにされて変更作業はまったく完了しません。したがって、先延ばしにされることがないよう、文書の更新は非常に簡単な作業である必要があります。通常は、列が数列ある単純な Microsoft Excel® スプレッドシートで問題ありません。

オブジェクト自体にコメントを作成する OU オブジェクトには、コメントを入力できる "説明" 属性があります。他のユーザーが OU の目的をすぐに認識できるように、コメントは、設計文書に記述するのではなく、"説明" 属性に追加することを検討してください。詳しい説明を含める必要がある場合には、簡単な説明を "説明" 属性に追加し、詳細を OU の文書に記述します。

文書化を自動化する スクリプトを記述して、OU 構造の内容をテキスト ファイル、Excel スプレッドシート、または HTML ファイルにダンプすることができます。このスクリプトは、スケジュール タスクとして毎晩実行できます。これは、コメントを OU の "説明" フィールドに追加している場合に非常に役立ちます。その場合、単に "説明" 属性をファイルにダンプするだけで、OU 構造の詳細な文書が自動的に作成され、この文書は常に最新の状態が保たれます。既存の文書を上書きするのではなく、スクリプトを実行するたびに新しいファイルを作成すると、時間の経過に伴う OU 構造の変更に関する履歴レコードを作成することができます。

残念ながら、多くの管理者が OU 構造を適切に文書化することの重要性を認識するのは、そのような文書が本当に必要になったときです。そのときは、たいてい真夜中で、復元を実行せずに、誤って削除された他の OU を特定することはほぼ不可能です。

こうした問題が発生する前に、対応策を講じてください。積極的に OU の文書化に取り組み、すぐに OU 設計の文書化を開始して、文書の更新担当者を任命することを強くお勧めします。文書を更新しやすくするという規則に従えば、更新作業が滞らないようにするのは非常に簡単な作業です。

Ken St. Cyr は、IT 業界での経験が 10 年ある、マイクロソフトのコンサルタントです。Active Directory の誕生以来、Active Directory ベースのディレクトリ ソリューションを設計および実装してきました。

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