Windows Server 2019でAD DSを導入してドメイン コントローラーに昇格した直後、グループ ポリシー エディターで「セキュリティの設定」が見えず、パスワード複雑さを変更できないと感じることがあります。原因と正しい設定場所、確認方法までまとめます。
よくある症状：AD DSインストール後に「セキュリティの設定」が消えたように見える
代表的な相談は次のパターンです。
- Windows Server 2019 Datacenter に Active Directory ドメイン サービス（AD DS）を追加して、ドメイン コントローラー（DC）へ昇格した
- gpedit.msc（ローカル グループ ポリシー エディター）を開いたら、コンピューターの構成 → Windows の設定 → セキュリティの設定 が見当たらない／期待した場所にない
- ユーザーのパスワード複雑さの要件（複雑さ、最小文字数、有効期限など）を変更したいができない
結論から言うと、「設定が壊れた」「Windowsの不具合」よりも、設定すべき場所（ローカル→ドメイン）が変わったことが原因であるケースが大半です。
結論：ローカル グループ ポリシーではなく「ドメインのGPO」を編集する
サーバーがDCになると、ドメイン全体のセキュリティを一貫して管理するために、重要なポリシー（特にパスワードポリシー）はドメインのグループ ポリシー オブジェクト（GPO）で管理するのが基本になります。
| ツール | 開くコマンド | 主な用途 | パスワード複雑さの変更 |
|---|---|---|---|
| ローカル グループ ポリシー エディター | gpedit.msc | 単体PC/メンバーサーバーのローカル設定 | DCでは基本的に運用対象外（反映しても意味が薄い） |
| ローカル セキュリティ ポリシー | secpol.msc | ローカルの監査やユーザー権利など | DCのドメインアカウントにはドメイン側が優先 |
| グループ ポリシー管理 | gpmc.msc | ドメインGPOの作成・リンク・編集・結果確認 | ここで変更する（推奨） |
| PowerShell（ADモジュール） | Get-ADDefaultDomainPasswordPolicy | 現在のドメイン パスワードポリシー確認 | 確認・運用自動化に便利 |
また、GPMCでGPOを編集する場合は、ツリーが「コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定」という並びになります。
「ポリシー」の下にある点が、ローカル（gpedit）と見え方が違うため、「セキュリティの設定が消えた」と誤解しやすいポイントです。
なぜこうなる？ドメイン コントローラーでは“ドメインのルール”が優先される
DCは、ドメイン内ユーザーの認証（ログオン）やパスワード変更の判断を行う中枢です。DCに昇格すると、次のような事情でローカル設定よりドメイン設定が前提になります。
- ドメインユーザーのパスワードはローカルSAMではなくActive Directory（AD）で一元管理される
- 「パスワードの複雑さ」「最小文字数」「有効期限」「ロックアウト」などは、ドメイン全体のセキュリティポリシーとして統一されるべき
- そのため、DC上でローカルポリシーを触っても、実務上はドメインのポリシーに上書きされる（または効かない）
つまり、「セキュリティの設定が消えた」のではなく、ドメインコントローラーになったことで“操作すべき管理ポイント”が変わったと捉えるのが正解です。
手順：既定のドメイン ポリシーでパスワードポリシーを変更する
最も確実で、現場で迷いにくい手順です。作業はドメイン管理者（Domain Admins）相当の権限で行うのが安全です。
グループ ポリシー管理コンソール（GPMC）を開く
- 「サーバー マネージャー」から、またはファイル名を指定して実行で
gpmc.mscを実行します。 - 左ペインで フォレスト → ドメイン →（対象ドメイン名） を展開します。
既定のドメイン ポリシーを編集する
- 「既定のドメイン ポリシー（Default Domain Policy）」を右クリックし、「編集」を選択します。
- エディターで、次の順に展開します。
コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → アカウント ポリシー → パスワード ポリシー
必要な項目を変更して適用する
たとえば「パスワードは複雑さの要件を満たす必要がある」を変更したい場合は、該当項目を開いて「有効／無効」を選択します。ほかにも、最小文字数、履歴、最大/最小パスワード有効期間などを同じ画面で調整できます。
| 項目 | 何が変わるか | 実務での注意点 |
|---|---|---|
| パスワードは複雑さの要件を満たす必要がある | 大文字/小文字/数字/記号の組み合わせなどの要件がかかる | 無効化すると総当たり・辞書攻撃に弱くなるため、他の防御（MFA等）とセットで検討 |
| 最小パスワード長 | ユーザーが設定できる最短文字数 | 短すぎると突破されやすい。運用上の妥協でも10〜12以上が目安になりやすい |
| パスワードの履歴を記録する | 過去のパスワード再利用を制限 | 短い履歴だと“回して戻す”が可能。長すぎるとヘルプデスク負荷が増える |
| パスワードの有効期間（最大） | 定期変更の頻度 | 頻繁すぎると使い回し誘発。組織方針・監査要件と合わせて決める |
| 暗号化を元に戻せる形式でパスワードを保存する | 復号可能な形式で保存（実質的に平文に近い） | 通常は無効が基本。古いシステム互換のために例外的に使う |
「既定のドメイン ポリシー」と「Default Domain Controllers Policy」は別物
同じ“既定”でも役割が違うため、ここで迷うと設定場所を誤りがちです。
| GPO名 | リンク先（ざっくり） | 主な対象 | パスワードポリシーの場所として適切？ |
|---|---|---|---|
| 既定のドメイン ポリシー（Default Domain Policy） | ドメイン ルート | ドメイン全体（ドメインユーザー/コンピューター） | 適切（ドメインの基本パスワードポリシーはここ） |
| Default Domain Controllers Policy | Domain Controllers OU | DCだけ | 原則不適切（DC向け監査や権利割り当て等が中心） |
「Default Domain Controllers Policy」だけを編集していると、意図した“ドメインユーザーのパスワード要件”が変わらない、という状況になりやすいので注意してください。
変更が反映されたか確認する（GUIとPowerShellの両方）
設定を変えたら、「ちゃんと効いたか」を確認しておくとトラブルが激減します。特に複数DCがある環境では、編集したDCと認証に使われたDCが違うだけで結果が変わることがあります。
PowerShellでドメイン既定のパスワードポリシーを確認する
ドメイン コントローラー（またはRSAT導入済み端末）で、次のコマンドが便利です。
Import-Module ActiveDirectory
Get-ADDefaultDomainPasswordPolicy出力の中で、MinPasswordLength、PasswordHistoryCount、ComplexityEnabled、MaxPasswordAgeなどを確認できます。
ユーザー単位の実効ポリシー（PSOがある場合）を確認する
後述するFine-Grained Password Policy（PSO）を使っていると、ユーザーによって実効値が変わります。その場合は以下で“そのユーザーに効いているルール”を確認できます。
Get-ADUserResultantPasswordPolicy -Identity ユーザー名GPMCの「グループ ポリシー結果」で適用状況を確認する
- GPMCで対象のコンピューター/ユーザーの「グループ ポリシー結果」を実行すると、どのGPOが適用されたかが一覧で見られます。
- 「パスワードポリシー」自体はドメインルートの優先順位が効くため、ドメインにリンクされたGPOの優先度がポイントになります。
それでも見えない・編集できないときのチェックリスト
「場所は分かったのに、まだおかしい」という場合は、次を順に潰すと原因が見つかりやすいです。
GPMC（グループ ポリシー管理）が入っているか
DCでも稀に管理ツールが外れていることがあります。サーバー マネージャーの「機能」からグループ ポリシー管理が入っているか確認してください。PowerShellなら次でも確認・導入できます。
Get-WindowsFeature GPMC
Install-WindowsFeature GPMC権限（編集権限）があるアカウントで操作しているか
- Domain Admins（またはGPO編集を委任されたグループ）であるか
- UACの影響を受けていないか（必要なら「管理者として実行」）
- GPOが読み取り専用になっていないか
編集している“ドメイン”が正しいか（複数ドメイン/複数フォレスト）
テスト用ドメインや検証フォレストがある環境では、別ドメインの既定ポリシーを編集していたという単純な見間違いも起きます。GPMCのツリー上部のドメイン名を再確認してください。
複数GPOがドメイン ルートにリンクされていないか
パスワードポリシーは「OUにリンクしたGPOで上書き」はできず、ドメイン ルートにリンクされたGPOのうち、優先度が高いものが勝ちます。
既定のドメイン ポリシー以外に、ドメイン ルートへリンクしたGPOがあり、そこにパスワード設定が入っていると、期待と違う挙動になります。
| 状況 | 起きやすい勘違い | 対処 |
|---|---|---|
| OUに「強いセキュリティGPO」をリンクした | OU配下だけパスワードが厳しくなると思った | パスワード要件はOU GPOでは分けられない。分けたい場合はPSOを使う |
| ドメイン ルートに複数GPOがリンク | 既定のドメイン ポリシーを変えたのに効かない | リンク順序（優先度）を確認し、意図したGPOが最優先になるよう整理 |
| Default Domain Controllers Policyを編集 | DC用だから“ドメイン全体”に効くと思った | ドメインユーザーのパスワード要件は既定のドメイン ポリシー側へ |
複数DC環境ならレプリケーションを疑う
複数DCがある場合、GPO（SYSVOL）やADの設定が行き渡っていないと、ユーザーが参照するDCによって結果が揃いません。以下は切り分けに使われやすい代表例です。
repadmin /replsummary
dcdiag /vエラーが出る場合は、DNS、サイト/サブネット、時刻同期、SYSVOLの複製（DFSR）など、基盤側の問題を先に解消します。
応用：部署やアカウント種別ごとにパスワード要件を分けたいならPSOを使う
「一般ユーザーは12文字、特権管理者は16文字、サービスアカウントは変更頻度を別にしたい」など、現場では“差を付けたい”ニーズが出ます。
しかしGPOのパスワードポリシーではOU単位の分離ができません。この要件を満たすのが、Fine-Grained Password Policy（FGPP）、通称PSO（Password Settings Object）です。
| やりたいこと | GPOだけで可能？ | 推奨アプローチ |
|---|---|---|
| ドメイン全体で同じ要件にする | 可能 | 既定のドメイン ポリシー（またはドメイン ルートGPO） |
| OU（部署）ごとに要件を変える | 不可 | PSO（FGPP）でユーザー/グループ単位に割り当て |
| 特定グループ（管理者だけ）を厳しくする | 不可 | PSO（FGPP）を管理者グループへ適用 |
PSOは「Active Directory 管理センター（ADAC）」からGUIでも作成できますし、PowerShellでも運用できます。まずはドメイン既定を固めたうえで、“例外”が必要な範囲だけPSOで分離すると混乱しにくいです。
PSO運用で押さえておきたい優先順位
- ユーザーに複数のPSOが適用され得る場合、Precedence（優先度）が最も小さいものが選ばれます。
- ユーザーへ直接割り当てる方法と、グループへ割り当てる方法があり、設計を誤ると意図しないルールが効きます。
- 結果は
Get-ADUserResultantPasswordPolicyで必ず確認します。
運用のベストプラクティス：迷子にならないGPO設計のコツ
「今回の問題」を再発させないために、現場で効く運用ポイントをまとめます。
- 既定のドメイン ポリシーは“必要最小限”にする（特にパスワード/ロックアウト/一部の基本設定だけ）。それ以外の設定は別GPOに分離すると後から追いやすい。
- パスワードポリシーを変更するなら、変更理由・変更日・影響範囲を必ず記録する（監査・引き継ぎで効きます）。
- 本番変更前に、テストユーザーでパスワード変更が通るか、ロックアウトが適切に動くかを確認する。
- 要件を弱める場合は、MFA、条件付きアクセス、侵害パスワード対策、監査ログなど、他のコントロールで補う。
よくある質問
gpedit.mscで「セキュリティの設定」を触っても絶対に無意味ですか？
DCに昇格したサーバーで、ドメインユーザーのパスワード要件を変える目的であれば、基本的に意味がありません。ドメインの認証・パスワード判定はドメイン側のルールに従うため、GPMCでドメインGPO（既定のドメイン ポリシー）を編集するのが正解です。
ドメイン ルートに新しいGPOを作って、既定のドメイン ポリシーを触らない運用はあり？
ありです。むしろ「既定のドメイン ポリシーを極力いじりたくない」という方針の組織もあります。
その場合は、ドメイン ルートに専用のGPO（例：Domain Password Policy）を作成してリンクし、リンク順序で最優先にします。混在させると追跡しづらいので、どちらかに寄せるのがコツです。
クライアントPCでgpupdate /forceをしてもパスワード要件が変わらないのはなぜ？
パスワード要件は「ユーザーがパスワードを変更する時」「ログオン時」にDCが判断します。クライアント側の更新だけでは解決しない場合があるため、どのDCが判定しているか、複数DCならレプリケーションが揃っているかを合わせて確認してください。
まとめ：見えなくなったのではなく、設定すべき場所が変わった
- AD DS導入でDCになると、パスワード要件はローカルではなくドメインGPOで管理する
- 変更は gpmc.msc → 既定のドメイン ポリシー → パスワード ポリシー が基本
- OU単位で分けたい場合はGPOではなくPSO（FGPP）を検討する
コメント