-
Notifications
You must be signed in to change notification settings - Fork 0
MS_ActiveDirectoryTerms
-
TOP > インフラストラクチャ > ドメイン サービス (AD DS)
- Active Directory(用語)
- Active Directory(概要)
- Active Directory(参考情報)
いずれも Active Directory(概要) を参照。
- ドメイン
- ドメイン コントローラ(DC)
- ドメイン ツリー
- フォレスト
Active Directory(概要) を参照。
Active Directory(概要) を参照。
-
Active Directory で管理される情報の最小単位のことである。
-
ユーザやグループ、コンピュータなどがオブジェクトとして管理される。
- オブジェクトの中には、ユーザやコンピュータとは異なり、
オブジェクトの内部に、さらに別のオブジェクトを含むことができるものがある。
これを「コンテナ オブジェクト」と呼ぶ。
- オブジェクトの中には、ユーザやコンピュータとは異なり、
-
「コンテナ オブジェクト」には 2 種類あり、
- 非コンテナ オブジェクトのみを含むことができる「コンテナ オブジェクト」と、
- 別の「コンテナ オブジェクト」も含むことができる「コンテナ オブジェクト」がある。
-
管理者が Active Directory 導入後に作成できるコンテナ オブジェクトは、
コンテナ オブジェクトを含むことができる「組織単位(OU)」だけである。 -
コンテナ オブジェクトを含むことができないコンテナ オブジェクトには、
デフォルトで作成される「Computers」や「Users」といったコンテナがあるが、
管理者がこれらを作成することはできない
(デフォルトで作成されるコンテナ内にオブジェクトを追加することはできる)。
補足: 「Computers」「Users」は
containerクラスのオブジェクトで、 グループ ポリシー(GPO)をリンクできないという重要な制約がある。 このため、ドメイン参加時の既定の配置先をredircmp/redirusrコマンドで OU に変更する運用がよく採られる。
-
Active Directory で新たに採用された管理単位
-
管理者が Active Directory 導入後に作成できる唯一のコンテナ オブジェクト
-
管理者が容易にドメインを管理できるようにすることを目的とする。
-
内部にさらに別の OU を含むことができる。オブジェクトを組織化するために利用される。
-
OU は地域別のオブジェクトや組織別オブジェクトなどを管理者が任意に格納できる。
-
組織化する主な目的は以下の 3 つである。
- OU 単位で管理者を割り当てるために管理範囲をまとめる。
- グループ・ポリシーを使い、OU の単位でコンピュータの利用環境の原則を定める。
- 管理者が分かりやすいようにオブジェクトを分類する。
-
ユーザ アカウント以外の共有リソースを管理することもできる。
- コンピュータ アカウント用 OU
- プリンター専用 OU
- 共有フォルダ専用 OU
-
Active Directory(レプリケーション)で説明済み。
Active Directory ドメインには、
「ネイティブ モード(native mode)」と「混在モード(mixed mode)」という
2 種類のドメインの動作モードがある。
-
ネイティブ モード
ドメインに参加しているドメイン コントローラが、すべて Windows 2000 の
ドメイン コントローラで構成されたドメインの場合に設定できる
(逆にいえば、NT ドメインのドメイン コントローラが存在する場合は、
このモードにすることはできない)。
ネイティブ モードでは Active Directory のすべての機能がサポートされる。 -
混在モード
機能の一部に制限がある代わりに、
Windows NT 4.0 の BDC(バックアップ ドメイン コントローラ)の混在をサポートする。
これにより、NT ドメインから Active Directory ドメインに移行した場合でも、
いままで使っていた BDC をそのまま利用できる。
ドメイン内のドメイン コントローラに 1 台以上の NT BDC が存在する場合は、
混在モードで運用しなければならない。
混在モードの場合、Active Directory のドメイン コントローラは、
NT BDC にもディレクトリ データベースの内容を複製する必要がある
(NT BDC もドメインのユーザ認証処理を担うため、データベース上にユーザ情報が必要である)。
そのため複製データには、NT BDC が理解できるものしか含めることができない。
補足(最新化): 「ネイティブ モード/混在モード」は Windows 2000 固有の用語で、 Windows Server 2003 以降は「機能レベル (ドメインの機能レベル/フォレストの機能レベル)」に置き換えられている。 現行の Windows Server ではこのモードの概念は存在しない。
「Active Directory 統合ゾーン」は、Windows 2000 の DNSサーバにおける
ゾーンの管理タイプの一種である。
Active Directory 統合ゾーンは、ドメイン コントローラと DNSサーバを
同一のコンピュータで構成することにより提供される機能である。
つまりゾーンの管理タイプの一種ではあるが、Active Directory を構築していないと利用できない。
Windows 2000 の DNS サービスでは、3 つのゾーン タイプがサポートされている。
-
標準プライマリ・ゾーン、標準セカンダリ・ゾーン
- 「標準プライマリ ゾーン」はマスタのゾーン ファイルを管理する役割になる。
- 「標準セカンダリ ゾーン」はプライマリ ゾーンからのゾーン ファイルの複製を保持する。
セカンダリ ゾーンはフォールト トレランス(耐障害性)や負荷分散を実現するために構成する。
ただし、セカンダリ ゾーンではレコードの追加や編集はできない。 - 標準プライマリと標準セカンダリで構成された DNS ゾーンの管理は
必ず標準プライマリ ゾーンに対して行う必要がある。
-
Active Directory統合ゾーン
ゾーン情報を Active Directory データベースのオブジェクトとして保持する。
Active Directory データベースはすべてのドメイン コントローラで登録、編集が可能であるため
プライマリ ゾーンが複数存在するのと同じ構成となる。
また、ゾーン転送も Active Directory の複製処理に任せることができる。
Active Directory 統合ゾーンでは、ゾーンに対する動的更新をセキュリティで保護することもできる。
ただし、DNSサーバが Active Directory データベースを保持する
ドメイン コントローラでないと「Active Directory 統合」は選択できない。
補足(最新化): Windows Server 2003 以降では、 3 つ目のタイプとして「スタブ ゾーン」が追加されている。 また、Active Directory 統合ゾーンのデータは Windows Server 2003 以降はアプリケーション パーティション (
DomainDnsZones/ForestDnsZones)に格納され、 レプリケーション スコープを選択できるようになった。
- ドメイン NetBIOS名
- デフォルトでは、割り当てた Active Directory ドメイン名の
先頭のピリオドまでが NetBIOS ドメイン名として利用されるため、
既存のネットワーク環境で先頭のピリオドまでの名前が一意かどうかを
確認しておく必要がある(「○○○.△△△.co.jp」なら「○○○」の部分)。 - また、NetBIOS 名の文字数は最長で 15 文字までしか割り当てられないため、
制限の範囲内にとどめるように名前を付けるべきである。 - もしどうしても NT のドメイン名と重複する場合は、
Active Directory のドメイン名とは別に、NetBIOS ドメイン名を割り当てることもできる。
- デフォルトでは、割り当てた Active Directory ドメイン名の
-
Active Directory のディレクトリ サービス等が使用するデータベース。
-
データベースの格納場所の指定
Active Directory データベースとログ ファイル
(ディレクトリ サービスに対するトランザクション ログ)の格納領域を指定する。
デフォルトではシステムがインストールされているフォルダ(%SystemRoot%)の中に
「NTDS」というフォルダが作成され、これが利用される。
データベース ファイルとログ ファイルのドライブを別の物理ディスクに指定することにより、
システムのパフォーマンスを上げることができる。
補足: データベースの実体は
%SystemRoot%\NTDS\ntds.ditで、 ESE(Extensible Storage Engine / JET Blue)を使用している。
-
ドメイン コントローラ間で共有されるファイルを格納する SYSVOL 共有フォルダ
-
SYSVOL 共有フォルダの場所の指定
システムがインストールされているフォルダ(%SystemRoot%)の中に
「SYSVOL」というフォルダが作成され、利用される。
特別な理由がなければ、混乱を避ける意味でも変更する必要はないだろう。
ここで指定した共有フォルダは、FRS(File Replication Service。ファイル複製サービス)によって、
ドメイン内のほかのドメイン コントローラが保持するシステム共有
(ほかのドメイン コントローラの SYSVOL フォルダ)と双方向の複製が自動的に行われる。この共有フォルダには、グループ ポリシー ファイルなどが配置され、
ほかのドメイン コントローラにも複製されるようになっている。
また NT ドメインで共有フォルダとして利用されていた NETLOGON 共有
(ログオン時のスクリプトなどが置かれているフォルダ)も
この SYSVOL フォルダ内で共有されるため、
下位互換のログオン スクリプトやシステム ポリシー ファイルも
自動的にほかのドメイン コントローラに複製される。
補足(最新化): FRS は Windows Server 2008 で非推奨となり、 Windows Server 2012 R2 以降では完全に廃止された。 現在の SYSVOL レプリケーションは DFSR(DFS レプリケーション) が担う (ドメインの機能レベルを Windows Server 2008 以上に上げたうえで
dfsrmigコマンドで移行する)。
| パーティション名 | 格納されている情報 | レプリケーション スコープ(複製範囲) |
|---|---|---|
| スキーマ パーティション | Active Directory に存在するクラス、オブジェクトの設計情報 | フォレスト ワイド |
| 構成パーティション | ● フォレスト、ドメインの構成情報 ● Active Directory 対応アプリケーションの構成情報 |
フォレスト ワイド |
| ドメイン パーティション | ドメインに存在するオブジェクトの情報 | ドメイン ワイド |
| アプリケーション パーティション | ※2003 から新規導入。Active Directory に情報を格納するように設計されているアプリケーションの情報 | 任意(指定した DC のみ) |
- 説明
-
ADSI Edit で参照可能。
-
スキーマ パーティション
- ディレクトリ サービスのスキーマ情報
- 例えば Active Directory に Exchange Server を導入するときには、
メール関連のクラスや属性が追加される。 - それはスキーマ パーティションへの変更(スキーマ拡張)であるため、
Active Directory 全体に影響が及ぶ。 - 例:
CN=Schema,CN=Configuration,DC=test,DC=local→ Active Directory スキーマ
-
構成パーティション
- Active Directory 自身の構成情報
- Active Directory 対応のアプリケーションの情報
- 例 1:
CN=Sites,CN=Configuration,DC=test,DC=local→ サイトとサービス - 例 2:
CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=local→ Exchange システム マネージャー
-
ドメイン パーティション
- ドメイン内のユーザー、グループ、コンピューターなどの情報
- 例:
DC=test,DC=local→ Active Directory ユーザーとコンピューター
-
- ドメイン ワイド(ドメイン単位の情報)
- フォレスト ワイド(ドメイン単位ではなく、Active Directory 全体にかかわる情報)
-
USN(Update Sequence Number)
DC ごとに保持される単調増加の更新シーケンス番号。
レプリケーションでは、
複製相手ごとに「どの USN まで受け取ったか」を記録することで差分だけを転送する。 -
RID(Relative ID)
SID の末尾を構成する、ドメイン内で一意な相対識別子。
RID プール マスタが各 DC にプールを払い出すことで重複を防ぐ。
- Active Directory(参考情報)
- Active Directory ドメイン サービス - Microsoft Learn
- SYSVOL レプリケーションの DFSR への移行 - Microsoft Learn
Tags: Active Directory, 認証基盤
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。