Active Directory（計画） のバックアップ(No.8)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Active Directory（計画） へ行く。
  • 1 (2014-10-06 (月) 07:40:40)
  • 2 (2014-10-06 (月) 07:43:38)
  • 3 (2014-10-09 (木) 01:00:02)
  • 4 (2015-08-08 (土) 12:10:02)
  • 5 (2015-12-01 (火) 15:57:03)
  • 6 (2016-01-26 (火) 13:02:40)
  • 7 (2016-07-08 (金) 14:00:57)
  • 8 (2016-07-11 (月) 11:18:53)
  • 9 (2017-01-04 (水) 15:57:09)
  • 10 (2017-01-07 (土) 19:35:43)
  • 11 (2017-02-27 (月) 18:29:35)
  • 12 (2017-04-28 (金) 19:00:43)
  • 13 (2018-02-15 (木) 09:57:19)

---

Open棟梁Project - マイクロソフト系技術情報 Wiki

• 戻る

目次 †

設計のポイント †

DNSサーバ †

• 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ドメインと認識する。

DNS要件 †

パターン †

ドメイン論理構造 †

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

単一ドメイン †

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

複数ドメイン †

• 観点

• 例

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

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

単一フォレスト †

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

ドメイン・コントローラ †

• １つのドメインには、１台以上のドメイン・コントローラが必要になる。
• 可用性向上のための冗長化のために、通常２台以上のドメイン・コントローラを配置する。
• ２台のドメイン・コントローラはマルチマスタ・レプリケーションで同期をとる。

• ストレージ関連

• 以下のフォルダが存在する。
  • NTDS
  • SYSVOL
  • ログ・ファイル

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

• ネットワーク関連
  • DHCPクライアントを使用している状態でもサーバを
    ドメイン・コントローラに昇格させることはできる。

• ただし、DHCPサーバの障害時にクライアントがドメイン・コントローラを
  特定できなくなる可能性があるので通常は、静的IPアドレスを設定する。

FQDNの設計方法 †

ネットワーク物理構造 †

サイト、サイトリンク †

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

• 複数の拠点を1つのサイトにしてしまうと、
  認証などに必要な拠点間でのネットワーク・トラフィックが非常に多くなってしまうが、

• 複数のサイトに分けておくと、
  サイト間のトラフィックは自動的に最適化され、トラフィックを抑えることができる。

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

• クライアントからのログオン認証が（ネットワーク的に）近くにあるドメイン･コントローラで行われるという保証がないし、

• ドメイン･コントローラ間の複製データも圧縮されないため、WANトラフィックを抑制することができない。

• そのため、ほかの通信でWAN回線を利用するサービスの応答が遅くなるなどの影響がある。

• サイトの構成

• 各「サイト」は、高速で安定した通信が可能な、1つの物理的／論理的なネットワークの範囲として構成する。
  一般的にはLAN環境（高速なLAN回線で相互に接続されているひとまとまりのネットワーク環境）を1サイトとすることが多い。

• サイトには、1つ以上のIPサブネットを割り当てる。

• つまり、同一サブネット内であれば、高速で安定した通信が可能だという前提で考えられている
  （VPN技術などを使えば拠点をまたぐような同一サブネットを構築することも可能だが、
  そのようなことはせずに、拠点ごとに異なるサブネットにする方がよい）。

• LANの内部で複数のサブネットを利用している場合は、
  1つのサイトに複数のIPサブネットを割り当てることもできる
  （複数のサブネットをすべてまとめて1つのサイトにすることもできる）。

ディレクトリ・サービス構造 †

グローバル カタログ †

組織単位（OU） †

• 管理を簡素化するためには、特に理由なくOUを階層化すべきではない。
• なにも、会社の組織図どおりに設定する必要はないのだ。

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

• 営業部OUの中に
  • 第一営業部OU、
  • 第二営業部OU

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

セキュリティ・グループ †

• ユニバーサル・グループ

• 混在モードの場合
  後述の「配布グループ」としてメールのあて先に使用する。

• ネイティブ・モードの場合
  別ドメインのユーザやグループが登録できる、
  最も汎用性が高いグループとして使用できる

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

• 混在モードの場合
  NTドメインのグローバル・グループと同様の機能となる

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

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

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

有効範囲と機能的な違い †

• ネイティブ・モード環境

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

• 混在モード環境

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

• サマリ
  • グループ・アカウントには、それぞれスコープがあり、
    利用範囲（そのグループ・アカウントを参照／検索できる範囲）が決められている。

• 下位のグループは、上位のグループを含むことができるが、逆はできない。
  （下位のグループは、上位のグループを知らないから追加できない的な。）

特徴 †

• ユニバーサル・グループ
  • 使用制限がないため、簡便な方法。
    • ユーザーを直接割り当て可能
    • グループをネストが可能

• 全ドメインのリソース オブジェクトのACL?-ACEに配置可能
  GC (グローバル カタログ) に保管され、レプリケーションされるため。
  注：性能に影響する。

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

• ドメイン・ローカル・グループ
  • GC クエリに対して効力がないため、
    Active Directory オブジェクトへのアクセス許可の割り当てには使用しない。

