Windows の管理

Active Directory で権限を委任する

Joel Yoker and Rob Campbell

 

概要:

  • 管理者の役割を定義する
  • OU とセキュリティ グループ モデルを開発する
  • 2 次アカウントを使用する
  • 権利の委任用ツール

Active Directory の委任機能は非常に機能性が高く、多くのセキュリティ問題に対応し、管理タスクを簡素化することができます。Active

Directory® で適切に権利を委任することにより、環境内で特定の役割を強制し、管理エラーの影響と可能性を抑え、インフラストラクチャ全体に最小特権の原則を適用することができます。それでも多くの組織は、Active Directory を使用しながらも、この委任機能を活用していないようです。この理由の 1 つとして、企業のための Active Directory 委任モデルの開発が一見、非常に複雑に見えるということが挙げられます。最大の障害は、各組織特有のニーズに応える委任モデルを開発することですが、多少の変更を加えるだけで、ほとんどの IT インフラストラクチャに応用できる非常にシンプルな委任モデルが存在します。

すべての環境は、方法、形状、または形態に何らかの違いがありますが、実際ほとんどの大企業は多くの点で似ており、同じ IT 上の課題を抱えています。たとえば、多くの企業はいくつかの地理的な地域に分けられ、複数の IT エンジニアリング チームまたは業務サポートチームにより展開され、独立した事業単位を持っています。そして、多くの大企業は、特権のエスカレーション、サービス アカウントの悪用、および「信頼」といった事項に対応することを強いられています。

信頼とは興味深い用語で、多くの場合、複数の Active Directory フォレストを持つ理由として使用されます。信頼の問題は、1 部門、または 1 地域が、別の部門または地域のシステムの可用性に影響を与えることからよく生じます。組織の境界にわたってスキル レベルが異なるのはよくあることで、特定の地域または特定の事業単位をサポートするために必要な特定システムに関する詳細知識が欠如していることも一般的です。このような理由から、部門では中央グループに管理権限を渡したがらないものです。

一方、Active Directory を実装するには、管理者は Active Directory インフラストラクチャを使用するアプリケーションの関与ルールを定義する必要があります。あいにく、このための一般的なアプローチ (アプリケーションのインストール ガイドでよく提唱されているもの)は、サービス アカウントをドメイン管理者クループのメンバにすることです。このアプローチの問題点は、サービス アカウントが本質的には汎用アカウントであることです。これらのアカウントにドメイン管理者の権利を許可すると、IT 環境を深刻な脅威にさらすことになります。サービス アカウントは、悪意のある管理者や不注意な管理者により不適切に使用されたり、アプリケーションの潜在セキュリティ問題を悪用する攻撃者により簡単に乱用されることがあります。

これらの障害は、克服不可能のように思われますが、Active Directory 委任モデルを実装するための優れたシナリオになります。委任モデルの開発は対話型の設計プロセスで、以下の手順に従うことをお勧めします。

  1. 組織内の IT 管理者の役割を定義する。
  2. 組織単位とセキュリティ グループ モデルを開発する。
  3. IT 管理者用に 2 次アカウントを設定する。
  4. 権利を委任する。

では、これらの手順について詳しく見てみましょう。

役割を定義する

役割の定義プロセスでは、最初にサービス管理とデータ管理について完全に理解する必要があります。これらのコンセプトが、あらゆる Active Directory 委任モデルの基礎になります。

サービス管理の中核を成すのは、Exchange サーバーやドメイン コントローラなどのディレクトリ サービス インフラストラクチャの主要コンポーネントの管理です。データ管理とは、サービスの中にあるメールボックスやユーザー アカウントなどのオブジェクトの管理です。Active Directory の範囲内では、サービス管理者は、究極的にディレクトリ サービスの提供と可用性に責任を持つ一方で、データ管理者は、ユーザー アカウントとサーバー アカウント、グループ、およびその他のドメイン リソースを管理します。

