• TOP > インフラストラクチャ > ドメイン サービス (AD DS)
  • Active Directory（計画）
  • Active Directory（操作マスタ・FSMO）
  • Active Directory（機能レベル）

• DNSサーバは、UNIX や Linux でおなじみの BIND などが使えるが、
  簡単に運用したいのであればドメイン コントローラに
  Windows 付属の DNSサーバを利用するとよい。

  • DNS は標準規格であり、当然のことであるが、
    マイクロソフト社の DNS は BIND など他社の DNS と連携して動作する。

    • 上位ドメインに BIND があっても下位ドメインに BIND があっても構わない。
    • また、プライマリ サーバーが BIND でセカンダリ サーバーがマイクロソフト DNS でも、
      あるいはその逆でも完全に正常に利用できる。
    • しかし、マイクロソフト DNS は、比較的新しい規格を採用しているので、
      古い BIND をセカンダリまたはプライマリにできない場合がある。BIND 8.2.1 以降なら安心だ。

  • クライアントを変更する必要はない。
    Windows 9x、Windows NT クライアントは、Active Directory ドメインを、
    従来の NT ドメインと認識する。

補足: BIND を使う場合の必須要件は SRV レコード（RFC 2782）と動的更新（RFC 2136）のサポートである。 動的更新に対応しない DNS では、DC が自身の SRV / A レコードを 手動で登録する必要がある（netlogon.dns を利用する）。 なお、Active Directory 統合ゾーンは Windows の DNS サーバでしか利用できない。

• フォレスト、ドメインなどの名称と構造は後の変更が容易では無い。
• ドメイン構造の変更は極めて困難なので、なるべくなら単一ドメインで使いたい。

• ドメイン構造の変更は極めて困難なので、なるべくなら単一ドメインで使いたい。
• ドメイン サービス (AD DS)に登録された情報は、
  同一ドメイン内であれば簡単に移動できる。
  従って部門ごとに管理権限を委任したい場合などは、ドメインとして分割するのではなく、
  可能な限り単一ドメイン内の OU として構成するべきだ。

• 例

  • 日本とフランスにオフィスがあり、
    • それぞれ管理者がいる。
    • 社員の出張は年に 1・2 度。
    • ネットワーク リソース共有の必要性は少ない。

  このような場合、両方のオフィスのオブジェクトの集中管理は困難なのでドメインを分割する。

補足（最新化）: 「ドメイン＝セキュリティ境界」という理解は誤りで、 セキュリティ境界はフォレストである （ドメイン管理者はフォレスト内の他ドメインを侵害しうる）。 ドメインは「レプリケーションとポリシーの境界」と捉えるべきで、 現在は WAN が高速化したこともあり、 単一フォレスト・単一ドメインが推奨構成である。

• Active Directory の操作範囲はフォレスト内に限られるため、
  可能な限り単一フォレストで運用すべきである。
• 例えばフォレストを分けて Active Directory を構成すると、
  グローバル カタログも分かれてしまい、
  組織全体の検索ができなくなってしまう。
• 後からフォレストを結合することもできないため、
  Active Directory フォレストの設計は非常に重要な作業となる。

• 1 つのドメインには、1 台以上のドメイン コントローラが必要になる。

• 可用性向上のための冗長化のために、
  通常 2 台以上のドメイン コントローラを配置する。

• 2 台のドメイン コントローラはマルチマスタ・レプリケーションで同期をとる。

• ストレージ関連

  • 以下のフォルダが存在する。
    • NTDS
    • SYSVOL
    • ログ ファイル
  • 各フォルダの容量見積もりは行うこと。
  • セキュリティを考慮し、
    • SYSVOL については、NTFS でフォーマットする。
    • 通常は、全てのパーティションを NTFS でフォーマットする。

• ネットワーク関連

  • DHCP クライアントを使用している状態でもサーバを
    ドメイン コントローラに昇格させることはできる。
  • ただし、DHCP サーバの障害時にクライアントがドメイン コントローラを
    特定できなくなる可能性があるので通常は、静的 IP アドレスを設定する。

