Skip to content

Instantly share code, notes, and snippets.

@beginerbeginer
Last active January 4, 2025 10:16
Show Gist options
  • Save beginerbeginer/da6c1a8641d7fb4b939ed1aff50e3a19 to your computer and use it in GitHub Desktop.
Save beginerbeginer/da6c1a8641d7fb4b939ed1aff50e3a19 to your computer and use it in GitHub Desktop.

中学生にもわかりやすいように、学校生活を例にして「WindowsのActive Directory(AD)」という仕組みをステップバイステップで説明します。イメージとしては「学校全体を管理するための生徒名簿&ルール管理システム」と考えてください。

  1. Active Directoryって何?

学校の例え: • Active Directory(AD) は「学校の仕組み全体を管理するためのシステム」です。 • たとえば学校だと、先生や生徒の情報をまとめて管理したり、「どの教室に入れるか」「どのロッカーを使えるか」などのルールを決めておく必要がありますよね。 • ADは、コンピュータの世界で「ユーザー(先生や生徒のような立場)」「コンピュータ(教室・部室・ロッカーなどのリソース)」「その人が何をできるか」をまとめて管理してくれる仕組みです。

  1. “ドメインコントローラー” は学校の“職員室” or “校長室”

学校の例え: • 学校には「職員室(あるいは校長室)」があって、そこで全校生徒の名簿やクラス分けの情報を管理していますよね。 • ドメインコントローラー(DC) は、ADの中でこの「職員室/校長室」の役割をするコンピュータです。 • 生徒・先生(ユーザー)の情報やパスワードなど、みんなの情報がここに集まります。 • 「この生徒は本当に学校の生徒か?」を確認する(認証)こともします。 • 1台でも学校運営はできますが、安心のために予備の職員室(セカンダリDC)を用意する場合もあります。

  1. “ドメイン” は学校そのもの

学校の例え: • 学校全体をまとめて「〇〇中学校」と呼ぶのと同じように、ADではネットワーク全体をまとめて**“ドメイン”**と呼びます。 • みんなが所属するドメイン(学校)に入ることで、学校の施設(パソコン室や図書室など)を使えるようになるイメージです。

  1. ADを使う前の準備

    1. サーバー(職員室となる部屋/PC)の準備 • Windows Serverという“特別なコンピュータ”を用意し、そこにADの機能を入れます。
    2. ドメイン名を決める • 学校名のように、ネットワークの名前を「example.local」などと決めてあげます。
    3. ネットワークの設定 • 職員室がネットワークの中心になるので、そこに正しい住所(IPアドレス)を割り当てるイメージです。
  2. インストールから実際に“ドメインコントローラー”にする手順

    1. 役割と機能の追加 • Windows Serverで「Active Directoryドメインサービス」をインストールします。
    2. AD DS(Active Directory Domain Services)の設定 • 「このサーバーをドメインコントローラーに昇格します」というボタンを押して、学校のメイン職員室にする作業を行います。
    3. 新しいフォレスト(学校グループ)の作成 • 初めての導入なら「新しい学校(ドメイン)を作る」イメージで設定していきます。
    4. DNSサーバーの設定 • 学校の職員室に「どの場所がどこにあるかを教える案内所(DNS)」の役割をもたせることが多いです。
    5. 再起動して完了 • 再起動すると、ADのドメインコントローラーとして使えるようになります。
  3. ユーザー(生徒・先生)の登録と管理

    1. ユーザー作成 • 職員室で「新入生」を受け入れるように、ADでも「新しいユーザー」を作ります。 • 例)「山田太郎」という生徒ユーザー、「山田先生」という先生ユーザーなど。
    2. パスワードや権限設定 • 先生は職員室に入れるけど生徒は入れない、などのルールをパスワードやグループで決めます。
    3. グループ分け • 学校でクラスを編成するように、ADでもユーザーをグループ(クラスや部活動など)に分けます。 • 例えば「サッカー部グループ」「吹奏楽部グループ」と作って、部室や活動場所(ファイルサーバー)への権限を管理できます。
  4. コンピュータ(教室のパソコン)をドメインに参加させる

学校の例え: • 学校に新しい教室ができたら、職員室に「〇〇教室をつくりました」と届け出る必要がありますよね。 • Windowsでいう「ドメイン参加」は、教室(パソコン)が“この学校(ドメイン)”の一部になりますと登録する作業です。 1. パソコンの名前を決めて(例:CLASS1-PC01など)、ドメインに参加すると「学校の生徒や先生がログインできるようになる」イメージです。

  1. 組織単位(OU)とグループポリシー(GPO)でルール管理

OU(Organizational Unit) • 組織単位(OU) は、ADの中でクラス・学年・部署ごとにまとめる“フォルダ”みたいなもの。 • 「1年生」「2年生」「3年生」や「先生」「事務職員」などに分けると、あとでルールを適用しやすくなります。

グループポリシー(GPO) • グループポリシーは「学校の校則やクラスのルールを一括で設定する仕組み」です。 • 例1:生徒はパソコンに勝手にソフトを入れちゃダメ(インストール禁止) • 例2:先生は成績データにアクセスできるけど、生徒はできない • ADでは、このようなルールをまとめて設定して「特定のOU」にだけ適用できるので、とても便利です。

  1. 毎日の運用:学校の“あたりまえの活動”

    1. ユーザーの追加・削除(入学・卒業・転校) • 新入生が来たら「ユーザー作成」、卒業や退職があったら「ユーザー削除or無効化」。
    2. グループや権限の見直し • 部活動が変わったら「グループの所属」を変更する。
    3. ルール(グループポリシー)の更新 • 校則変更があれば、ADでポリシーを変更して全員のパソコン設定を更新できる。
    4. ログのチェック・セキュリティ強化 • 職員室の監視カメラや出入りチェックのように、ADでもイベントログを見て怪しい動きがないか確認します。
  2. まとめ & 次のステップ

