「設定済みです」で止まるIDaaS障害。現場はどこから切り分けるか

結論は、製品ごとの設定画面を順番に眺めるのではなく、一件のユーザー、一回のサインイン、一つの変更時刻を軸に、人事イベントからSaaS側の利用状態までを時系列でつなぐことです。

最初に「何が起きたか」を一文にする

「SSOができない」「SCIMがおかしい」だけでは調査範囲が広すぎます。まず、本来の動作、実際の動作、発生時刻、対象アプリ、対象者、直前変更を一件の事象として固定します。

問い合わせ時に揃える情報

条件付きアクセスのMicrosoft公式手順では、トラブルシューティング時にユーザー情報、OS、発生時刻、対象アプリ、クライアント種別、Correlation IDを収集するよう示されています。これにIDライフサイクルとプロビジョニングの情報を加えます。

• 本来どうなるはずだったか
• 実際に何が起きたか。エラー文だけでなく、通った・残った・更新されなかった等の結果
• 発生時刻とタイムゾーン。利用者の申告時刻とログ時刻を分ける
• 対象アプリ、端末OS、ブラウザまたはクライアント種別
• Correlation ID、Request ID、プロビジョニングログの対象ユーザーとAction
• 直前に変更したポリシー、グループ、割り当て、属性、証明書、資格情報

六層で切り分ける

1. 起点となるイベント人事・契約・申請で、誰が、いつ、何を変更することになっていたか。退職日と最終就業日、契約終了日とアクセス終了日が同じとは限りません。
2. Entra IDのユーザー状態accountEnabled、削除状態、認証方法、グループの直接・動的メンバーシップ、同期元を確認します。
3. アプリ割り当てと認証直接割り当て、グループ割り当て、アプリロール、ユーザーサインインの許可、SAML・OIDC設定を分けます。
4. 条件付きアクセスポリシーの設定値ではなく、該当サインインで実際に適用・非適用となったポリシー、認証結果、端末状態を確認します。
5. プロビジョニングスコープ、照合属性、Modified properties、SaaS APIの応答、再試行、検疫状態、最終成功時刻を確認します。
6. SaaS側の利用状態active属性だけでなく、ローカル認証、既存セッション、APIキー、個人アクセストークン、共有アカウント、アプリ内ロールを確認します。

担当者が詰まりやすい三つの場面

成功ログがあるので「問題なし」と判断する

プロビジョニングログのSuccessは、記録された操作が処理されたことを示します。期待した属性、アプリ側セッション、ローカルID、別経路のAPIアクセスまで失効したかは別に確認します。Action、Target ID、Modified properties、SaaS側の結果を対応させます。

除外で復旧したため、原因調査が止まる

除外は復旧手段になり得ますが、どのポリシーのどの条件が影響したかは確定しません。Microsoftも除外を慎重に使い、できるだけ早く戻すことを示しています。除外日時、承認者、期限、解除条件、代替コントロールを障害票へ残します。

管理画面のアプリ名だけで所有者へ確認する

表示名が似たサービスプリンシパルや検証用アプリが存在すると、別オブジェクトを確認することがあります。Object ID、Application ID、Tenant ID、サービスプリンシパルの所有者、資格情報、API権限、最終利用を一組にして確認します。

原因が分からなくても、引き継げる記録にする

その場で根本原因が確定しない場合でも、確認済み事実、未確認事項、暫定対応、影響範囲、次の確認者を分けます。「たぶん条件付きアクセス」「ベンダー側と思われる」といった推測は、事実欄へ混ぜません。

この状態のまま相談できます

• 担当者が異動し、構成図や設計理由が残っていない
• 除外で復旧したが、元に戻すと再発する
• SCIMログは成功でも、SaaS側の表示や権限が違う
• アプリ登録とエンタープライズアプリの対応が分からない
• 監査までに、確認済み事実と未確認事項を分けたい