【第2回】Windows Server 2025：ADDSドメインコントローラーの構築と設計

前回の第1回では、M365のハイブリッド認証を支えるADDS、ADFS、WAP、そしてAlmaLinux 9によるLVS（ロードバランサー）の全体アーキテクチャを俯瞰しました。システムのパケットフローと各コンポーネントの役割が明確になったところで、今回からはいよいよ具体的なサーバー構築のフェーズに入ります。

構築の第一歩となるのは、すべての認証の源泉（IdP：Identity Providerのバックエンド）となる「Active Directory Domain Services (ADDS)」、すなわちドメインコントローラー（DC）の構築です。「WindowsのGUI画面をポチポチクリックするのは面倒だ」「裏側で何が起きているのかブラックボックスで気持ち悪い」と感じるLinuxエンジニアのために、本記事ではLinuxのディレクトリサービス（OpenLDAP等）とのアーキテクチャ比較を交えながら、Windows Server 2025環境におけるADDSの設計思想と、PowerShell（CLI）を用いた完全自動化可能な構築手順を圧倒的な情報密度で解説します。

---

1. Linuxエンジニアから見たActive Directory (ADDS) の正体

Linux環境でユーザーの集中管理を行う場合、古くはNIS、現在ではOpenLDAPやFreeIPAを利用するのが一般的です。しかし、Windows環境、特にM365とのハイブリッド環境においては、Microsoft Active Directory Domain Services (ADDS) が不可欠です。まずはLinuxエンジニアの頭の中にある概念を、Windowsの概念にマッピング（変換）してみましょう。

1-1. ADDS vs OpenLDAP vs Samba4 アーキテクチャ比較

以下の表は、各ディレクトリサービスの特徴と、エンタープライズ環境（特にM365連携を前提とした場合）での適性を比較したものです。

比較項目	Microsoft ADDS (Win Server 2025)	OpenLDAP (Linux)	Samba4 AD (Linux)
コアプロトコル	LDAP, Kerberos v5, DNS統合	LDAP	LDAP, Kerberos v5, SMB
クライアント管理機能	GPO (Group Policy Object) に完全対応。レジストリやセキュリティの強制適用が可能。	なし。別途Ansible等の構成管理ツールが必要。	GPOの一部に対応するが、最新のWindows 11等への完全互換性には遅れが生じやすい。
冗長化方式	マルチマスター・レプリケーション（どのノードからでも更新可能）。	シングルマスター（Provider/Consumer）またはMulti-Provider。	マルチマスター（ADDS互換）。
M365 (Entra ID) 連携	◎ フルサポート。Entra Connectを用いた公式同期対象。	× 非対応。	△ 技術的には同期可能だが、Microsoftの公式サポート対象外。

1-2. M365 (Entra ID) 同期の前提となる「純正AD」の重要性

Linuxエンジニアの中には「どうしてもWindows Serverのライセンスコストを削減したい」とSamba4でADを構築しようとする方がいます。しかし、M365のハイブリッド認証において、オンプレミスとクラウドを同期する公式ツール「Microsoft Entra Connect (旧Azure AD Connect)」は、純正のWindows Server ADDSを前提に設計されています。

パスワードハッシュの同期（PHS）、デバイスライトバック、シームレスSSOのKerberosチケット連携など、高度なセキュリティ機能は、純正ADDSのスキーマ拡張や独自の暗号化メカニズムに依存しています。認証基盤において「サポート対象外（Unsupported）」の構成をとることは、エンタープライズインフラにおいて最大のタブーです。だからこそ、ADDSはWindows Serverで構築しなければならないのです。

2. Windows Server 2025の初期設定ベストプラクティス（PowerShell）

ドメインコントローラー（DC）は、ネットワーク内の「神」となるサーバーです。IPアドレスが頻繁に変わったり、時刻がずれたりすることは致命的な障害に直結します。まずはOSインストール直後の初期設定をPowerShellで確実に行います。

2-1. コンピューター名と固定IPアドレスの設定

Linuxにおける hostnamectl や nmcli の代わりに、以下のPowerShellコマンドレットを管理者権限で実行します。

# 1. ネットワークアダプタの名称を取得（例: Ethernet0）
Get-NetAdapter

# 2. IPアドレス、サブネットマスク、デフォルトゲートウェイの固定（例: 192.168.10.10/24）
New-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress "192.168.10.10" -PrefixLength 24 -DefaultGateway "192.168.10.1"