Active Directoryは、 • “誰が、どこに、どうやって入れるのか” を一元的に管理するためのシステム • 学校の例でいえば、「職員室(ドメインコントローラー)を中心に全校生徒や教室、ルールを管理」 するイメージ

次にやってみたいこと 1. 仮想マシンで小さな学校(ドメイン)を作ってみる • VirtualBoxやHyper-Vなどを使って、ADを一度インストールしてみましょう。 2. OU・グループポリシーの実験 • クラスや部活を仮想で作って、どんな設定が一括で変えられるか試してみる。 3. トラブルシューティング • 生徒がログインできないときはどう対処する? ポリシーが反映されないときは? など、よくある問題を練習すると現場で役立ちます。

これだけを聞くと少し難しく感じるかもしれませんが、実際に自分で触ってみると「なるほど、学校みたいに管理してるんだな」と分かりやすくなるはずです。

最初は小さく始めて、「ユーザーを作ってログイン」→「グループポリシーでルールを設定」 を体験してみるのがおすすめです。学校をイメージしながら進めると、Active Directoryの基本的な考え方がぐっとわかりやすくなると思います。

以下は、学校のイメージを参考にした Active Directory の関係性を示す Mermaid の例です。

  • ドメインコントローラー(職員室/校長室)
  • ADドメイン(学校)
  • OU(学年や部署のフォルダ)
  • ユーザー(先生・生徒)
  • コンピューター(教室PC)
  • グループ(クラス/部活)
  • GPO(校則)

などがどのようにつながっているかを図にしています。

flowchart TB
    DC1["ドメインコントローラー(DC01)\n職員室/校長室"] -->|管理する| AD_Domain["ADドメイン\n(例: example.local)\n学校全体"]
    
    %% OU(組織単位)
    AD_Domain --> OU_Students["OU_Students\n(1年生/2年生など)"]
    AD_Domain --> OU_Teachers["OU_Teachers\n(先生)"]
    AD_Domain --> OU_Computers["OU_Computers\n(教室PC)"]

    %% ユーザー(生徒・先生)
    OU_Students --> StudentA("山田太郎")
    OU_Students --> StudentB("佐藤花子")
    OU_Teachers --> TeacherA("山田先生")

    %% コンピューター(教室PC)
    OU_Computers --> PC1("教室PC1")
    OU_Computers --> PC2("教室PC2")

    %% グループ(クラス/部活動)
    AD_Domain --> Group["グループ\n(クラス/部活)"]
    Group --> StudentA
    Group --> StudentB
    Group --> TeacherA

    %% GPO(グループポリシー/校則)
    AD_Domain --> GPO["グループポリシー(GPO)\n校則/ルール"]

    %% 装飾(オプション)
    classDef dc fill:#2F4F4F,stroke:#eee,stroke-width:1px,color:#fff
    classDef domain fill:#4169E1,stroke:#eee,stroke-width:1px,color:#fff
    classDef ou fill:#1E90FF,stroke:#fff,stroke-width:1px,color:#fff
    classDef user fill:#32CD32,stroke:#eee,stroke-width:1px,color:#fff
    classDef pc fill:#FFA07A,stroke:#eee,stroke-width:1px,color:#fff
    classDef group fill:#DA70D6,stroke:#eee,stroke-width:1px,color:#fff
    classDef gpo fill:#FFD700,stroke:#666,stroke-width:1px,color:#000

    class DC1 dc
    class AD_Domain domain
    class OU_Students,OU_Teachers,OU_Computers ou
    class StudentA,StudentB,TeacherA user
    class PC1,PC2 pc
    class Group group
    class GPO gpo
Loading

• ドメインコントローラー(DC): 学校でいう「職員室/校長室」。全体管理やユーザーの認証を担当 • ADドメイン: 学校全体に相当。ネットワーク内の“所属先” • OU(組織単位): 「1年生」「2年生」「先生」など、グループ化するフォルダ • ユーザー: 生徒や先生 • コンピューター: 教室PCなど • グループ: クラスや部活など、役割や共通点でまとめる集団 • GPO(グループポリシー): 学校の校則やクラスのルールを一括で管理する仕組み

この図を見れば、「職員室(DC)を中心に、学校全体(ドメイン)に属する生徒・先生(ユーザー)や教室PC(コンピューター)をフォルダ分け(OU)し、必要に応じてグループやルール(GPO)を設定する」というイメージが把握しやすくなります。

以下では、Active Directory (AD) を導入・運用する際の「ユースケース」「ビジネス要件」「他にも満たせる要件」「効率的な運用保守のための設計方法」を、大きく4つのセクションに分けてステップバイステップで解説します。

1. Active Directoryのユースケース

ステップ1-1: ユーザー認証・シングルサインオン

  • どのように役立つか
    • Windowsドメイン環境にログインすると、同じアカウントでファイルサーバーやプリンタ、社内ウェブシステムなどにもアクセス可能
    • ユーザーがサービスごとにパスワードを入力する手間を軽減

ステップ1-2: ユーザーとコンピュータの一元管理

  • どのように役立つか
    • 社員のアカウント・パソコン(クライアント端末)・サーバーをドメインに参加させることで、アカウントの作成や削除、パスワード変更などを一括管理
    • ユーザーや端末が増えても管理しやすい

ステップ1-3: グループポリシーによるポリシー適用

  • どのように役立つか
    • OSやソフトウェアの設定、セキュリティポリシー、デスクトップ環境を集中管理
    • 全社的なセキュリティ基準(USB制御など)を短時間で一括適用

ステップ1-4: 監査ログ・セキュリティ強化

  • どのように役立つか
    • AD上のユーザー認証やパスワード変更、失敗ログインなどの記録を監視可能
    • セキュリティ侵害の疑いがある場合にトレースしやすい

ステップ1-5: フォレスト/ドメイン統合

  • どのように役立つか
    • 複数拠点や子会社などをフォレストやツリードメインとして統合し、グループ会社全体のポリシーや認証を統一
    • 信頼関係(Trust)で必要なリソースのみを共有

