Active Directory 技術概要

  • [アーティクル]

概要
このホワイト ペーパーでは、Active Directory の技術的概要を述べます。重要な概念と機能、Active Directory のアーキテクチャ、および、Microsoft® Windows NT® Version 4.0 (以下 Windows NT 4.0) オペレーティング システムから Microsoft Windows® 2000 (以下 Windows 2000) への移行について説明します。また、よく寄せられる質問 (FAQ) に対する回答も示します。Active Directory は、Microsoft BackOffice® ファミリの統合製品のプラットフォームとなる Windows 2000 分散システムの基盤を支えます。

トピック

はじめに はじめに
重要な概念 重要な概念
アーキテクチャ アーキテクチャ
Active Directory の機能 Active Directory の機能
移行 移行
よく寄せられる質問 よく寄せられる質問

はじめに

このホワイト ペーパーでは、Windows 2000 Server オペレーティング システムで新しく採用されたディレクトリ サービスである Active Directory の技術的概要を述べます。このホワイト ペーパーには、Active Directory の重要な概念、アーキテクチャ要素、および機能の詳細な説明が記載されています。最初の節「重要な概念」では、Active Directory そのものに取り組む前に理解すべき用語について述べます。「アーキテクチャ」と「Active Directory の機能」では、Active Directory で何が実現され、どのような機能が Windows に付加されているか、Active Directory がどのように実装されているかについて掘り下げて説明します。「移行」では、Windows NT 4.0 から Windows 2000 へのドメイン モデルとディレクトリ構造の移行について説明します。最後の節「よく寄せられる質問」では、Active Directory とその仕組みに関するいくつかの具体的な質問に対する回答を示します。

"ディレクトリ" とは、オブジェクトに関する情報を格納する情報ソースです。たとえば、電話帳には電話加入者に関する情報が記載されますが、これも一種のディレクトリと考えることができます。また、ファイル システムでは、ファイルに関する情報がディレクトリに格納されます。

分散型コンピューティング システムやインターネットなどのパブリック コンピュータ ネットワークには、プリンタ、ファックス サーバー、アプリケーション、データベース、ユーザーなど多数のオブジェクトが存在します。これらのオブジェクトを検索して使用する立場の人がユーザー、これらのオブジェクトの使用方法を管理する立場の人が管理者となります。

このドキュメントで使用する用語 "ディレクトリ" および "ディレクトリ サービス" は、パブリック ネットワークとプライベート ネットワークにおけるディレクトリを指します。ディレクトリ サービスとディレクトリの違いに注意してください。ディレクトリ サービスは、ディレクトリ情報のソースを意味すると同時に、ユーザーに対して情報を利用可能にするサービスを意味します。

ディレクトリ サービスは、コンピュータ システムの機能を拡張する上で、最も重要な要素の 1 つです。ユーザーや管理者がオブジェクトにアクセスしようとするときに、そのオブジェクトの正確な名前がわからないことがよくあります。しかし、オブジェクトの "属性" が 1 つでもわかっていれば、"ディレクトリ" に照会して、その属性を持つオブジェクトのリストを取得することができます。たとえば、第 26 ビルにあるすべての両面印刷プリンタを検索することなどが可能です。このように、特定の属性を持つオブジェクトを検索できるようにするのが、ディレクトリ サービスの基本的な働きです。

ディレクトリ サービスには、次のような機能があります。

  • 管理者によって定義された "セキュリティ" を適用し、情報を侵入者から守ります。

  • ネットワーク上の多数のコンピュータにディレクトリを "分散" します。

  • ディレクトリを "複製" して、より多くのユーザーがディレクトリを使用できるようにすると共に、障害の発生に備えます。

  • ディレクトリを複数のストアに "分割" し、膨大な数のオブジェクトを格納できるようにします。

ディレクトリ サービスは、管理ツールであると同時にエンド ユーザー ツールでもあります。ネットワーク内のオブジェクトの数が増えるにつれて、ディレクトリ サービスがますます重要になります。大規模な分散システムを円滑に運用するための車輪の役を担うのがディレクトリ サービスです。

Active Directory は、Windows 2000 Server に組み込まれたディレクトリ サービスです。従来の Windows ベースのディレクトリ サービスの機能が強化されているだけでなく、従来になかった新しい機能も追加されています。Active Directory の特長を言い表すキーワードとして、"セキュリティ"、"分散"、"パーティション (分割)"、および "複製" が挙げられます。Active Directory は、数百件以内のオブジェクトを扱う単一サーバー環境から、数千台のサーバーで数百万件のオブジェクトを扱う大規模な環境に至るまで、あらゆるサイズの環境で使用できるように設計されています。Active Directory には、大量の情報に対する検索と管理を効率化するための新機能が豊富に用意されており、管理者とユーザーのどちらにとっても時間的負担が大幅に軽減されます。

ページのトップへ ページのトップへ

重要な概念

Active Directory の概念と用語には、新しいものもあれば、従来から踏襲されたものもあります。ある程度定着していると思われる用語にも、複数の意味を持つものがあるので注意が必要です。ここでは、Active Directory に関して特に重要な概念と用語について説明します。

Active Directory は、広い "範囲" を対象とするディレクトリ サービスです。個々のオブジェクト (プリンタ、ファイル、ユーザー)、個々のサーバー、単一のワイド エリア ネットワーク内の個々のドメインをすべて格納できるほか、複数のワイド エリア ネットワークの組み合わせを格納することもできます。Active Directory はスケーラビリティに優れており、単一のコンピュータから単一のコンピュータ ネットワーク、そして多数のコンピュータ ネットワークの組み合わせに至るまで、さまざまな規模の環境に対応できます。これから説明する用語には単一のネットワークの範疇を超えて適用するものもあるため、Active Directory のスケーラビリティを念頭に置いた上で、これらの用語の意味を理解することが重要です。

ほかのディレクトリ サービスと同様、Active Directory はまず第一に "名前空間" として機能します。名前空間とは、名前を解決するための有限の領域です。身近な例で言うと、電話帳も一種の名前空間です。名前の解決処理では、名前が対応するオブジェクトや情報に変換されます。電話帳は、電話加入者の名前を電話番号に解決するための名前空間ということになります。同様に、Windows ファイル システムは、ファイル名をファイル自体に解決するための名前空間です。

Active Directory は、ディレクトリ内のオブジェクト名をオブジェクトそのものに解決するための名前空間として機能します。

"オブジェクト" とは、ユーザー、プリンタ、アプリケーションなどの具体的存在を表す "属性" を 1 つの明確な集合にまとめ、名前を付けたものです。属性には、ディレクトリ オブジェクトによって識別される対象を記述するデータが保持されます。ユーザー オブジェクトの属性には、ユーザーの姓名や電子メール アドレスなどがあります。

act1

図 1: ユーザー オブジェクトとその属性

"コンテナ" は、オブジェクトと同様に属性を持ち、Active Directory 名前空間に含まれますが、具体的存在を表さない点がオブジェクトと異なります。コンテナには、オブジェクトのグループやほかのコンテナが格納されます。

このホワイト ぺーパーでは、オブジェクトやコンテナの階層について述べるときに、"ツリー" という用語を使います。通常、ツリーの両端にはオブジェクトがあります。ツリー内のノード (ツリーが枝分かれする部分) には、コンテナがあります。ツリーは、複数のオブジェクトがどのように接続されているか、つまり、あるオブジェクトから別のオブジェクトへのパスを示します。単純なディレクトリは、それ自体 1 つのコンテナです。コンピュータ ネットワークやドメインもコンテナです。ツリー内に分断されていないパスがあるとき、そのパス内のコンテナに含まれるすべてのメンバが連続したサブツリーを形成します。

act2

図 2: ファイル ディレクトリの連続したサブツリー

Active Directory 内のオブジェクトは、いずれも "名前" で識別されます。次の 2 種類の名前があります。

