net accountsで確認できるのは、パスワードの長さ・履歴・有効期間などの一部のアカウントポリシーです。複雑さ要件や期限切れ前の通知日数まで、このコマンドだけで確認・変更できるわけではありません。特に/uniquepwは履歴の数であり、通知日数ではありません。
このガイドではローカルWindowsアカウントとActive Directory（AD）ドメインアカウントを分けて説明します。Microsoftアカウント、Microsoft Entra ID、Windows Hello PINのルールを同じ設定と考えないでください。変更例は管理者が承認した検証環境向けで、数値は一律の推奨値ではありません。実機でポリシー変更を実行した検証結果は含みません。
最初に設定対象を確認する
スタンドアロンPCのローカルアカウントを管理する場合と、組織のADドメインアカウントを管理する場合では適用先が違います。ドメイン参加PCでローカル設定を変更しても、ドメインユーザーのパスワード規則を変更したことにはなりません。GPOやMDMで管理されている端末では、管理元と既存ポリシーを先に確認します。
whoami
net accounts
net help accounts引数なしのnet accountsは、このコンピューター側のアカウントポリシー確認に使います。表示された項目とOS上のヘルプを記録します。変更は管理者権限が必要ですが、確認のためだけに権限を広げることはしません。
net accounts /domainADドメインのポリシーを照会する例です。ドメイン接続と必要なアクセスが前提になります。/domainを変更用引数と組み合わせるとドメイン側への変更になり得るため、ローカルの練習コマンドへ気軽に追加しないでください。細かい設定のパスワードポリシー（FGPP）が適用されるユーザーは、この表示だけでは実効ルールを判断できません。
net accountsの主な設定項目
/minpwlenは最小長、/maxpwageは最大有効期間、/minpwageは最短使用期間、/uniquepwは再使用を制限するパスワード履歴の数です。表示にはアカウントロックアウト関係の項目が含まれる場合もありますが、複雑さ要件の有効/無効はnet accountsの出力では確認できません。
長さや日数の許容範囲は実機のnet help accountsと対応OSのポリシー仕様で確認します。現行の長いパスワードを扱うポリシーとnet.exeの旧来の設定範囲が同じとは限りません。上限に当たったときに推測したレジストリ値で回避しないでください。
ローカルの最小長・履歴・有効期間を変更する構文例
次の数値は構文を説明するための例です。既存値と対象アカウント、サービス・タスクへの影響、復旧手順を記録してから、承認された項目だけ変更します。全部をまとめて実行する必要はありません。
net accounts /minpwlen:12
net accounts /uniquepw:24
net accounts /maxpwage:90
net accounts /minpwage:1
net accounts最小有効期間は、利用者が短時間でパスワードを何度も変更して履歴制限をすり抜けることを抑える設定です。最大有効期間と矛盾する値を指定せず、管理者によるリセットや次回変更要求と通常の利用者変更の違いも考慮します。設定変更は現在のパスワードを一括して書き換える操作ではありません。
最大有効期間を短くすると、既存パスワードの経過日数や例外設定によって利用者への影響が出ます。無期限属性のアカウントやサービスアカウントも確認し、変更日と利用者への案内を計画してください。
複雑さ要件はsecpol.mscやGPOで別に確認する
secpol.msc利用できるエディションでは、ローカルセキュリティポリシーの「アカウントポリシー → パスワードのポリシー → パスワードは複雑さの要件を満たす必要がある」で確認します。Homeなどで管理ツールがない場合、非公式な追加ツールを入れず、対応する管理方法を確認してください。ドメイン全体は組織のGPO/AD管理手順で扱います。
Windows標準の複雑さは「大文字・小文字・数字・記号の4種類を必ず全部入れる」という意味ではありません。対象の文字カテゴリーのうち3種類以上を使う条件や、アカウント名・氏名の一部を含めない条件があります。カテゴリーには大文字/小文字に分類されないUnicodeの文字も含まれます。追加のパスワードフィルターがある環境では条件がさらに異なります。
複雑さはパスワードの作成・変更時に評価されます。最小長と有効期間をnet accountsで変更しただけでは、この複雑さの有効化にはなりません。管理者はテスト用アカウントで許可・拒否される条件を確認し、実際のパスワードを記録しないようにします。
期限切れ前の通知は「セキュリティオプション」
通知の設定場所は「コンピューターの構成 → ポリシー → Windowsの設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション」にある「対話型ログオン: パスワードが無効になる前にユーザーに変更を促す」です。ローカル設定ではsecpol.mscの「ローカルポリシー → セキュリティオプション」を確認します。
net accounts /uniquepw:14を実行しても14日前の通知にはなりません。変更されるのは履歴の数です。通知日数と最大有効期間、ユーザーの無期限属性、実際のサインイン方法を別々に確認します。このWindowsの対話型ログオン通知をMicrosoft 365全般の通知設定や任意メッセージ配信と混同しません。
ADでユーザー別に異なる場合は実効ポリシーを調べる
管理者がRSAT/ActiveDirectoryモジュールを使える環境では、次の読み取り例でドメイン既定とユーザーの結果ポリシーを確認できます。example.comとusernameは実際の対象へ置き換えます。
Get-ADDefaultDomainPasswordPolicy -Identity 'example.com'
Get-ADUserResultantPasswordPolicy -Identity 'username'後者はユーザーへ適用される細かい設定のパスワードポリシーを調べるためのものです。結果がない場合は既定のドメインポリシーとの関係を確認し、照会失敗を「制限なし」と解釈しません。OUへローカル向けGPOを追加するだけで、ドメインユーザーのパスワードを個別設定できると考えないでください。
定期変更を一律に60〜90日へ設定しない
古い例の数値をそのまま安全基準にするのではなく、組織の現行基準、侵害検知、使い回し防止、長い固有のパスワード、MFAやパスワードレス、漏洩した場合の対応を組み合わせます。Microsoftの近年のベースラインは定期的な期限切れの強制を外す方向ですが、それだけを理由に管理中の規則を無断変更してよいわけではありません。
侵害や漏洩が疑われる場合の速やかな変更と、理由なく短周期で繰り返す定期変更は別です。業界・組織の要件がある場合はその所有者と調整します。Windows標準の複雑さルールの説明と、現代的な認証方式の推奨を区別してください。
反映されないときの切り分け
まずローカル/ドメイン/クラウド/PINのどれを変更したか、GPOやFGPPの適用、ユーザー固有の無期限属性を確認します。gpupdate /forceを実行すれば、あらゆるアカウントへ即座に同じ規則が適用されるわけではありません。ポリシーの優先順位、ADレプリケーション、対象DCやクライアントの到達性も管理者が確認します。
設定がグレー表示だったり再び元へ戻ったりする場合は、中央管理の方針を確認します。障害回避としてAdministratorのPasswordNeverExpiresをtrueにするスクリプトを配布することは、ポリシーの標準化ではなく個別の例外を作る操作です。一般的な解決策として実行しないでください。
変更と戻し方を記録する
変更前後のnet accounts表示、GPOの適用先と設定、テストアカウントでの結果、利用者への影響を記録します。戻す場合は保存した元の数値・有効/無効・未構成の状態へ戻し、別の制御を上書きしないようにします。定期スクリプトで無条件に設定し直す運用は、GPOとの競合や変更理由の不明化につながります。
確認用の演習
1. net accountsだけで複雑さが分かるか：分かりません。2. /uniquepw:14は何か：履歴14件の指定で、通知ではありません。3. メンバーPCのローカル変更でADユーザーの規則が変わるか：同じ対象ではありません。4. 長さの設定で既存パスワードが自動的に新しい文字列へ変わるか：変わりません。実機演習は承認された検証環境で行います。
公式資料
Microsoft：Netコマンド / Password Policy / 複雑さ要件 / 期限切れ前の通知 / Get-ADUserResultantPasswordPolicy
コメント