Active Directoryで「どのパスワードポリシーが最終的に効くのか」は、実はシンプルです。ドメインユーザーにはまずドメイン ルートにリンクされたアカウントポリシーが土台として効き、対象ユーザーにきめ細かなパスワードポリシー（Fine-Grained Password Policy、以下FGPP）があれば、そのユーザーにはFGPPが優先されます。さらに複数のFGPPが競合する場合は、ユーザーへの直接適用がグループ経由より優先され、そのうえでPrecedence は数値が小さいほうが強いのがルールです。OUにリンクしたGPOのパスワード設定で、ドメインユーザーの認証ルールを部署別に変えることはできません。
この違いを曖昧なまま運用すると、「営業部OUにGPOを当てたのに効かない」「管理者用PSOより例外ユーザー用PSOのほうがなぜか優先された」といった混乱が起きやすくなります。ここでは、きめ細かなパスワードポリシーの優先順位を判断表つきで整理し、設計のコツ、確認手順、FGPPで足りない場合の代替策まで、実務でそのまま使える形でまとめます。
最初に結論だけ押さえる
ドメインユーザーのパスワードポリシーを判断するときは、次の順番で見れば迷いません。
| 状況 | 実際に効くもの | 覚えておくポイント |
|---|---|---|
| FGPPが1つも適用されていない | ドメイン ルートにリンクされたGPOのAccount Policies | ドメインユーザーの基準はここ |
| ユーザーにFGPPが直接適用されている | その直接適用FGPP | グループ経由より強い |
| 複数のFGPPがグループ経由で適用される | Precedenceが最小のFGPP | 数字が小さいほうが優先 |
| 直接適用FGPPとグループ適用FGPPが両方ある | 直接適用FGPP | Precedenceの大小より先に「直接適用」が勝つ |
| 同じPrecedenceのFGPPが複数ある | objectGUIDの小さいPSOが結果になる | ただし通常は重複設計を避けるべき |
特に重要なのは、Precedenceの数値だけで全順位が決まるわけではないことです。まず「直接適用か、グループ経由か」で勝敗が決まり、その後にPrecedenceを比べます。ここを逆に理解していると、想定と違う結果になりやすいです。
まず整理したい、パスワードポリシーの3つの置き場所
ドメイン全体のアカウントポリシー
ドメインユーザーに対する基本のパスワードポリシーは、ドメイン ルートにリンクされたGPOのAccount Policiesから決まります。実務ではDefault Domain Policyにまとめることが多いですが、ドメイン ルートに別GPOをリンクして上位に置く設計も可能です。いずれにしても、ドメインユーザー向けの基準はOUではなくドメイン ルート側で決まると理解しておくのが大切です。
きめ細かなパスワードポリシー（FGPP / PSO）
FGPPは、Password Settings Object（PSO）として管理される仕組みで、ユーザー単位またはグローバル セキュリティ グループ単位で、ドメイン既定より細かいパスワード要件やロックアウト要件を適用できます。全社共通ルールはドメイン側で維持しつつ、特権アカウントだけ強化したいときに向いています。
OUにリンクしたGPOのパスワード設定
ここが一番誤解されやすい点です。OUにリンクしたGPOのAccount Policiesは、そのOU配下のメンバーサーバーやクライアントのローカルアカウントには影響しますが、ドメインユーザーの認証ルールを部署別に変える方法にはなりません。つまり、「営業部OUにだけ最小文字数12を適用したい」という要件を、OUリンクGPOだけで実現することはできません。
きめ細かなパスワードポリシーの優先順位はこう決まる
FGPPがなければ、ドメイン ルートのポリシーが効く
対象ユーザーにFGPPが一切関連付けられていなければ、そのユーザーにはドメイン ルートのアカウントポリシーが適用されます。最初に確認すべきなのは「FGPPがあるかどうか」で、これが分かるだけでも切り分けがかなり速くなります。
直接適用FGPPは、グループ経由FGPPより優先される
Microsoftの仕様では、複数のPSOがユーザーに関連付いている場合、そのユーザーに直接適用されたPSOが結果のPSOになるとされています。つまり、グループ経由のPSOにPrecedence 1を付けても、ユーザーに直接適用されたPSOが存在すれば、まずそちらが優先されます。
たとえば、Privileged-Users グループに紐づくPSOが Precedence 10 で、あるユーザーに直接紐づく例外PSOが Precedence 500 だったとしても、勝つのは直接適用PSOです。Precedenceより前に、適用経路の違いが判定されると覚えると、挙動を説明しやすくなります。
複数FGPPが競合したら、Precedenceの小さい値が勝つ
直接適用同士、またはグループ経由同士で複数のPSOが競合した場合は、msDS-PasswordSettingsPrecedence の値が最も小さいPSOが結果になります。数値が大きいほど優先ではなく、小さいほど優先です。ここは運用中に逆に覚えてしまう人が多いので注意が必要です。
同じPrecedenceにすると、最終的にはGUID順になる
仕様上、同じPrecedenceのPSOが複数適用候補になった場合は、objectGUID が小さいPSOが結果になります。ただし、PowerShellの New-ADFineGrainedPasswordPolicy では、すでに使われているPrecedenceを指定するとエラーになるため、通常運用では同値競合を作らない設計にしておくのが安全です。
よくある勘違い
「OUごとに別パスワードポリシーを作れる」は半分だけ正しい
OUにリンクしたGPOで変えられるのは、そのOU内コンピューターのローカルアカウント側です。ドメインユーザーに対して「部署別のパスワードポリシー」をしたいなら、OUではなくFGPPを使います。Microsoftのドキュメントでも、FGPPはユーザーまたはグローバル セキュリティ グループに適用し、OUへは直接適用できないため、OU単位の発想で運用したい場合はシャドウグループを使う方法が案内されています。
「Precedenceが小さければ何にでも勝つ」は誤り
Precedenceが比較されるのは、あくまで複数候補のPSOが同じレイヤーで競合したときです。直接適用とグループ経由が競合しているなら、先に「直接適用」が勝ちます。ここを誤解したまま設計すると、例外用にユーザーへ直付けしたPSOが、想定以上に強く効いてしまいます。
「ADACで見えているPSOがそのまま実効値」とは限らない
ADACでは、ユーザーのプロパティに「直接関連付けられたパスワード設定」と「結果のパスワード設定」があります。前者は明示的な関連付けしか出ず、グループ経由の暗黙適用は見えません。実際にどのFGPPが効いているかを知りたいなら、結果のパスワード設定を見るのが正解です。
どんな運用に向いているか
全社共通ルールはドメイン ルートのGPOで管理する
最小文字数、履歴、複雑さ、ロックアウトなど、全社で統一したいルールはドメイン ルートのアカウントポリシーにまとめるのが基本です。ここを複数GPOに分散させると、リンク順や管理責任が分かりにくくなり、障害時の切り分けも遅くなります。
管理者・特権アカウントだけを強化したいならFGPP
Domain Admins相当、運用管理者、緊急用のブレークグラスアカウントなど、一部のユーザーだけ別基準にしたいときはFGPPが向いています。対象はグローバル セキュリティ グループでまとめると、メンバー変更だけで適用範囲を管理しやすくなります。
例外ユーザーへの直付けは「一時対応」に寄せる
仕様上はユーザーへPSOを直接適用できますが、例外が増えるほど、どのユーザーに何が効いているか追いにくくなります。直接適用は「移行期間だけ」「監査対応だけ」といった一時措置に寄せ、恒常運用はグループベースにしたほうが保守しやすいです。これは製品仕様というより、優先順位ルールを踏まえた運用設計上の判断です。
失敗しにくい設計ルール
Precedenceは飛び番で割り当てる
10, 20, 30 や 100, 200, 300 のように飛び番で管理しておくと、あとからPSOを追加しやすくなります。Precedenceは重複させず、数値が小さいほど強いというルールをチーム内で固定しておくと、レビューもしやすくなります。PowerShellの作成時にも重複Precedenceはエラーになりやすいため、最初から命名規則と番号体系を決めておくのが無難です。
OUで考えず、グループで考える
「経理部のユーザーにだけ強いルールを適用したい」と考えた瞬間にOUへ寄せたくなりますが、ドメインユーザー向けにはFGPPの対象がOUではありません。部署・役割・特権区分ごとのグローバル セキュリティ グループを設計し、そこへPSOを結びつけるほうが、結果が読みやすく、異動や兼務にも対応しやすいです。
FGPPで変えられない領域もある
FGPPで調整できるのは、既定のドメインパスワードポリシーの設定とアカウントロックアウト設定です。一方で、KerberosポリシーはFGPPの対象ではありません。つまり、「特定ユーザーだけチケット有効期間も変えたい」といった要求は、FGPPの守備範囲ではありません。
実際に確認するときの手順
1. まずドメイン既定のポリシーを確認する
ドメインユーザーの土台になる設定は、PowerShellなら次のコマンドで確認できます。
Get-ADDefaultDomainPasswordPolicyこれで全社共通の基準が見えます。FGPPの切り分けを始める前に、ここが意図どおりかを先に見ておくと、問題の切り分けが速くなります。
2. 対象ユーザーに実効FGPPがあるか確認する
ユーザーに対して、実際にどのFGPPが結果として適用されているかは、次のコマンドで確認できます。
Get-ADUserResultantPasswordPolicy -Identity user01GUIならADACのユーザープロパティにある「結果のパスワード設定」でも確認できます。設定したPSOではなく、結果として効いているPSOを見ることが重要です。
3. PSO一覧と適用先を洗い出す
どのPSOが存在し、どこへ紐づいているかを整理するときは、PSO本体と適用先の両方を見ます。
Get-ADFineGrainedPasswordPolicy -Filter *
Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-Admins"これで「PSOそのものの設定」と「どのユーザー・グループに関連付いているか」を分けて確認できます。設定値だけ見て安心しないことが大切です。
4. 想定どおり効かないときは、OU前提で考えていないか見直す
「OUにGPOをリンクしたのに効かない」という症状が出たら、まず対象がドメインユーザーなのか、ローカルアカウントなのかを確認してください。ドメインユーザーなら、見るべき場所はOUリンクGPOではなく、ドメイン ルートのアカウントポリシーとFGPPです。
FGPPで足りない場合の代替策
禁止語や弱い単語を防ぎたいなら、Microsoft Entra Password Protectionを検討する
FGPPは長さや履歴、複雑さ、ロックアウトには向いていますが、「会社名を含むパスワードは不可」「よくある弱い単語は拒否したい」といった内容ベースの制御には限界があります。こうした要件には、オンプレミスAD DSでも利用できるMicrosoft Entra Password Protectionが候補になります。監査モードから始められるため、いきなり運用を止めたくない環境でも導入しやすいです。
独自ルールを深く入れるなら、パスワードフィルターDLLという選択肢もある
さらに細かい独自判定が必要なら、ドメインコントローラーへパスワードフィルターDLLを登録する方法もあります。これは自由度が高い反面、実装・配布・検証の難易度も高く、設計や障害時の影響範囲をよく見て採用すべき手段です。FGPPはこうした追加フィルターの代替ではなく、補完関係として考えるのが安全です。
サービスアカウントなら、そもそもgMSAのほうが向くことがある
定期変更が面倒なサービスアカウントで悩んでいるなら、ユーザー型アカウントへFGPPを当てる前に、gMSAを使える構成か検討する価値があります。gMSAはWindows側でパスワード管理を自動化できるため、サービス用途では運用負荷を大きく下げられます。
迷ったら、この順で判断すれば外しにくい
まず、その要件が全社共通なのか、特定ユーザーや特定ロールだけなのかを切り分けます。全社共通ならドメイン ルートのアカウントポリシー、特定ロールならFGPPです。OU単位で考えたくなったら、一度立ち止まって「本当に必要なのはOUか、それともグループか」を見直すと、設計が崩れにくくなります。
そのうえで、実際の優先順位は次の3点だけ覚えれば十分です。FGPPがあればドメイン既定よりFGPPが優先、直接適用はグループ適用より優先、複数候補ならPrecedenceが小さいものが優先です。確認は Get-ADDefaultDomainPasswordPolicy と Get-ADUserResultantPasswordPolicy を起点にすれば、大半の切り分けは進められます。
次にやるべきことは、現在のPSO一覧と適用先を棚卸しし、直付けPSOが残っていないか、Precedenceが分かりやすく設計されているか、OU前提の誤った期待が混ざっていないかを確認することです。そこまで整理できれば、きめ細かなパスワードポリシーの優先順位で迷う場面はかなり減らせます。
コメント