2. Active Directoryが満たせるビジネス要件

ステップ2-1: セキュリティ要件

  • : 「社員のアカウントを安全に管理したい」「退職者や異動者のアクセス権を即時無効化したい」
  • ADで実現
    • 一括アカウント管理・グループ管理・パスワードポリシー適用
    • 組織改編や人事異動にあわせたアクセス権変更がスムーズ

ステップ2-2: 生産性向上(運用効率・業務効率)

  • : 「ユーザーがIDを複数持つのは非効率」「社内リソースへのログインを一回で済ませたい」
  • ADで実現
    • シングルサインオンに近い形でWindowsログイン後に各種リソースにアクセス
    • グループポリシーでソフトウェア設定やパッチ適用も集中管理

ステップ2-3: コンプライアンス対応

  • : 「情報漏えい対策」「監査対応」
  • ADで実現
    • 監査ログ(イベントログ)によるアクセス履歴の追跡
    • セキュリティ基準(パスワードの強度、ロックアウトポリシーなど)を全社員に徹底

ステップ2-4: スケーラビリティ(拡張性)

  • : 「事業拡大でユーザーが増える」「子会社を傘下に収める」
  • ADで実現
    • 1つのフォレスト内で新規ドメインを追加して拡張
    • フォレスト間の信頼関係設定でグループ全体の資源共有を管理

3. 他にも満たせる要件

ステップ3-1: “ハイブリッド” 要件 (Azure AD との連携)

  • どのように役立つか
    • オンプレミスのADとAzure ADを同期し、クラウドサービス(Office 365やSharePoint Onlineなど)にも同じアカウントでログイン
    • 社内システムとクラウドサービスの境界を意識せずに一元管理

ステップ3-2: リモートワーク対応

  • どのように役立つか
    • VPNやDirectAccessなどと組み合わせ、ドメインアカウントを使って社外からも認証
    • グループポリシーでテレワーク端末のセキュリティ設定を統一

ステップ3-3: デバイス管理 (MDM/Intuneなどとの連携)

  • どのように役立つか
    • Windowsサーバー + Intune といった構成でモバイルデバイスやPCを一元的にポリシー管理
    • 社内外問わずデバイスの利用状況やセキュリティを確保

ステップ3-4: カスタムアプリケーション認証基盤

  • どのように役立つか
    • 自社開発のアプリをADで認証する仕組みを導入し、ユーザー管理をADに集約
    • 認証処理をアプリ側で個別に実装する手間を削減

4. 効率的な運用保守をするための設計方法

ステップ4-1: ドメイン構成・命名規則の策定

  1. ドメイン名の決定
    • 社内向けなら「company.local」や「company.internal」など
    • 社外公開ドメインを使う場合は、運用ポリシーとコンフリクトしないように注意
  2. ドメイン階層・フォレスト設計
    • 将来拡張や子会社統合を見据え、1フォレスト or 複数フォレストかを検討
    • 信頼関係(Trust)の設計が複雑にならないように最初に計画する

ステップ4-2: OU(組織単位)設計

  1. 部門/拠点/デバイス種類で分類
    • 例:部門別(営業部、技術部、総務部)、拠点別(東京、大阪、海外)、デバイス種別(サーバー、クライアントPC、端末)
  2. グループポリシーの適用範囲を考慮
    • どのOUに対して、どんなポリシーが必要か
    • 組織変更にも柔軟に対応できるよう、OU構造はシンプルに

ステップ4-3: グループポリシー(GPO)設計

  1. 基本方針(セキュリティポリシー)のドメインルート適用
    • 企業全体で共通のセキュリティ基準(パスワード長、ロックアウトポリシーなど)はドメインルートに設定
  2. 部署単位・機能単位のGPO
    • 部署ごと、用途ごとに必要なポリシーをOUにリンク
    • 例:ソフトウェア配布、デスクトップ制限など
  3. テストOUを用意して検証
    • GPOは設定範囲が広いので、誤設定で全ユーザーに影響が及ばないように
    • テスト用OUで少人数へ適用して検証→問題なしで本番OUに展開

ステップ4-4: グループ設計 (セキュリティグループ/配布グループ)

  1. 役割ベースのグループ化
    • 例:経理部グループ、開発チームグループ、プロジェクトXYZグループ
  2. セキュリティ権限の委譲に応じたグループ作成
    • 共有フォルダの読み取り・書き込み権限をグループに割り当て、個々のユーザーはグループに所属させる形で運用
    • 「ユーザー → グループ → 権限」でシンプル管理

ステップ4-5: 冗長構成・バックアップ戦略

  1. ドメインコントローラー(DC)の冗長化
    • 1台故障しても、他のDCが認証サービスを提供
  2. 定期的なシステム状態のバックアップ
    • ADデータベース(NTDS)やシステム状態のバックアップ取得
    • 復旧テストも含め、ディレクトリ復元モード(DSRM)の手順確認

ステップ4-6: 運用管理・監視体制

  1. イベントログ・監査ログの定期チェック
    • ドメインコントローラーのイベントビューアで認証失敗やレプリケーションエラーを監視
  2. アカウント管理フローの標準化
    • 入社時のアカウント発行、退職時のアカウント無効化、異動時のグループ変更フローをドキュメント化
  3. 権限の委任
    • ヘルプデスク部門や現場管理者にもパスワードリセット権限などを委任
    • 管理者の負担を減らす

ステップ4-7: 将来的な拡張・バージョンアップ計画

  1. ADの機能レベル管理
    • ドメイン/フォレスト機能レベルを上げることで、新しいWindows Serverの機能が使える
  2. Azure ADとの統合検討
    • ハイブリッドクラウド認証を視野に、Azure AD Connectなどで同期
  3. 定期的なOS・ADのアップグレード計画
    • Windows Serverのサポート期限に合わせてアップグレードをスムーズに実施