補足（正誤）: SYSVOL は「NTFS でフォーマットするのが望ましい」のではなく、 NTFS 上にしか作成できない（ジャンクションと ACL に依存するため）。 なお、DC の静的 IP は「DHCP サーバ障害時」だけの理由ではなく、 DNS の A / SRV レコードが安定して解決できることが本質的な理由である。

• WAN 回線で結ばれた複数の拠点に分かれているようなネットワークの場合には、
  それぞれの拠点ごとに別々のサイトになるように定義するとよい。

  • 複数の拠点を 1 つのサイトにしてしまうと、
    認証などに必要な拠点間でのネットワーク トラフィックが非常に多くなってしまうが、
  • 複数のサイトに分けておくと、
    サイト間のトラフィックは自動的に最適化され、トラフィックを抑えることができる。

• サイトを構成していない場合には、

  • クライアントからのログオン認証が（ネットワーク的に）近くにある
    ドメイン コントローラで行われるという保証がないし、
  • ドメイン コントローラ間の複製データも圧縮されないため、
    WAN トラフィックを抑制することができない。
  • そのため、ほかの通信で WAN 回線を利用するサービスの応答が遅くなるなどの影響がある。

• サイトの構成

  • 各「サイト」は、高速で安定した通信が可能な、
    1 つの物理的／論理的なネットワークの範囲として構成する。
    一般的には LAN 環境（高速な LAN 回線で相互に接続されている
    ひとまとまりのネットワーク環境）を 1 サイトとすることが多い。
  • サイトには、1 つ以上の IP サブネットを割り当てる。
    • つまり、同一サブネット内であれば、高速で安定した通信が可能だという前提で考えられている
      （VPN 技術などを使えば拠点をまたぐような同一サブネットを構築することも可能だが、
      そのようなことはせずに、拠点ごとに異なるサブネットにする方がよい）。
    • LAN の内部で複数のサブネットを利用している場合は、
      1 つのサイトに複数の IP サブネットを割り当てることもできる
      （複数のサブネットをすべてまとめて 1 つのサイトにすることもできる）。

詳細は Active Directory（レプリケーション）を参照。

Active Directory（グローバル カタログ）

• 管理を簡素化するためには、特に理由なく OU を階層化すべきではない。

• なにも、会社の組織図どおりに設定する必要はないのだ。

• 例えば、

  • 営業部の全員が同じ地域におり、
  • 同じアプリケーションを使い、
  • 同じポリシーを適用するのであれば、

• 営業部 OU の中に

  • 第一営業部 OU、
  • 第二営業部 OU

  といった階層を設けるのは、無意味なことが多い。

補足: OU の設計は「組織図」ではなく ①権限委任の単位、②グループ ポリシーの適用単位で決める、 というのが原則である。組織改編のたびに OU を作り直すのは避けたい。

• ユニバーサル グループ

  • 混在モードの場合
    後述の「配布グループ」としてメールのあて先に使用する。
  • ネイティブ モードの場合
    別ドメインのユーザやグループが登録できる、
    最も汎用性が高いグループとして使用できる。

• グローバル グループ（人事用グループ）

  • 混在モードの場合
    NT ドメインのグローバル グループと同様の機能となる。
  • ネイティブ モードの場合
    同じドメインのグローバル グループをネストできる。
    使い方は従来と同じく、ユーザを組織化する目的で使用する。

• ドメイン ローカル グループ（リソース用グループ）

  • ドメイン全体で使えるローカル グループ。
  • リソースを公開したいコンピュータ上で使用。
  • リソースに対してドメイン ローカル グループを割り当てる（リソース用グループ）。
  • ドメイン ローカル グループにグローバル グループ（人事用グループ）を追加する。
  • これにより、リソースと人事上の変更を別々に管理できる。

• ネイティブ モード環境