識別名
Active Directory 内の各オブジェクトには、"識別名" (DN) があります。識別名は、オブジェクトを保持しているドメインを識別し、コンテナ階層内でオブジェクトに至るまでの完全なパスを示します。DN の例を次に示します。

/O=Internet/DC=COM/DC=Microsoft/CN=Users/CN=James Smith

この DN では、Microsoft.com ドメイン内の James Smith ユーザー オブジェクトを識別しています。

act3

図 3: 識別名のグラフィカル表現

相対識別名
オブジェクト名のうち、オブジェクト自体の属性となる部分が "相対識別名" (RDN) です。上に示した例では、CN=James Smith が James Smith ユーザー オブジェクトの RDN です。また、親オブジェクトの RDN は CN=Users です。

Active Directory は、1 つまたは複数の "名前付けコンテキスト" で構成されます。ディレクトリ内の任意の連続したサブツリーが名前付けコンテキストになります。"パーティション" とも呼ばれます。名前付けコンテキストが複製の単位になります。

Active Directory では、各サーバーが常に少なくとも次の 3 つの名前付けコンテキストを保持します。

  • スキーマ

  • 構成 (複製トポロジおよび関連するメタデータ)

  • 1 つまたは複数のユーザー名前付けコンテキスト (ディレクトリ内で実際のオブジェクトを格納しているサブツリー)

Windows NT コンピュータ ネットワークおよび Windows 2000 コンピュータ ネットワークでは、"ドメイン" がセキュリティ境界になります。ドメインの詳細については、Windows のマニュアルを参照してください。Active Directory は、1 つまたは複数のドメインで構成されます。スタンドアロンのワークステーションでは、コンピュータ自体がドメインになります。ドメインには、物理的に異なる場所にあるコンピュータを含めることもできます。各ドメインには、固有のセキュリティ ポリシーが設定されます。あるドメインとほかのドメインとの間には、セキュリティ関係が確立されます。複数のドメインが信頼関係で接続されており、共通のスキーマ、構成、およびグローバル カタログを共有しているとき、それらのドメインは "ドメイン ツリー" を形成します。さらに、複数のドメイン ツリーを接続して "フォレスト" を作成することができます。

ドメイン ツリー ("ツリー") は、共通のスキーマと構成を共有する複数のドメインで構成され、連続した名前空間を形成します。ツリー内のドメインも、信頼関係で互いにリンクされています。Active Directory は、1 つまたは複数のツリーで構成されます。

ツリーは、ドメイン間の信頼関係に基づくビューとドメイン ツリーの名前空間に基づくビューのどちらでも表示できます。

信頼関係の表示
ドメイン ツリーは、個々のドメインとそれらの間の信頼関係に基づいて表示できます。

Windows 2000 では、Kerberos セキュリティ プロトコルに基づいてドメインの間に信頼関係を確立します。Kerberos 信頼は階層的かつ推移的です。ドメイン A がドメイン B を信頼しており、ドメイン B がドメイン C を信頼していれば、ドメイン A からドメイン C に対しても信頼が成立します。

act4

図 4: 信頼関係に基づいて表示したドメイン ツリー

名前空間の表示
ドメイン ツリーは、名前空間に基づいて表示することもできます。オブジェクトの識別名は、ドメイン ツリーの名前空間の上層に向かってパスをたどることで確認できます。このビューは、複数のオブジェクトを論理階層にグループ化するときに役立ちます。連続した名前空間の利点は、名前空間のルートから深い階層レベルまで検索することにより、階層全体を検索できるという点です。

act5

図 5: 名前空間として表示したドメイン ツリー

"フォレスト" は、連続した名前空間を形成していない 1 つまたは複数のツリーの集合です。フォレスト内のすべてのツリーは、共通のスキーマ、構成、およびグローバル カタログを共有します。また、フォレスト内のすべてのツリーは、階層的かつ推移的な Kerberos 信頼関係を通じて相互に信頼し合います。ツリーとは異なり、フォレストには明確な名前を付ける必要がありません。フォレストは、複数の相互参照オブジェクトとメンバ ツリー間の Kerberos 信頼関係の集合として存在します。フォレスト内のツリーは、Kerberos 信頼に応じた階層を形成します。フォレストは、信頼ツリーのルートのツリー名で参照できます。

act6

図 6: フォレストを構成する複数のツリー

"サイト" とは、ネットワーク内で Active Directory サーバーが配置されている場所を意味します。サイトは、接続の良好な 1 つまたは複数のサブネットとして定義されます。"良好な接続" とは、ネットワーク接続の信頼性と速度が高いことを意味します。たとえば、 毎秒 1000 万ビット以上の転送速度を持つ LAN は良好な接続といえます。管理者は、物理ネットワークの能力を活かすように Active Directory へのアクセスと複製トポロジを構成する必要がありますが、これらの構成作業は、サイトをサブネットの集合として定義することで効率化できます。ユーザーがログオンすると、Active Directory クライアントがユーザーの所属先サイト内の Active Directory サーバーを検索します。同じサイト内のコンピュータは物理ネットワーク内で互いに近い位置にあるため、コンピュータ間の通信の信頼性、速度、および効率性が高くなります。ユーザーがログオンしようとする時点では、ユーザーのワークステーションは自分がどの TCP/IP にあるかが既にわかっており、サブネットは Active Directory サイトに直接変換されます。そのため、ごく簡単な処理でローカル サイトを判別することができます。

ページのトップへ ページのトップへ

アーキテクチャ

ここでは、Active Directory の主要なアーキテクチャ要素をいくつか取り上げて、簡潔に説明します。

Active Directory では、X.500 データ モデルから派生したデータ モデルを使用しています。ディレクトリには、さまざまな種類の対象物を表すオブジェクトが属性と共に保持されます。ディレクトリにどのようなオブジェクトを格納でき、それらがどのような属性を持つかは、スキーマで定義されます。スキーマは、各オブジェクト クラスに対して、クラスのインスタンスに必須の属性、省略可能な属性、およびそのクラスの親となるオブジェクト クラスを定義します。

Active Directory スキーマは、ディレクトリ内に格納されるオブジェクト クラス インスタンスの集合として実装されます。これは、スキーマをサポートしていても、起動時に読み込むテキスト ファイルとして保存するものが多いほかのディレクトリ サービスとの大きな違いです。スキーマをディレクトリに格納することには、さまざまな利点があります。たとえば、ユーザー アプリケーションからスキーマにアクセスすれば、どのオブジェクトとプロパティが利用可能かを判別できます。

Active Directory スキーマは、動的更新が可能です。つまり、アプリケーションから新しい属性とクラスを動的に追加してスキーマを拡張することができます。しかも、拡張したスキーマは即時に使用できます。スキーマを更新するには、ディレクトリ内にスキーマ オブジェクトを作成するか、または既存のスキーマ オブジェクトを変更します。ほかの Active Directory オブジェクトと同様、スキーマ オブジクトは、許可されたユーザーだけがスキーマを変更できるようにアクセス制御リストによって保護されます。

ディレクトリは、Windows 2000 の信頼性を重視するコンピューティングの基礎の一部であり、Windows 2000 セキュリティ インフラストラクチャの不可欠な要素です。Active Directory 内のすべてのオブジェクトは、ACL によって保護されます。Active Directory Windows 2000 のアクセス妥当性検査ルーチンでは、Active Directory 内のオブジェクトまたは属性に対してアクセスが試行されるたびに、ACL に基づいてアクセスの妥当性を検査します。

Active Directory 内の管理は、適切な権限を持つユーザーが行います。ユーザーに対して、通常より高い権限を与えることを "管理の委任" と呼びます。管理を委任するときは、ディレクトリ内で委任の対象となるサブツリーのオブジェクトおよびオブジェクト クラス、および操作を指定します。管理の委任では、どのユーザーにどの操作を許可するかを細かく制御でき、しかも委任先のユーザーの特権レベルを上げる必要がありません。