まとめ

  1. ADの主要ユースケース: ユーザー認証・一元管理・グループポリシー
  2. 満たせるビジネス要件: セキュリティ強化、業務効率化、コンプライアンス対応、拡張性
  3. 他にも満たせる要件: ハイブリッド連携、リモートワーク、デバイス管理、カスタム認証基盤
  4. 効率的な運用保守のための設計:
    • ドメイン/OU/グループ/ポリシーの設計
    • 冗長化とバックアップの徹底
    • テスト検証環境の整備
    • ログ監視・権限委任・バージョン管理

これらのステップを踏んで設計・導入・運用を行うことで、ADの利点を最大限に活かしながら組織のビジネス要件を満たすことができます。 特に「将来の拡張を想定して余裕をもった構成にする」「OUやグループの設計をシンプルにする」ことが、長期運用では重要なポイントです。

以下では、「2000年代の古いActive Directory (AD)から、Azureを用いた新しいAD(オンプレミスのWindows Server + Azure AD連携)へ移行する」 ことを前提に、移行手順と戦略、具体的な方法をステップバイステップで解説します。


前提とゴール

  1. 古いAD(2000年代レベルのドメイン/フォレスト機能レベル)
    • 例:Windows Server 2003/2008など
  2. 新しいAD環境
    • オンプレミスの最新Windows Server(2019/2022)でAD DSを構築
    • Azure ADとも連携(ハイブリッド環境)し、将来的にはクラウドサービス(Office 365など)を利用予定

最終的には、古いドメインコントローラーを廃止し、新しいサーバー上でのAD DS + Azure AD Connect を運用することを目指します。


1. 移行戦略の大枠

ステップ1-1: 移行方法の選択

  1. インプレースアップグレード
    • 既存サーバーOSをアップグレードしながらADの機能レベルを上げていく方法
    • デメリット: OSアップグレードの失敗リスクやダウンタイムが大きい、複数回の段階的アップグレードが必要
  2. サイドバイサイド移行(新規サーバーを建てる)
    • 新しいサーバーに最新OSを導入 → ドメインコントローラーに昇格 → FSMO役割やデータを移行 → 古いDCを段階的に除去
    • メリット: リスクが少なくダウンタイムを最小化しやすい

一般的にはサイドバイサイド移行が推奨されます。ここではサイドバイサイドを前提とします。

ステップ1-2: ドメイン機能レベルの確認

  • Windows 2000/2003ドメイン機能レベルのままでは、最新OSのドメインコントローラーを参加させられない場合があります。
  • まずは**「現在のドメイン機能レベル」**を確認し、必要に応じて最低でも2003/2008レベルまで上げられるか検討します。

ステップ1-3: 移行の全体像

  1. 現行AD環境の調査: ドメイン構成、OU構造、グループポリシー、FSMOの所在などを確認
  2. 新ADサーバーの構築: 最新Windows Serverを用意し、ドメイン参加・DC昇格
  3. FSMO役割・データ移行: 新しいDCにPDC Emulatorなどの役割を移行
  4. Azure AD Connectの導入: ハイブリッド環境の設定
  5. クライアント・サーバーの再確認: ドメイン参加やGPO適用状況を検証
  6. 古いDCの降格・廃止: 最終的に不要になった旧DCを除去

2. ステップバイステップの移行手順

ステップ2-1: 現行AD環境のアセスメント

  1. ドメイン・フォレスト機能レベルの確認
    • Active Directoryユーザーとコンピュータ → ドメインのプロパティ → 「ドメイン機能レベル」を確認
    • 2000 Native/2003などの場合、一度2008レベルなどに上げる必要があるかもしれません。
  2. FSMO役割の所在確認
    • netdom query fsmo コマンドなどで、現在のPDC EmulatorやRID Masterなどの役割を把握
  3. OU構造・グループポリシーの整理
    • 不要なOUやGPOがあれば先に整理しておく
    • 長年運用していると重複や使っていないポリシーがあるので、移行前にクリーンアップを行う
  4. クライアントOSのバージョン確認
    • 古いPC(Windows XP/7など)が残っていると、機能レベルアップ後に動作検証が必要な場合もある

ステップ2-2: 新サーバー(最新OS)のセットアップ

  1. ハードウェア/仮想環境の準備
    • Windows Server 2019/2022をインストールした新しいマシン(もしくはVM)を用意
  2. ネットワーク設定(固定IP/DNS)
    • 旧ドメインと同一ネットワーク上に置き、DNSを指し示す
  3. サーバー名の決定
    • 例:NEW-DC01 など、わかりやすい命名
  4. ドメインへの参加
    • 新サーバーをメンバーサーバーとして既存ドメインに参加 (旧ドメインに参加する形)

ステップ2-3: 新サーバーをドメインコントローラーに昇格

  1. 役割と機能の追加
    • 「Active Directory ドメイン サービス (AD DS)」をインストール
  2. DCへの昇格ウィザード
    • 「既存のドメインに追加するドメインコントローラー」オプションを選択
    • グローバルカタログ(GC)・DNSサーバー機能も一緒にインストールすることが多い
  3. レプリケーション確認
    • インストール後、Active Directory サイトとサービスレプリケーションが正常に行われているかチェック

ステップ2-4: ドメイン機能レベル・フォレスト機能レベルのアップグレード(必要に応じて)

  1. 条件が整えばアップグレード
    • 古いDCをすべて Windows Server 2008 R2 以上にしてからドメイン機能レベルを上げられる場合が多い
  2. 慎重に実施
    • 機能レベルを上げると元に戻せないことがある
    • 本番前にテスト環境で問題なく動作するか確認

ステップ2-5: FSMO(エフモ)役割の移行

  1. 役割一覧:
    • PDC Emulator / RID Master / Infrastructure Master / Schema Master / Domain Naming Master
  2. 移行手順
    • Active Directory ユーザーとコンピュータ, Active Directory ドメインと信頼関係, Active Directory スキーマスナップイン、またはPowerShellNTDSUtilコマンドで手動移行
  3. 確認
    • netdom query fsmo で新DCに役割が集約されているか確認

