Active Directory
Active Directory (アクティブディレクトリ) とはマイクロソフトによって開発されたオンプレミスにおけるディレクトリ・サービス・システムであり、Windows 2000 Serverから導入された、ユーザとコンピュータリソースを管理するコンポーネント群の総称である。なお、クラウドコンピューティングにおけるディレクトリ・サービス・システムであるAzure Active Directoryと区別する場合、オンプレミス Active Directoryと表記することもある[1][2]。
経緯
[編集]Microsoft 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サーバの設置やゾーン情報の編集が必須となるなど、設計、構築、運用、保守の全てにおいて必要なスキル水準が上昇した。したがって、ファイルとプリンタの共有ができれば十分であり、システムをリプレースするメリットはないと判断して導入を見送ったユーザーも多かった。
Active Directoryの構成要素と概念
[編集]
ADドメイン
[編集]ADドメインとは、Windows 2000 Server以降のWindows Server DCで構成される、ユーザーとコンピュータの管理単位である[3]。
DCはADをインプリメントした実体であり、ディレクトリデータベースにPCやユーザー、グループなどのアカウントを登録することにより、ユーザーやコンピュータの権利と権限の集中管理を可能とする。また、「グループポリシー」機能によってPCやユーザーの環境を制御できる。
ADドメインに登録されたユーザは「Domain Users」など何らかのセキュリティグループに所属しており、通常は管理を簡略化するためグループ単位でセキュリティを設定する。セキュリティグループには、適用範囲の狭い順に「ビルトインローカル」「ドメインローカル」「グローバル」「ユニバーサル」の4種類があり、異なる種類のグループを別のグループに所属させる“入���子”も可能である。
ADドメインの主要な機能である、ユーザー認証とグループポリシーの適用を管理する機能を持たされた特別なサーバがDCである。DCはクライアントPCから常に参照可能でなければならないため、IPアドレスを固定で割り当てる必要がある。ADドメインのドメイン階層構造はDNSの名前階層構造をLANに応用したものであり、コンピュータ間の名前解決にはDNSサーバが必須である。
基本的に1つのフォレストに1台のDNSサーバがあればサブドメインを含めて統一管理できるので、必ずしもADのサブドメインに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の名前階層に従って階層構造、すなわちフォレストを構成できる。Wikipediaを例に取ると、基準となる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では変更できないようにしたい」といった要求に対応できる。
サイト
[編集]サイトは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ドメインコントローラ
脚注
[編集]- ^ “Azure AD (Office 365) 上のユーザーをオンプレミス Active Directory ユーザーと紐付ける方法について”. マイクロソフト (2017年3月22日). 2021年3月14日閲覧。
- ^ “de:code 2015 Azure Active Directory とオンプレミス Active Directory の連携”. マイクロソフト (2017年3月22日). 2021年3月14日閲覧。
- ^ “Active Directory ドキュメント”. マイクロソフト (2020年11月9日). 2021年3月14日閲覧。
外部リンク
[編集] | |||||||||
|---|---|---|---|---|---|---|---|---|---|
| 人物 |
| ||||||||
| ソフトウェア |
| ||||||||
| 開発言語 | |||||||||
| 技術 | |||||||||
| オンラインサービス |
| ||||||||
| ゲーム | |||||||||
| ハードウェア | |||||||||
教育と認識 | |||||||||
| ライセンス | |||||||||
| 会議 | |||||||||
| 批判 | |||||||||
| 訴訟 | |||||||||
| 買収企業 | |||||||||
| キャラクター | |||||||||
| 関連人物 | |||||||||
| 部門 | |||||||||