Active Directory では、組織単位 (OU) により権限を分割して委任することがサポートされています。既存のディレクトリ サービスまたはドメイン モデルで、管理者が使用できるものと同じ権限レベルを提供するために、OU をカスタム化することができます。しかし、一部の機能を単純に委任することはできず、信頼できる 1 つのグループまたはエンティティが管理を行う必要があります。

さらにタスクの分析も重要になります。管理者によりどの Active Directory タスクが実行され、これらのタスクがどの役割に割り当てられているかを理解する必要があります。たとえば、Active Directory サイトの作成はサービス管理者のタスクであり、セキュリティ グループ メンバシップの変更は通常データ管理者により行われます。各タスクについて、頻度、重要性、および難易度を評価する必要があります。これらにより、権利を委任すべきかどうかが決まるため、タスクの定義において重要な側面になります。日常的に実行されるタスク、リスクが限られたタスク、および実施があまり重要でないタスクは、委任に適しています。一方、まれにしか実行しないタスク、組織全体に対して大きな影響を持つタスク、および高いスキル レベルが要求されるタスクは、委任に向きません。これらのタスクには、代わりにエスカレーション (アカウントを一時的に要求される役割に昇格するか、タスクを再割り当て) が適切な手段になります。

大企業では多くの特徴が似ているため、共通の委任モデルを実装できると考えても差し支えないでしょう。この記事では、組織の境界を考慮し、信頼の問題 (ドメイン コントローラのような企業全体の資産の可用性など) を軽減しながら管理機能を可能にする役割のサンプル セットを提供します。このモデルは単なる例です。組織の役割の検討を始めるためには最適ですが、このガイダンスに逐一沿って計画を立てないようにしてください。

一部の役割は Active Directory により既に定義されており、一部は委任モデルを完成するために最初から設定する必要があります。多くの大規模 Active Directory 環境に適した役割のサンプル セットは、サービス管理用のエンタープライズ管理者、ドメイン管理者、および Tier4 管理者、そしてデータ管理用の Tier3 管理者、地域管理者、Tier2 管理者、および Tier1 管理者で構成することが考えられます。これらの役割とその責任の一覧については、図 1 を参照してください。

Figure 1 役割と責任を定義する

サービス管理者 説明
エンタープライズ管理者 全社のトップレベルのサービス管理を担当します。恒久的なメンバを含めることを避ける必要があります。
ドメイン管理者 ドメイン全体のトップレベルのサービス管理を担当します。管理しやすい少人数の信頼できる管理者のみを含める必要があります。
Tier 4 管理者 ドメイン全体のサービス管理を担当します。必要なサービスの管理に要する権利のみを許可されています。データ管理者のエスカレーション ポイントとなります。
データ管理者 説明
Tier 1 管理者 ディレクトリ オブジェクトの一般的な管理を担当し、パスワードのリセット、ユーザー アカウントのプロパティ変更などのタスクを実行します。
Tier 2 管理者 ローカルまたは組織のユーザー アカウントとコンピュータ アカウントの一部作成または削除を担当します。
地域管理者 ローカル OU 構造の管理を担当します。自身の OU 内でほとんどのオブジェクトを作成する権限が与えられています。
Tier 3 管理者 すべてのデータ管理者の管理を担当します。すべての地域管理者の上位層ヘルプ デスクとエスカレーション ポイントとなります。

サービス管理者

サービス管理者の役割を詳しく見てみましょう。サービス管理者は、重要なインフラストラクチャ コンポーネントを管理します。このカテゴリに属するすべての管理者には高い特権が与えられています。このことから、このケースでは、必要なタスクの実行に要求される最低権限のみを許可する最小特権戦略を強くお勧めします。

エンタープライズ管理者とドメイン管理者。Active Directory では、ディレクトリ内の重要な機能にこれらのセキュリティ コンテキストが必要になる 2 つの特別管理者グループを定義します。これらのグループ (エンタープライズ管理者とドメイン管理者) は、トップレベルのサービス管理を担当します。このように高い特権を備えたグループにつきまとうリスクを軽減するために、これらのグループには、メンバシップを制限することを強くお勧めします。実際には、エンタープライズ管理者グループには恒久的なメンバを含めることなく、ドメイン管理者グループには、管理しやすい少人数の信頼できる常勤社員のみを含めます。

