MFA 適用のトラブルシューティング

MFA の適用によるトラブルシューティング情報

ServiceNow は、Yokohama リリースのアップグレード後にデフォルトで MFA を適用し、非 SSO ログイン (ユーザー名とパスワードまたは LDAP ベースの認証のみでログインを実行するユーザー) に MFA を必須にすることで、セキュリティ体制を強化し、侵害のリスクを軽減します。

MFA の適用は、デフォルトで Yokohama からアクティブ化されているか、Yokohama にアップグレードされている MFA ポリシーを介して実行されます。MFA の動作に変更があった場合に実行できるトラブルシューティングタスクの一部を次に示します。

• トラブルシューティングツールを使用したデバッグ
• ログの場所とデバッグプロパティに移動します
• MFA の使用中のユーザーエクスペリエンスに基づいて MFA シナリオを理解します
• 以前のリリースからのアップグレードによる MFA の問題を理解する

MFA のデバッグ

次のツールのいずれかまたは組み合わせを使用して、デバッグ情報を理解してください。

• Splunk - デバッグログを表示します。
• システムログまたはノードログ。
• MFA のデバッグログを分析するための HAR ログ。

ログの場所とデバッグプロパティ

ログの詳細については、次の場所に移動してください。

• システムログについては、次に移動します: All (すべて) > システムログ > システムログ.
• ノードログの場合は、 All (すべて) > システムログ > ユーティリティ > ノードログファイルブラウザ.

システムデバッグログとインスタンスノードログは、デバッグのために必要です。有効にする必要があるデバッグプロパティは次のとおりです。

• glide.webauthn.debug.enabled
• glide.log.default_log_debug
• glide.authenticate.policy.debug
• glide.authenticate.hybrid_user_tracking.debug

シナリオに基づく MFA の問題

シナリオ 1:ユーザーが第 2 要素を使用してログインできない

ユーザーの MFA をリセットし、次のテーブルから古いユーザーレコードを削除します。

• user_multifactor_auth
• sys_user_public_credential
• sys_user_multi_factor_setup

シナリオ 2:アドミニストレーターが第 2 要素を使用してログインできない

アドミンアクセス権を持つ別のユーザーが、ブロックされたアドミンユーザーの MFA をリセットできます。それでも問題が解決しない場合は、 ServiceNow サポートに連絡してください。

シナリオ 3:MFA セットアップまたは検証中にエラーが発生した

「関連するエラーコード/警告:6桁の確認コードが正しくありません。正しいコードでもう一度お試しください。

次の手順を実行します。

• TOTP 認証アプリの場合、認証システムの MFA デバイスとインスタンスの日時が同期していない場合 (±30 秒)、TOTP コードは受け入れられません。デバイスとインスタンスの日時を確認します。
• メールの場合は、ユーザーレベルの通知、送信メール設定、およびユーザーを sys_user テーブルで正しく構成します。
• SMS の場合は、Twillio またはその他の SMS サービスプロバイダー統合を正しく構成し、アクティブに設定します。ユーザーの携帯電話番号が sys_user テーブルで正しく構成されているかどうかを確認します。

アップグレードによる問題

TBD.