# 3. DNSサーバーの設定（最初は自分自身 127.0.0.1 と、外部のフォワーダーを設定）
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses ("127.0.0.1", "8.8.8.8")

# 4. コンピューター名の変更と再起動
Rename-Computer -NewName "DC01" -Restart

2-2. タイムゾーンとNTP（時刻同期）の厳格化

Active Directoryの認証のコアである「Kerberosプロトコル」は、クライアントとサーバー間の時刻のズレ（デフォルトで5分以上）を許容しません。時刻がずれると認証トークンが無効になり、誰もログインできなくなります。Linuxの chronyd のように、Windowsでは w32tm コマンドで外部NTPサーバー（例: NICT）と同期させます。

# タイムゾーンを東京（JST）に設定
Set-TimeZone -Id "Tokyo Standard Time"

# 外部NTPサーバー（NICT）との同期設定
w32tm /config /manualpeerlist:"ntp.nict.jp,0x8" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync

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

初期設定が完了したら、いよいよActive Directoryの役割をインストールし、サーバーをドメインコントローラーに「昇格」させます。

3-1. 論理構造の理解（フォレスト、ツリー、ドメイン）

コマンドを叩く前に、ADの論理構造を理解しておく必要があります。Linuxエンジニア向けにDNSの名前空間（Namespace）に例えて解説します。

ADの概念	概要とLinux的解釈
ドメイン (Domain)	セキュリティと管理の基本境界。例: linuxkoubou.local。DNSのゾーン情報と密接に連携し、この配下にあるオブジェクト（ユーザーやPC）で一つのデータベースを共有します。
ツリー (Tree)	連続したDNS名前空間を持つドメインの集合。例: tokyo.linuxkoubou.local のように、親ドメインの下にサブドメインが連なる構造です。
フォレスト (Forest)	Active Directoryの最上位の論理コンテナ。1つ以上のツリーを含み、「スキーマ（データベースの構造定義）」を共有する最大の境界です。最初に構築するドメインが「フォレストルートドメイン」となります。

3-2. PowerShellによるADDS役割の追加とフォレスト構築

今回は、新規にフォレストとルートドメイン（例：linuxkoubou.local）を構築します。Linuxにおける dnf install と設定ファイルの流し込みに相当する作業です。

# 1. ADDSの役割（Role）と管理ツールをインストール
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

