Question: Active Directory はいつ開発された

Active Directory

Active Directory (アクティブディレクトリ) とはマイクロソフトによって開発されたオンプレミスにおけるディレクトリ・サービス・システムであり、Windows 2000 Serverから導入された、ユーザとコンピュータリソースを管理するコンポーネント群の総称である。なお、クラウドコンピューティングにおけるディレクトリ・サービス・システムであるAzure Active Directoryと区別する場合、オンプレミス Active Directoryと表記することもある。[1][2]

経緯
Windows 95発売後、Windowsはグラフィカルユーザインタフェース (GUI) で操作できる利便性からクライアント用オペレーティングシステム (OS) として急速に普及した。標準でネットワーク機能を有していたことから、主に企業や大学などでPCのネットワーク化が促進されたが、ユーザ管理やアクセス制御機能が貧弱で、ネットワークの規模が拡大するにつれて管理上の弱点となっていった。
これに対してWindows NTでは、クライアントPC単体でユーザ管理およびアクセス制御機能を搭載しており、さらにWindows NTサーバを中心とするNTドメインを構築することで、ユーザーおよびパーソナルコンピュータ (PC) のユーザアカウントをドメインコントローラ (Domain controller、以下DC) で集中管理できるようになった。

やがてNTサーバが大規模ネットワークでも利用されるようになると、NTドメインの短所が露呈してくる。すなわち：
ドメイン間の階層構造がとれない

PC名 (NetBIOSコンピュータ名) の名前空間が単一であるため、別NTドメインであっても同名のPCが同一ネットワーク上に存在できない
基本的にLAN内で構築することが前提のシステムであり、WANのような狭帯域の回線が存在すると、ログオン認証パケットの不達や遅延によるアクセス不能問題を起こしやすい。

Security Account Manager (SAM) データベース (実体はレジストリ) の最大容量がわずか40MBと少なく、ユーザーアカウントやコンピュータアカウントを4万件程度しか登録することが出来ない。
などである。
これらの問題を解決し、NTドメインのユーザーおよびコンピュータ管理機能を継承しつつ、大規模ネットワークでも利用できるように大幅に改良したのがActive Directory (以下AD) である。

ADでは、上記の欠点を改善したほか、以下のような特徴を持つ。
DNSやケルベロス認証システム、LDAPの導入など、いわゆる「インターネット系のオープン技術」が大幅に取り入れられている。
DNSやDCにおいて、複数のマスタサーバが存在する「マルチマスタシステム」が取り入れられている。
反面、ADを構築するにはDNSサーバの設置やゾーン情報の編集が必須となるなど、設計、構築、運用、保守の全てにおいて必要なスキル水準が上昇してしまい、NTドメインほど「お手軽」ではなくなってしまった。また、ファイルとプリンタの共有ができれば十分であり、サポートが得られなくても現に利益を生み出しているシステムを、リプレースするメリットはないと判断したユーザーも多い。2006年末でWindows NT Server 4.0のサポートはオンラインサポートも含めて完全に終了したが、依然として稼働中のNTドメインが残っており、マイクロソフトはNTドメインからADへの移行を促進することを課題としている。


ADの構成要素と概念

ドメイン
ADドメインとは、Windows 2000 Server以降のWindows Server DCで構成される、ユーザーとコンピュータの管理単位である。
[3]
[4]
DCはADをインプリメントした実体であり、ディレクトリデータベースにPCやユーザー、グループなどのアカウントを登録することにより、ユーザーやコンピュータの権利と権限の集中管理を可能とする。また、「グループポリシー」機能によってPCやユーザーの環境を制御できる。

ADドメインに登録されたユーザは、必ず「Domain Users」など何らかのセキュリティグループに所属しており、通常はセキュリティ管理を簡略化するためグループ単位でセキュリティを設定する。セキュリティグループには、適用範囲の狭い順に「ビルトインローカル」「ドメインローカル」「グローバル」「ユニバーサル」の4種類があり、異なる種類のグループを別のグループに所属させる“入れ子”も可能である。

ADドメインの主要な機能である、ユーザー認証とグループポリシーの適用を管理する機能を持たされた特別なサーバがDCである。DCはクライアントPCから常に参照可能でなければならないため、IPアドレスを固定で割り当てる必要がある。ADドメインのドメイン階層構造はDNSの名前階層構造をLAN内に応用したものであり、コンピュータ間の名前解決にはDNSサーバが必須である。

