動作のしくみ: Azure AD のセルフサービス パスワード リセット
Azure Active Directory (Azure AD) のセルフサービス パスワード リセット (SSPR) により、ユーザーは、管理者やヘルプ デスクが関与することなく、自分のパスワードを変更またはリセットできるようになります。 ユーザーはアカウントがロックされた場合やパスワードを忘れた場合でも、画面の指示に従って自分自身のブロックを解除して、作業に戻ることができます。 この機能により、ユーザーが自分のデバイスやアプリケーションにサインインできなくなった場合のヘルプ デスクの問い合わせが減り、生産性の喪失も軽減されます。 「Azure AD の SSPR を有効にして構成する方法」の動画をぜひご覧ください。
重要
概念に関するこの記事では、セルフサービスによるパスワードのリセットのしくみを管理者向けに説明します。 既にセルフサービス パスワード リセットの登録が済んでいて、自分のアカウントに戻る必要があるエンド ユーザーは、 https://aka.ms/sspr にアクセスしてください。
ユーザーが自分でパスワードをリセットする機能が IT チームによって有効にされていない場合は、ヘルプデスクに連絡して追加のサポートを依頼してください。
パスワード リセット プロセスのしくみ
ユーザーは、SSPR ポータルを使用してパスワードをリセットまたは変更できます。 まず、希望する認証方法を登録しておく必要があります。 ユーザーが SSPR ポータルにアクセスすると、Azure Platform によって次の要素が考慮されます。
- ページはどのようにローカライズする必要があるか?
- ユーザー アカウントは有効か?
- ユーザーが属しているのはどのような組織か?
- ユーザーのパスワードがどこで管理されるか?
ユーザーがアプリケーションまたはページから [アカウントにアクセスできません] というリンクを選択した場合、または https://aka.ms/sspr に直接移動した場合、SSPR ポータルで使用される言語は、次のオプションに基づきます。
- 既定では、SSPR を適切な言語で表示するために、ブラウザーのロケールが使用されます。 パスワード リセットのエクスペリエンスは、Microsoft 365 でサポートされている言語と同じものにローカライズされます。
- 特定のローカライズされた言語で SSPR にリンクする場合は、パスワード リセット URL の末尾に、必要なロケールと共に
?mkt=
を追加します。- たとえば、スペイン語の es-us ロケールを指定するには、
?mkt=es-us
- https://passwordreset.microsoftonline.com/?mkt=es-us を使用します。
- たとえば、スペイン語の es-us ロケールを指定するには、
SSPR ポータルが必要な言語で表示された後、ユーザー ID を入力して CAPTCHA を渡すように求められます。 Azure AD によって次のチェックが行われ、ユーザーが SSPR を使用できることが確認されます。
- ユーザーに対して SSPR が有効になっていることを確認します。
- ユーザーに対して SSPR が有効になっていない場合、そのユーザーは管理者に連絡してパスワードをリセットするように求められます。
- ユーザーのアカウントで、適切な認証方法が管理者ポリシーに従って定義されていることを確認します。
- ポリシーで要求される方法が 1 つのみの場合は、管理者ポリシーで有効になっている 1 つ以上の認証方法に対して、ユーザーに適切なデータが定義されていることを確認します。
- 認証方法が構成されていない場合、ユーザーは管理者に連絡してパスワードをリセットするように求められます。
- ポリシーで要求される方法が 2 つの場合は、管理者ポリシーで有効になっている 2 つ以上の認証方法に対して、ユーザーに適切なデータが定義されていることを確認します。
- 認証方法が構成されていない場合、ユーザーは管理者に連絡してパスワードをリセットするように求められます。
- Azure 管理者ロールがユーザーに割り当てられている場合、強力な 2 ゲート パスワード ポリシーが適用されます。 詳細については、「管理者リセット ポリシーの相違点」を参照してください。
- ポリシーで要求される方法が 1 つのみの場合は、管理者ポリシーで有効になっている 1 つ以上の認証方法に対して、ユーザーに適切なデータが定義されていることを確認します。
- ユーザーのパスワードがオンプレミスで管理されているかどうか (Azure AD テナントでフェデレーション、パススルー認証、またはパスワード ハッシュ同期が使用されているかどうかなど) を確認します。
- SSPR ライトバックが構成されていて、ユーザーのパスワードがオンプレミスで管理されている場合、ユーザーは自分のパスワードを認証してリセットできます。
- SSPR ライトバックがデプロイされておらず、ユーザーのパスワードがオンプレミスで管理されている場合、ユーザーは管理者に連絡してパスワードをリセットするように求められます。
上記のすべてのチェックが正常に完了した場合、パスワードをリセットまたは変更するプロセスがユーザーに案内されます。
注意
SSPR では、パスワード リセット プロセスの一環としてユーザーにメール通知が送信される場合があります。 これらのメールは、複数のリージョンにまたがってアクティブ/アクティブ モードで動作する SMTP リレー サービスを使用して送信されます。
SMTP リレー サービスでは、メールの本文が受信され、処理されますが、保存はされません。 顧客から提供された情報を含む可能性がある SSPR メールの本文は、SMTP リレー サービスのログに格納されません。 ログには、プロトコルのメタデータのみが含まれています。
SSPR の使用を開始するには、次のチュートリアルをご覧ください。
サインイン時にユーザーに登録を求める
Azure AD を使用して任意のアプリケーションにサインインするために最新の認証または Web ブラウザーを使用する場合は、SSPR 登録を完了するようにユーザーに要求するオプションを有効にすることができます。 このワークフローには、次のアプリケーションが含まれます。
- Microsoft 365
- Azure portal
- アクセス パネル
- フェデレーション アプリケーション
- Azure AD を使用するカスタム アプリケーション
登録を必須としない場合、ユーザーはサインイン時には要求されませんが、手動で登録することができます。 ユーザーは https://aka.ms/ssprsetup にアクセスするか、アクセス パネルの [プロファイル] タブの下にある [パスワード リセットの登録] リンクを選択することができます。
![Azure portal での SSPR の登録オプション][登録]
注意
ユーザーは、 [キャンセル] を選ぶか、ウィンドウを閉じることで、SSPR 登録ポータルを終了できます。 ただし、登録を完了するまでは、サインインのたびに登録を求められます。
ユーザーが既にサインインしている場合、SSPR に登録するためのこの中断によりその接続が切断されることはありません。
認証情報を再確認する
パスワードのリセットまたは変更が必要になったときに認証方法が正しいことを確実にするために、一定期間後にユーザーに登録情報を確認するように要求できます。 このオプションは、 [Require users to register when signing in](サインイン時にユーザーに登録を要求する) オプションを有効にした場合にのみ使用できます。
登録されている方法の確認をユーザーに求める有効な値は、0 から 730 日までです。 この値を 0 に設定すると、ユーザーが認証情報の確認を求められることはありません。 統合された登録エクスペリエンスを使用する場合、ユーザーは情報を再確認する前に自身の ID を確認する必要があります。
認証方法
ユーザーは、SSPR が有効になっている場合には、少なくとも 1 つの認証方法を登録する必要があります。 2 つ以上の認証方法を選択することを強くお勧めします。そうすれば、一方の認証方法を利用できない場合でも、必要があれば、ユーザーはもう一方の認証方法を利用できます。 詳細については、「認証方法とは」を参照してください。
SSPR で使用できる認証方法は次のとおりです。
- モバイル アプリの通知
- モバイル アプリ コード
- 携帯電話
- 会社電話 (有料サブスクリプションを使用するテナントでのみ使用可能)
- セキュリティの質問
ユーザーが自分のパスワードをリセットできるのは、管理者が有効にした認証方法を自分で登録した場合のみです。
警告
Azure "管理者" ロールが割り当てられたアカウントは、「管理者リセット ポリシーの相違点」で定義されている方法を使用する必要があります。
![Azure portal の [認証方法] セクション][認証]
必要な認証方法の数
ユーザーがパスワードをリセットまたはロック解除するために指定する必要がある、使用可能な認証方法の数を構成できます。 この値は 1 または 2 に設定できます。
ユーザーは、複数の認証方法を登録でき、またそうする必要があります。 ここでも、ユーザーが 2 つ以上の認証方法を選択することが強く推奨されます。そうすれば、一方の認証方法を利用できない場合でも、必要があれば、もう一方の認証方法を利用できます。
ユーザーが SSPR を使用しようとしたときに、必要な最低限の数の方法が登録されていない場合は、管理者にパスワードのリセットを依頼するよう指示するエラー ページが表示されます。 SSPR に登録された既存のユーザーが存在する場合、必要な方法の数を 1 から 2 に増やすと、それらのユーザーはその機能を使用できなくなるのでご注意ください。 詳細については、後続セクション「認証方法を変更する」を参照してください。
モバイル アプリおよび SSPR
パスワード リセットの方法として Microsoft Authenticator アプリなどのモバイル アプリを使用している場合は、次の考慮事項が適用されます。
- 管理者がパスワードのリセットに 1 つの方法の使用を必須にすると、使用できる選択肢は確認コードのみになります。
- 管理者がパスワードのリセットに 2 つの方法の使用を必須にすると、ユーザーは通知または確認コードを、他の有効な方法に加えて使用できます。
リセットに必要な方法の数 | 1 つ | 2 つ |
---|---|---|
使用可能なモバイル アプリの機能 | コード | コードまたは通知 |
https://aka.ms/ssprsetup からセルフサービス パスワード リセットを登録するときに、ユーザーはモバイル アプリを登録するオプションを選択できません。 ユーザーは、https://aka.ms/mfasetup で、または統合されたセキュリティ情報の登録 (https://aka.ms/setupsecurityinfo) でモバイル アプリを登録できます。
重要
認証アプリは、1 つの方法のみが必須の場合に唯一の認証方法として選択することはできません。 同様に、方法が 2 つ必要な場合は、認証アプリと追加の方法を 1 つだけ選択するということはできません。
認証アプリを方法として含む SSPR ポリシーを構成する場合、1 つの方法を必須にするときは追加の方法を少なくとも 1 つ選択する必要があります。2 つの方法を必須として構成するときは、追加の方法を少なくとも 2 つ選択する必要があります。
この要件の理由は、現在の SSPR 登録エクスペリエンスに認証アプリを登録するオプションが含まれていないためです。 認証アプリを登録するオプションは、新しい統合された登録エクスペリエンスに含まれています。
認証アプリだけ (1 つの方法が必須の場合)、または認証アプリと追加の方法を 1 つだけ (2 つの方法が必須の場合) を使用するポリシーを許可すると、ユーザーは新しい統合された登録エクスペリエンスを使用するように構成されるまで、SSPR の登録をブロックされる可能性があります。
認証方法を変更する
リセットまたはロック解除に必要な認証方法が 1 つしか登録されていないポリシーで開始し、それを 2 つの方法に変更した場合、どうなるでしょうか。
登録されている方法の数 | 必要な方法の数 | 結果 |
---|---|---|
1 つ以上 | 1 | リセットまたはロック解除できる |
1 | 2 | リセットまたはロック解除できない |
2 つ以上 | 2 | リセットまたはロック解除できる |
使用可能な認証方法を変更した場合も、ユーザーに問題が発生する可能性があります。 ユーザーが使用できる認証方法の種類を変更すると、誤って、使用できるデータが最小量に及ばない場合にユーザーが SSPR を使用できないようにする可能性があります。
次のシナリオ例について考えてみます。
- 元のポリシーには、必要な 2 つの認証方法が構成されています。 会社電話番号とセキュリティの質問のみを使います。
- 管理者は、今後セキュリティの質問を使用せず、携帯電話および連絡用メール アドレスを使用できるようにポリシーを変更します。
- 携帯電話または連絡用メール アドレスのフィールドに入力していないユーザーは、パスワードをリセットできなくなります。
通知
パスワード イベントを認識しやすくするために、SSPR を使用して、ユーザーと ID 管理者の両方に対して通知を構成できます。
[パスワードのリセットについてユーザーに通知しますか]
このオプションが [はい] に設定されている場合、パスワードをリセットするユーザーは、パスワードが変更されたことを通知するメールを受け取ります。 メールは、SSPR ポータル経由で、Azure AD に格納されているプライマリおよび連絡用メール アドレス宛に送られます。 プライマリまたは代替のメール アドレスが定義されていない場合、SSPR はユーザーのユーザー プリンシパル名 (UPN) を介してメール通知を試行します。 このリセット イベントは他の誰にも通知されません。
他の管理者が自分のパスワードをリセットしたときに、すべての管理者に通知する
このオプションが [はい] に設定されている場合は、その他すべての Azure 管理者が、Azure AD に格納されているプライマリ メール アドレスにメールを受け取ります。 メールでは、別の管理者が SSPR を使ってパスワードを変更したことが通知されます。
次のシナリオ例について考えてみます。
- 1 つの環境に 4 人の管理者がいます。
- 管理者 A が SSPR を使ってパスワードをリセットします。
- 管理者 B、C、D がパスワード リセットを通知するメールを受け取ります。
Note
SSPR サービスからのメール通知は、使用している Azure クラウドに基づいて、次のアドレスから送信されます。
- パブリック: msonlineservicesteam@microsoft.com
- 中国: msonlineservicesteam@oe.21vianet.com
- 政府機関: msonlineservicesteam@azureadnotifications.us
通知の受信で問題が発生した場合は、スパム設定を確認してください。
オンプレミスの統合
ハイブリッド環境を使用している場合は、Azure AD からオンプレミスのディレクトリにパスワード変更イベントを書き戻すように Azure AD Connect を構成することができます。
![パスワード ライトバックの検証が有効かつ動作中][ライトバック]
Azure AD によって現在のハイブリッド接続が確認され、Azure portal に次のいずれかのメッセージが表示されます。
- お客様のオンプレミスのライトバック クライアントは稼働しています。
- Azure AD Connect はオンラインであり、オンプレミスのライトバック クライアントに接続されていますが、 インストールされている Azure AD Connect のバージョンが古いようです。 最新の接続機能と重要なバグ フィックスを確実に入手するため、Azure AD Connect のアップグレードをご検討ください。
- 申し訳ございません。インストールされている Azure AD Connect のバージョンが古いため、オンプレミスのライトバック クライアントの状態を確認できません。 Azure AD Connect をアップグレードし、接続の状態を確認できるようにしてください。
- 申し訳ございません。現在オンプレミスのライトバック クライアントに接続できないようです。 Azure AD Connect のトラブルシューティングを行い、接続を復元してください。
- 申し訳ございません。パスワード ライトバックが正しく構成されていないため、オンプレミスのライトバック クライアントに接続できません。 パスワード ライトバックを構成し、接続を復元してください。
- 申し訳ございません。現在オンプレミスのライトバック クライアントに接続できないようです。 これはマイクロソフト側の一時的な問題が原因の可能性があります。 問題が解決しない場合は、Azure AD Connect のトラブルシューティングを行い、接続を復元してください。
SSPR 書き戻しの使用を開始するには、次のチュートリアルをご覧ください。
オンプレミス ディレクトリへのパスワード ライトバック
Azure portal を使用して、パスワード ライトバックを有効にすることができます。 また、Azure AD Connect を再構成する必要なくパスワード ライトバックを一時的に無効にすることもできます。
- このオプションが [はい] に設定されている場合、書き戻しが有効になります。 フェデレーション、パススルー認証、またはパスワード ハッシュ同期されたユーザーは、自分のパスワードをリセットできます。
- このオプションが [いいえ] に設定されている場合、書き戻しは無効になります。 フェデレーション、パススルー認証、またはパスワード ハッシュ同期されたユーザーは、自分のパスワードをリセットできません。
パスワードをリセットせずにアカウントのロックを解除することをユーザーに許可する
既定では、Azure AD はパスワード リセットを実行するときにアカウントをロック解除します。 柔軟性を確保するために、ユーザーが自分のパスワードをリセットする必要なくオンプレミスのアカウントのロックを解除できるようにすることを選択できます。 これら 2 つの操作を分離するには、以下の設定を使います。
- [はい] に設定すると、ユーザーは、パスワードをリセットしてアカウントのロックを解除するか、パスワードをリセットする必要なくアカウントのロックを解除するかを選択できます。
- [いいえ] に設定すると、ユーザーはパスワードのリセットとアカウントのロック解除を組み合わせた操作しか実行できません。
オンプレミスの Active Directory のパスワード フィルター
SSPR を使用すると、管理者によって開始されたパスワードのリセットと同等の動作が Active Directory で実行されます。 カスタムのパスワード ルールを提供するためにサードパーティのパスワード フィルターを使用していて、Azure AD のセルフサービス パスワード リセット中にこのパスワード フィルターを確認する必要がある場合、サードパーティのパスワード フィルターのソリューションが確実に管理者のパスワード リセット シナリオで適用されるように構成します。 Active Directory Domain Services での Azure AD パスワード保護は、既定でサポートされます。
B2B ユーザーのパスワードのリセット
パスワードのリセットと変更は、すべての企業間 (B2B) 構成で完全にサポートされています。 B2B ユーザーのパスワード リセットは、次の 3 つの場合にサポートされます。
- 既存の Azure AD テナントがあるパートナー組織のユーザー:パートナーを組んでいる組織に既存の Azure AD テナントがある場合は、そのテナントで有効になっているパスワード リセット ポリシーが常に尊重されます。 パスワード リセットが機能するためにパートナー組織で必要なのは、Azure AD SSPR を有効にすることだけです。 Microsoft 365 のお客様に追加料金は発生しません。
- セルフ サービス サインアップを使ってサインアップしたユーザー:パートナーを組んでいる組織がセルフ サービス サインアップ機能を使ってテナントに参加している場合は、登録したメールを使ってパスワードをリセットできます。
- B2B ユーザー:新しい Azure AD B2B 機能を使って作成された B2B ユーザーも、招待プロセス中に登録した電子メールを使って自分のパスワードをリセットできます。
このシナリオをテストするには、これらのパートナー ユーザーのいずれかで https://passwordreset.microsoftonline.com に移動します。 連絡用電子メールまたは認証用電子メールが定義されている場合、パスワードのリセットは予想どおりに機能します。
注意
Azure AD テナントへのゲスト アクセスを許可されている Microsoft アカウント (Hotmail.com、Outlook.com、他の個人メール アドレスなどのもの) では、Azure AD SSPR を使うことができません。 このようなユーザーは、「Microsoft アカウントにサインインできない場合」の情報を使って、パスワードをリセットする必要があります。
次のステップ
SSPR の使用を開始するには、次のチュートリアルをご覧ください。