ステップ2-6: Azure AD Connect の導入 (ハイブリッド化)

  1. Azure AD テナント用意
    • Office 365やMicrosoft 365等を導入する場合、既にAzure ADテナントがあるか、または新規に作成
  2. Azure AD Connectのインストール
    • 新しいDC上、もしくは別のメンバーサーバーにAzure AD Connectをセットアップ
    • オンプレADAzure ADを同期させ、ハイブリッドIDを実現する
  3. 同期スコープの設定
    • 同期するOU/ユーザーを選択し、不要なアカウントは同期対象外に
    • パススルー認証(PTA)フェデレーション(AD FS) の要件を検討
  4. テスト同期
    • 小規模OUでテストし、Azure AD上にアカウントが正しく作成されるか確認

ステップ2-7: クライアント・サーバーの切り替え・検証

  1. クライアントのログオンテスト
    • 新DCが認証を担当する状態で、ユーザーが問題なくログオンできるか
    • グループポリシーが正常に適用されるか
  2. ファイル/プリンタサーバーの接続確認
    • 古いDCが持っていたDNSやDHCP、ファイルサーバー機能などを移行している場合は、接続動作テスト
  3. Azure ADサインインテスト
    • 同期されたアカウントでOffice 365やAzureポータルにログイン可能か
    • Modern Authentication(MFA等)の有効化も検討

ステップ2-8: 古いドメインコントローラーの降格・廃止

  1. 役割が残っていないか最終チェック
    • FSMO役割はすべて新DCへ移行済みか
    • DNSやGCなど必要なサービスが残っていないか
  2. DCPromoで降格 (古いOSの場合)
    • Windows 2003/2008時代のツールによりドメインコントローラーを降格
    • 新DCのみで問題ないことが確認できたら古いサーバーを廃止
  3. メタデータクリーンアップ
    • 強制降格した場合や降格手順が失敗した場合には、AD上に残る古いDCの情報をNTDSUtilなどで削除
  4. ライセンス/ハードウェアの整理
    • 古いサーバーのライセンスを無効化、または物理撤去・リソース再利用などを行う

3. 運用上のポイントと追加考慮事項

ステップ3-1: バックアップ・検証環境の準備

  • 移行前にシステム状態バックアップを取得
  • 可能であればテスト用ドメイン検証環境を用意し、同様の手順を先に試す

ステップ3-2: 機能レベルアップ時の非互換チェック

  • 古いアプリケーションがNTLMv1などに依存している場合、機能レベルの上昇に伴う制限で動かなくなるリスクがある
  • レガシーアプリケーションの互換性を事前に確認

ステップ3-3: Azure ADのライセンス形態

  • Azure AD Free / Office 365 / P1 / P2 のどのライセンスを使うかで、多要素認証(MFA)や条件付きアクセスなどの機能差あり
  • 企業要件に応じてライセンスを検討

ステップ3-4: セキュリティ強化策

  • パスワードポリシーアカウントロックアウトポリシーを見直す
  • MFA(多要素認証) を導入して、外部からの不正ログインを防御

ステップ3-5: 定期的な運用モニタリング

  • イベントログでレプリケーションエラーAzure AD Connectの同期エラーをチェック
  • FSMO役割が正しく動作しているかを定期的に確認

4. まとめ: 移行の要点

  1. サイドバイサイド移行: 新OSのDCを参加させて役割移行するのが安全
  2. ドメイン機能レベルの引き上げ: 必要に応じて段階的に実施し、テスト環境での検証を怠らない
  3. Azure AD Connect導入: OUスコープ設定や同期方式(PTA/フェデレーション)を計画的に
  4. 検証→本番移行: 小規模OUやテストユーザーで動作確認後、全社員へ段階的に展開
  5. 旧DCの廃止とメタデータクリーンアップ: 役割の取りこぼしやメタデータが残らないように丁寧に実施

最終的なゴール

  • 古いAD環境に依存せず、最新のWindows Server + Azure AD連携でセキュリティ・運用性を高める
  • ハイブリッド環境を活用することで、クラウドサービス(Office 365など)へのシームレスなログインやMFA等の高度なセキュリティ機能を実現

これらの手順・戦略を踏まえて段階的に移行を進めれば、ダウンタイムやリスクを最小限に抑えたスムーズなAD移行が期待できます。




5. ロールバック計画とトラブルシュート

Active Directory の移行は、環境によっては非常に複雑になることがあります。万が一トラブルが発生した場合に備え、ロールバック計画を立てておくことが重要です。ここでは、移行手順の続きとして、ロールバックの考え方トラブルシュートのヒントを示します。


ステップ5-1: ロールバック計画の策定

  1. バックアップとスナップショットの活用

    • オンプレミスAD: システム状態バックアップ (NTDS、SYSVOL、レジストリ含む) を取得しておく
    • 仮想環境: 移行手順を実行する前に、DCのスナップショット (VMの機能) を取得しておく
      • ただし、ドメインコントローラーのスナップショット復元は注意が必要
      • 本番DCへのスナップショット復元は推奨されませんが、緊急手段としての位置づけを理解しておく
  2. フェーズごとのロールバックポイントを確保

    • 例: FSMO 移行前、ドメイン機能レベル引き上げ前、Azure AD Connect 導入前など
    • それぞれのタイミングで、何か問題が起きた場合に「直前の状態」に戻せるかを確認しておく
  3. ドキュメント化と手順書整備

    • ロールバックする際の手順書を作成しておき、関係者間で周知
    • 誰がどのコマンドを実行し、どのように確認するかを明確にしておく

