「パスワードの複雑性要件、各端末で設定してます」——100台のPCがある現場でこれを聞くと、背筋が凍ります。
Active Directoryを使っているなら、パスワードポリシーはドメイン側で一元管理するのが基本です。しかし「とりあえずデフォルトのまま」「特権アカウントも一般ユーザーも同じ設定」という現場は少なくありません。
この記事では、ADのパスワードポリシーの仕組みと設計の考え方を、複雑性・有効期限・ロックアウトの3つの軸で整理します。設定値の根拠まで理解することで、「なんとなく設定した」から「守れる設計ができた」に変われます。
パスワードポリシーとは——ADで複雑性・有効期限・ロックアウトを一元管理する仕組み
パスワードポリシー(Password Policy) ドメイン参加端末のユーザーアカウントに対して、パスワードの複雑性・長さ・有効期限・ロックアウト条件を強制するActive Directoryの設定。
Active Directoryのパスワードポリシーは、ドメイン内のすべてのユーザーに対してパスワードのルールを強制する仕組みです。グループポリシー(GPO)を通じて適用され、端末ごとに設定する必要はありません。
設定できる主な項目は以下の通りです。
| 設定項目 | 概要 |
|---|---|
| パスワードの複雑性 | 大文字・小文字・数字・記号の組み合わせを要求 |
| パスワードの最小文字数 | 設定した文字数以上を要求 |
| パスワードの有効期限 | 一定期間での変更を強制 |
| パスワードの履歴 | 過去N回分の使い回しを禁止 |
| アカウントロックアウト | 失敗回数が閾値を超えたらアカウントをロック |
| ロックアウトのリセット時間 | ロックカウンターをリセットするまでの時間 |
ADのグループポリシーの基本的な仕組みについては「GPO設計入門」で詳しく解説しています。
デフォルトのパスワードポリシーはどこにある?