基本的に1つの「フォレスト」に1台のDNSサーバがあれば、サブドメインを含めて統一管理できるので、ADのサブドメインにもDNSサーバを設置する必要はない。ただし、どのようにDCやDNSサーバを設置する場合でも、1台だけではサービス効率と耐障害性が劣るため、複数台設置するのが通常である。
ディレクトリデータベースはDC間で「マルチマスタレプリケーション」が行われており、ユーザアカウントの登録などディレクトリデータベースへの変更操作は、基本的にすべてのDCで可能である。ただし、Windows Server 2008の「読み取り専用DC」においてはこの限りではない。ちなみに、NTドメインではSAMの“原本”を扱うプライマリDCがただ1台あり、必要に応じて“謄本”を扱うバックアップDCを追加する。ユーザアカウントの登録などは常にプライマリDCが行い、バックアップDCは複製されたSAMを参照してユーザー認証を行う。
フォレストの階層構造の変更や、オブジェクトの元となるスキーマの編集、相対IDの発行などは、ドメインまたはフォレストごとに1台存在する、Flexible Single Master Operations (FSMO) の操作マスタを実行するDCが占有的に操作する。

ログオン認証などでは、分厚い“電話帳”であるディレクトリデータベースよりも、もっぱら簡易な“早見表”に相当する「グローバルカタログ(GC)」が多用される。
フォレスト
フォレストはDNSの名前階層に基づく1つ以上のADドメインの階層的集合である。1つ以上のADドメインを含むシステム領域であり、ADの概念の中で最も外側の領域である。
1つ以上のADドメインを設置する際に、DNSの名前階層に従って階層構造、すなわちフォレストを構成できる。基準となるADドメインD1 (ja.wikipedia.org) の下層に作成されたADドメインD2 (sub1.ja.wikipedia.org) は「サブドメイン」となる。基準ドメインD1とサブドメインD2の間には自動的に双方向の信頼関係が結ばれる。サブドメインD2は、ドメインD1の下に作成された別のサブドメインD3 (sub2.ja.wikipedia.org)、あるいはドメインD1のさらに上位ドメインD0 (wikipedia.org) とも自動的に信頼関係が結ばれる。つまり、「ドメインD2がドメインD1を信頼し、ドメインD1がドメインD0を信頼しているとき、ドメインD2はドメインD0を信頼する」という論理で信頼関係を結ぶ。これを「信頼の推移」と呼ぶ。

同一フォレスト内のADドメインであれば、信頼の推移が行われるとともに、グループの共有も可能である。ただ1つのADドメインしかなくてもフォレストを形成し、シングルフォレスト、シングルドメイン、シングルサイト構成になる。最初に構築したADドメインは「フォレストルートドメイン」となり、他のADドメインを増設する際の基準ドメインになる。先の例では、ドメインD0 (wikipedia.org) がフォレストルートドメインであり、他のADドメインに先駆けて最初に構築しなければならない。

Windows 2000 Serverによるフォレストでは、フォレスト間で一括して信頼関係を結ぶことはできない。すなわち、フォレストルートドメイン間で信頼関係を結んでも、サブドメインには信頼は推移しない。NTドメインと同様に、異なるフォレストに属するADドメイン間で個別に信頼関係を結ぶことはできる。Windows Server 2003以降では「フォレスト間信頼」がサポートされ、フォレストルートドメイン間で信頼関係を結ぶことで、各フォレストに属するADドメインも自動的に推移する信頼関係を結んだことになる。
組織単位
組織単位 (OU; Organizational Unit, Organization Unitとも) とは、セキュリティグループとは別に、ユーザーやコンピュータを管理するグループである。本社、支社、支店といった大きな分類の下に、経理、営業、総務、開発などのOUを作成して、現実の組織体制や資産管理体制に即したグループの階層を構築することで、運用管理を容易にする。組織体制に則した複数のADドメインを作成する必要がなく、セキュリティ要件 (パスワード管理) が同一であれば、単一ドメインで管理できる。
また、OUにはグループポリシーオブジェクトをリンクできるので、「開発用のPCではデスクトップ環境をカスタマイズ可能にするが、経理のPCでは変更できないようにしたい」といった要求に対応できる。
サイト
サイト</b>はADとはやや性格を異にする、物理ネットワークの境界に基づいた概念であり、主に4つの目的で使用される。すなわち、ディレクトリデータベースの複製トラフィックの最適化、ログオン認証トラフィックの最適化、グループポリシーの適用スコープ変更、そして管理の委任である。