ステップ5-2: トラブルシュートのポイント

  1. DNS 関連の不具合

    • AD は DNS を前提として動作するため、DNS 設定ミスレコードのレプリケーション不良があると認証障害が起こりやすい
    • 移行後にクライアントやサーバーが正しく新DCを参照しているか、ホスト(A)レコードやSRVレコードが登録されているかを確認
  2. レプリケーションエラー

    • 「Active Directory サイトとサービス」でレプリケーションを強制同期し、イベントビューアでエラーが出ていないかチェック
    • NTDS Replication (イベントID 1084, 1645 など) や NTFRS/SYSVOL の問題に注意
  3. FSMO ロール移行トラブル

    • netdom query fsmo でロールが移転していることを確認
    • 移行時にエラーが出た場合は、NTDSUtil コマンドで “seize (強制移行)” が必要になることもある
    • 強制移行後は、旧サーバーが再度 FSMO を主張しないよう確実に降格/廃止する
  4. グループポリシー (GPO) 適用の失敗

    • 「gpresult /r」や「RSOP.msc」でクライアント側の適用状況を確認
    • SYSVOL の共有が正常か、ポリシーのファイルが新DCに正しくレプリケートされているかをチェック
  5. Azure AD Connect 同期エラー

    • Azure AD Connect の Synchronization Service Manager でエラーを確認
    • 「アカウントが競合している」「重複属性がある」などが典型的なトラブル
    • フィルタリングで除外したOUにユーザーが入っていないか、同期される属性に問題がないかを見直す
  6. 認証エラー (Kerberos / NTLM)

    • 古いバージョンのクライアントやアプリケーションが NTLMv1 を使用している場合は、機能レベルやポリシー変更で通信がブロックされることがある
    • 事前に Kerberos と NTLMv2 の利用を推奨するように環境を整備しておく

6. 移行後の運用・最適化

移行作業が完了したら終わりではなく、新しい AD 環境を安定稼働させるために、運用・最適化を行うことが重要です。

ステップ6-1: 運用ドキュメントの更新

  1. 運用フローの修正

    • 「ユーザー追加」や「パスワードリセット」手順を新 AD / Azure AD Connect 前提に修正
    • ロール (FSMO) が新サーバーにあることを踏まえ、各種手続きが変わっていないか確認
  2. 障害対応マニュアルの整備

    • 新しく導入した機能 (例: パススルー認証、フェデレーションサーバー) を含む形でトラブルシュート手順を追記
    • Azure AD Connect のエラー対応マニュアルをまとめておく

ステップ6-2: セキュリティ強化策の導入

  1. MFA (多要素認証) の展開
    • Office 365 や Azure AD Premium ライセンスを利用している場合は、MFA を有効にし、不正ログインへの対策を強化
  2. 条件付きアクセス (Conditional Access)
    • ログインする端末やネットワーク環境によってアクセス可否を制御し、リスクを低減
  3. 権限の最小化 (Least Privilege)
    • ドメイン管理者アカウントを最小限にし、日常運用には特権のないアカウントを使用する

ステップ6-3: 機能レベルをさらにアップグレード (必要に応じて)

  1. 最新のドメイン機能レベル (2016/2019/2022) への引き上げ
    • 新しい機能 (Privileged Access Management、Azure AD Join との親和性向上 など) が活用可能
  2. フォレスト機能レベルも合わせてアップ
    • フォレスト全体で使用する機能が拡張されるため、子ドメインがある場合も含めて段階的に実施

7. ロングタームでのアプローチ

オンプレ AD と Azure AD がハイブリッドになったことで、将来的には「クラウドファースト」にシフトするケースも増えています。以下のような方向性も検討できます。

  1. 完全クラウドへの移行 (クラウドオンリー)
    • オンプレ AD を廃止し、Azure AD にすべてを集約する (一部の中小企業で採用例あり)
    • ただし Windows Domain Join や GPO の要件が残る企業ではまだハイブリッドが主流
  2. Azure AD Domain Services (AAD DS) の活用
    • Azure 上でドメインサービスを提供するマネージドサービス
    • オンプレのサーバーリソースを削減しつつ、Windows VM がドメイン参加できる
  3. ゼロトラストセキュリティ
    • デバイスやユーザーのコンテキストに基づいて柔軟にアクセスを制御するモデル
    • Azure AD 条件付きアクセスや Microsoft Defender シリーズなどとの連携強化

8. 結論

古い Active Directory から新しい Windows Server + Azure AD への移行は、システム全体のセキュリティと運用効率を飛躍的に高める機会になります。しかし、移行過程で考慮すべき項目は多岐にわたるため、テスト環境での検証詳細な移行計画、そしてロールバック手順の準備が欠かせません。

  • ロールバックポイントを複数用意しながら段階的に移行する
  • DNS、レプリケーション、FSMO、グループポリシーなどの要チェック項目を一つずつ丁寧に検証する
  • 移行後は Azure AD Connect や MFA、条件付きアクセスなどを有効活用し、最新のセキュリティを確保する

これらを着実に進めることで、古いAD環境を安全にアップグレードし、ハイブリッド環境クラウドサービスを活用できるインフラ基盤を整えることができるでしょう。

flowchart TB
    A0([移行プロジェクト開始]) --> A1{現行AD環境のアセスメント}
    A1 --> A2[ドメイン・フォレスト機能レベルの確認]
    A2 --> A3["OU・GPOの整理\nユーザー/PCクリーンアップ"]
    A3 --> A4["移行計画書作成\n(ロールバック計画含む)"]

    A4 --> B1{新環境準備}
    B1 --> B2["新サーバーに\n最新Windows Serverをインストール"]
    B2 --> B3["ドメイン参加\n(旧ADにメンバーサーバーとして参加)"]
    B3 --> B4["Active Directory DS導入\nDC昇格\n(DNSとGC設定)"]

    B4 --> C1{FSMO役割移行と機能レベル}
    C1 --> C2["netdom / NTDSUtil\nFSMOを新DCへ移行"]
    C2 --> C3["必要に応じて\nドメイン/フォレスト機能レベルを引き上げ"]

    C3 --> D1{Azure AD Connect設定}
    D1 --> D2["Azure ADテナント準備\n(Office 365など)"]
    D2 --> D3["Azure AD Connect導入\n(PTA / フェデレーション)"]
    D3 --> D4["OU同期範囲の指定\n& テスト同期"]

    D4 --> E1{検証とテスト}
    E1 --> E2["クライアントログオン\n& GPO適用テスト"]
    E2 --> E3["ファイル/プリンタなど\n共有リソース接続確認"]
    E3 --> E4["Azure ADポータルへの\nサインイン確認"]

    E4 --> F1{問題解消とロールバック検討}
    F1 --> F2["イベントログ/レプリケーション確認\nトラブルシュート"]

    F2 --> G1{旧DC廃止}
    G1 --> G2["旧DC降格(dcpromo等)\nメタデータクリーンアップ"]
    G2 --> G3["DNS/DHCP等の役割が\n残っていないか最終確認"]

    G3 --> H1{運用最適化}
    H1 --> H2["セキュリティ強化\n(MFA / Conditional Access)"]
    H2 --> H3["権限委任・最小化\nドキュメント更新"]
    H3 --> I1([移行完了・本番運用へ])