グループ範囲名	使用目的	含むことのできるメンバー	有効範囲
ドメイン ローカル グループ	セキュリティ設定	フォレスト内の全ドメインのユーザー フォレスト内の全ドメインのグローバル グループ フォレスト内の全ドメインのユニバーサル グループ 同じドメイン内のドメイン ローカル グループ	ドメイン内のコンピュータ
グローバル グループ	ドメイン内の組織化	同じドメイン内のユーザー 同じドメイン内のグローバル グループ	フォレスト内のコンピュータ
ユニバーサル グループ	ドメインをまたがる組織化	フォレスト内の全ドメインのユーザー フォレスト内の全ドメインのグローバル グループ フォレスト内の全ドメインのユニバーサル グループ	フォレスト内のコンピュータ

• 混在モード環境

グループ範囲名	使用目的	含むことのできるメンバー	有効範囲
ドメイン ローカル グループ	セキュリティ設定	フォレスト内の全ドメインのユーザー フォレスト内の全ドメインのグローバル グループ	ドメイン コントローラ上のみ
グローバル グループ	ドメイン内の組織化	同じドメイン内のユーザー	フォレスト内のコンピュータ
ユニバーサル グループ	―（セキュリティ グループとしては使用不可）	―	―

• サマリ
  • グループ アカウントには、それぞれスコープがあり、
    利用範囲（そのグループ アカウントを参照／検索できる範囲）が決められている。
  • 下位のグループは、上位のグループを含むことができるが、逆はできない。
    （下位のグループは、上位のグループを知らないから追加できない的な。）

補足（最新化）: 「混在モード／ネイティブ モード」は Windows 2000 の用語であり、 現在は「機能レベル」に置き換わっている。 Windows Server 2003 以降の機能レベルでは、 ユニバーサル セキュリティ グループが常に利用可能である。

• ユニバーサル グループ

  • 使用制限がないため、簡便な方法。
    • ユーザーを直接割り当て可能
    • グループのネストが可能
    • 全ドメインのリソース オブジェクトの ACL・ACE に配置可能
      GC（グローバル カタログ）に保管され、
      レプリケーションされるため。
      注：性能に影響する。

• グローバル グループ

  • グローバル グループを他のグローバル グループにネスト可能
  • 同一ドメイン内にあるリソース オブジェクトの ACL・ACE にのみ配置可能
    GC（グローバル カタログ）に保管されるが、メンバの情報はレプリケーションされないため。

• ドメイン ローカル グループ

  • GC クエリに対して効力がないため、
    Active Directory オブジェクトへのアクセス許可の割り当てには使用しない。
  • Active Directory オブジェクトでない
    特定のリソース（ファイル サーバーの共有やプリンタ キューなど）の
    ACL・ACE にのみ配置可能。

補足: 「ユニバーサル グループは性能に影響する」というのは、 メンバシップが GC に複製されるためである。 ただし Windows Server 2003 以降は LVR（Linked Value Replication）により 値単位の複製となったため、影響は大幅に軽減されている。

• ユニバーサル グループ
  高機能であるが、レプリケーションの性能に影響。

• グローバル グループ（人事用グループ）

  • 複数のグループを 1 つにまとめて分かりやすい別名を付ける。
  • OU（組織単位）をネストし、OU ツリー上の階層レベルに合わせて
    権限を減らしながら OU 管理機能を委譲する。

• ドメイン ローカル グループ（リソース用グループ）

  • 実際に、ACL・ACE に配置する。

A-G-L-P（I-G-L-A）や A-G-DL-P（I-G-DL-A）などのポリシーがある。

• ポリシーを構成する要素

記号	意味
A	アカウント（I：アイデンティティ）
G	グローバル グループ
U	ユニバーサル グループ
DL	ドメイン ローカル グループ
L	ローカル グループ
P	パーミッション（A：アクセス（ACL・ACE））

