🖥️

【2-4【Proxmox VE 実践編】Windows ServerでActive Directory構築ガイド：ドメイン作成からGPOまで

に公開
初心者
Active Directory
Windows Server
Proxmox
自宅サーバ
tech

【Proxmox VE 実践編】Windows ServerでActive Directory構築ガイド：ドメイン作成からGPOまで

前回の記事では、Windows Serverのインストールと初期設定を行いました。
https://zenn.dev/koikoi_infra/articles/ccb764b735033f
今回はそのサーバーを中核にして、多くの企業でITインフラの心臓部として機能しているActive Directoryドメイン環境をゼロから構築していきます。

1. Active Directoryとは？

**Active Directory (AD)**とは、ネットワーク上の資源（ユーザー、コンピューター、プリンターなど）に関する情報を格納し、それらへのアクセスを管理するための中央集権的なデータベースおよびサービス群です。
主に以下の3つの核心的な機能を提供します。

  • 認証 (Authentication): ユーザーが誰であるかを確認します。
  • 認可 (Authorization): 認証されたユーザーが、何に対して、どのような操作を許可されているかを決定します。
  • 集中管理 (Centralized Management): ユーザーアカウント、コンピューター設定、セキュリティポリシーなどをドメインコントローラーから一元的に管理します。

インターネットドメインとの違い

zenn.devのようなインターネットドメインは、世界中の誰もがアクセスできる公開された住所です。
一方、Active Directoryドメイン（今回作成するkoikoi_infra.localなど）は、特定の組織内だけで通用するプライベートな管理範囲を定義するものです。

2. 今回構築するActive Directory環境の設計図

実際の設定作業に入る前に、今回構築する環境の最終的な完成図を共有します。この設計図に沿って、各ステップを進めていきます。

ドメインとOU構成

  • ルートドメイン名: koikoi_infra.local（例）
  • OU（組織単位）構造:
    koikoi_infra.local
├─ Corporate（企業全体）
│  ├─ Users（ユーザーアカウント）
│  │  ├─ Administrators（管理者）
│  │  ├─ IT-Staff（IT部門）
│  │  └─ End-Users（一般ユーザー）
│  ├─ Computers（コンピューターアカウント）
│  │  ├─ Servers（サーバー）
│  │  ├─ Workstations（クライアントPC）
│  │  └─ Mobile-Devices（モバイル）
│  └─ Groups（グループ管理）
│  │  ├─ Security-Groups（セキュリティグループ）
│  │  └─ Distribution-Groups（配布グループ）

3. AD DSのインストールとドメインコントローラーへの昇格

手順1：AD DS役割のインストール

サーバーマネージャーの「役割と機能の追加」から、「Active Directory ドメイン サービス」を選択してインストールします。

手順2：ドメインコントローラーへの昇格

インストール完了後、サーバーマネージャーの通知（旗マーク）から「このサーバーをドメイン コントローラーに昇格する」を実行します。ウィザードでは、「新しいフォレストを追加する」を選び、ルートドメイン名に設計図通りのkoikoi_infra.local（例）を入力し、DSRMパスワードなどを設定します。
インストールが完了すると、サーバーは自動的に再起動します。

補足：「役割のインストール」と「DC昇格」の違い
  1. 役割のインストール: サーバーにAD DSを管理するためのプログラム（機能）を追加する作業です。
  2. DCへの昇格: インストールされた機能を使って、サーバーをドメインの管理者（ドメインコントローラー）として構成する作業です。ここで初めてドメインが誕生します。

4. ドメイン環境へのサインインとDNS設定

手順3：ドメインアカウントでのサインイン

再起動後、サインイン画面が表示されます。そのままでは以前のローカルアカウント情報が残っている場合があるため、**「その他のユーザー」を選択し、ユーザー名にKOIKOI_INFRA\Administrator**のようにドメイン名\ユーザー名の形式で入力し、パスワードでサインインします。

補足：なぜサインイン方法が変わるのか？ ローカル vs ドメイン認証

DCへ昇格する前、サーバーはSAM（Security Account Manager）と呼ばれるPC固有のアカウントデータベースを持っていました。Administratorというユーザーは、このローカルのSAMに記録されていました。

DCへ昇格すると、このローカルSAMは無効化され、サーバーは**ドメイン全体で共有される中央データベース（Active Directory）**を使って認証を行うようになります。

KOIKOI_INFRA\Administratorというサインイン名は、「ローカルのSAMではなく、KOIKOI_INFRAというドメインのデータベースに登録されているAdministratorとして認証してください」という明確な指示なのです。同じAdministratorという名前でも、その所属と権限の範囲が全く異なる、別のユーザーに生まれ変わったと理解してください。

補足：Active Directoryのサインイン形式について

Active Directoryドメイン環境では、複数のサインイン形式が利用可能です。それぞれの形式には明確な違いがあるため、正しく理解しておきましょう。

サインイン形式の種類

Active Directoryでは、以下の2つの主要なサインイン形式をサポートしています：

NetBIOS形式:
ドメイン名\ユーザー名（例：KOIKOI_INFRA\Administrator）

UPN形式:
ユーザー名@FQDN（例：Administrator@koikoi_infra.local）

NetBIOSドメイン名とFQDNの関係

重要なポイントは、NetBIOSドメイン名とFQDN（完全修飾ドメイン名）は異なるということです：

  • FQDN: koikoi_infra.local（ドメイン昇格時に設定した名前）
  • NetBIOSドメイン名: KOIKOI_INFRA（FQDNの最初の部分から自動生成）