DHCP サーバーの認証や Active Directory サイトの作成など、エンタープライズ管理タスクを実行する必要がある場合、Active Directory フォレストのルート ドメインのドメイン管理者は、エンタープライズ管理者グループのメンバシップを管理することで、特権をエスカレートできます。これらの特権は、エンタープライズ管理者グループに恒久的なメンバを作成することを避けるため、短期間のみ許可する必要があります。もちろん、任意の Active Directory フォレスト内のドメイン管理者グループのすべてのメンバには、信頼を等しく設定する必要があります。

委任モデルの開発においてほとんどの組織が陥る落とし穴として挙げられるのは、これらの組み込まれた役割を無効にしたり、不能にしたりすることです。既定の役割を変更すると、予期せぬ結果を招くことがあり、サービス パックの改訂または製品のアップグレードでこれらの設定が維持される保証がありません。さらに、この種の変更により、組織の外にサポートされてない環境が作られます。実用的なアプローチとして挙げられるのは、組み込まれたグループと役割を使用しながらも、メンバシップを制限することです。これを行うには、おそらく、以前はドメイン管理者のようなグループのメンバシップに依存していた管理者のために新しい役割を作成することが必要になる可能性があります。

Tier4 管理者。Tier4 管理者グループは、すべてのエンタープライズ サービスをサポートする中央のサービス管理者で構成する必要があります。これは作成された役割であるため、組織の特定の要件に合わせてディレクトリ サービスとシステムへのアクセス許可をカスタム化できます。このグループのメンバはサービス管理者でありながら、ときにフォレスト全体のデータ管理タスクを実行することもあります。システムには多くのクラスが存在し、さまざまな責任領域があることから、Tier4 の役割は、ディレクトリのさまざまなサブグループに分けられます。たとえば、Exchange サーバーなど、特定システムを個別に管理するための別の Tier4 グループを作成する必要があります。このグループは、データ管理者のエスカレーション ポイントにもなります。

人々がよくドメイン管理グループのメンバシップを求める 1 つの理由は、任意のドメイン内のすべてのシステムに対する管理権限を得るためです。最小特権モードでこれらのサービス管理者を運用するためのコツは、Tier4 管理者をドメイン管理者にするのではなく、Tier4 管理者にエンタープライズ サーバーの制御を許可することです。特権のエスカレーションを避けるために、Tier4 管理者には、ドメイン コントローラの BUILTIN\Administrators グループのメンバシップを許可しないようにします。このグループは、ディレクトリ サービスに対して分けることができない多くの潜在権利を備えています。たとえば、任意のドメインの BUILTIN\Administrators グループのメンバは、ドメイン管理者グループのメンバシップを管理することができ、メンバが特権をエスカレートできるようになるため、権利の抑制と均衡が維持できなくなります。

既定の権限を不能にしないことの原則を念頭に置いたうえでこのリスクを軽減するには、Tier4 グループをサーバー オペレータと DNS 管理者の組み込みドメイン グループのネストされたメンバにします。これにより、ドメイン コントローラのローカル管理が可能になる一方で Tier4 管理者の特権をエスカレートする能力を制限できます。ほとんどのシステムには (ドメイン コントローラ、証明書サーバーなどを除く)、Tier4 管理者グループをローカル管理者グループのメンバにする必要があります。ネストされたローカル グループ メンバシップを自動化するには、グループ ポリシーの制限されたグループ機能を使用することができます。

データ管理者

それでは、次にデータ管理者の役割を詳しく見てみましょう。これらは、累積的な権利を持つように設計する必要があります。つまり、Tier2 管理者は、Tier1 管理者のすべての権利に加え、何らかの追加特権を与えるというようにします。このような理由から、これらのグループについては下から順に見ていきます。

