Active Directory サーバー（ADサーバー）の構築手順を初心者にも分かり易く徹底解説

結論から言うと、Active Directory Domain Services（AD DS）の構築は、Server Managerでチェックを付ける作業より、事前設計が本体です。新しいフォレストを作るのか、既存ドメインへ追加ドメインコントローラーを入れるのかを最初に分け、DNS名、IP、機能レベル、DSRMパスワード、バックアップ、2台目のDC、管理権限を決めてから操作してください。昇格後に問題が出ても、AD DSロールを直接削除してはいけません。正式な降格手順で戻します。

この記事は、Windows Server 2025、2022、2019、2016で、新しいフォレストの最初の書き込み可能ドメインコントローラーを構築する流れを中心に解説します。既存の24枚の画像はWindows Server 2016の画面です。役割追加と構成ウィザードの大きな流れを確認する参考として残しますが、Server 2025／2022では文言、配置、選べる機能レベルが異なる場合があります。画像の値をそのまま本番へ入力せず、現在の公式画面と設計書を優先してください。

最初の判断：新規フォレストか追加DCか

状況	選ぶ構成	必要な主権限	重要な確認
組織にAD DSが存在しない	新しいフォレスト	対象サーバーのローカルAdministrator	ルートDNS名、将来の統合、2台目DC
既存ドメインの可用性を上げたい	既存ドメインへ追加DC	Domain Admins相当	DNS、サイト、複製、機能レベル
既存フォレストへ新ドメインを追加	子ドメインまたは新ドメインツリー	Enterprise Admins相当	本当にドメイン分割が必要か
支店で資格情報を限定したい	RODCを検討	設計に応じた委任	物理保護、パスワード複製ポリシー
短期検証だけ	隔離ラボ	ラボ内だけ	本番DNS・ネットワークと分離
Microsoft 365のIDだけ必要	Microsoft Entra IDも比較	クラウド側の役割	オンプレミスAD DSが本当に必要か

既存のドメインがあるのに「新しいフォレストを追加する」を選ぶと、同じ組織内に別の認証基盤を作ることになります。ユーザー、端末、グループポリシー、名前解決が自動で統合されるわけではありません。既存環境が少しでもある場合は、フォレスト管理者へ確認してから進めます。

構築前チェックリスト

項目	決める内容	未決定なら
OS	組織がサポートするServer 2025／2022／2019／2016	導入を止める
構成種別	新規フォレスト、追加DC、RODC	既存ADを調査
サーバー名	命名規則に沿う一意な名前	昇格前に確定
ルートDNS名	一意なFQDN。管理下の名前空間のサブドメイン	ネットワーク／ID担当と設計
IPとDNS	安定したアドレス、正しいDNSクライアント参照	ネットワーク担当へ確認
機能レベル	参加予定の全DC OSと必要機能に合う値	将来構成を棚卸し
DSRM	強い固有パスフレーズと安全な保管先	昇格しない
バックアップ	システム状態／フルサーバーと復旧担当	本番運用を開始しない
可用性	2台目DC、DNS、別ホスト／別障害領域	単一障害点を受容する期間を明記
管理	Tier 0専用アカウント、管理端末、パッチ、監視	通常業務アカウントを使わない

新しいルートドメイン名は単一ラベルにできません。「CORP」のような名前だけではなく、DNS形式のFQDNが必要です。また、Microsoftの公式導入資料は、新しい内部フォレストを外部公開サイトと完全に同じ名前にしないよう注意し、corp.contoso.comのような一意なサブドメインを例示しています。実環境では、自組織が所有・管理する名前空間の承認済みサブドメインを使います。

サーバーのWindows Update、時刻、イベントログ、ディスク空き容量、ネットワークを確認します。既存ドメインへ追加するDCは、先に既存DNSを参照して正常にドメインを解決できる必要があります。新規フォレストの1台目は、昇格後に自身がDNSを担う前提を含めて設定を確認します。一般の公開DNSだけを参照した状態でADの名前解決を運用しません。