• Active Directory オブジェクトでない
  特定のリソース (ファイル サーバーの共有やプリンタ キューなど) のACL?-ACEにのみ配置可能

用途 †

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

• グローバル・グループ（人事用グループ）
  • 複数のグループを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にローカルグループの作成を許可する権限を与える。

• 欠点：ドメインローカルグループはActive Directory上のオブジェクトであり、
  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を入れ込む。

参考 †

• グループ・アカウントの種類を知る － ＠IT
  http://www.atmarkit.co.jp/fwin2k/win2ktips/737groups/groups.html

• 管理者のためのActive Directory入門：第8回
  Active Directoryの導入後の作業 (3-3) - ＠IT
  http://www.atmarkit.co.jp/ait/articles/0303/28/news002_3.html

• ASCII.jp：Windows Serverで学ぶサーバOS入門
  Active Directoryのアカウントとグループとは？
  ユーザーアカウントやグループ、グループ戦略
  「AGLP、AGDLP、AUP、AGUDLP」を知ろう
  
  • http://ascii.jp/elem/000/000/504/504463/
  • http://ascii.jp/elem/000/000/504/504463/index-2.html
  • http://ascii.jp/elem/000/000/504/504463/index-3.html
  • http://ascii.jp/elem/000/000/504/504463/index-4.html

• ドメインローカルグループとグローバルグループの使い分けについて
  http://social.technet.microsoft.com/Forums/windowsserver/ja-JP/06bf4720-4e70-4121-b196-83e74d4824d1

• Windows Serverで学ぶサーバOS入門 ― 第8回
  小規模向けのAUPと大規模環境向けのAGUDLPについても学ぼう
  「機能レベル」でActive Directoryの互換性を確保しよう
  http://ascii.jp/elem/000/000/505/505060/

• AUUPで良いのでは？ - ActiveDirectory?のグループ設計はどうあるべきか。
  (AGDLP, AGUDLP, AUP, AU(U)P) WindowsServer?管理者への道
  http://ebi.dyndns.biz/windowsadmin/2013/02/02/auup%e3%81%a7%e8%89%af%e3%81%84%e3%81%ae%e3%81%a7%e3%81%af%ef%bc%9f-activedirectory%e3%81%ae%e3%82%b0%e3%83%ab%e3%83%bc%e3%83%97%e8%a8%ad%e8%a8%88%e3%81%af%e3%81%a9%e3%81%86%e3%81%82%e3%82%8b/

操作マスタ（FSMO） †

フォレスト単位 †

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

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

ドメイン単位 †

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

• PDCエミュレータ
• RID（Relative ID）プール マスタ
• インフラ ストラクチャ マスタ
  • マルチドメイン環境では、グローバル・カタログとは同居できないので注意。
  • インフラ ストラクチャ マスタのオブジェクトの情報が最新であるかどうかを
    グローバル・カタログ・サーバのオブジェクトと比較して確認するため。

転送と強制 †

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

• 以下のケースで操作マスタ（FSMO）を他のDCに割り当てる（転送する）
  • メンテナンスのため長期間オフラインにする。
  • メンバサーバに降格する。

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

機能レベル †

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

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

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

• Windows 2000ネイティブ
  • 既定のドメインの機能レベル
  • Windows 2000 Server、Windows Server 2003、Windows Server 2008のDCをサポート
  • ユニバーサルセキュリティグループ、SIDヒストリの機能を使用できる。

• Windows 2003
  • Windows Server 2003、Windows Server 2008のDCをサポート
  • Windows Server 2003 Active Directoryのすべての機能を使用できる。
  • 例：DC名の変更、アカウントの既定の作成場所の変更

• Windows 2008
  • Windows Server 2008のDCをサポート
  • Windows Server 2008 Active Directoryのすべての機能を使用できる。
  • 例：DFSを使用してSYSVOLをレプリケート、特定ユーザに異なるパスワード・ポリシを適用

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

• Windows 2000ネイティブ
  • 既定のフォレストの機能レベル、どのドメインの機能レベルでも使用可能。

• Windows 2003
  • 全てのドメインの機能レベルをWindows 2003にする。
  • Windows Server 2003 Active Directoryのすべての機能を使用できる。
  • 例：DC名の変更、フォレスト間の信頼

• Windows 2008
  • 全てのドメインの機能レベルをWindows 2008にする。
  • Windows Server 2008 Active Directoryのすべての機能を使用できる。
  • 例：・・・

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

DCの冗長化 †

インストール要件 †

・・・

その他 †

草の根Active Directoryドメイン †

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

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

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

Active Directoryの導入計画 †

Active Directoryの導入に必要なコストは？ †

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

• サーバPC
  拠点ごとに1台、全社で（1ドメインあたり）2台以上のサーバが必要である
  • Active Directoryのドメイン・コントローラ1台
  • 可用性向上のための1台以上の追加ドメイン・コントローラ）。

• ソフトウェア・ライセンス
  • Windows Serverライセンスがサーバ数だけ必要
  • ログオン・ユーザー数だけのクライアント・ライセンスが必要

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

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

移行による導入 †

Active Directory（移行）

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.062 sec.