DSA (Directory System Agent) は、ディレクトリの物理記憶域を管理するプロセスです。クライアントは、サポートされているインターフェイスのいずれかを使用して DSA に接続し、ディレクトリ オブジェクトやそれらの属性に対して、検索、読み取り、および書き込みを実行することができます。DSA に接続すれば、ディレクトリ データの物理記憶域の形式をクライアント側で意識する必要がありません。

ページのトップへ ページのトップへ

Active Directory の機能

ここでは、Active Directory の主要な機能と構成要素をいくつか取り上げて説明します。

Active Directory は、ドメイン ネーム システム (DNS) と緊密に統合されています。DNS は、インターネット上でコンピュータ名およびサービス名を TCP/IP アドレスに解決するために使用されている分散型ネームスペースです。イントラネットを持つ企業の大半は、名前解決サービスとして DNS を使用しています。Active Directory では、DNS を "検索サービス" として使用します。

Windows 2000 ドメインの名前は、DNS ドメイン名です。たとえば、Microsoft.com は有効な DNS ドメイン名ですが、この名前を Windows 2000 ドメイン名として使用することも可能です。Active Directory は、DNS と緊密に統合されているので、インターネットやイントラネット環境との親和性に優れています。クライアントは、ディレクトリ サーバーをすばやく、かつ簡単に検索できます。企業内の Active Directory サーバーを直接インターネットに接続すれば、顧客やパートナーとの間の通信や電子商取引を安全かつ円滑に進めることができます。

検索サービス
クライアントがドメイン名だけを指定して Active Directory サーバーにアクセスできるように、Active Directory サーバーのアドレスが公開されます。Active Directory サーバーは、DNS 内のサービス リソース レコード (SRV RR) を通じて公開されます。SRV RR は、サービスの名前をサービスの提供元のサーバーの名前にマップするための DNS レコードです。SRV RR の名前は、次の形式をとります。

<service>.<protocol>.<domain>

Active Directory サーバーは、TCP プロトコルを通じて LDAP サービスを提供します。このため、サーバー名は次の形式で公開されます。

ldap.tcp.<domain>

したがって、Microsoft.com の SRV RR は、ldap.tcp.microsoft.com となります。SRV RR にはサーバーの優先度と重要度を示す情報も格納されるので、クライアント側では最もニーズに合ったサーバーを選択できます。

Active Directory サーバーをインストールすると、後で述べる "ダイナミック DNS" を経由してサーバーが公開されます。TCP/IP アドレスは変更される可能性があるため、サーバーは定期的に登録内容をチェックして、現在の TCP/IP アドレスが正しいかどうかを確認し、必要に応じてアドレスを更新します。

ダイナミック DNS
DNS 標準には、ダイナミック DNS に関する仕様が新たに追加されました1。ダイナミック DNS では、DNS サーバーを動的に更新して、新しい値や変更された値を反映させるためのプロトコルが定義されています。ダイナミック DNS が登場するまで、DNS サーバーに格納されるレコードは、管理者が手動で更新する必要がありました。

オブジェクトには、必ず "識別名" (DN) があります。DN は、オブジェクトを一意に識別します。また、DN には、クライアントがディレクトリからオブジェクトを取得するための情報が格納されています。オブジェクトの DN は、かなり長くなることがあり、憶えやすい名前ではありません。さらに、オブジェクトの DN が変更される可能性もあります。オブジェクトの DN は、オブジェクトとその親オブジェクトの RDN で構成されるので、オブジェクト自体か親オブジェクトの名前が変更されると、DN も変更されることになります。

DN は記憶しにくい上、変更される可能性があるので、オブジェクトの取得にはほかの手段を使った方が便利です。Active Directory では、属性による照会がサポートされています。これにより、正確な DN が不明な場合や DN が変更された場合でもオブジェクトを検索できます。オブジェクトを照会して検索する処理が簡単になるように、Active Directory スキーマには次の 2 つの便利なプロパティが定義されています2。

  • オブジェクトの GUID （ **Globally Unique Identifier)**一意性が保証された 128 ビットの番号。GUID は、オブジェクトの作成時に割り当てられます。オブジェクトを移動したり、オブジェクト名を変更しても、GUID は変更されません。アプリケーション側で GUID を保存しておくと、オブジェクトの DN が変更されてもオブジェクトにアクセスできるようになります。

  • ユーザー プリンシパル名 (UPN) それぞれのセキュリティ プリンシパル (ユーザーおよびグループ) には、DN より短く記憶しやすい "フレンドリ名" として、"ユーザー プリンシパル名" (UPN) が割り当てられます。ユーザー プリンシパル名は、ユーザー名およびユーザー オブジェクトの所属先ドメイン ツリーの DSN 名を "略記" した名前です。たとえば、microsoft.com ツリー内のユーザー James Smith の UPN は、JamesS@Microsoft.com などとなります。

名前の一意性
識別名は、一意性が保証されています。Active Directory では、同じ親を持つ 2 つのオブジェクトに同じ RDN を割り当てることはできません。DN は RDN で構成されているため必然的に一意となります。GUID は、一意性を保証するアルゴリズムで生成されるので一意です。その他の属性については一意性は保証されません。

Active Directory へのアクセスには、クライアントとサーバー間のメッセージ形式および対話形式を定義した "ワイヤ プロトコル" が使用されます。これらのプロトコルには、さまざまなアプリケーション プログラミング インターフェイス (API) からアクセスできます。

プロトコルのサポート
Active Directory では、次のプロトコルをサポートしています。

  • LDAP Active Directory では、LDAP (Lightweight Directory Access Protocol) が中心的なプロトコルとして使用されます。LDAP Version 2 および Version 33 がサポートされています。

  • MAPI-RPC Active Directory では、MAPI インターフェイスに対応したリモート プロシージャ コール (RPC) インターフェイスをサポートしています。

  • X.500 Active Directory では、X.500 情報モデルから派生した情報モデルを使用しています。ただし、X.500 に定義されているワイヤ プロトコルのうち、次のものは Active Directory には実装されていません。

    DAP - Directory Access Protocol

    DSP - Directory System Protocol

    DISP - Directory Information Shadowing Protocol

    DOP - Directory Operational Binding Management Protocol

    これらのプロトコルが Active Directory に実装されていないのは、次の理由によります。

    • これらのプロトコルが必要になるケースが非常に少なく、また、実際に実装している例もほとんどない。

    • これらのプロトコルは、OSI ネットワークに依存している。OSI は TCP/IP に代わる技術ですがあまり普及していません。TCP/IP ネットワーク上で OSI を使用するのは、TCP/IP を直接使用する場合に比べて効率性に劣ります。

    • DAP および DSP が提供する機能のうち、特に重要なものは LDAP でも提供されており、TCP/IP 上で LDAP を使用する限りは、TCP/IP 内に OSI を "囲い込む" ことに伴うオーバーヘッドが生じない。

    • 1993 年版と 1997 年版の DISP 仕様および DOP 仕様には曖昧な点があり、これらの仕様に準拠してプロトコルを実装しても相互運用性が保証されないため、プロトコルの価値が大きく損なわれている。

アプリケーション プログラミング インターフェイス
Active Directory では、次の API をサポートしています。

  • ADSI ADSI (Active Directory Service Interfaces) は、Active Directory へのシンプルかつ強力なオブジェクト指向インターフェイスを提供します4。この API は、Java 、Visual Basic®、C、C++ など、さまざまなプログラミング言語から使用できます。スクリプトから完全に操作できる ADSI は、システム管理者にも使いやすい API です。ADSI を使用すると、ユーザーが LDAP 通信の詳細を意識せずに Active Directory にアクセスできるようになります。

  • LDAP API RFC 1823 で定義されている LDAP C API は、C プログラマ用の低レベル インターフェイスです。

  • MAPI Active Directory では、下位互換性を維持する目的で MAPI をサポートしています。アプリケーションを新規に開発する場合は、ADSI または LDAP C API を使用してください。