Tier1 管理者。Tier1 管理者グループには、以前に作成されたディレクトリ オブジェクトの一般的な管理を実行できるようにする必要があります。このグループは、最低のトレーニングを受けた管理者、またはパスワードのリセットなど、分離したタスクを実行する人のためのものです。このグループには、それぞれの組織単位内で、非管理者グループのためのユーザー アカウントのプロパティ変更、ユーザー アカウントのパスワードのリセット、アカウントのロック解除、ユーザー アカウントの有効化/無効化、ワークステーション コンピュータ アカウントの追加とリセット、およびグループ オブジェクト メンバシップの変更を行う権利を与えます。

Tier2 管理者。このグループには、オブジェクトの一部管理と作成を許可し、Tier1 管理者が管理できる場所にのみオブジェクトを作成できるようにします (たとえば、セキュリティ グループは、グループ OU にのみ作成できます)。Tier2 管理者は、Tier1 管理者アカウントの追加と変更、OU のユーザー アカウントの追加、変更、および削除、ワークステーション コンピュータ オブジェクトの削除、およびサーバー、連絡先、共有フォルダの各オブジェクトの追加、変更と削除ができます。

地域管理者。このグループは、地域の OU 構造に対して排他的な権利が与えられています。しかし、ディレクトリ内の他の地域の OU 構造は管理できません。地域管理者アカウントは高い特権を備えているものと見なされるため、これらのアカウントは、別の OU 階層に保存し、Tier4 管理者のサービス管理者が管理を行います。地域管理者は、それぞれの OU 構造内で制限なくほとんどのオブジェクトを作成する権限を備えているため (例外として、その他の組織単位の作成が挙げられることに注意)、下の層により管理できないオブジェクトを作成するリスクが高まります。

Tier3 管理者。多くの組織には、集中管理のヘルプ デスクまたは上位層のヘルプ デスクがあります。この役割はデータ管理者の一覧から構成され、すべての地域管理者よりも上位のデータ管理者グループとなります。ディレクトリ内ではこれらのグループに特に権利を委任するのではなく、各地域管理者グループのネストされたメンバを使用します。これがすべてのデータ管理者のトップレベル エスカレーション ポイントとなるだけでなく、サービス管理者グループにエスカレートされる問題のエントリ ポイントとなります。

OU とセキュリティ グループ モデルを構築する

組織内の役割を定義したら、OU とセキュリティ グループ モデルを定義する必要があります。Active Directory で OU を作成する理由として、権利の委任、およびグループ ポリシー オブジェクトがリンク可能なポイントの作成という主に 2 つの理由があります。OU によりディレクトリ内の管理スコープ (SOM) が定義され、これを使用してさまざまなレベルのオブジェクトに対する権利を制限できます。このため、OU 構造の実装方法を決めるうえで、どのように権限を委任するかが重要な要因となります。

これを念頭に置くと、トップレベル OU (または一連の OU) を、すべてのオブジェクトを格納するドメインのすぐ下に作成する必要があります。この OU が、Tier4 管理者用の最高レベルの SOM を定義する特別な目的となります。トップレベル OU を作成することにより、ディレクトリ サービスに対する権利を、ドメイン レベルからではなく、OU レベルから明確に始めることができます。ドメインからではなく、トップレベル OU から委任を行うことで、既に解説している組み込みドメイン グループを操作して、特権をエスカレートする能力を持つユーザーのリスクを軽減できます。

トップレベル OU の下には、別のデータ管理チームを持つ各地域または各事業単位を表す別の サブ OU 階層を作成する必要があります。各地域のサブ OU は、ディレクトリ オブジェクトを管理する目的で、拡張不能な共通の OU 階層を持たせる必要があります。権利の委任のほとんどは自動化されることになるため、継続的な管理において一貫性が重要になります。各地域で独自の OU を希望する場合があるため、これは難しい注文かもしれません。しかし、IT 管理者は自分の方針を曲げないことが大切です。1 つの地域を拡張する必要があれば、すべての地域のサブ OU 構造を拡張すべきです。これは当初は難しいかもしれませんが、組織でオブジェクトに対する汎用的な格納構造を確立すれば、やがて例外的な状況にも対応できるようになるものです。

