Conclusion
この記事の結論
管理者のリセット完了は画面で確認できました。利用再開には、本人による認証手段の再登録とログイン確認が必要です。
問い合わせでいう「ログインできない」には、認証手段を使えない場合と、認証後にJira Service Management（JSM）の目的の画面へ入れない場合があります。最初に、どちらの段階で止まるかを聞き取ります。管理者がリセットした後も、本人が新しい認証手段を登録して実際に利用を再開するまでは、作業の担当が利用者に移った状態です。
今回の対応
11月8日、Jira Service Managementの対象アカウントと適用される認証ポリシーを照合し、管理側で2段階認証をリセットしました。操作後、管理画面に完了通知が表示されたことを確認しました。
認証の管理元を先に確かめる
Atlassianの組織で管理するアカウントでは、該当ユーザーのセキュリティ設定と適用ポリシーを確認します。SSOで外部のIDプロバイダーが認証を担当する構成では、認証手段の管理元が異なります。JSMの画面を使っているという情報だけでリセット対象を決めず、実際にどの認証画面で止まったかを照合します。
状況別の判断と次の対応
| 観察した状態 | そこから判断できること | 次に確認すること |
|---|---|---|
| 管理画面にリセット完了を表示 | 管理者の操作を受け付けた | 完了時刻を記録し本人へ登録を引き継ぐ |
| 本人が登録後も認証を通れない | 認証段階の問題が残る | 対象アカウント・認証元・表示された段階を照合する |
| 認証後にJSMだけ開けない | 認証後のアクセスで止まっている | 利用先と権限を確認しリセットを繰り返さない |
問い合わせを閉じるための確認例
既に開いている画面は、リセット前のセッションで表示できている可能性があります。再登録後、本人に新しいサインインで認証を通し、普段使うJSMのポータルまたは画面を開けたか確認してもらいます。記録例は「管理操作完了／本人の再登録待ち／新規ログインの結果待ち」です。認証コードや復旧コードそのものをチケットに転載する必要はありません。
- 01認証が止まった段階と管理元を確認する
- 02対象のリセット完了表示を記録する
- 03本人が新規ログインでJSMを開けたか確認する
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認