手順1：AD DSサーバーロールを追加する

まずAD DSのバイナリと管理ツールを追加します。この工程だけではドメインコントローラーになりません。再起動の可能性があるため、業務サーバーで実行する場合は変更時間帯とコンソール接続を確保します。

1. 対象Windows Serverへローカル管理者としてサインインし、Server Managerを開きます。
2. 右上の「Manage」から「Add Roles and Features」を選びます。旧画面ではダッシュボードの「役割と機能の追加」からも開始できます。

3. 「Before you begin」で対象と前提を確認し、「Next」を選びます。

4. 「Role-based or feature-based installation」を選びます。Remote Desktop Services installationと取り違えません。

5. サーバープールから対象サーバーを選びます。名前とIPを再確認し、別サーバーへ誤投入しないようにします。

6. 「Active Directory Domain Services」を選びます。

7. 必要な管理ツールを追加する確認が出たら「Add Features」を選びます。PowerShellでロールだけを追加すると管理ツールが自動で入らない場合があるため、GUIツールを使う構成では含めます。

8. AD DSへチェックが付いたことを確認して進みます。

9. 追加機能画面では、設計書にない機能を「ついで」に入れません。DCは単一用途に近づけ、攻撃対象と保守負担を増やさないことが原則です。

10. AD DSの説明を読み、役割追加と昇格が別工程であることを確認します。

11. 確認ページで対象サーバー、AD DS、管理ツールを確認し、「Install」を選びます。自動再起動を許可するかは変更計画に従い、無人の本番サーバーで無条件に選びません。

インストール中はウィザードを閉じても処理が継続できますが、完了結果を確認します。失敗した場合はエラーを保存し、役割を再選択する前にWindows Update、ソース、再起動保留、ディスク、イベントログを確認します。

「Installation succeeded」を確認します。ここで閉じても、まだ新しいフォレストは作られていません。次の昇格工程へ進みます。

手順2：新しいフォレストの最初のDCへ昇格する

役割追加後、Server Managerの通知に「Promote this server to a domain controller」が表示されます。ここからは名前空間と認証基盤を作る不可逆性の高い工程です。入力前に設計書と承認を再確認します。

1. Server Manager右上の通知を開き、構成が必要なAD DSの通知を確認します。

2. 「Promote this server to a domain controller」を選びます。

3. 新規環境だけ「Add a new forest」を選び、承認済みのルートドメインFQDNを入力します。画像内の例示値を本番へコピーしません。

4. フォレスト／ドメイン機能レベルを選びます。最初のDCはGlobal Catalogとなり、RODCにはできません。DNS Serverを確認し、強いDSRMパスワードを入力して承認済み保管庫へ記録します。

DSRMパスワードは通常のドメインAdministratorパスワードと同じにしません。障害時にオフライン復旧へ使うTier 0資格情報です。チケット、メール、スクリプト、チャットへ平文で残さず、利用手順とともに厳格に保管します。

5. DNS Optionsを確認します。親DNSゾーンへ委任を作れない新規フォレストでは警告が出ることがありますが、警告文と設計上の受容理由を記録します。説明できない警告は無視しません。

6. NetBIOSドメイン名の自動候補を確認します。既存の名前と競合しないか、15文字制約や古いアプリの要件を確認します。

7. ADデータベース、ログ、SYSVOLのパスを確認します。小規模構成で既定値を使う場合も、バックアップ、容量、セキュリティ、性能要件に合う理由を記録します。

8. Review Optionsで、フォレスト名、NetBIOS名、機能レベル、DNS、パスを設計書と照合します。必要なら構成をPowerShellスクリプトとして表示し、変更記録へ添付しますが、秘密情報は含めません。

9. Prerequisites Checkを実行し、各警告とエラーを読みます。エラー、名前解決不良、資格情報不足、説明できない警告があれば「Install」を押しません。
10. 合格条件を満たしたら「Install」を選びます。処理後は自動再起動されるため、コンソール接続と再サインイン用資格情報を用意します。