最後に、それぞれのサブ OU 階層に対して、管理者の特権のエスカレーション能力を排除するために、Tier1 管理者グループ、Tier2 管理者グループ、および地域管理者グループといった別々のサブ管理者グループとアカウントを作成します。これらのアカウントを別々の OU に配置することにより、それ以下のレベルの管理を制限することができます。このため、すべての Tier1 管理者アカウントと関連セキュリティ グループが、権利のない OU に存在する場合、管理者は他の管理者アカウントをハイジャックしたり、自身のレベルに他の管理者の特権をエスカレートしたりできません。たとえば、ドメイン管理者グループの任意のメンバは、ドメイン内の他の任意のユーザーアカウントをドメイン管理者にすることができます。しかし、この OU モデルでは、そのリスクが軽減されます。図 2 には、OU 構造とその関連セキュリティ グループの例を示します。

図 2 OU 構造と関連するセキュリティ グループ

図 2** OU 構造と関連するセキュリティ グループ **

2 次アカウントを設定する

委任モデルを成功させるうえで鍵になるのは、最小特権の原則を強制することです。実際には、これはセキュリティの原則上、与えられた役割に必要なタスクを実行する能力のみを与え、それ以上のものは与えないことを意味します。残念ながら、多くの IT 管理者は、ディレクトリの管理と、Web ブラウズや電子メールを読むなどの毎日のタスクに同じセキュリティの原則を使用しています。別のアカウントを持つことにより、階層化された管理者がディレクトリ サービスに間違ってダメージを与えたり、日常的なアプリケーションを経由してなされる、ディレクトリ管理者を標的にした攻撃を受けたりする可能性が低減します。

ユーザーにログオフしてからログオンしてもらうことなくこれを可能にするには、Secondary Logon サービス (Runas.exe) を使用します。これによりユーザーは、サーバーとワークステーションでスクリプトか実行可能ファイルを実行するときに、別の資格情報を使用して、特権をエスカレートすることができます。

最小特権アカウントの使用というコンセプトは比較的シンプルですが、組織では昔ながらの IT 慣習を破ることが難しいため、ときに徹底が難しいようです。日常的なタスクに特権アカウントを使用するのを防ぐ単純なアプローチとして挙げられるのは、Exchange サーバーのこれらのアカウントに電子メール アクセスを許可せず、組織の管理ポリシーとしてこれを強制することです。これは比較的シンプルなアプローチで、このようなアカウントが管理以外の定常的なタスクに使用される可能性を大幅に低減します。

権利を委任する

委任モデル開発の最後の手順は、Active Directory で実際に権利を委任することです。これには、ディレクトリ内に保存されたデータのアクセス制御エントリ (ACE) とアクセス制御リスト (ACL) の操作が必要になります。Active Directory コンテナの ACL により、どのオブジェクトが作成可能かと、これらのオブジェクトの管理方法が定義されます。権利の委任では、オブジェクトの表示、指定クラスの子オブジェクトの作成、特定クラスのオブジェクトの属性とセキュリティ情報の読み取りの能力など、オブジェクトに対する基本操作を行います。これらの基本操作に加えて、Active Directory では、送信者とレプリケーション管理トポロジなどの操作を可能にする拡張権利が定義されます。

前の手順では、定義された組織の役割に割り当てるセキュリティ グループの作成について検討しました。これは、すべての役割に対して、サブ OU 構造により関連付けられたセキュリティ グループが存在することを意味します。委任モデルを実装するには、これらのグループにディレクトリのオブジェクトに対する権限を割り当てる必要があります。プロセスのこの段階では、以前のように高度にカスタム化された環境の構築を繰り返したくはありません。代わりに、できるだけ組み込みグループと権利を活用するよう心掛けます。たとえば、特定の役割でフォレストの DNS レコードを管理する必要があるとします。この場合、コンテナと Active Directory に統合された DNS に関連する名前付けコンテキストに対する権利を委任しないでください。代わりに、ドメインの BUILTIN\DNS 管理者グループを活用します。さらに、グループ ポリシーによりユーザー権利と他の権限を拡張して、与えられた役割によるシステムの特定クラスの管理に必要な追加権利を付与することができます。