ドメインパスワードポリシー——Default Domain Policyの場所と確認方法
ADのパスワードポリシーは、Default Domain PolicyというGPOにデフォルトで格納されています。場所はグループポリシー管理エディター上で以下の階層です。
コンピューターの構成
└ Windowsの設定
└ セキュリティの設定
└ アカウントポリシー
├ パスワードのポリシー
└ アカウントロックアウトのポリシー
重要な原則:ドメインのパスワードポリシーが有効になるのは、ドメインルート(Default Domain Policy)に適用したGPOのみです。特定のOUにGPOを適用してもパスワードポリシーは上書きされません。OU単位で設定を変えたい場合は、後述の「きめ細かいパスワードポリシー(PSO)」を使います。
PowerShellで現在のポリシーを確認するには以下のコマンドを使います。
Get-ADDefaultDomainPasswordPolicy
きめ細かいパスワードポリシー(PSO)——グループや個人に別の設定を適用する
きめ細かいパスワードポリシー(PSO:Password Settings Object) Windows Server 2008以降で利用可能な機能。ドメイン全体のポリシーとは別に、特定のユーザーやグループに異なるパスワードポリシーを適用できる。
デフォルトのドメインポリシーはドメイン内の全ユーザーに一律で適用されます。しかし現場では「一般ユーザーと特権アカウントで要件を分けたい」というニーズが必ず出てきます。これを解決するのがPSOです。
PSOはActive Directoryユーザーとコンピューター、またはPowerShellで作成・適用します。
# PSOの作成例(特権アカウント向け)
New-ADFineGrainedPasswordPolicy `
-Name "PSO_PrivilegedUsers" `
-Precedence 10 `
-MinPasswordLength 16 `
-PasswordHistoryCount 24 `
-MaxPasswordAge "180.00:00:00" `
-ComplexityEnabled $true `
-LockoutThreshold 3 `
-LockoutDuration "00:30:00" `
-LockoutObservationWindow "00:30:00"
# グループへの適用
Add-ADFineGrainedPasswordPolicySubject `
-Identity "PSO_PrivilegedUsers" `
-Subjects "Domain Admins"
PSOにはPrecedence(優先度)という数値があり、数値が小さいほど優先されます。複数のPSOが同一ユーザーに適用された場合は、Precedenceの値が最も小さいPSOが有効になります。
3つの設定項目を正しく理解する
複雑性要件——「複雑なパスワード」の定義と現場での落とし穴
Windowsの「複雑性の要件を満たす必要がある」を有効にすると、以下の4カテゴリのうち3つ以上を含むパスワードが要求されます。
| カテゴリ | 例 |
|---|---|
| 大文字(A〜Z) | Password |
| 小文字(a〜z) | password |
| 数字(0〜9) | Pass1234 |
| 記号(!@#$ など) | Pass@word |
現場でよくある誤解:「複雑性要件を有効にしたから安全」と思い込んでしまうケースです。Password1!はこの要件を満たしますが、辞書攻撃に対しては非常に脆弱です。複雑性要件はあくまで最低ラインであり、パスワードの長さを重視する設計に移行することが現在の主流です。
参考:NIST SP 800-63B デジタルアイデンティティガイドライン
有効期限——定期変更は本当に必要か?NISTの最新見解
長年「パスワードは定期的に変更すべき」とされてきましたが、NISTのSP 800-63Bでは定期的な強制変更を推奨しない方針に転換しています。理由は「定期変更を強制するとPassword1→Password2→Password3のような予測可能なパターンに陥りやすいため」です。
現在の推奨アプローチは以下の通りです。
| 状況 | 対応 |
|---|---|
| 漏えいが疑われる場合 | 即時変更を要求 |
| 通常運用 | 長いパスワード+MFAで補完し、定期変更は不要 |
| 特権アカウント | 組織のリスク許容度に応じて設定(180日程度が現実的) |
MFAの設定と組み合わせることで、パスワード単体への依存を下げる設計が有効です。MFAの基本については「MFAとは?」を参照してください。
アカウントロックアウト——ブルートフォース対策と運用コストのバランス
アカウントロックアウト(Account Lockout) 一定回数のログオン失敗でアカウントをロックする機能。ブルートフォース攻撃を防ぐ一方、設定が厳しすぎると誤操作でのロックが多発し運用コストが増大する。
ロックアウトの設定は「セキュリティ」と「運用コスト」のトレードオフです。
| 設定項目 | 推奨値 | 理由 |
|---|---|---|
| ロックアウトのしきい値 | 10回 | 誤操作を許容しつつブルートフォースを防ぐ |
| ロックアウト期間 | 15〜30分 | 自動解除で運用負担を軽減 |
| カウンターのリセット | 15〜30分 | しきい値と同値が管理しやすい |
特権アカウントは別設定で強化を:Domain Adminsなどの特権アカウントはPSOでしきい値を3〜5回に下げ、ロックアウト期間を長め(または手動解除)にする設計が有効です。特権アカウントの設計全般については「AD特権アカウントの設計」で解説しています。
現場で使えるパスワードポリシー設計パターン

一般ユーザー向けの推奨設定値
| 設定項目 | 推奨値 |
|---|---|
| 最小パスワード長 | 12文字以上 |
| 複雑性の要件 | 有効 |
| パスワードの有効期限 | 180日(MFA導入済みなら無期限も可) |
| パスワードの履歴 | 24世代 |
| ロックアウトのしきい値 | 10回 |
| ロックアウト期間 | 15分(自動解除) |
特権アカウント向けの強化設定(PSO適用)
| 設定項目 | 推奨値 |
|---|---|
| 最小パスワード長 | 16文字以上 |
| 複雑性の要件 | 有効 |
| パスワードの有効期限 | 180日 |
| パスワードの履歴 | 24世代 |
| ロックアウトのしきい値 | 3〜5回 |
| ロックアウト期間 | 30分〜手動解除 |
サービスアカウントへの適用——無期限設定と管理方法
サービスアカウント(Service Account) アプリケーションやサービスがADに対して認証するために使う専用アカウント。人が操作せず、システムが自動的に使用する。
サービスアカウントのパスワードに有効期限を設けると、期限切れ時にサービスが停止するリスクがあります。現場での対応パターンは主に2つです。
① パスワードを無期限に設定してPSOで管理する サービスアカウント専用のPSOを作成し、有効期限を無期限に設定します。ただし長期間同じパスワードを使い続けるリスクがあるため、パスワードを長く複雑に設定することが前提です。
② gMSA(グループマネージドサービスアカウント)を使う
gMSA(Group Managed Service Account) Windowsが自動的にパスワードを管理・ローテーションするサービスアカウント。人手によるパスワード管理が不要になる。
gMSAはWindowsが120日ごとに自動でパスワードをローテーションするため、管理負担を大幅に削減できます。新規構築の場合はgMSAの採用を優先的に検討してください。
サービスアカウントの権限設計全般については「サービスアカウントの権限設計」を参照してください。
よくある失敗パターン——設定ミスが招くセキュリティリスクと運用トラブル

① デフォルト設定のまま運用している
Windows Serverのデフォルトでは最小パスワード長が7文字、有効期限が42日に設定されています。現代の攻撃手法に対しては不十分であり、導入直後に見直しが必要です。現在の設定を確認するにはGet-ADDefaultDomainPasswordPolicyを実行してください。
② 全ユーザーに同じポリシーを適用している
一般ユーザーと特権アカウントに同じポリシーを適用するのは設計の不備です。Domain AdminsのパスワードがPassword1!でも通過してしまいます。PSOを使って特権アカウントには必ず強化設定を適用してください。
③ OU単位のGPOでパスワードポリシーを設定しようとしている
ADの仕様として、パスワードポリシーはドメインルートに適用したGPOでしか機能しません。「管理者OUに強いポリシーを設定したのに反映されない」という問い合わせは現場でよく発生します。OU単位での適用にはPSOを使うのが正解です。
④ サービスアカウントのパスワードが期限切れでサービス停止
パスワードの有効期限をサービスアカウントに設定したまま運用し、期限切れでサービスが停止するケースは頻繁に起きます。サービスアカウントには無期限設定かgMSAを使い、定期的にアカウント一覧を棚卸しする運用フローを作ってください。
実務チェックリスト——パスワードポリシー設計の確認ポイント
基本設定の確認
- [ ] Default Domain Policyのパスワードポリシーを確認したか(
Get-ADDefaultDomainPasswordPolicy) - [ ] 最小パスワード長が12文字以上になっているか
- [ ] パスワードの履歴が24世代以上に設定されているか
- [ ] ロックアウトのしきい値が設定されているか(0=無効は危険)
特権アカウントの強化
- [ ] 特権アカウント向けのPSOを作成・適用したか
- [ ] PSOのPrecedenceが一般ポリシーより小さい数値になっているか
- [ ] 特権アカウントのロックアウトしきい値を3〜5回に設定したか
サービスアカウントの管理
- [ ] サービスアカウントの有効期限設定を確認したか
- [ ] gMSAへの移行を検討したか
- [ ] サービスアカウントの棚卸し・レビュー運用があるか
定期レビュー
- [ ] 現在のポリシー設定値がNIST・社内基準に沿っているか
- [ ] ロックアウトの発生状況を定期的に確認しているか
まとめ——今日確認すべきことは1つです
今日やることは1つだけです。Get-ADDefaultDomainPasswordPolicyを実行して、現在の設定値を確認してください。
最小パスワード長が7文字のまま、またはロックアウトのしきい値が0(無効)になっていたら、今日中に見直しが必要です。特権アカウントへのPSO適用と、サービスアカウントの有効期限設定はその次のステップとして計画に入れてください。
ADのユーザーとグループ管理の設計と合わせて整備することで、パスワードポリシーはより効果を発揮します。詳しくは「ADのユーザーとグループ管理」を参照してください。
あわせてご覧ください


コメント