マルチファクター認証の適用のトラブルシューティング

  • リリースバージョン: Australia
  • 更新日 2026年03月12日
  • 所要時間：2分

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

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

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

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

    MFA のデバッグ

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

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

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

    ログについて詳しく知るには、次の場所に移動します。
    • システムログの場合は、 すべて > システムログ > システムログ.
    • ノードログの場合は、次に移動します すべて > システムログ > ユーティリティ > ノードログファイルブラウザ.

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

    • 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 テーブルで正しく構成されているかどうかを確認します。