Loading

以下では、**「古いAD(2000年代)から新しいAD(Windows Server + Azure AD連携)へ移行」**する際の手順のうち、
**「Active Directory DS導入 & DC昇格」や「FSMO役割移行」「ドメイン機能レベルの引き上げ」**について、
中学生にもわかるように段落ごとに分かりやすくまとめ直しています。


Active Directory DS導入 & DC昇格 (B4)

  1. 新しいサーバーを用意
    • 新サーバーにWindows Server(2019/2022など)をインストールし、旧ドメインにメンバーサーバーとして参加。
  2. Active Directory DSのインストール
    • サーバーマネージャーから「役割と機能の追加」を選び、「Active Directory ドメイン サービス」を入れる。
  3. ドメインコントローラーへ昇格
    • 「このサーバーをドメインコントローラーに昇格する」を実行し、DNSサーバーやグローバルカタログ(GC)の設定もオンにする。
  4. レプリケーション確認
    • ADのツール「Active Directory サイトとサービス」で、新しいDCと他のDCが情報を正しくやり取りしているかチェック。

FSMO役割移行と機能レベル (C1)

  1. FSMO(エフモ)とは?
    • ADには「PDCエミュレーター」「RIDマスター」「インフラストラクチャマスター」「スキーママスター」「ドメインネーミングマスター」の5つの特別な役割がある。
    • これらをまとめて「FSMOロール(Flexible Single Master Operations)」と呼ぶ。
  2. なぜ移行が必要?
    • 古いDCが持っていた重要な役割を、新しいDCに移さないと完全に新環境で動かせない。

netdom / NTDSUtilでFSMOを新DCへ移行 (C2)

  1. GUIツールでも移行できる
    • 「Active Directory ユーザーとコンピュータ」や「ADドメインと信頼関係」などの管理ツールから移行可能。
  2. コマンドツール(netdom, NTDSUtil)で移行
    • コマンドを使って役割を移すのも手軽。
    • 例: netdom query fsmo でどのサーバーに役割があるかを確認し、 ntdsutil で「transfer」と「seize」ができる。
  3. 移行後の確認
    • netdom query fsmo で5つの役割が全部新しいDCに集まっているかチェック。

必要に応じてドメイン/フォレスト機能レベルを引き上げ (C3)

  1. 機能レベルってなに?
    • ADには「ドメイン機能レベル」「フォレスト機能レベル」があり、それぞれが高いほど新しい機能が使える。
  2. 古いサーバーがあると上げられない
    • たとえば2003のDCが残っているとドメイン機能レベルを2008以上にできない。
  3. 手順
    • まず古いDCをすべて降格または廃止してから、「Active Directory ドメインと信頼関係」のコンソールを使って機能レベルをアップ。
    • 一度上げると下げられないので、慎重にテスト環境で検証してから実施。

まとめ

  • Active Directory DS導入 & DC昇格: 新サーバーをDCにするための最初の大きなステップ。
  • FSMO役割移行: ADの大事な役割を、新しいDCへきちんと渡してあげる。
  • ドメイン/フォレスト機能レベルの引き上げ: 新しい機能を使えるようにする一方で、後戻りができないので要注意。

このように段階的に作業を進めれば、古い環境から新しい環境への移行をスムーズに行い、Azure ADとも連携して最新のセキュリティや便利な機能を活用できるようになります。 中学生でもイメージしやすいように言えば、「古い学校の名簿システムから、新しい学校の名簿システムに移して、さらに校外(クラウド)のオンラインシステムとも繋げる」ようなイメージです。

以下では、Active Directory の設定や役割移行などを GUIではなくコマンドで実行する方法をステップバイステップで解説します。
最終的に「シェルスクリプトでの自動化」も可能ですが、まずはPowerShellやコマンドラインツールを使った方法を中心にご紹介します。


1. PowerShellモジュール「ActiveDirectory」の活用

ステップ1-1: モジュールのインストール&ロード

  1. Windows Server (2012以降) であれば標準搭載
    • サーバーマネージャー → 「機能の追加」→「Active Directory 管理ツール(Active Directory Module for Windows PowerShell)」を有効にする。
    • もしくは PowerShell で下記コマンドでもOKです。
      Install-WindowsFeature RSAT-AD-PowerShell
  2. PowerShellでモジュール読み込み確認
    Import-Module ActiveDirectory
    Get-Command -Module ActiveDirectory
    
     •	「New-ADUser」「Set-ADGroup」などのコマンドが表示されればOKです。
    

ステップ1-2: ユーザーやグループの設定をコマンドで実行 1. ユーザーの作成