NetBIOSドメイン名は、ドメイン昇格時にFQDNの最初のドット（.）より前の部分から自動的に生成されます。この名前は15文字の制限があり、レガシーシステムとの互換性を保つために存在します。

使用できるサインイン形式の組み合わせ

実際にサインインで使用できる形式は以下の通りです：

✅ 正しい形式:

  • KOIKOI_INFRA\Administrator（NetBIOS形式）
  • Administrator@koikoi_infra.local（UPN形式）

❌ 間違った形式:

  • koikoi_infra.local\Administrator（FQDNを使ったバックスラッシュ形式は無効）

なぜFQDNでバックスラッシュ形式が使えないのか？

ドメイン名\ユーザー名形式は、NetBIOSドメイン名専用の認証方式です。FQDNであるkoikoi_infra.localはNetBIOSドメイン名ではないため、この形式では認証が失敗します。

FQDNを使用する場合は、必ずUPN形式（ユーザー名@FQDN）を使用する必要があります。

実践例

もしドメインをkoikoi.infra.localと設定していた場合、以下のようになります：

✅ 使用可能:

  • KOIKOI\Administrator（NetBIOS形式）
  • Administrator@koikoi.infra.local（UPN形式）

❌ 使用不可:

  • koikoi.infra.local\Administrator

この理解により、Active Directory環境でのサインイン時に適切な形式を選択できるようになります。

手順4：DNSフォワーダーの設定と確認

サーバーマネージャーの「ツール」→「DNS」を開き、サーバーのプロパティからフォワーダーに8.8.8.8などを設定します。
最後に、コマンドプロンプトでnslookup ws01.koikoi_infra.localとnslookup zenn.devを実行し、両方が成功することを確認します。

5. Active Directoryの内部構成

次に、設計図に基づいてActive Directoryの内部構造を構築します。

手順5：組織単位（OU）の作成

「Active Directory ユーザーとコンピューター」を開き、設計図で計画したOU（組織単位）をすべて作成します。OUは、ユーザーやPCを部署ごとに整理し、GPOを適用するための管理単位です。
作成するには、ドメイン名や親となるOUを右クリックし、**「新規作成」→「組織単位 (OU)」**を選択します。

手順6：ユーザーとグループの作成

作成したOUの中に、設計図通りのユーザーアカウントとセキュリティグループを作成し、ユーザーを適切なグループに所属させます。

  1. ユーザーの作成:

    • ユーザーを作成したいOU（例: Users\Administrators）を右クリックし、「新規作成」→「ユーザー」を選択します。
    • ウィザードで姓名、ログオン名（例: adm-labuser）、パスワードを入力してユーザーを作成します。

  2. グループの作成:

    • グループを作成したいOU（例: Groups\Security-Groups）を右クリックし、「新規作成」→「グループ」を選択します。
    • グループ名（例: IT-Administrators）を入力し、グループの種類が「セキュリティ」になっていることを確認して作成します。

  3. ユーザーをグループに所属させる:

    • 作成したユーザー（例: adm-labuser）を右クリックして「プロパティ」を開きます。
    • 「所属するグループ」タブに移動し、「追加」ボタンから所属させたいグループ（例: IT-Administrators）を検索して追加します。

6. グループポリシー（GPO）によるルールの適用

最後に、ドメイン全体のルールブックである**グループポリシー（GPO）**を作成し、設定を一元管理します。

グループポリシー（GPO）とは？

GPOは、ユーザーやコンピューターに対して、セキュリティ設定やデスクトップ環境などを一元的に、かつ強制的に適用するための設定集です。これにより、「全社員のパスワードを12文字以上にする」といった企業のルールを、一台一台設定することなく、自動で徹底させることができます。

手順7：GPOの作成と編集

  1. 「グループ ポリシーの管理」ツールを開き、「グループ ポリシー オブジェクト」を右クリック→「新規」で新しいGPO（例: Corporate-Security-Baseline）を作成します。
  2. 作成したGPOを右クリック→「編集」でグループ ポリシー管理エディターを開きます。
  3. 左側のツリーをたどり、目的のポリシー（例: コンピューターの構成 → ポリシー → ... → 監査ポリシー）を探します。
  4. 右側の一覧から設定したい項目（例: ログオンの監査）をダブルクリックし、「このポリシー設定を有効にする」にチェックを入れ、編集します。

手順8：GPOのリンクと優先順位の管理

作成したGPOを、適用したいドメインやOU（例: koikoi_infra.local）を右クリックし、**「既存の GPO のリンク」**を選択して関連付けます。

同じ場所に複数のGPOがリンクされている場合、「リンクの順序」の数字が小さいほど優先度が高くなります。ドメインやOUを選択し、「リンクされたグループ ポリシー オブジェクト」タブで、GPOを選択して左の矢印ボタンで優先順位を変更できます。

補足：パスワードポリシーの例外

「パスワードのポリシー」と「アカウントロックアウトのポリシー」は、ADの仕様上、**Default Domain Policy**というGPOで設定するのがベストプラク-ティスです。自作のGPOで設定しても、Default Domain Policyが優先されてしまい、設定が反映されないため注意が必要です。

手順9：適用結果の確認

コマンドプロンプトでgpupdate /forceコマンドを実行してポリシーを即時適用させ、rsop.mscコマンドで設定が意図通りに反映されているかを確認します。

まとめ

これで、Proxmox VE上に本格的なActive Directoryドメイン環境の基礎が完成しました。これは、多くの企業で利用されているITインフラの根幹をなす技術です。

Discussion