再起動後は、ローカルアカウントではなく作成したドメインの管理アカウントでサインインします。最初に使った組み込みAdministratorは初期構築と障害復旧へ限定し、日常管理用の委任アカウントとTier 0管理端末を準備します。

PowerShellで構築する場合

Microsoft LearnはPowerShellによるAD DS導入も公式手順として案内しています。自動化は再現性がありますが、ドメイン名や資格情報を記事の固定値で実行しないことが重要です。以下は承認済みFQDNを対話入力し、DSRMパスワードを安全なプロンプトで入力する流れです。

1. 管理者PowerShellでAD DSロールと管理ツールを追加します。

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

2. 設計書で承認されたFQDNを入力し、新しいフォレストを作成します。

$DomainName = Read-Host "承認済みのフォレストルートFQDN"
Install-ADDSForest -DomainName $DomainName -InstallDNS

3. 表示される構成を確認し、DSRMパスワードをマスクされたプロンプトへ入力します。コマンドライン引数、履歴、平文ファイルへパスワードを書きません。
4. 前提条件チェックを読み、問題がなければ昇格と再起動を完了します。
5. 同じコマンドを別サーバーへ再実行する前に、新規フォレストではなく追加DC用のInstall-ADDSDomainControllerが必要かを確認します。

無人実行で-Confirm:$falseを付けると確認を省略できますが、初心者向けの初回本番構築では推奨しません。まず対話手順で内容と警告を理解し、レビュー済み自動化だけを変更管理下で使います。

構築後の確認

「Active Directory Users and Computers」が開いただけでは合格ではありません。ドメイン情報、DNS、SYSVOL、NETLOGON、イベント、時刻、追加DCがある場合の複製を確認します。

旧画像ではシステム画面にドメイン名が表示されています。この画像のtest.co.jpは過去の例であり、現在の本番命名例ではありません。

Active Directory Users and Computersを開き、ドメインと既定コンテナーが見えることを確認します。ただし、ツールが開くこととディレクトリ全体の正常性は別です。

Group Policy Managementも起動を確認します。最初からDefault Domain PolicyやDefault Domain Controllers Policyを大量編集せず、目的別の新しいGPOと変更承認を使います。

1. PowerShellでフォレスト名、ドメイン名、機能レベルを確認します。

Get-ADForest
Get-ADDomain

2. ローカルDCの基本診断を実行します。

dcdiag

3. DNSを詳細確認します。出力が長いため、変更記録へ保存し、失敗したテスト名を確認します。

dcdiag /test:DNS /v

4. SYSVOLとNETLOGON共有が存在し、ドメインクライアントから正しく名前解決できることを確認します。
5. Event ViewerのDirectory Service、DNS Server、DFS Replication、Systemを確認します。警告を件数だけでなく内容と時刻で判断します。
6. Windows TimeのSourceを確認します。新規フォレストのPDCエミュレーターは、組織の時刻設計に基づき外部または内部の権威ある時刻源へ設定します。
7. 追加DCがある場合はrepadmin /replsummaryなどで複製を確認します。1台目だけなら複製先がないため、2台目の導入計画を進めます。

確認領域	合格条件	不合格時
ドメイン情報	承認済みFQDNと機能レベル	利用開始を止める
dcdiag	主要テストに説明不能な失敗なし	テスト名ごとに原因調査
DNS	ゾーン、SRV、動的登録、名前解決が正常	クライアント参加を止める
SYSVOL／NETLOGON	共有が存在しアクセス可能	GPO配布を開始しない
イベント	重大・反復エラーなし	原因解消後に再診断
時刻	PDCと階層のSourceが設計どおり	認証展開を止める
バックアップ	システム状態またはフルサーバーの取得と復元担当	本番扱いにしない

2台目のDCと安全な運用

