「うちのパスワードは何文字以上ですか」と聞かれて、規程の文書ではなく実際に適用されている設定を即答できる会社は多くありません。規程に「8文字以上」と書いてあっても、実機で強制されていなければ意味がありません。この記事では、いま何が効いているのかを確認する手順をまとめます。
いちばん速い確認方法
コマンドプロンプトで次を実行します。ドメインに参加しているPCなら、どの端末からでも実行できます。
net accounts /domainドメイン全体に適用されている値が表示されます。ローカルの設定を見たい場合は /domain を外します。
| 表示される項目 | 意味 |
|---|---|
| パスワードの最小の長さ | 何文字以上を要求するか |
| パスワードの最長使用期間 | 何日で変更を求めるか |
| パスワードの最短使用期間 | 変更後、次に変えられるまでの日数 |
| パスワード履歴を記憶する | 過去いくつまで再利用を禁じるか |
| ロックアウトのしきい値 | 何回失敗でロックするか |
「パスワードの最小の長さ」が0になっている場合、パスワードなしのアカウントを作れる状態です。ここは真っ先に確認してください。
PowerShellで詳しく見る
net accounts では表示されない項目があります。特に「複雑さの要件」が有効かどうかは、こちらでないと分かりません。
Get-ADDefaultDomainPasswordPolicy次のような項目が返ります。
- ComplexityEnabled — 英大文字・小文字・数字・記号のうち3種類以上を要求するか
- MinPasswordLength — 最小文字数
- MaxPasswordAge — 有効期限
- LockoutThreshold — ロックアウトのしきい値
- ReversibleEncryptionEnabled — 元に戻せる暗号化の有無
ReversibleEncryptionEnabled が True になっていたら、それは即座に直すべき設定です。パスワードが復元可能な形で保存されることを意味し、ドメインコントローラーの情報が持ち出された場合、パスワードがそのまま読み取られます。古い機器との互換性のために有効化された設定が、そのまま残っているケースがあります。
「きめ細かいパスワードポリシー」を見落とさない
ここが最も間違えやすい点です。Active Directory には、既定のポリシーとは別に、特定のユーザーやグループだけに違う設定を適用する仕組みがあります。
これが設定されていると、net accounts の結果はそのユーザーには当てはまりません。確認は次のコマンドです。
Get-ADFineGrainedPasswordPolicy -Filter *何も返らなければ、既定のポリシーだけが効いています。設定がある場合は、適用対象を確認します。
Get-ADUserResultantPasswordPolicy -Identity ユーザー名このコマンドが、そのユーザーに実際に効いている値を返します。特定の人だけを調べるなら、これが最も確実です。
きめ細かいポリシーは、管理者アカウントだけを厳しくする目的で使われる一方、特定の部署だけ緩められている場合もあります。後者は、全社の規程と実態がずれている状態そのものです。
どのグループポリシーが効いているかを調べる
設定の出所を辿りたい場合は、対象のPCで次を実行します。
gpresult /h C:¥temp¥gpo.htmlHTMLのレポートが生成され、どのグループポリシーオブジェクトが適用され、競合した場合にどれが勝ったかまで確認できます。設定した覚えのない値が効いている場合、この方法で出所を特定できます。
グループポリシーによる設定方法そのものは グループポリシーでのアカウント保護設定で扱っています。
確認したあとに何を判断するか
値を取得することが目的ではありません。次の3点を突き合わせてください。
- 社内規程に書かれた値と、実機の値が一致しているか — 一致していなければ、どちらかが実態を反映していません
- きめ細かいポリシーで、規程より緩い例外が作られていないか
- 有効期限の設定が、いまの考え方に合っているか
3点目については補足が必要です。定期的なパスワード変更の強制は、現在は推奨されない方向に整理されています。頻繁な変更を求めると、利用者は覚えられる範囲の単純な変形（末尾の数字を増やすなど）に流れ、かえって推測されやすくなるためです。
ただし「期限をなくせばよい」という単純な話でもありません。漏えいが疑われる場面での変更や、そもそもパスワードだけに頼らない構成が前提になります。考え方は パスワードポリシーの設計で整理しています。
また、ポリシーの値を厳しくしても、使い回されていれば効果は限定的です。他社のサービスで漏れたパスワードが社内でも使われていれば、文字数の要件は攻撃者にとって関係がありません。確認手段は パスワードの使い回しを確認する方法にまとめています。
Pマーク・ISMSの審査で問われる箇所
認証の取得・更新を行っている場合、この確認結果は記録として使えます。審査で問題になりやすいのは、規程に書いてある値と実際の設定が一致していないケースです。
「規程はあるが、実機で確認した記録がない」という状態が最も多い不足です。コマンドの出力をそのまま日付入りで保管しておけば、確認した事実を示せます。関連は JIS Q 15001とパスワード管理と Pマーク更新審査の準備で扱っています。
よくある質問
現在のパスワードポリシーを確認するコマンドは何ですか
コマンドプロンプトなら net accounts /domain、PowerShellなら Get-ADDefaultDomainPasswordPolicy です。後者は複雑さの要件など、前者に出ない項目まで確認できます。
コマンドの結果と実際の動きが違うのはなぜですか
きめ細かいパスワードポリシーが、特定のユーザーやグループに別の設定を適用している可能性があります。Get-ADUserResultantPasswordPolicy でそのユーザーに実際に効いている値を確認してください。
パスワードの有効期限は設定すべきですか
定期変更の強制は、単純な変形を招くため現在は推奨されない方向に整理されています。ただし期限をなくすだけでは不十分で、漏えい時の変更手順や、パスワード以外の認証要素を併用する構成が前提になります。
自社の対応状況を確認するには
パスワードポリシーの確認は出発点で、値が適切かどうかの判断はその先にあります。文字数や有効期限だけでは、いまの攻撃手法には対抗しきれません。applippliの無料診断では、約3分の質問に回答するだけで、ID・パスワードに関連する対応状況を5段階で判定し、結果をPDFレポートでお届けします。個人情報の入力は不要で、会員登録もありません。
参考・出典
※ 本記事は2026年9月時点の一般的な解説です。コマンドの出力項目や画面の名称は、Windows Serverのバージョンおよび環境によって異なる場合があります。設定の変更は、影響範囲を確認のうえ実施してください。