委任により権限を割り当てる場合、ディレクトリ内の拒否 ACE の使用を制限するか、場合によっては完全に排除する必要があります。これらは、トラブルシューティング時に厄介になる可能性があります。より良いアプローチは、明確な許可 ACE を活用して、自身の役割を表すカスタム グループに権利を許可することです。Tier4 管理者などのユーザー定義の役割は、その役割に明確に定義された権利しか備えていないことに気をつけてください。

Active Directory のセキュリティにおいて継承は重要な要因で、これによりどのように特定 ACL が任意のコンテナまたはサブコンテナの子オブジェクトに適用されるかが定義されます。継承可能な ACE をできるだけ目的のオブジェクトの近くに適用するよう確認することで、常に継承の範囲を明確にします。親オブジェクトに適用される継承可能な拒否権限は、祖父母オブジェクトに適用される継承可能な拒否権限よりも優先されます。これが、実際の委任には拒否 ACE を推奨できない主な理由の 1 つです。さらに、継承可能な権限によりオブジェクトに対する明確な ACE を上書きすることはできません。このために、階層化された管理者の能力を制限するか、排除して、ディレクトリ オブジェクトの随意アクセス制御リストを変更すること (書き込み DACL 特権を削除することで) をお勧めします (オブジェクトの作成者は潜在的にこれらの権利を備えています)。経験からいって、管理者にオブジェクトの DACL を変更する能力が与えられていれば、実際にそれを実行するはずです。選択肢を与え、管理エラーの可能性を作ることにより、委任モデルに対する組織の努力が無駄にならないようにしてください。

Active Directory 委任モデルを適切に実装するには、必要なツールがいくつか存在します。非常に大きな組織の場合、組み込みの委任ウィザードを使用してディレクトリに権限を割り当てることは面倒な作業で、管理エラーを引き起こす可能性に満ちています。代わりに必ず自動手順を使用して、委任モデルが正しく文書化されていること、それがサポート可能であること、および何らかの理由で設定が失われたり、間違って変更された場合に復旧オプションが利用できることを確実にする必要があります。

委任の実装に必要な主要ツールは、オブジェクトのディレクトリ サービス ACL の操作に使用する DSACLS.EXE コマンド ライン ツールです。このツールでは、親オブジェクトに DACL の継承フラグを指定することもできます (継承フラグには、このオブジェクトとサブオブジェクト、サブオブジェクトのみ、および継承可能なアクセス許可を 1 レベルのみ伝達するがあります)。DSACLS コマンドは、継承フラグが正しく設定されていないと、最終的にはエラーとなるため、このツールの使用時はテストが重要になります。以降に、ターゲットのデモ OU にコンピュータ オブジェクトを作成する能力を委任するための DSACLS 構文例を示します。

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

DSACLS では、オブジェクト タイプの大文字と小文字が区別されます。つまり、"cn=computer" に対して "cn=Computer" オブジェクト クラスに対する権限を委任しようとしても機能しません (図 3 を参照してください)。

図 3 大文字と小文字の区別によるエラー

図 3** 大文字と小文字の区別によるエラー **(画像を拡大するには、ここをクリックします)

一部のオブジェクトを作成するには、一定の権利セットが必要になります。これは、オブジェクトの "must contain" と "may contain" 属性に関係します。今まで聞いた中で、このコンセプトを説明する最適な比喩は、ハンバーガーのモデルを使用するものです。ハンバーガーがハンバーガーと見なされるには、肉のパティとパンが含まれる必要があります。これらは、ハンバーガー オブジェクト クラスの must-contain 属性です。ピクルス、ケチャップ、レタスなどの品目は may-contain 属性です。このオブジェクト クラスを拡張してチーズバーガーを定義すると、must-contain 属性の一覧にはチーズが追加されます。

ユーザー オブジェクトも同じように機能します。このモデルに従い、次の DSACLS 構文を使用してユーザー オブジェクトを作成してみましょう。

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