AD DSは1台目から構築できますが、本番を単一DCのまま運用すると、OS障害、ホスト障害、保守再起動、DNS障害で認証基盤全体が止まります。2台目の書き込み可能DCとDNSを、可能なら別の物理ホストや障害領域へ配置します。最初のDCと同じスナップショット、同じストレージ、同じ電源だけに置けば、台数が増えても共通障害を避けられません。

ドメインコントローラーはTier 0です。一般ユーザーのWeb閲覧、メール、Office作業、ファイルサーバー、業務アプリを同居させません。MicrosoftはDC上でWebブラウザーを使わず、インターネットアクセスを厳しく制御し、対応可能ならServer Coreと専用のセキュア管理端末を検討するよう案内しています。

• 組み込みAdministratorは初期構築と復旧へ限定します。
• Domain Admins／Enterprise Adminsを通常業務アカウントへ恒久付与しません。
• Tier 0管理アカウントをワークステーションやメールへ使いません。
• DCのパッチ、EDR、監視、バックアップを一般サーバーと分離して管理します。
• フルサーバーまたはシステム状態バックアップと、フォレスト復旧手順を準備します。
• 仮想マシンのチェックポイントだけをADバックアップの代わりにしません。

失敗したときの分岐

AD DSロールのインストールに失敗する

再実行を繰り返す前に、Windows Update、再起動保留、役割ソース、ディスク、対象サーバー、権限、Server ManagerとSystemイベントを確認します。この段階ではまだDCではないため、原因を解消できなければ役割追加を中止し、Server Managerから不要なロールを削除できます。

「Promote this server」が表示されない

AD DSロールのインストール結果、Server Managerの更新、対象サーバー、再起動保留を確認します。役割が別サーバーへ入っていないかも見直します。旧来のdcpromo画面を探すのではなく、現行のAD DS Configuration WizardまたはADDSDeployment PowerShellを使います。

前提条件チェックでDNS delegation警告が出る

新規フォレストの親DNSに委任を作れない場合など、設計上想定される警告はあります。ただし「警告だから無視」ではありません。親ゾーンを誰が管理するか、外部から名前解決させるか、内部クライアントがどのDNSを参照するかを確認し、受容理由を記録します。

昇格後にDNSやdcdiagが失敗する

新規ユーザーやPCを参加させる前に作業を止めます。DNSクライアント設定、AD統合ゾーン、SRVレコード、Netlogon、SYSVOL、時刻、イベントを確認します。公開DNSを追加して一時的にWebだけ見える状態にしてもAD DNSの問題は解決しません。原因が分からなければMicrosoft SupportまたはAD担当者へ診断結果を引き継ぎます。

追加DCの複製が失敗する

DNS、時刻、サイト、ファイアウォール、RPC、認証、既存DCの健全性を確認します。失敗した追加DCへ利用者を向けず、FSMOやDNSを移動しません。複製できていないDCを強制降格すると、そのDCだけにある未複製変更を失うため、まず通常の通信・名前解決を修復します。

元に戻す方法

現在の段階	戻し方	禁止事項
ロール追加前	ウィザードを中止	なし
ロール追加済み・未昇格	Server ManagerでAD DSロールを削除	関連機能を無差別に削除しない
追加DCへ昇格済み	健全性確認後に正式降格	DISMで役割を直接削除しない
新規フォレストの唯一のDC	ドメイン消滅を理解した計画的降格	承認・バックアップなしで実行しない
他DCへ連絡不能	通信修復を優先。強制降格は最終手段	孤立メタデータを放置しない

