Microsoft Entra IDのSelf-service password reset policies、いわゆるSSPRポリシーを確認するうえで、管理者が最初に押さえるべき結論は「ユーザー向けSSPRの設定だけを見ても不十分」という点です。特に今回の公式情報では、管理者アカウントに適用されるSSPRポリシー、ハイブリッド環境でのパスワード同期、Authentication methods policyへの移行状況をセットで確認する必要があります。Microsoft Learnの対象ページは最終更新日が2026年5月18日と表示されており、日本時間で2026年5月19日前後に確認すべき更新として扱えます。(Microsoft Learn)
この記事では、Microsoft Entra IDのSSPRポリシー更新について、何が変わったのか、どのユーザーや管理者に影響するのか、展開前にどの設定を確認すべきかを実務目線で整理します。
Microsoft Entraのセキュリティ更新で確認すべき要点
今回の「Self-service password reset policies – Microsoft Entra ID」は、SSPRそのものの新機能紹介というより、パスワードポリシー、管理者向けSSPR、パスワード有効期限、ハイブリッド環境での制約を整理した公式情報です。SSPRでユーザーがパスワードを変更またはリセットすると、Microsoft Entra IDのパスワードポリシーが確認され、要件を満たさない場合は再入力を求められます。(Microsoft Learn)
管理者が特に確認すべきポイントは次の4つです。
| 確認項目 | 実務上の意味 |
|---|---|
| 管理者アカウントのSSPR | 一般ユーザー向けSSPRとは別の強いポリシーが適用される |
| Authentication methods policy | SSPRやMFAで使える認証方法の管理場所が統合されているか確認する |
| ハイブリッドID環境 | オンプレミスAD、Microsoft Entra Connect、パスワードライトバックの組み合わせで挙動が変わる |
| パスワード有効期限 | 一括変更すると大量のユーザーに次回サインイン時の変更要求が出る可能性がある |
「SSPRを有効にしているから安全」と考えるのは危険です。実際には、管理者ロール、認証方法、同期方式、既存ポリシーの残り方によって、ユーザー体験もセキュリティリスクも変わります。
2026年5月の更新で何が変わったのか
GitHub上のMicrosoftDocsの履歴では、2026年5月14日のコミットで「SSPR管理者ポリシーの明確化」と「管理者ロール一覧の更新」が行われています。具体的には、two-gate SSPRポリシーの対象となる管理者ロールに不足していた51ロールが追加され、管理者向けパスワードリセットポリシーを無効化した場合の注意点も追記されています。(GitHub)
つまり、今回の更新を読むときの焦点は「SSPRの画面操作が変わったか」ではなく、「自社で管理者扱いになるロールが増えていないか」「管理者向けSSPRを無効化した場合に想定外の登録導線が残っていないか」です。
更新で特に注目すべき管理者SSPRの明確化
Microsoft Entra IDでは、管理者アカウントには既定で強いtwo-gateのパスワードリセットポリシーが適用されます。two-gateとは、メール、認証アプリ、電話番号などの認証情報を2つ要求する考え方です。セキュリティの質問は管理者向けSSPRでは使用できません。(Microsoft Learn)
ここで重要なのは、管理者向けSSPRポリシーはユーザー向けに構成したSSPRポリシーと同じではないことです。たとえば、通常ユーザーには1つの認証方法でパスワードリセットを許可していても、管理者には別の強い要件が適用されます。
さらに、SSPR administrator policyはAuthentication methods policyに完全には依存しません。公式情報では、Authentication methods policyでサードパーティ製ソフトウェアトークンを無効にしても、管理者アカウントはSSPR用途に限って登録・利用できる場合があると説明されています。(Microsoft Learn)
影響範囲は「一般ユーザー」「管理者」「同期ユーザー」で分けて考える
SSPRポリシーの影響範囲は、全ユーザーに一律で見てはいけません。クラウド専用ユーザー、オンプレミスADと同期しているユーザー、管理者ロールを持つユーザーでは、確認すべき設定が異なります。
| 対象 | 主な影響 | 確認すべき設定 |
|---|---|---|
| クラウド専用ユーザー | Microsoft Entra IDのパスワードポリシーが直接適用される | パスワード有効期限、SSPR対象範囲、認証方法 |
| 管理者ロールを持つユーザー | two-gateポリシーが適用される | 対象ロール、管理者SSPRの有効/無効、登録導線 |
| オンプレミス同期ユーザー | オンプレミスAD側のポリシーやライトバック設定の影響を受ける | Microsoft Entra Connect、パスワードライトバック、Unicode文字の扱い |
| B2Bユーザー | 相手テナントや招待時の構成に依存する | 外部ユーザーの認証方法、Email OTP、ゲスト運用ルール |
管理者ロールを一時的に付与しているアカウントも確認対象です。たとえば、運用担当者に一時的にConditional Access AdministratorやAuthentication Administratorを付与している場合、そのアカウントは一般ユーザーと同じSSPRテスト結果にはなりません。
Microsoft Entra IDのパスワードポリシーの基本
Microsoft Entra IDで直接作成・管理されるユーザーには、Microsoft Entra IDのパスワードポリシーが適用されます。公式情報では、パスワードは8文字以上256文字以下で、英小文字、英大文字、数字、記号の4種類のうち3種類を含める必要があるとされています。Unicode文字は許可されません。(Microsoft Learn)
パスワード有効期限については、既定値が「無期限」とされています。ただし、2021年より前に作成されたテナントでは、既定で90日になっている場合があります。現在の設定はMicrosoft Graph PowerShellのGet-MgDomainなどで確認できます。(Microsoft Learn)
変更できるものと変更しにくいもの
Microsoft Entra IDのパスワードポリシーは、オンプレミスADのように細かくすべてを自由に変更できるわけではありません。実務では、次のように切り分けると判断しやすくなります。
| 項目 | 変更可否の考え方 | 補足 |
|---|---|---|
| パスワード長・複雑性 | 基本設定として固定的に扱う | 最小8文字、最大256文字など |
| パスワード有効期限 | 変更可能 | テナントやユーザー単位の設定確認が必要 |
| 禁止パスワード | カスタム禁止パスワードで補強可能 | 会社名、製品名、拠点名などを含む弱いパスワード対策に有効 |
| アカウントロックアウト | Smart Lockoutのしきい値や期間を調整可能 | 既定では誤ったパスワードによるサインイン失敗を検知する |
既定では、誤ったパスワードによるサインイン試行が10回続くとアカウントが1分間ロックされ、以降の誤試行でロック期間が長くなります。また、Smart Lockoutは直近3つの誤ったパスワードハッシュを追跡し、同じ誤パスワードの繰り返しでロックカウンターが無駄に増えないようにします。(Microsoft Learn)
SSPR利用時にパスワードポリシーはどう判定されるか
SSPRでは、ユーザーが「パスワードを忘れた」「アカウントがロックされた」といった状態から自分で復旧できます。ただし、SSPRポータルに到達すれば必ずリセットできるわけではありません。Microsoft Entra IDは、ユーザーがSSPRの対象か、必要な認証方法を登録済みか、管理者ロールが付与されていないか、パスワードがオンプレミス側で管理されていないかを確認します。(Microsoft Learn)
実務では、SSPRの問い合わせを次のように分類すると切り分けが早くなります。
| ユーザーの症状 | よくある原因 | 管理者の確認先 |
|---|---|---|
| SSPR画面で管理者に連絡するよう表示される | SSPR対象外、または必要な認証方法が未登録 | Password resetの対象範囲、Authentication methods |
| 新しいパスワードが拒否される | 複雑性、履歴、オンプレミスAD側ポリシーに不一致 | Entra IDのポリシー、ADパスワードポリシー |
| 同期ユーザーだけリセットできない | パスワードライトバック未構成 | Microsoft Entra Connect、writeback設定 |
| 管理者アカウントだけ挙動が違う | two-gate管理者ポリシーが適用されている | 管理者ロール、AllowedToUseSspr |
ヘルプデスク向けには、「SSPRが有効か」だけでなく「どのポリシーで拒否された可能性があるか」を確認できるチェックシートを用意しておくと、問い合わせ対応が速くなります。
管理者が確認すべき設定
SSPRの対象範囲
最初に見るべき設定は、SSPRの対象範囲です。全ユーザーに展開する前に、パイロットグループで動作確認し、一般ユーザー、管理者ロールを持たない運用担当者、同期ユーザーを分けてテストします。
特に避けたいのは、管理者をユーザー向けSSPRの対象に含めたまま、管理者向けSSPRを無効化する構成です。公式情報では、管理者向けパスワードリセットポリシーを無効にすると、管理者はユーザー向けSSPRポリシーの対象であってもSSPRでリセットできません。その場合でも登録を促されることがあるため、管理者をユーザー向けSSPRポリシーから明示的に除外することが推奨されています。(Microsoft Learn)
管理者向けSSPRの有効・無効
管理者向けSSPRは、必要に応じてAllowedToUseSsprで無効化できます。変更の反映には最大60分かかる可能性があります。(Microsoft Learn)
Connect-MgGraph -Scopes Policy.ReadWrite.Authorization
Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false無効化する場合は、少なくとも次の3点を事前に決めておきます。
| 確認項目 | 理由 |
|---|---|
| 緊急時の管理者復旧手順 | 全管理者がSSPRを使えない状態でロックアウトすると復旧が難しくなる |
| ブレークグラスアカウントの管理 | 条件付きアクセスやMFA障害時の非常用アカウントが必要 |
| 管理者のSSPR登録導線 | 登録を促すのに使えない、という不自然な体験を避ける |
「セキュリティ強化のために管理者SSPRを無効化する」判断自体はあり得ます。ただし、その場合は代替の復旧経路を文書化し、少人数の特権管理者だけが知っている状態にしないことが重要です。
パスワード有効期限
パスワード有効期限は、セキュリティ方針だけでなくユーザー影響が大きい項目です。Microsoft Learnでは、パスワードを無期限に設定していたユーザーを期限ありに戻す場合、LastPasswordChangeDateTimeが90日を超えているユーザーに次回サインイン時の変更要求が出る可能性があると警告されています。(Microsoft Learn)
対象ユーザーの状態確認には、次のコマンドが使えます。
Get-MgUser -All -Property UserPrincipalName, PasswordPolicies |
Select-Object UserPrincipalName,
@{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}個別ユーザーのパスワードを期限ありに戻す場合は、次のように設定します。
Update-MgUser -UserId <user ID> -PasswordPolicies None全ユーザーに対して一括実行する前に、必ず対象件数を確認してください。特に長期間パスワード変更をしていないユーザーが多い組織では、翌朝に大量のサインイン失敗や問い合わせが発生する可能性があります。
ハイブリッド環境で失敗しやすいポイント
オンプレミスADとMicrosoft Entra IDを同期している環境では、SSPRの挙動がクラウド専用ユーザーより複雑になります。パスワードライトバックが構成されていれば、フェデレーション、パススルー認証、パスワードハッシュ同期のユーザーもSSPRでパスワードリセットできます。一方、ライトバックがない場合、オンプレミス側で管理されるパスワードはSSPRでリセットできず、管理者への連絡が必要になります。(Microsoft Learn)
Unicode文字を含むパスワードに注意
Microsoft Entra IDのパスワードポリシーではUnicode文字が許可されません。ハイブリッド環境でEnforceCloudPasswordPolicyForPasswordSyncedUsersを有効にしている場合、同期ユーザーにもMicrosoft Entra IDのパスワードポリシーが適用されます。オンプレミス側ではUnicode文字を含むパスワード変更が成功しても、Microsoft Entra ID側では要件を満たさず、クラウド側に反映されない可能性があります。(Microsoft Learn)
さらに、リスクベースのパスワード変更が有効な場合、ユーザーは再度パスワード変更を求められることがあります。公式情報では、クラウド側要件を満たさないパスワードの場合でも、ユーザーに明確なエラーが表示されないケースが説明されています。(Microsoft Learn)
この問題は、現場では「パスワードを変えたのにまた変更を求められる」「SSPRは成功したように見えるのにリスクが下がらない」といった問い合わせになりがちです。対策として、オンプレミスAD側のパスワードフィルターや社内案内で、Microsoft Entra ID側の制約と矛盾しないルールにそろえる必要があります。
Authentication methods policyへの移行状況を確認する
SSPRの認証方法は、従来のSSPRポリシーだけで見てはいけません。Microsoftは、従来のMFAポリシーとSSPRポリシーで個別に管理されていた認証方法を、Authentication methods policyへ統合する移行を案内しています。2025年9月30日以降、従来のMFAおよびSSPRポリシーでは認証方法を管理できないとされています。(Microsoft Learn)
Authentication methods policyでは、Microsoft Authenticator、SMS、Voice calls、Email OTP、OATHトークンなどをより一元的に管理できます。ただし、すべてが完全に統合済みというわけではありません。たとえば、セキュリティの質問は現在も従来のSSPRポリシー側で管理される扱いです。(Microsoft Learn)
移行時の実務チェック
移行前後で最も多い失敗は、「従来ポリシーでは使えていた方法をAuthentication methods policyで無効にしてしまい、ユーザーが登録済みの方法を使えなくなる」ケースです。
| 移行ステップ | 確認内容 |
|---|---|
| 現状棚卸し | 従来MFA、従来SSPR、Authentication methods policyの設定を記録する |
| 対象グループ確認 | All usersなのか、特定グループなのかを明確にする |
| 方法ごとの突合 | SMS、Voice、Authenticator、Email OTP、OATHの有効/無効を比較する |
| パイロット | 管理者ではないユーザーでSSPRとMFAを実際に試す |
| 移行完了 | Migration Completeにした後、旧ポリシーが効かない前提で確認する |
Microsoftの移行ガイドでは、Authentication methods policyの移行ウィザードを使って現在のMFA/SSPR設定を監査し、統合管理へ移行できると説明されています。移行ガイドはテナントポリシー設定を対象とし、個別ユーザー設定は移行しない点に注意が必要です。(Microsoft Learn)
開発者・自動化担当者が注意すべきポイント
開発者や自動化担当者は、SSPRを「単なるユーザー向けパスワードリセット画面」として扱わないことが重要です。Microsoft GraphやPowerShellでポリシー確認・変更を自動化する場合、次の点を前提に設計します。
| 観点 | 注意点 |
|---|---|
| API操作 | 管理者SSPRの有効/無効は認可ポリシー側の設定で扱う |
| 認証方法 | Authentication methods policyと従来ポリシーの残存状態を確認する |
| 監査ログ | 誰がパスワード有効期限やSSPR設定を変更したかを追えるようにする |
| エラー表示 | ユーザーに明確なエラーが出ないケースをヘルプデスク手順で補う |
| 管理者ロール | 一時付与ロールもSSPR挙動に影響するため、棚卸し対象に含める |
たとえば、管理者向けSSPRを無効にする処理だけを自動化し、管理者をユーザー向けSSPR対象から除外する処理を忘れると、登録を求められるのに利用できない状態を作りかねません。公式更新でこの点が強調されたことは、運用設計上かなり重要です。(GitHub)
展開前に行うべき実務手順
SSPRポリシーの見直しは、いきなり全社展開せず、次の順序で進めるのが安全です。
現在の設定を棚卸しする
最初に、次の設定を一覧化します。
| 設定 | 確認場所の例 |
|---|---|
| SSPRの対象範囲 | Entra ID > Users > Password reset |
| 認証方法 | Entra ID > Authentication methods > Policies |
| 管理者ロール | Entra ID > Roles and administrators |
| パスワード有効期限 | Microsoft Graph PowerShell |
| Microsoft Entra Connect構成 | Connectサーバー、クラウド同期設定 |
| パスワードライトバック | SSPRのオンプレミス統合設定 |
この段階では設定変更をしません。まず「現在どうなっているか」を記録することが重要です。
テストユーザーを3種類用意する
SSPRの検証では、最低でも次の3種類のアカウントを用意します。
| テストアカウント | 目的 |
|---|---|
| クラウド専用の一般ユーザー | Microsoft Entra ID標準のSSPR動作を確認する |
| 同期ユーザー | パスワードライトバックやオンプレミスAD側ポリシーの影響を確認する |
| 管理者ロールなしの運用担当者 | 管理者ポリシーの影響を受けない通常動作を確認する |
管理者アカウントだけでSSPRをテストすると、two-gateポリシーの影響で一般ユーザーと違う結果になります。公式情報でも、パスワードリセット機能はAzure管理者ロールを持たないユーザーでテストすることが推奨されています。(Microsoft Learn)
ユーザー通知を準備する
SSPR展開では、技術設定よりもユーザー通知で失敗することがあります。特に、認証方法の再登録、電話番号やメールアドレスの確認、パスワード要件の変更は問い合わせが増えやすい項目です。
通知文には、次の内容を入れておくと実務で役立ちます。
| 通知内容 | 例 |
|---|---|
| 何が変わるか | パスワードを忘れた場合、自分でリセットできるようになる |
| 事前に必要な作業 | Microsoft Authenticatorやメールなどの認証方法を登録する |
| 使えないケース | 認証方法が未登録の場合はヘルプデスクへ連絡する |
| 注意点 | 管理者アカウントや同期アカウントでは条件が異なる場合がある |
ユーザー向けには「SSPR」「Authentication methods policy」といった製品用語を多用せず、「パスワードを忘れたときの本人確認方法」と説明する方が伝わりやすくなります。
よくある疑問
SSPRポリシーとパスワードポリシーは同じものですか
同じではありません。SSPRポリシーは、誰がどの認証方法で自分のパスワードをリセットできるかを制御します。一方、パスワードポリシーは、設定するパスワードが長さや複雑性などの要件を満たしているかを判定します。SSPR実行時には、リセット後のパスワードがMicrosoft Entra IDのパスワードポリシーに照らして確認されます。(Microsoft Learn)
管理者も一般ユーザーと同じSSPR設定で動きますか
いいえ。管理者アカウントには、既定で強いtwo-gateパスワードリセットポリシーが適用されます。このポリシーは、一般ユーザー向けに設定したSSPRポリシーと異なる場合があり、変更できません。(Microsoft Learn)
パスワードリセット時に以前のパスワードは使えますか
Microsoft Learnでは、パスワード変更時は直前のパスワードを再利用できない一方、忘れたパスワードのリセットでは最後のパスワードを使用できると説明されています。また、クラウド専用ユーザーのリセットでは古いパスワードを保持していないため、再利用を確認・防止できないとされています。(Microsoft Learn)
このため、単に「履歴で防げる」と考えず、カスタム禁止パスワード、MFA、条件付きアクセス、サインインリスク検知を組み合わせることが現実的です。
Security questionsはAuthentication methods policyに移行できますか
現時点の公式情報では、セキュリティの質問はAuthentication methods policyではまだ管理できず、従来のSSPR設定側に残る扱いです。セキュリティの質問を使っている組織は、移行時に無効化するのか、当面残すのかを明確にしておく必要があります。(Microsoft Learn)
まとめ：まず管理者ロールと移行状態を確認する
今回のMicrosoft Entra IDのSSPRポリシー更新で、管理者が最初に行うべきことは、SSPRを有効化することではなく、現在の影響範囲を正しく把握することです。
特に優先度が高いのは、管理者ロールを持つアカウントの棚卸し、Authentication methods policyへの移行状態、ハイブリッド環境でのパスワードライトバック、パスワード有効期限変更時の影響確認です。管理者向けSSPRを無効化する場合は、AllowedToUseSsprの設定だけでなく、ユーザー向けSSPRポリシーから管理者を除外する運用までセットで見直してください。
次に取るべき行動は明確です。まず現在のSSPR対象範囲、管理者ロール、認証方法ポリシー、パスワード有効期限を一覧化します。そのうえで、クラウド専用ユーザー、同期ユーザー、管理者ロールなしユーザーを使ってパイロットテストを行い、問題がなければ段階的に展開します。SSPRはヘルプデスク負荷を減らす便利な機能ですが、管理者ポリシーとハイブリッド構成を見落とすと、復旧できないアカウントや不要な問い合わせを生む原因になります。
コメント