Active Directory では、ほかのディレクトリにアクセスする手段として "仮想コンテナ" をサポートしています。仮想コンテナを使用すると、Active Directory から LDAP に準拠したディレクトリに透過的にアクセスできます。仮想コンテナは、Active Directory に格納された知識情報を通じて実装されます。知識情報は、Active Directory 内のどの位置から外部ディレクトリにアクセスできるようにするかを示します。また、この情報には、外部ディレクトリのコピーを保持しているサーバーの DNS 名、および外部 DS 内で検索処理を開始する位置の識別名 (DN) が格納されます。

Active Directory は、複数のパーティション (名前付けコンテキスト) で構成できます。オブジェクトの "識別名" (DN) には、オブジェクトを保持しているパーティションのレプリカを検索するのに十分な情報が含まれます。ただし、ユーザーやアプリケーションがあるオブジェクトにアクセスしようとするときに、目的のオブジェクトの DN や目的のオブジェクトが格納されているパーティションが常に事前にわかっているとは限らず、不明なことの方がむしろ多くなります。このような場合でも、目的のオブジェクトの属性が 1 つでもわかっていれば、"グローバル カタログ" (GC) を通じて、Active Directory ドメイン ツリー内のオブジェクトを検索することができます。

グローバル カタログには、スキーマおよび構成名前付けコンテキストのほか、ディレクトリ内の各ユーザー名前付けコンテキストの部分レプリカが格納されます。つまり、GC には、Active Directory 内のすべてのオブジェクトのレプリカが保持されますが、その属性についてはごく少数のものしか保持されません。GC に格納される属性は、検索操作で多用される属性 (ユーザーの姓名やログイン名など) とオブジェクトの完全なレプリカを検索するために必要な属性です。GC を使用すると、オブジェクトが保持されているドメインがわからなくても、またエンタプライズ内に連続した名前空間がなくても、必要なオブジェクトをすばやく検索することができます。

Active Directory 複製システムは、グローバル カタログを自動的に構築し、複製トポロジを自動生成します。グローバル カタログに複製される情報には、Microsoft によって定義された基本セットのプロパティが含まれます。管理者は、実際のニーズに応じて新しいプロパティを追加できます。

ここでは、Active Directory のセキュリティの概要を述べるにとどめます。Windows 2000 のセキュリティ モデルの詳細については、ホワイト ペーパー「Windows 2000 の分散セキュリティ サービスを使用したセキュリティで保護されたネットワーキング」を参照してください。

オブジェクトの保護
Active Directory 内のすべてのオブジェクトは、アクセス制御リスト (ACL) によって保護されます。ACL では、どのユーザーがオブジェクトにアクセスでき、各ユーザーがどのような操作をオブジェクトに対して実行できるようにするかを定義します。あるオブジェクトへのアクセスが許可されていないユーザーには、そのオブジェクトが存在することさえ知ることができません。

ACL は、アクセス制御エントリ (ACE) と保護対象のオブジェクトとを関連付けるリストです。Windows 2000 では、"セキュリティ記述子" と呼ばれるバイナリ値として ACL を保存します。各 ACE には、適用対象の "プリンシパル" (ユーザーまたはグループ) を識別するセキュリティ ID (SID) と、許可または拒否するアクセスの種類に関する情報が格納されます。

ディレクトリ オブジェクトの ACL には、オブジェクト全体に適用する ACE とオブジェクトの個々の属性に適用する ACE が格納されます。これにより、管理者は、どのユーザーにオブジェクトへのアクセスを許可するかを指定すると共に、どのプロパティへのアクセスを許可するかを指定することができます。たとえば、ユーザーの属性には、電子メール アドレスや電話番号のように、ほかのすべてのユーザーに読み取りアクセスを許可しても問題ないものもありますが、特定のセキュリティ管理者グループに属していないユーザーがセキュリティに関するプロパティにアクセスしようとした場合には、アクセスを拒否する必要があります。一般に、個々のユーザーには、各自のユーザー オブジェクトの個人情報属性 (電話番号や電子メール アドレスなど) への書き込みアクセスを許可します。

委任
"委任" は、Active Directory の最も重要なセキュリティ機能の 1 つです。委任とは、より高い管理権限を持つ管理者が、コンテナおよびサブツリーに対する特定の管理者権限をユーザーやグループに付与することを意味します。これにより、ユーザー人口をいくつかの大きなセグメントに分けて権限を分散できるので、"ドメイン管理者" を配備する必要が減ります。

コンテナ内のオブジェクトに対する管理者権限は、ACE を通じてユーザーやグループに付与できます。特定のオブジェクト クラスに対して特定の操作を行う権利は、コンテナの ACL の ACE を通じて付与されます。たとえば、ユーザー "James Smith" を組織単位 "Corporate Accounting" の管理者にするには、"Corporate Accounting" の ACL に次のような ACE を追加します5。

"James Smith";Grant ;Create, Modify, Delete;Object-Class User
"James Smith";Grant ;Create, Modify, Delete;Object-Class Group
"James Smith";Grant ;Write;Object-Class User; Attribute Password

これにより、James Smith には、組織単位 Corporate Accounting のユーザーとグループを新規作成する権限と既存のユーザーのパスワードを作成する権限が与えられます。ただし、ほかのオブジェクト クラスを作成する権限や、ほかのコンテナのユーザーに対する変更を行う権限は与えられません。

継承
"継承" とは、あるコンテナに適用された ACE がそのコンテナのすべての子オブジェクトに伝達されることを意味します。継承と委任を組み合わせると、ディレクトリ内のサブツリー全体に対する管理者権限を 1 回の操作で付与できます。

Active Directory では、"マルチマスタ複製" と呼ばれる仕組みを採用しています。マルチマスタ複製では、特定のパーティションのすべてのレプリカが書き込み可能になります。これにより、どのパーティションのどのレプリカに対しても更新を適用できます。Active Directory の複製システムでは、いずれかのレプリカに加えられた変更をほかのすべてのレプリカに伝達するようになっています。複製は、自動的かつ透過的に行われます。

更新の伝達
ディレクトリ サービスには、変更の検出と伝達にタイムスタンプを使用するものがあります。これらのシステムでは、すべてのディレクトリ サーバー上のクロックの同期を維持することが特に重要な条件となります。しかし、ネットワーク上で時間の同期をとることには、かなりの困難が伴います。ネットワーク上の時間をうまく同期できていても、各ディレクトリ サーバーの時刻設定に誤りが生じる可能性は十分にあります。時刻の設定に誤りがあると、更新情報が失われることになります。

Windows 2000 には分散型の時間同期機能がありますが、Active Directory の複製システムでは、更新情報の伝達にタイムスタンプではなく、64 ビットの "更新シーケンス番号" (USN) を使用します。USN は、各 Active Directory サーバーに保持されます。この Active Directory サーバーが Active Directory にプロパティを書き込むと、USN は 1 つ増分され、書き込まれたプロパティと共に格納されます。この処理は非常に小さな単位で実行されます。つまり、USN の増分と保存、およびプロパティ値の書き込みは、何か 1 つの操作が行われるたびに失敗か成功かが判断されます。

また、各 Active Directory サーバーでは、複製パートナーから受信した USN のテーブルが維持されます。このテーブルには、各パートナーから受信した USN のうち、最も大きいものが格納されます。パートナーからディレクトリ サーバーに対し、複製が必要であることが通知されると、ディレクトリ サーバーは最後に受信した USN より大きい USN が関連付けられている変更をすべて要求します。これにより、タイムスタンプの正確さに依存せずに更新を伝達することが可能になっています。

テーブルに保存されている USN は、更新情報が受信されるたびに更新されるので、障害発生後の回復も簡単です。テーブル内の最後の有効なエントリよりも大きい USN を持つ変更をすべて複製するようにサーバーからパートナーに要求するだけで、複製を再開できます。USN テーブルは変更が適用されるたびに細かく更新されます。したがって、複製サイクルが中断された場合でも、中断時と同じポイントから複製を再開できます。更新情報が損失したり重複したりすることはありません。