• ポリシーのコンセプト

  • A-U-P（小規模向け）

    • ユニバーサル グループを利用する。
    • ユーザーではなくユニバーサル グループにアクセス権を付与する。
    • 別の人が権限を引き継ぐ際や別の人にも同じ権限を付与する場合に
      直接アクセス権をいじらずともメンバの変更だけで済む。

  • A-G-L-P（基本的なポリシー、Active Directory 管理者とサーバー管理者が分離している場合）

    • ローカル グループを積極的に使うのが特徴。
    • アカウントをまとめるグループと権限を付与するグループ（役割）を分離する。
      • ローカル グループ：権利の割当（つまり資源管理）
      • グローバル グループ：ユーザーの分類
    • ローカル グループはサーバー管理者権限があれば、
      Active Directory の権限がなくても作成、メンバ変更ができるのがよい。
    • 欠点：ローカル グループはサーバー単位にしか存在しないので
      複数サーバーで同じ事をやろうとするとサーバー毎に設定が必要。
    • 欠点：ドメインをまたがる権限設定ができない。

  • A-G-DL-P（Active Directory 管理者とサーバー管理者が同じ場合）

    • コンセプトは AGLP と一緒、複数のサーバがある環境に適している。
    • ドメイン ローカル グループは、同一ドメイン内の全サーバから参照できるため、
      複数のサーバから利用でき、A-G-L-P の欠点であるサーバー毎の作業が無くなる。
    • ドメイン ローカル グループの作成にはドメイン管理者の権限が必要だが、
      Active Directory はオブジェクト作成の権限を
      ほかのユーザーやグループに委任できる。
    • 適当な組織単位（OU）を作成し、プロジェクト管理者に対して、
      その OU にグループの作成を許可する権限を与える。
    • 欠点：ドメイン ローカル グループは ドメイン サービス (AD DS)上の
      オブジェクトであり、Active Directory の管理者権限が必要となる。
      OU への権限委任等で回避するケースあり。
    • 欠点：ドメインをまたがる権限設定ができない。

  • A-G-U-DL-P（マルチドメインの大規模環境向け）

    • コンセプトは A-G-L-P, A-G-DL-P と一緒。
    • ユニバーサル グループでグローバル グループを
      まとめる事によってドメインをまたがる権限設定を行えるようになる。

• ベスト プラクティスは、A-G-(U)-DL-P。

  • A-G-DL-P という管理手法は、TCO 削減やわかりやすさ、効率性を向上
    するための一つの方法としてマイクロソフトが推奨している方法。
  • この戦略のポイントは、次の通り。
    1. G はあくまでもユーザーを束ねるだけに使用する。
    2. リソースの権限を付与するのは DL。
    3. DL に対して G を入れ込む。

Active Directory（操作マスタ・FSMO）

各フォレスト毎に 1 台必要。

• スキーマ マスタ
  • インストール後のスキーマ マスタの変更は容易では無い。
• ドメイン名前付けマスタ

各ドメイン毎に 1 台必要。

• PDC エミュレータ
• RID（Relative ID）プール マスタ
• インフラ ストラクチャ マスタ
  • マルチドメイン環境では、
    グローバル カタログとは同居できないので注意。
  • インフラ ストラクチャ マスタは、他ドメインのオブジェクトへの参照が最新であるかどうかを
    グローバル カタログ サーバのオブジェクトと
    比較して確認するため（自身が GC だと差分が生じず、更新処理が働かない）。

• 大幅なネットワーク インフラストラクチャの変更を除き
  操作マスタ（FSMO）を他の DC に割り当てる（転送する）必要は無い。

• 以下のケースで操作マスタ（FSMO）を他の DC に割り当てる（転送する）。

  • メンテナンスのため長期間オフラインにする。
  • メンバ サーバに降格する。

• また、以下のケースで操作マスタ（FSMO）を他の DC に割り当てる（強制する）。

  • ハードウェア障害等で操作マスタ（FSMO）が存在しなくなった場合。
  • 強制した場合、復旧した操作マスタ（FSMO）は
    そのままオンラインにはできないので、降格後 → 再昇格する。
  • 参考：Active Directory（バックアップ）

古いドメイン コントローラが混在する環境等で使用する。
新しい機能は古い DC では使用できないので機能レベルで制限しておく。

機能レベルには、以下の 2 種類がある。