1. 昇格前なら、Server Managerの「Remove Roles and Features」でAD DSロールを削除できます。
2. 昇格後は、Server ManagerでAD DSロールを外そうとすると降格用の検証画面へ進みます。まず「Demote this domain controller」を実行します。
3. 追加DCの降格前に、FSMO、DNS、Global Catalog、サイト、クライアント参照、複製、システム状態バックアップを確認します。
4. 最後のDCを降格すると、そのドメインが削除されます。フォレスト最後のドメインならフォレスト全体がなくなります。責任者承認とデータ保全なしでは進めません。
5. PowerShellではUninstall-ADDSDomainControllerを使います。対話実行ではローカルAdministratorパスワードを安全なプロンプトへ入力します。
6. 降格後に再起動し、その後で不要なAD DSロールバイナリを削除します。
7. 強制降格を使った場合は、残存DCでメタデータ、DNS、FSMO、未複製変更を直ちに処理する必要があります。通常のロールバック手段として選びません。

DCの復旧は、一般サーバーの「スナップショットへ戻す」と同じ感覚で行いません。Microsoftのフォレスト復旧ガイドに沿って、既知の正常なシステム状態またはフルサーバーバックアップ、復旧順序、DNS、SYSVOL、FSMO、資格情報リセットを含む計画を用意します。

よくある質問

Windows Server 2025でも画像どおりですか？

役割追加から構成ウィザードへ進む大枠は共通ですが、画面、文言、機能レベル、セキュリティ機能は異なる場合があります。画像はServer 2016の参考です。Server 2025／2022では現在のMicrosoft Learnと実画面を優先してください。

ドメイン名は会社のWebサイトと同じでよいですか？

新しいフォレストを外部公開DNS名と完全に同一にすることは避け、管理下の名前空間の一意なサブドメインを設計します。単一ラベル名も使えません。すでにADがある場合は既存の命名を変更せず、フォレスト管理者へ確認します。

最初からDCは2台必要ですか？

新規フォレストは1台目から作成できます。ただし本番可用性、保守、DNSのため、2台目を別障害領域へ早期に追加する計画が必要です。「2台ないとインストールできない」ではなく、「1台のままでは単一障害点」という意味です。

DSRMパスワードを忘れたらドメインAdministratorで代用できますか？

DSRMはディレクトリ復旧時に使う別の高価値資格情報です。通常のドメインサインインとは目的が異なります。構築時に強い固有パスフレーズを設定し、組織の秘密管理と復旧手順に従って保管・定期確認してください。

DCへファイルサーバーや業務アプリも入れてよいですか？

原則として分離します。DCが侵害されるとフォレスト全体の信頼性に影響し、追加アプリは攻撃面、再起動、バックアップ、復旧を複雑にします。Tier 0の単一用途サーバーとして扱います。

前提条件の警告があってもInstallボタンが押せれば進めてよいですか？

いいえ。DNS委任のように設計上受容できる警告はありますが、内容を理解して記録する必要があります。名前解決、権限、互換性、ネットワークの警告を無視すると、昇格後に認証基盤が不安定になります。

公式資料

• Microsoft Learn：Install Active Directory Domain Services
• Microsoft Learn：AD DS configuration wizard page descriptions
• Microsoft Learn：Create an AD DS forest root domain with Server Manager
• Microsoft Learn：dcdiag
• Microsoft Learn：Active Directory forest recovery procedures
• Microsoft Learn：Securing domain controllers against attack
• Microsoft Learn：Demote domain controllers and domains
• Microsoft Learn：AD DS tier model for privileged access

まとめ

安全なAD DS構築は、ロール追加、昇格、診断、冗長化、バックアップ、正式な降格までを一つの作業として設計することです。新規フォレストか追加DCかを分け、一意なFQDN、安定したIPとDNS、参加DCに合う機能レベル、固有のDSRMパスワードを決めます。Server ManagerでAD DSロールを追加したあと、新規フォレストへ昇格し、dcdiag、DNS、SYSVOL、NETLOGON、イベント、時刻を検証します。1台で動いた時点を完成とせず、別障害領域の2台目DC、システム状態／フルサーバーバックアップ、Tier 0専用管理を整えてください。問題時はロールを直接削除せず、段階に応じた正式な降格と復旧計画で戻します。