衝突の検出 - バージョン番号
Active Directory のようなマルチマスタ複製システムでは、複数のレプリカで同じプロパティが同時に更新される可能性があります。1 番目のレプリカの変更が完全に伝達される前に 2 番目以降のレプリカでプロパティが変更されると、複製の "衝突" が発生します。衝突の検出には、"プロパティ バージョン番号" が使用されます。サーバー固有の値である USN とは異なり、プロパティ バージョン番号は Active Directory オブジェクトのプロパティに固有の値です。あるプロパティが最初に Active Directory オブジェクトに書き込まれると、そのプロパティのバージョン番号が初期化されます。

"発信側書き込み" が発生すると、バージョン番号が増分されます。ここでいう発信側書き込みとは、変更を開始するシステムにおけるプロパティへの書き込みを意味します。発信側書き込みではなく、複製の結果としてプロパティの書き込みが発生した場合には、バージョン番号は増分されません。たとえば、ユーザーが自分のパスワードを変更した場合は、発信側書き込みが発生するので、バージョン番号が増分されます。しかし、変更したパスワードが複製の結果としてほかのサーバーで書き込まれたときには、バージョン番号は増分されません。

複製のプロパティ バージョン番号が受信側にローカルで保存されているプロパティ バージョン番号と同じで、なおかつ、受信した値と保存されている値が異なっていれば、衝突が検出されます。衝突発生時、受信側のシステムでは、タイムスタンプの新しい方の更新が適用されます。時間に基づく制御が複製に適用されるのは、この場合だけです。

各サーバーでは、受信したバージョン番号とローカルに保存されているバージョン番号のどちらが新しいかに基づいて、更新を適用するかどうかを決定します。受信したバージョン番号の方が新しければ更新を受け付け、保存されているバージョン番号の方が新しければ、更新内容が最新ではないとみなし、更新を破棄します。

伝達の緩衝
Active Directory 複製システムでは、複製トポロジのループがサポートされています。パフォーマンスと可用性を確保するために必要であれば、サーバー間に複数のパスがある複製トポロジを構成できます。Active Directory 複製システムには、"伝達を緩衝" する機能があります。これにより、変更が無限に伝達されるのを防ぎ、既に最新の状態になっているレプリカに冗長な変更が伝達されるのを防ぎます。

Active Directory の複製システムでは、"最新ベクタ" と呼ばれる仕組みを通じて伝達を緩衝します。最新ベクタは、サーバーと USN のペアのリストとして各サーバーに保持されます。各サーバーの最新ベクタには、USN とペアになっているサーバーから受信した発信側書き込みの USN のうち、最も大きい番号が示されます。各サイトのサーバーの最新ベクタには、そのサイト内のほかのすべてのサーバーが示されます。

複製サイクルが開始すると、要求側サーバーは、その最新ベクタを送信元のサーバーに送信します。送信元サーバーは、要求側サーバーに送信された変更をこの最新ベクタでフィルタをかけます。発信側書き込みの最大 USN が、ある更新の発信側書き込み USN と同じかそれより大きい場合、送信元サーバーは要求側に変更を送信する必要はありません。要求側サーバーには既に最新の情報が反映されています。

各 Windows 2000 ドメインは 1 つの Active Directory パーティションで構成されます。これらのドメインの階層が Windows 2000 ドメイン ツリーです。ドメインの DNS 名によって、ツリーの形状とツリー メンバ間の関係が決まります。各ツリー内のドメインは、a.myco.com が myco.com の子になり、b.myco.com が a.myco.com の子になるというように、連続した名前空間を形成します。

推移的な双方向信頼
ドメインを Windows 2000 ドメイン ツリーに参加させると、そのドメインとツリー内の親の間に信頼関係が自動的に確立されます。この信頼関係は推移的かつ双方向なので、ツリー メンバ間にこのほかの信頼関係を追加する必要はありません。信頼階層は、Configuration コンテナ内にディレクトリ メタデータの一部として格納されます。

これらの必須オブジェクトは、ドメインをツリーに参加させたときにディレクトリ内に作成されます。

名前空間
Windows 2000 ドメイン ツリー内のドメインは、連続した名前空間を形成しなければなりません。既定では、各ドメインのすぐ下層にある子ドメインは、連続した名前を持ち、ドメインの名前空間に既に含まれています。つまり、子ドメイン内の各オブジェクトの識別名には、親ドメインの名前がプレフィックスとして付加されています。名前空間が連続していない複数のドメイン ツリーを接続すると、フォレストを作成できます。

act7

図 7: 子ドメインの名前の直前には親ドメインの名前がプレフィックスとして付加されているので、親ドメインと子ドメインは連続した名前空間を形成します

たとえば、親ドメイン O=Internet/DC=COM/DC=Microsoft のルート オブジェクトは子ドメイン O=Internet/DC=COM/DC=Microsoft/DC=PBS のルート オブジェクトのすぐ上の階層の親なので、この親ドメインと子ドメインは連続したネーミング ツリーを形成しています。親ドメインと子ドメインがネーミング ツリーを形成するので、親ドメインから深い階層までの検索を開始すると、子ドメインも自動的に検索されます。

どのような場合にドメイン ツリーを作成するか
Windows 2000 ドメイン ツリーは、エンタプライズ全体にわたる Active Directory です。エンタプライズ内のすべての Windows 2000 ドメインは、エンタプライズ ドメイン ツリーに所属させる必要があります。エンタプライズ内に DNS 名が連続していない複数のドメインがある場合は、それらのドメインでフォレストを形成する必要があります。

ドメイン ツリーまたはフォレストの作成方法
ドメイン ツリーへの Windows 2000 ドメインの参加は、インストール処理中に行われます。Windows 2000 Server を新しくインストールするか、Windows NT からアップグレードするときには、次のいずれかのオプションを選択できます。

  • 新しいフォレストに最初のツリーを作成する。

  • 既存のフォレストに新しいツリーを作成する。

  • 既存のドメインの新しいレプリカを作成する。

  • 子ドメインをインストールする。

ドメイン ツリーにドメインを参加させるには、[既存のドメインの追加ドメイン コントローラ] を選択し、新しい子ドメインの親となるドメインを指定します。今後、Windows では、複数の既存のツリーを結合して、より大きな単一のツリーにする機能が追加される予定です。

作成したツリー全体の形状は、ツリー内のドメインを自由に移動して変更できます。良いツリーを計画することは非常に重要ですが、ツリーの良し悪しは、主観に依存する部分が大きく、また実際のニーズにも大きく依存します。ツリーの形状は必要に応じて変更できるので、最初から完璧な設計を目指す必要はありません。

サイトとは、ネットワーク内において、相互の接続が非常に良好であるという前提に基づいて複数のコンピュータをグループ化したものです。Windows 2000 では、1 つまたは複数の IP サブネットとしてサイトを定義します。これは、同じサブネット アドレスを持つコンピュータは LAN やその他の高帯域幅6 環境 (フレーム リレーや ATM など) を通じて同じネットワーク セグメントに接続されているという前提に基づいています。

Windows 2000 では、サイト情報に基づいて、ユーザーの最寄りの Active Directory サーバーを検索します。ユーザー ワークステーションは、ネットワークに接続するときに DHCP サーバーから TCP/IP アドレスを受信します。また、ワークステーションが接続されているサブネットも識別されます。静的に構成された IP アドレスを持つワークステーションの場合は、サブネット情報も静的に構成されます。どちらの場合も、ワークステーションで認識されているサブネット情報に基づいて、Windows 2000 ドメイン コントローラ (DC) ロケータがユーザーと同じサブネット上の Active Directory サーバーを検索します。