通常は、同一LANで通信できる範囲をサイトとする。ただし、高速なWAN回線を使う場合は、WANを越えたサイトを作成することもある。ADドメインを新規構築すると、自動的に「Default-First-Site-Name」という名前のサイトも作成されるため、意識せずともサイトを利用する。
サイト内では、ディレクトリ情報は変更がある度に圧縮されずに複製される。また複製パスは最大3ホップの複数リング状に構成される。一方、サイト間の場合は、定期的に (既定値は180分、最短で15分に構成可能)、圧縮して複製される。また、複製パスはスパンツリー型に構成される。

クライアントは、自分のサブネット情報をもとにサイト情報を取得し、同一サイトのDCに対して優先的に認証を要求する。
サイトの目的を達成するためには、各サイトに1台以上のDCが設置されている必要がある。DCのないサイトは、近隣サイトのDCがそのサイトを自動的に担当する。これを「自動サイトリカバリ」と呼ぶ。
あるDCが持つディレクトリ情報を他のサイトのDCに複製することを、「サイト間レプリケーションを行なう」という。レプリケーションを行なうDCは、管理ツールの「Active Directoryサイトとサービス」でサイトを作成し、レプリケーションパートナーとなる相手のサイトリンクと関連付ける必要がある。レプリケーションすることで、ディレクトリデータベースの情報を共有するため、グループポリシーやデータベースをパートナー同士で自動的に最新の状態を維持することができる。

ひとつの地域に複数のDCがあるとき、サイト内と同様のパスで他の地域とレプリケーションすると、ネットワークに膨大な負荷がかかる。そのためサイト内の1台のDCを「ブリッジヘッドサーバ」、すなわち橋頭堡として自動的に選出し、そのDCをサイトの代表としてサイト間複製を行う。そのほかのDCはそのブリッジヘッドサーバから得た情報をサイト内で複製する。つまり、ブリッジヘッドサーバは、他の地域からレプリケーションされたものをそのサイト内のすべてのDCへレプリケーションする。そうすることで効率よく最新の状態を確保している。
例
東京にあるDC「wiki」と、大阪にあるDC「pedia」があるとする。二つのDCはレプリケーションパートナーとなっている。
東京のDCのドメインに参加しているクライアントを使っている「草薙さん」がブリッジヘッドサーバのグループポリシーを変更すると、定期的に変更が大阪のレプリケーションパートナーにもフィードバックされ、大阪のブリッジヘッドサーバにも変更が反映されるため、大阪ドメインの「バトーさん」も同じ状態のグループポリシーで作業ができる。
同じように全国のDCをレプリケーションパートナーとして設定すると、東京で変更したディレクトリデータベースが自動的に自分の参加しているDCに反映されるため、東京のサーバにアクセスする必要が無い。また、レプリケーション間隔はDCで設定できる。ここで設定した間隔もすべてのパートナー間でレプリケーションする。
マルチマスタレプリケーション
マルチマスタレプリケーションとは、分散管理されているADのディレクトリデータベースおよびグループポリシーオブジェクトを、矛盾なく相互に交換し統合する複製手法である。同一オブジェクトが複数のDCで更新された場合、時系列的に後に更新されたオブジェクトが採用される。これによって、複数のDCを設置しても「船頭多くして船山に登る」状況を回避できる。

ADSI
アプリケーションがADにアクセスするためのAPIが、ADSI (= Active Directory Service Interface) である。AD内のオブジェクトの検索、閲覧、編集、削除を実行できるため、例えばユーザー管理やコンピュータ管理などの操作を自動化することができる。
関連項目
ネットワークオペレーティングシステム
LAN Manager
ドメインコントローラ
Samba - オープンソースのActive Directoryドメインコントローラ
外部リンク

 Microsoft ホームページ Windows Server 製品情報ページ

脚注