管理者がユーザー オブジェクトを作成すると、いくつかのエラーが発生します。パスワードの設定など、ユーザー オブジェクトに必要な属性を設定するための特権を許可する必要があります。これは、次の追加 DSACLS 構文に示されています。

最初の手順として、ユーザー クラスのすべての属性に汎用読み取り/汎用書き込みを許可して、must-contain 属性を書き込む特権を許可します。

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

次の手順では、パスワードを変更する拡張権利を許可します。

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

最後の手順では、[最終パスワード変更日時] 属性の [プロパティの読み取り] と [プロパティの書き込み] を行う特権を許可します。

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

適切な権利を委任したら、定義された役割はコンテナの DACL に定義されたオブジェクト クラスを管理することのみに限定されます。前のコンピュータ オブジェクトの例を使用すると、Active Directory ユーザーとコンピュータのコンテキスト メニューが、このような権利を委任されたユーザーが作成可能な新しいオブジェクトの一覧に制限されます (図 4 の制限された一覧を参照してください)。

図 4 新しいオブジェクトの制限一覧

図 4** 新しいオブジェクトの制限一覧 **

DSACLS を自動化して権利を複雑に展開することもできます。以下には、任意のコンテナのユーザー オブジェクトに対する一般的なアドレス属性を操作するための権利の委任に使用できる DSACLS コマンドをいくつか示します。

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

これらの例は、ほとんどの委任モデルに共通しており、前に定義した役割と共に使用することができます。

委任の実装に使用する別のツールは DSREVOKE.EXE で、これにより管理者は、ディレクトリ内のオブジェクトの特定セキュリティ原則のために委任された権利を検索し、削除できます。このツールは非常に有益ですが、セキュリティ原則のみに対して行うもので、セキュリティ グループ内のネストされたメンバシップが評価されません。

これらのコマンド ライン ツールのほかに、グループ ポリシーのユーザー権利の割り当てと制限されたグループの使用を強くお勧めします。既に解説したように、IT 管理者は、ユーザー権利の割り当てにより特定ターゲット システムのさまざまなユーザー グループに対して低レベルの権利 (システムのリモート アクセスと再起動の権利など) を拡張するか、削除することができます。制限されたグループは、フォレスト内のローカル グループ メンバシップとドメイン グループ メンバシップの指定と強制に使用できます。これらのツールを組み合わせることで、Active Directory 委任モデルの自動化と実装に必要なすべての機能が得られます。

まとめ

Active Directory 委任モデルの開発というタスクは、複雑そうに見えますが、実際には、非常にシンプルな委任モデルをほとんどの IT インフラストラクチャに応用できます。実際の委任モデルの展開で最も重要な手順の 1 つは、明確な役割を定義することです。定義された役割は、管理しやすい少人数のみに限定する必要があります。役割が多すぎると使用されていない役割が出現し、役割が少なすぎると役割の分離ができなくなるため、慎重にバランスを見極める必要があります。

タスクを定義する際に注意する事項は、タスクを頻度、重要性、および難易度で整理することです。役割を定義したら、各役割で可能なことと不可能なことを示し、テスト プロセスを自動化するための一連の使用事例を準備します。使用事例を周到に準備することにより、組織内の関係する人々に対するこれらの役割の説明が容易になり、自動化エラーによる思いがけない事態の発生を軽減することができます。

最後に、委任モデルの開発には実用的なアプローチを踏襲することをお勧めします。簡単であればあるほどサポート性が向上し、維持しやすい委任モデルを開発することで、組織の Active Directory 環境における管理権限の管理が大幅にやりやすくなります。

参考資料

Joel Yoker は、マイクロソフト連邦政府チームのシニア コンサルタントです。Joel と Rob は、米国連邦政府関係の顧客向けのセキュリティ ソリューションの開発と展開を専門にしています。

Rob Campbell は、マイクロソフト連邦政府チームのシニア テクニカル スペシャリストです。Joel と Rob は、米国連邦政府関係の顧客向けのセキュリティ ソリューションの開発と展開を専門にしています。

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