サイトと複製
Windows 2000 の複製システムでは、各サイト内の Active Directory サーバーの間にリング トポロジを自動生成します。サイト内のディレクトリ複製は、リモート プロシージャ コール (RPC) を通じて行われます。サイト間の複製は、RPC か SMTP のいずれかを使用するように構成できます。Windows 2000 には、シンプルな SMTP メッセージ処理が標準機能として用意されています。Microsoft Exchange を利用できる場合は、Exchange でサポートされているメール トランスポート (SMTP や X.400 など) のいずれかを使って、サイト間の複製を Exchange 経由で実行することもできます。

サイトの計画
最もシンプルなサイトは、単一の IP サブネットで構成されます。Windows 2000 では、同じサイト内のすべてのコンピュータが共通の広帯域幅ネットワークを共有しているものとみなされます。このため、サイトの設計の良し悪しは、サイトに割り当てたすべてのサブネットの間で広帯域幅ネットワークが共有されているかどうかに依存します。ネットワークが複数の物理的な場所にまたがっており、それらがワイド エリア ネットワークや複数のルーターなど、速度の遅いリンクで接続されている場合は、複数のサイトに分ける必要があります。

ディレクトリ内に格納できる各オブジェクトとその属性は、Active Directory スキーマで定義します。スキーマでは、各オブジェクト クラスの親になれるオブジェクトを指定することで、ディレクトリ ツリー内のどの位置に各オブジェクトを作成できるようにするかを定義します。クラスの内容は、必須属性と省略可能属性のリストで定義されます。

どのような場合にスキーマを拡張するか
ユーザーやアプリケーションがスキーマを拡張するのは、実際のニーズを満たすオブジェクト クラスがスキーマに定義されていない場合です。スキーマは、簡単に拡張することができます。

属性の追加
スキーマには、新しい属性を随時追加できます。属性の定義には、名前、一意なオブジェクト識別子 (OID)、属性に保持できるデータの種類を定義する構文、および有効範囲 (省略可能) が含まれます。文字列の場合は、文字列の最小の長さと最大の長さを指定します。整数の場合は、整数の最大値と最小値を指定します。

Active Directory における照会のパフォーマンスは、照会の最適化に使用できるインデックスが用意されているかどうかに大きく影響されます。照会に使用できるインデックスがない場合、LDAP サーバーは、パーティション全体を読み込んで照会された情報を検索しなければならなくなります。属性を定義するときは、その属性のインデックスを必要に応じて作成できます。また、attributeSchema オブジェクトの searchFlags 属性を 1 に設定して属性のインデックスを作成することもできます。インデックスは、次の条件を満たす属性にのみ追加するようにしてください。

  • 照会に使用される頻度が高い属性であること。属性を追加すると、記憶域が余分に消費されるうえ、アイテムの挿入時にインデックスを管理する必要があるため挿入のパフォーマンスが低下します。このため、使用頻度が低い場合はインデックスを追加しないでください。

  • 属性の値の一意性が高いこと。True と False の 2 つの値しかとらないブール型属性にはインデックスを付加しないでください。社員番号や姓は一意性が高いので、インデックスに適しています。

  • 照会される頻度が高いオブジェクトの属性であること。属性にインデックスを付けると、その属性を持つオブジェクトをより高速に照会できるようになります。インデックスを追加する前に、その属性が目的のオブジェクトの必須属性または省略可能属性であることを確認してください。

新しいオブジェクトの追加

スキーマには、新しいオブジェクト クラスを随時に追加できます。オブジェクトの定義は、名前、オブジェクト識別子 (OID)、必須属性と省略可能属性のリスト、オブジェクトの親になれるクラスのリスト、オブジェクトの派生元のクラス、およびオブジェクトに適用する補助型クラスのリストで構成されています。

スキーマの拡張方法
スキーマは、ディレクトリに格納できる情報を管理し、ディレクトリに既に格納されている情報を示します。したがって、スキーマへの書き込みアクセスは、既定では、管理者に対してのみ許可されます。Windows 2000 には、Microsoft 管理コンソール (MMC) 用のスキーマ管理スナップインが用意されています。適切な特権を持つユーザーであれば、新しい属性とクラスを作成することでスキーマを拡張できます。属性は、新しいクラスと既存のクラスのどちらにも追加できます。新しい属性やクラスのそれぞれについて、OID が必要です。

オブジェクト識別子 (OID)
オブジェクト識別子は、ディレクトリ サービス内のオブジェクト クラスまたは属性を明確に識別する番号です7。OID は、"発行機関" によって発行され、階層を形成します。OID は、"1.2.3.4" のように 10 進数の数をピリオド (.) で区切った文字列として表されます。企業または個人として発行機関からルート OID を取得したら、その OID を使って新しい OID を割り当てることができます。たとえば、Microsoft に対して発行されたルート OID は 1.2.840.113556 です。Microsoft では、このルート OID から枝分かれする OID を社内で管理しています。Active Directory クラスや属性など、オブジェクトの種類に応じて、異なる枝を使用しています。

世界の多くの国々では、企業に対する OID の発行を統括する "登録機関 (NRA: National Registration Authority)" が指定されています。米国では、American National Standards Institute (ANSI) が登録機関として指定されています。ルート ID は、登録機関によって発行されます。企業が OID の名前を登録することも可能です。ルート OID の発行と名前の登録には費用がかかります。詳細については、登録機関にお問い合わせください8。

公開とは、利用可能にしたい情報が直接格納されているオブジェクトか、またはその情報への参照が格納されているオブジェクトをディレクトリ内に作成することを意味します。たとえば、ユーザー アカウントには、電話番号や電子メール アドレスなど、有用なユーザー情報が格納され、また、ボリューム オブジェクトには共有ファイル システム ボリュームへの参照が格納されます。

どのような場合に情報を公開するか
Active Directory への情報公開は、その情報がユーザー コミュニティの関心が高く、大多数のユーザーに役立つ場合、そして多くのユーザーがその情報にアクセスする必要がある場合に行います。

Active Directory に公開する情報は、次の 2 つの条件を満たしている必要があります。

  • 比較的静的で、変更の頻度が低いこと。たとえば、電話番号や電子メール アドレスは変更頻度が低いので、公開に適しています。これとは逆に、ユーザーが現在選択している電子メール メッセージのような情報は、揮発性が高く、公開に適していません。

  • 構造化されており、明確な属性の集合として表現できること。たとえば、ユーザーの住所は構造化された情報なので、公開に適しています。これとは逆に、ユーザーの音声は構造化されていない情報なので、ファイル システムを使用する方が適しています。

アプリケーションの操作に関する情報は、Active Directory への公開に特に適した情報です。このような情報には、特定のアプリケーションのすべてのインスタンスに適用するグローバルな構成情報などがあります。たとえば、リレーショナル データベース製品の場合なら、データベース サーバー用の既定の構成情報を Active Directory 内にオブジェクトとして保存することが考えられます。この場合、製品を新しくインストールするときにオブジェクトから既定の構成情報を取得できるので、インストール処理が簡単になり、企業内のインストールの整合性が強化されます。

また、アプリケーションの "接続ポイント" をディレクトリに公開することもできます。接続ポイントは、クライアントとサーバーのランデブに使用されます。Active Directory では、"サービス管理ポイント オブジェクト" を使った統合サービス管理のアーキテクチャが定義されており、RPC、Winsock、および COM に基づくアプリケーションで使用できる標準接続ポイントが提供されています。接続ポイントの公開に RPC インターフェイスまたは Winsock インターフェイスを使用しないアプリケーションの場合は、"サービス接続ポイント オブジェクト" を明示的にディレクトリに公開できます。

また、アプリケーション固有のオブジェクトを使って、アプリケーション データをディレクトリに公開することもできます。アプリケーション固有のデータは、前述の条件を満たす必要があります。多くのユーザーの関心を引き、揮発性が低く、構造化されたデータを公開するようにしてください。