• ドメインの機能レベル：ドメインの機能にだけ影響する。

  • Windows 2000 ネイティブ
    • 既定のドメインの機能レベル
    • Windows 2000 Server、Windows Server 2003、Windows Server 2008 の DC をサポート
    • ユニバーサル セキュリティ グループ、SID ヒストリの機能を使用できる。
  • Windows Server 2003
    • Windows Server 2003、Windows Server 2008 の DC をサポート
    • Windows Server 2003 Active Directory のすべての機能を使用できる。
    • 例：DC 名の変更、アカウントの既定の作成場所の変更
  • Windows Server 2008
    • Windows Server 2008 の DC をサポート
    • Windows Server 2008 Active Directory のすべての機能を使用できる。
    • 例：DFS を使用して SYSVOL をレプリケート、特定ユーザに異なるパスワード ポリシを適用

• フォレストの機能レベル：フォレストの機能にだけ影響する。

  • Windows 2000 ネイティブ
    • 既定のフォレストの機能レベル、どのドメインの機能レベルでも使用可能。
  • Windows Server 2003
    • 全てのドメインの機能レベルを Windows Server 2003 にする。
    • Windows Server 2003 Active Directory のすべての機能を使用できる。
    • 例：DC 名の変更、フォレスト間の信頼
  • Windows Server 2008
    • 全てのドメインの機能レベルを Windows Server 2008 にする。

• 機能レベルは一度上げると下げられない。

補足（最新化）: 上記は Windows Server 2008 時点の記述である。 現行では Windows Server 2016 レベルが最上位で、 Windows Server 2019 以降は新しい機能レベルが追加されていない。 また、Windows Server 2008 R2 以降のレベルであれば、 条件付きで機能レベルを下げられるようになっている。 詳細はActive Directory（機能レベル）を参照。

DCの冗長化

• ボトムアップ的に Active Directory ドメインを構築することはできないのか？

• 建前としてはできない。

  • しかし、以下のように設定すれば草の根的に
    Active Directory ドメインを構築できる。
  • 「草の根的な Active Directory」とは、
    ネットワーク管理者の正式な許可を得ずに、
    ある部署内だけで独自に立ち上げている Active Directory ドメインのこと。

1. DNSサーバを独自にインストールする（草の根 DNS サーバ）。
2. 草の根 DNS サーバに適当なドメインを作る（草の根ドメイン）。
3. DNSサーバのプロパティにあるフォワーダ フィールドに、
   社内ドメインの DNSサーバを指定する。
4. 草の根ドメインに Active Directory をインストールする。
5. 草の根ドメインのクライアントは、草の根 DNS サーバへ照会する。

注意: これはあくまで「技術的には可能」という話である。 無許可の DC・DNS サーバは、名前解決の競合や 資格情報の管理外化といったセキュリティ リスクを生むため、 実運用では必ずネットワーク管理者の承認を得ること。

• ネットワーク インフラ

  • TCP/IP を標準とし、社内用の DNSサーバを設定する必要がある。
  • 社内用 DNSサーバは
    Active Directory ドメイン コントローラと兼任させるのが最も簡単。

• サーバ PC
  拠点ごとに 1 台、全社で（1 ドメインあたり）2 台以上のサーバが必要である。

  • Active Directory のドメイン コントローラ 1 台
  • 可用性向上のための 1 台以上の追加ドメイン コントローラ

• ソフトウェア ライセンス

  • Windows Server ライセンスがサーバ数だけ必要
  • ログオン ユーザー数だけのクライアント ライセンス（CAL）が必要

• 移行コスト

  • 移行する場合、移行コストを計上する必要がある。
  • 移行コストは、移行パターンによって大きく異なる。

• アプリケーション コスト
  使用中のアプリケーションが新しいプラットフォームに対応していない場合、
  対応するプラットフォームへ環境移行する必要がある。また、動作テストも行う必要がある。

• 移行による導入：Active Directory（移行）
• AD DS の設計と計画 - Microsoft Learn
• セキュリティ グループのスコープ - Microsoft Learn

---

Tags: Active Directory, 認証基盤