# 2. 新規フォレストの構築（ドメインコントローラーへの昇格）
# ※実行時にDSRM（ディレクトリサービス復元モード）パスワードの入力が求められます
Install-ADDSForest `
    -CreateDnsDelegation:$false `
    -DatabasePath "C:\Windows\NTDS" `
    -DomainMode "WinThreshold" `
    -DomainName "linuxkoubou.local" `
    -DomainNetbiosName "LINUXKOUBOU" `
    -ForestMode "WinThreshold" `
    -InstallDns:$true `
    -LogPath "C:\Windows\NTDS" `
    -NoRebootOnCompletion:$false `
    -SysvolPath "C:\Windows\SYSVOL" `
    -Force:$true

実行後、サーバーが自動的に再起動します。再起動後、ログインプロンプトが LINUXKOUBOU\Administrator となっていれば、無事にドメインコントローラーへの昇格が完了しています。

4. 冗長化設計：FSMO（操作マスター）とマルチマスターのキモ

ADDSは基本的にどのドメインコントローラー（DC）からでもユーザーパスワードの変更やオブジェクトの追加が可能な「マルチマスター」アーキテクチャです。しかし、一部の特殊な操作（スキーマの変更やドメインの追加など）は、ネットワーク内で競合が発生すると致命的なデータベース破損を招きます。これを防ぐために、特定のDCだけが実行権限を持つFSMO（Flexible Single Master Operations）という仕組みがあります。

4-1. 5つのFSMOロールとその配置戦略

FSMOは以下の5つの役割に分かれています。フォレスト全体で1つしか存在しない役割と、各ドメインごとに1つ存在する役割があります。

FSMOロール名	スコープ	役割の解説（Linuxエンジニア向け）
スキーママスター	フォレスト全体で1台	ADのデータベース構造（RDBMSのテーブル定義のようなもの）を変更する権限。Exchange Server等の導入時にスキーマ拡張を行う際、このマスターがダウンしていると拡張に失敗します。
ドメイン名前付けマスター	フォレスト全体で1台	フォレスト内に新しいドメインを追加・削除する権限を管理します。日常業務ではほとんど使われません。
PDCエミュレーター	ドメインごとに1台	【最重要】パスワード変更の最優先処理、アカウントロックアウトの判定、ドメイン全体のNTP（時刻同期）のルートとなる、最も負荷のかかる役割です。
RIDマスター	ドメインごとに1台	ユーザーやグループを作成する際に割り当てられる一意のID（SID）のプールを、各DCに払い出す役割です。枯渇すると新規ユーザーが作成できなくなります。
インフラストラクチャマスター	ドメインごとに1台	複数ドメイン環境において、他ドメインのオブジェクト（グループメンバーなど）の参照情報を更新します。単一ドメイン環境では気にする必要はありません。

最初の1台目（DC01）を構築した時点では、これら5つの役割すべてがDC01に集中しています。2台目（DC02）を構築して冗長化を図る際、負荷分散と障害耐性の観点から、「PDCエミュレーターなどの重要なFSMOロールは高性能なDCに寄せる」「DC01がダウンした際は、手動（PowerShellの Move-ADDirectoryServerOperationMasterRole コマンド等）でDC02にFSMOを強制転送（Seize）する運用手順を確立しておく」ことがベストプラクティスとなります。

4-2. グローバルカタログ（GC）の役割

FSMOと並んで重要な概念が「グローバルカタログ（GC）」です。GCは、フォレスト内のすべてのオブジェクトの「検索用インデックス（キャッシュ）」を持つ機能です。
M365（Entra ID）と連携するハイブリッド環境や、Exchangeサーバーをオンプレミスで運用する環境では、ユーザーの検索処理が大量に発生します。そのため、基本的には「すべてのドメインコントローラーにGCの役割を持たせる」のが現代のエンタープライズ設計の定石です（上記PowerShellの構築手順では、デフォルトでGCが有効になります）。

5. M365連携のための最重要設定：UPNサフィックスの追加

ADDSの構築が完了し、ユーザーを作成していく前に、M365連携を前提とするLinuxエンジニアが絶対に知っておくべきトラップがあります。それが「UPN（User Principal Name）」の設定です。

今回、内部のADドメイン名を linuxkoubou.local として構築しました。したがって、作成したユーザーのログオン名は taro@linuxkoubou.local となります。
しかし、M365（Entra ID）などのパブリッククラウドは、インターネット上で名前解決できない .local などのプライベートドメインを認証IDとして受け付けません。M365上のメールアドレス（例：taro@linuxkoubou.com）と、オンプレミスのADユーザーを安全に同期させるためには、AD側にパブリックドメインと同じ「UPNサフィックス」を追加登録する必要があります。

# Active Directoryドメインと信頼関係のモジュールを使用してUPNサフィックスを追加
Get-ADForest | Set-ADForest -UPNSuffixes @{Add="linuxkoubou.com"}

この設定を行うことで、ユーザー作成時に @linuxkoubou.com をドロップダウンから選択（またはCLIで指定）できるようになります。このUPNが、Entra ID側のユーザー名（メールアドレス）と一致することで、第1回で解説したADFSによる「SAMLトークンの受け渡し（SSO連携）」が初めてシームレスに機能するのです。

6. 第2回の総まとめと次回の予告

本記事では、M365ハイブリッド認証のバックエンドとなるWindows Server 2025のActive Directory (ADDS) について、Linuxエンジニアの視点からアーキテクチャの紐解きと、PowerShellを用いたCUI構築手法、そしてFSMO等の冗長化設計を解説しました。

「Active Directoryはレガシーだ」と誤解されることもありますが、KerberosとLDAPを洗練された形で統合し、M365のEntra IDと強固に同期できるADDSは、現在のエンタープライズインフラにおいて依然として最強のIdentity基盤です。インフラエンジニアとして、Linuxの構成管理（Ansible）スキルとWindows ServerのPowerShell（CLI）スキルを掛け合わせることで、GUIに頼らない「真のインフラのコード化（IaC）」が実現できます。

次回の【第3回】Windows Server 2025：ADFS（フェデレーションサーバー）の構築と証明書管理では、今回構築したADDSとM365（Entra ID）の間を取り持つ「トークン発行局」であるADFSサーバーの構築手順を解説します。SAML認証のキモとなるSSL/TLS証明書の管理と、Linuxエンジニアが得意とする暗号化技術の知識がフルに活きる領域です。お楽しみに！