公開の方法
情報の公開手段は、アプリケーションやサービスによって異なります。

  • RPC RPC アプリケーションでは、RpcNs* ファミリの API を通じて、ディレクトリに接続ポイントを公開し、接続ポイントから公開元のサービスを照会します。

  • Windows Sockets Windows Sockets アプリケーションでは、Winsock 2.0 に用意されている Registration and Resolution ファミリの API を通じて、接続ポイントを公開し、接続ポイントから公開元のサービスを照会します。

  • DCOM DCOM サービスでは、Active Directory 内にある DCOM クラス ストアを経由して接続ポイントを公開します。

Windows 2000 には、新しいグループ機能が搭載されています。

  • 次期 Exchange をインストールすると、グループを配布リストとして扱えるようになります。

  • グループには、セキュリティ用以外のメンバも含めることができます。これにより、同じグループをセキュリティと配布リストの両方の目的で使用できます。

  • グループをセキュリティ目的で使用できないように設定できます。これにより、グループの使用目的を配布リストだけに制限できます。

  • グループは、入れ子にすることができます。

  • 新しいグループの種類として、"ユニバーサル" グループが追加されました。

ユニバーサル グループは最も単純なグループで、フォレスト内のどの ACL にも追加できます。また、このユニバーサル グループには、ほかのユニバーサル グループやグローバル グループ、あるいはフォレスト内のどのユーザーでも格納することができます。小規模な環境では、ユニバーサル グループだけを使用できます。グローバル グループやローカル グループは使用できません。

グローバル グループは、フォレスト内のどの ACL にでも追加できます。グローバル グループには、同じドメイン内のユーザーや同じドメイン内のほかのグローバル グループを格納できます。

ドメイン ローカル グループは、定義元のドメイン内の ACL でのみ使用できます。ドメイン ローカル グループには、フォレスト内の任意のドメインのユーザーとグローバル グループを格納できるほか、ユニバーサル グループや、所属先のドメイン内のほかのドメイン ローカル グループを格納できます。

これらの 3 種類のグループを適切に使い分けることで、詳細で柔軟なアクセス制御を実現でき、グループ メンバシップの変更に伴うグローバル カタログへの複製トラフィックを低減できます。ユニバーサル グループは GC に追加されますが、そのメンバは、主にフォレスト内のドメインに所属するグローバル グループです。グローバル グループをいったん確立すれば、ユニバーサル グループのメンバシップに対する変更はごく低い頻度でしか発生しなくなります。グローバル グループは GC に追加されますが、グループのメンバは含まれません。グローバル グループ内のメンバシップの変更は、定義元のドメイン以外のドメインには複製されません。ドメイン ローカル グループは、定義元のドメイン内でのみ有効となるので、GC には追加されません。

ページのトップへ ページのトップへ

移行

ここでは、以前のバージョンの Windows NT からの移行の概要を示します。https://www.microsoft.com/japan/windows2000/default.mspx には、移行の詳細について述べた複数のドキュメントが用意されています。

Windows NT 3.51 システムおよび Windows NT 4.0 システムは、Windows 2000 に直接アップグレードできます。Windows NT 3.1 システムおよび Windows NT 3.5 システムは、いったん Windows NT 3.51 または 4.0 にアップグレードした上で、Windows 2000 にアップグレードする必要があります。Windows 2000 を新規にインストールできるシステムは、Windows 2000 ハードウェア互換性リストに記載されているとおりです。

ドメイン コントローラでは、ディレクトリのコピーが維持されます。Windows NT 3.51 および 4.0 では、プライマリ ドメイン コントローラ (PDC) とバックアップ ドメイン コントローラ (BDC) の 2 種類のドメイン コントローラがあります。プライマリ ドメイン コントローラには読み取り/書き込みコピーが置かれ、バックアップ ドメイン コントローラには読み取り専用コピーが置かれます。

Windows 2000 では、各ドメインのすべてのドメイン コントローラにディレクトリの書き込み可能コピーが置かれます。プライマリとバックアップの区別はなく、すべてのドメイン コントローラが同等に機能します。

Windows NT 3.51 または 4.0 のドメインを Windows 2000 に移行するには、まず最初にドメインのプライマリ ドメイン コントローラを Windows 2000 にアップグレードする必要があります。これにより、ドメイン ディレクトリ内のユーザーとグループが自動的に Active Directory にロードされます。アップグレード処理として、ドメインを次のいずれかとして作成するように指定します。

  • 新しいフォレスト内の新しいツリーのルート。

  • 既存のフォレスト内の新しいドメイン ツリーのルート。

  • 既存のドメイン ツリーの子ドメイン。

作成した直後のドメインは、"混在ドメイン" として扱われます。ドメインは、Windows 2000 管理ツールを使用して管理できます。ディレクトリ内に複数の組織単位フォルダからなる階層構造を作成して、管理権限を委任することができます。バックアップ ドメイン コントローラ、メンバ サーバー、およびクライアントは変更されず、PDC が Active Directory サーバーとして機能するようになったことの影響は受けません。

バックアップ ドメイン コントローラを移行するには、各コントローラを Windows 2000 にアップグレードします。バックアップ ドメイン コントローラは、アップグレード処理中に検出され、Active Directory レプリカとして自動的にインストールされ、複製トポロジに挿入されます。すべてのドメイン コントローラを Windows 2000 にアップグレードし終えると、ドメインは混在ドメインではなくなり、入れ子になったグループがサポートされるようになります。

メンバ サーバーを移行するには、各サーバーを Windows 2000 にアップグレードします。ローカル ユーザーおよびローカル グループはメンバ サーバーのレジストリに保存されているので、Active Directory には移動されません。メンバ サーバーを Windows 2000 にアップグレードすると、Kerberos セキュリティへの参加が可能になり、Active Directory 対応アプリケーションのサポートが追加されると共に、Microsoft 管理コンソール、Active Directory 対応シェル、およびコモン ダイアログが追加されます。

Windows NT Workstation がインストールされているクライアントを移行するには、それらを Windows 2000 Professional にアップグレードします。Windows 95 がインストールされているクライアントを移行するには、クライアントを Active Directory 対応にするためのソフトウェア コンポーネントが含まれているサービス パックをインストールします。クライアントをアップグレードすると、Kerberos セキュリティへの参加が可能になり、Active Directory 対応アプリケーションのサポートが追加されると共に、Active Directory 対応シェルおよびコモン ダイアログが追加されます。

ユーザー アカウントは、ダウンレベル PDC (3.51 または 4.0) を Windows 2000 にアップグレードすると、Active Directory に移行され、ドメイン ルート内の User コンテナに格納されます。

コンピュータ アカウントは、ダウンレベル PDC (3.51 または 4.0) を Windows 2000 にアップグレードすると、Active Directory に移行され、ドメイン ルート内の Computers コンテナに格納されます。

グループは、ダウンレベル PDC (3.51 または 4.0) を Windows 2000 にアップグレードすると、Active Directory に移行され、ドメイン ルート内の User コンテナに格納されます。組み込みのグループは、Built-in コンテナに格納されます。

ページのトップへ ページのトップへ

よく寄せられる質問

ワークステーションは、所属先のサイトを発見するときに、まず、割り当てられているサブネット マスクを割り当てられている IP アドレスに適用してサブネットを決定します。これらのサブネット マスクと IP アドレスは、DHCP によって割り当てられる場合と、静的に構成される場合があります。次に、ワークステーションは、決定したサブネットを最初に接続した Active Directory サーバーに提示します。ワークステーションが最初に接続したサーバーは、提示されたサブネットに基づいて、ワークステーションが所属しているサイトのサイト オブジェクトを検索します。現在のサーバーがそのサイトに所属していない場合は、ワークステーションから使用するのに適した別のサーバーがワークステーションに通知されます。

ワークステーションは、DNS を照会してディレクトリ サーバーを検索します。各ドメイン内のディレクトリ サーバーは、次の形式の名前を使用して、DNS に SRV リソース レコードを公開します。

LDAP.TCP.<domain name>

たとえば、Microsoft.com にログインするワークステーションは、LDAP.TCP.Microsoft.com の SRV レコードを DNS に照会します。ワークステーションは、リスト内のサーバーを選択して接続します。前述したように、ワークステーションが接続したサーバーは、ワークステーションが提示したサブネット情報に基づいて、ワークステーションからの使用に最も適したサーバーを決定します。

ユーザーが Windows 2000 Professional にログオンするときは、さまざまな形式のさまざまな名前を使用できます。これらには、Win32® API の DsCrackNames 関数でサポートされている名前形式が含まれます。この関数は、名前形式を必要に応じて変換します。

  • ドメイン NETBIOS 名と SAM アカウント名 これは、Windows NT 4.0 スタイルのログオン名です。ドメインの NETBIOS 名は、移行以前にドメインに割り当てられていた名前です。SAM アカウント名は、移行以前にユーザーに割り当てられていた名前です。

  • ユーザー プリンシパル名 <friendly name>@<dotted-dns-domain-name> の形式の名前です。名前が一意でなければ、ログインが失敗し、"不明なユーザー" エラーが発生します。

アクセス制御リストは、移行による直接の影響を受けません。Windows NT 3.51 ドメインと Windows NT 4.0 ドメインをすべて現状のまま移行する限り、ACL に関しては変更が生じません。

リソース ドメインから移行後のアカウント ドメイン内の組織単位にサーバーを移動し、"リソース ドメインを削除" した場合は、削除したドメインを参照している ACE が含まれている ACL を編集する必要が生じます。これは、Windows 2000 への移行が原因となって必要になるわけではありません。どのバージョンの Windows NT でも、ドメインを削除すると、そのドメインから発行したセキュリティ ID は無効になります。

Windows NT 3.51 または 4.0 から Windows 2000 への移行時に既存のリソース ドメインを OU で置き換え、それらのリソース ドメインを削除する場合は、それらのリソース ドメインのグループを ACL に移動しないようにすれば、ACL リソースを再適用する必要がなくなります。ただし、これはメンバ サーバーのローカル グループは関係ありません。影響を受けるのはドメイン コントローラのローカル グループだけです。

Windows 2000 には、今後リソースへの ACL の再適用を支援するツールが追加される予定です。

ドメイン内に作成したグループには、そのドメインによって発行されたセキュリティ ID (SID) が割り当てられます。グループに割り当てられた SID を ACL に追加すると、その SID を含むトークンを持つユーザーに対してアクセスが許可されます。SID を発行したドメインにユーザーがログオンすると、その SID がユーザーのトークンに追加されます。この処理は、ネットワーク ログオンの場合にも有効で、透過的に行われます。

ACL を編集するときには、SID を引数として API 関数 LookupAccountName が呼び出されます。SID の発行元のドメインを削除すると、ACL のユーザーおよびグループのリストに "不明なユーザー" と表示されます。Windows NT 3.51 および Windows NT 4.0 では、ドメインや信頼リンクを削除した場合に、このエラーが発生します。

2 つの場合に分けて回答します。

  • メンバ サーバー上のローカル グループの場合 メンバ サーバー上のローカル グループは、ローカルなままに維持されます。これらのグループは、メンバ サーバー上の SAM にのみ存在するので、Active Directory に移行されません。メンバ サーバーでは、アカウント ドメインで定義されたグローバル グループを保持する目的でローカル グループを使用することがよくあります。この場合、サーバー管理者がローカル グループをサーバー リソースの ACL に追加した上で、グローバル グループをローカル グループに追加します。これは Windows 2000 でも基本的に同じですが、グローバル グループが通常のグループとなり、Active Directory に公開される点が異なります。

  • PDC および BDC 上のローカル グループの場合 バックアップ ドメイン コントローラには、読み取り専用の SAM が置かれます。BDC 上でローカル グループを作成すると、作成操作が PDC を経由して ほかのすべての BDC に複製されます。メンバ サーバー上のローカル グループと意味的に同一のローカル グループが PDC およびすべての BDC 上に存在することになります。Windows 2000 へのアップグレード時には、これらのローカル グループのそれぞれに対応するドメイン ローカル グループ オブジェクトが Active Directory 内に作成されます。

グローバル カタログの検索は、次のいずれかの方法で開始できます。

  • NULL DN (名前空間のルート) からサブツリー検索または 1 レベルの LDAP 検索を行う。この場合は、グローバル カタログへの参照が生成されます。

  • GC レプリカの GC ポートを直接参照する。ただし、クライアント プログラムでこの検索方法が使用されることはあまりありません。

  • GC ADSI プロバイダ (GC://) を明示的に参照する。

Microsoft DNS の方がさまざまな点で優れていますが、RFC 準拠の DNS サーバーでも十分使用できます。ダイナミック DNS の使用をお勧めします。ダイナミック DNS サーバーを使用すると、Active Directory サーバーが必要なレコードを DNS に自動登録できるようになります。静的な DNS サーバーも十分使用できますが、Active Directory サーバーごとに DNS 登録を手動で実行しなければなりません。

Windows 2000 に用意されている DNS サーバーは、RFC および BIND に準拠してダイナミック DNS を実装したものです。パブリック ドメインとして実装された BIND を移植したものではなく、Windows 2000 用にネイティブに実装されています。各 Microsoft DNS サーバーには、Active Directory 内でそのサーバーが権限を持つ DNS ゾーンが格納されます。Microsoft DNS サーバー間では、ゾーン転送ではなく、Active Directory 複製を通じて、DNS データを複製します。Microsoft DNS サーバーでは、ほかの DNS サーバーとの相互運用性を確保するために、標準の DNS ゾーン転送をサポートしています。

Windows 2000 には、DHCP サーバーに関する大きな変更はありません。DHCP クライアントは DNS に対応しており、ダイナミック DNS のサービスを使用して、DHCP から発行されたアドレスを DNS 内に直接登録するようになっています。DHCP で WINS サーバーが認識される限り、DHCP クライアントは WINS にも引き続き登録されます。

Windows 2000 には、WINS に関する変更はありません。Windows 2000 クライアント (および Active Directory アップグレードをインストールした Windows 95 クライアント) では、NETBIOS 名前空間を使用する必要がなくなりました。WINS は、ダウンレベル クライアントとサーバーが相互を検索するために引き続き使用されます。エンタプライズ内にダウンレベル クライアントがなくなったら、その時点で WINS サーバーをオフにすることができます。

© 1999 Microsoft Corporation. All rights reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証を致しません。

Microsoft、BackOffice、BackOfficeロゴ、MSN、Visual Basic、Win32、Windows、Windows NT、Active Directory は米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。

その他、記載されている会社名および製品名は、各社の商標および登録商標です。

Microsoft Corporation. One Microsoft Way. Redmond, WA 98052-6399 USA

  1. RFC 2136
  2. スキーマでは、さまざまな有用なプロパティが定義されています。特に検索に役立ちます。
  3. このドキュメントを作成した時点 (98/12/8) において、LDAP v3 (RFC 2251) は、まだ提唱段階のプロトコルです。
  4. ADSI では、すべての LDAP ディレクトリ、Windows NT 4.0、NetWare 3.x、NetWare 4.x を含む複数のドメインに共通の方法でアクセスできます。
  5. これらの ACE は、あくまで例として示しています。ACE の実際の構文は、例示したものと異なります。
  6. ここで "高帯域幅" とは、イーサネット相当の速度 (毎秒 1000 万ビット) か、それ以上の速度を意味します。
  7. OID は、ほかの多くのアプリケーションでも使用されていますが、ディレクトリ サービス アプリケーションでの使用が最もよく知られています。
  8. 国際標準化機構 (ISO) では、メンバ組織のリストを Web サイト http://www.iso.ch に公開しています。

ページのトップへ ページのトップへ