New-ADUser -Name "Taro Yamada" -SamAccountName "taro" -UserPrincipalName "[email protected]" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true ` -Path "OU=Users,DC=example,DC=local"

2.	グループの作成・メンバーの追加

グループ作成

New-ADGroup -Name "TestGroup" -GroupCategory Security -GroupScope Global -Path "OU=Groups,DC=example,DC=local"

メンバー追加

Add-ADGroupMember -Identity "TestGroup" -Members "taro"

3.	OUの作成

New-ADOrganizationalUnit -Name "SalesDept" -Path "DC=example,DC=local"

これらをPowerShellスクリプト(ps1ファイル)としてまとめておけば、GUI操作なしでユーザーやグループ、OUを一括登録・更新できます。

  1. Active Directoryドメインサービス(AD DS)のインストールと昇格

ステップ2-1: PowerShellでAD DSをインストール

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

•	GUIの「サーバーマネージャー」で行っていた作業をコマンドで実行可能です。

ステップ2-2: 新規フォレストの作成/既存ドメインにDC追加 1. 新規ドメインフォレストの場合

Install-ADDSForest -DomainName "example.local" -ForestMode "Win2016Forest" -DomainMode "Win2016Domain" -InstallDns:$true -SafeModeAdministratorPassword (ConvertTo-SecureString "RecoveryPass1" -AsPlainText -Force)

2.	既存ドメインに追加DCを作る場合

Install-ADDSDomainController -DomainName "example.local" -InstallDns:$true -Credential (Get-Credential) ` -SafeModeAdministratorPassword (ConvertTo-SecureString "RecoveryPass1" -AsPlainText -Force)

•	コマンドが完了するとサーバーが自動再起動し、新しいドメインコントローラーの役割が設定されます。
  1. FSMO役割の移行 (netdom / NTDSUtil / PowerShell)

ステップ3-1: netdomコマンドを使う例 • FSMOロールがどこにあるか確認:

netdom query fsmo

•	移行 (例: PDCエミュレーターをNEW-DCへ移行):

netdom /transfer pdc NEW-DC

※実際の構文は移行したいロールに応じて異なります。

ステップ3-2: NTDSUtilを使う例 1. NTDSUtil起動

ntdsutil

2.	ロール移行モードに入る

ntdsutil: roles fsmo maintenance: connections

3.	サーバーを指定

server connections: connect to server NEW-DC

4.	ロール移行

fsmo maintenance: transfer pdc

•	transfer rid master / transfer schema master など、移行するロールを指定。

ステップ3-3: PowerShellでFSMO移行 (ドメイン機能レベルが対応している場合)

Move-ADDirectoryServerOperationMasterRole -Identity "NEW-DC" -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

•	これで5つのFSMOロールを一括移行できます。
  1. ドメイン機能レベルやフォレスト機能レベルの変更

ステップ4-1: PowerShellコマンドで変更

ドメイン機能レベルをWindows2016に上げる例

Set-ADDomainMode -Identity "example.local" -DomainMode Windows2016Domain

フォレスト機能レベルをWindows2016に上げる例

Set-ADForestMode -Identity "example.local" -ForestMode Windows2016Forest

•	注意: 一度上げると原則戻せないので、事前にテスト・旧DC降格を完了させておくこと。
  1. グループポリシー(GPO)の操作 (PowerShell / コマンド)

ステップ5-1: PowerShellでGPO作成・リンク 1. GPMC(グループポリシー管理)モジュールの読み込み

Import-Module GroupPolicy

2.	GPOの作成

New-GPO -Name "PasswordPolicyGPO" -Comment "Set strong password policy"

3.	OUへGPOをリンク

New-GPLink -Name "PasswordPolicyGPO" -Target "OU=Users,DC=example,DC=local" -Enforced No

4.	GPOの編集
•	パスワードポリシーなどの一部設定はGUI「gpedit.msc」を使わずに、Set-GPRegistryValue コマンドなどで変更できる場合もあります。
  1. Azure ADとの連携(ハイブリッド)もコマンドで行う

ステップ6-1: Azure AD Connectのインストール • Azure AD ConnectそのものはGUIを含むウィザードが主流ですが、 **「無人インストール (unattended install)」**のモードも用意されています。 • 公式ドキュメント(英語)に「Azure AD Connect unattended」として手順が公開されています。

ステップ6-2: Azure CLI / PowerShellで設定を変更 • Azure AD関連は「Azure CLI」や「Azure PowerShellモジュール」を使うことで、 ユーザー作成やライセンス付与などをGUIなしで自動化可能。

Connect-AzureAD New-AzureADUser -DisplayName "Sato Hanako" -UserPrincipalName "[email protected]" ...

•	ただし、オンプレADとAzure ADの「ハイブリッド構成」を細かく変更する場合は、

Azure AD Connectの構成ウィザードを使用するケースが多いです。

  1. コマンドをまとめて自動化するには?

    1. PowerShellスクリプト(.ps1)でステップごとにまとめる • 例: 01_InstallADDS.ps1、02_MoveFSMO.ps1、03_CreateUsers.ps1…など。 • スクリプトにすることで「コマンド入力ミス(タイプミス)」を減らせ、ケアレスミス防止に役立ちます。
    2. タスクスケジューラやAzure DevOpsなどを活用 • 定期的に実行するジョブ(例: ユーザー情報の同期やクリーンアップ)を自動化できる。
    3. DSQUERY/DSADD/DSMOD/DSRMなどの古いCLIも存在 • ただし、古いWindows Serverでしか使えない場合があり、今から導入するならPowerShellの方がおすすめ。
  2. まとめ • GUIを使わずに設定を変えたい → PowerShellの「ActiveDirectory」モジュールや netdom, ntdsutil などのコマンドラインツールを活用。 • ケアレスミスを防ぐ → 手入力ではなくスクリプト化し、パラメータだけを変えて実行する仕組みにする。 • Azure AD連携も自動化可能 → Azure CLIやPowerShellモジュール、またはAzure AD Connectの無人インストールオプションなどを検討。

これらのコマンドを組み合わせれば、ほぼ全てのAD管理作業をGUIなしで行うことが可能です。シェルスクリプト(バッチファイル)やPowerShellスクリプトを使えば、一連のステップをミスなく自動実行できますので、ぜひ活用してみてください。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment