会社のアプリへサインインした際に「アクセスがブロックされた」と表示され、エラー詳細に AADSTS53003 が記録されている場合、Microsoft Entra IDの条件付きアクセスによって拒否されています。ただし、53003だけでは「どのポリシーの、どの条件に違反したのか」までは分かりません。
原因を特定するには、エラー画面のCorrelation ID、発生時刻、アカウント、対象アプリを控え、Microsoft Entra IDのサインインログから同じイベントを探します。そのうえで「条件付きアクセス」タブを開き、失敗したポリシーとデバイス情報、認証の詳細、実際に要求されたリソースを照合します。([Microsoft Learn][1])
AADSTS53003は条件付きアクセスによるブロックを示す
AADSTS53003のエラー文字列は「BlockedByConditionalAccess」です。これは、サインイン処理において条件付きアクセスポリシーがアクセスを拒否したことを示します。パスワードの入力ミスやパソコンの故障を直接示すエラーではありません。([Microsoft Learn][2])
重要なのは、次のように切り分けることです。
| 確認できること | AADSTS53003だけで確認できないこと |
|---|---|
| 条件付きアクセスがブロックに関係した | どのポリシーが拒否したか |
| Microsoft Entra ID側で拒否された | どの条件を満たさなかったか |
| 管理者によるログ確認が必要 | 端末、場所、認証方法のどれが原因か |
| エラー発生時刻のイベントを調べる必要がある | 利用者側の操作だけで解決できるか |
Microsoft Learnでは、53000はデバイス非準拠、53001はドメイン参加要件、53002は未承認アプリ、53003は条件付きアクセスによるブロックとして区別されています。似た画面が表示されても、エラー番号を確認せずに原因を決めつけないことが大切です。([Microsoft Learn][1])
最初に利用者から受け取る情報
管理者が調査を始める前に、利用者から次の情報を受け取ります。特に発生時刻とCorrelation IDがあると、サインインログの対象イベントを見つけやすくなります。
| 必要な情報 | 記録する内容 | 確認する理由 |
|---|---|---|
| 発生日時 | 日付、時刻、タイムゾーン | 同じ利用者が複数回サインインしている場合にイベントを特定するため |
| アカウント | サインインに使用したメールアドレス | ユーザー名でログを絞り込むため |
| 対象アプリ | Teams、Outlook、社内Webアプリなど | 表示上のアプリとログを対応させるため |
| エラーコード | AADSTS53003など | 他のサインインエラーと区別するため |
| Correlation ID | エラー詳細に表示される識別子 | 特定のイベントを検索するため |
| Request ID | 表示されている場合に記録 | サポート依頼やイベント照合に使用するため |
| 利用環境 | 会社PC、私物端末、ブラウザー、アプリなど | 端末やクライアントアプリの条件を確認するため |
| 接続場所 | 社内、在宅、出張先、VPN利用の有無 | 場所やネットワーク条件を確認するため |
ブラウザーのエラー画面では、「詳細」または「More details」を開くと、サインインログの検索やサポート依頼に役立つ情報が表示される場合があります。画面を閉じる前に、エラー詳細を保存してもらいましょう。([Microsoft Learn][2])
一方、次の情報は受け取ってはいけません。
- パスワード
- Microsoft Authenticatorなどに表示された確認コード
- SMSで届いたワンタイムコード
- 秘密の質問に対する回答
- セキュリティキーや証明書の秘密情報
調査に必要なのはイベントを特定する情報であり、認証情報そのものではありません。
サインインログから拒否されたイベントを探す
必要な権限を確認する
サインインログを確認するには、Microsoft Entra管理センターへ、少なくとも レポート閲覧者（Reports Reader） の権限を持つアカウントでサインインします。一般利用者が自分で条件付きアクセスポリシーを変更することはできないため、管理者または社内の情報システム担当者による確認が必要です。([Microsoft Learn][2])
サインインログを開く
Microsoft Entra管理センターで、次の順に開きます。
Entra ID → 監視と正常性（Monitoring & health）→ サインイン ログ（Sign-in logs）
画面表記は管理センターの言語や更新状況によって異なる場合がありますが、「Sign-in logs」または「サインイン ログ」を開く点は同じです。Microsoftの公式手順でも、この画面から対象のサインインイベントを検索します。([Microsoft Learn][1])
条件を追加してイベントを絞り込む
最初から一覧を目視で探すのではなく、次の順にフィルターを追加すると効率的です。
- 発生日時
- ユーザー名
- Correlation ID
- 条件付きアクセスの結果
- リソース
Correlation IDが分かっている場合は、最優先で指定します。分からない場合は、発生時刻を前後数分程度に絞り、ユーザー名とリソースを組み合わせて探します。
Microsoft Learnでは、サインインログの絞り込み項目として、Correlation ID、条件付きアクセス、ユーザー名、日付、リソースが案内されています。条件付きアクセスのフィルターを「失敗」に限定すると、対象イベントを見つけやすくなります。([Microsoft Learn][2])
同じ時刻のイベントが複数ある場合
TeamsやMicrosoft 365のアプリでは、1回の操作で複数のクラウドリソースへアクセスすることがあります。そのため、同じ利用者、同じ時刻付近に複数のサインインイベントが並ぶ場合があります。
1件だけを見て判断せず、次の項目を比較してください。
- アプリケーション
- リソース
- サインイン結果
- 条件付きアクセスの結果
- Correlation ID
- 発生時刻
- クライアントアプリ
- デバイス情報
表示上はTeamsへのサインインに見えても、実際に拒否された対象がSharePointや別のMicrosoft 365リソースである可能性があります。([Microsoft Learn][2])
「条件付きアクセス」タブで失敗したポリシーを特定する
対象のサインインイベントを開いたら、「条件付きアクセス」タブを選択します。このタブには、そのイベントに対して評価された条件付きアクセスポリシーが表示されます。
確認する順番は次のとおりです。
- 失敗またはブロックに関係したポリシーを確認する
- ポリシー名を開く
- 対象ユーザー、対象リソース、条件、アクセス制御を確認する
- サインインイベント側の情報と照合する
条件付きアクセスの一覧には、成功したポリシー、適用されなかったポリシー、アクセス拒否に関係したポリシーが混在する場合があります。ポリシーが一覧に表示されているだけで、そのポリシーが拒否原因だと判断しないでください。
Microsoft Learnでは、対象イベントの「条件付きアクセス」タブから、サインインを中断したポリシーを確認し、ポリシー名を選択して設定内容を詳しく調査する手順が案内されています。([Microsoft Learn][1])
ポリシー詳細で確認する項目
| 確認項目 | 見る内容 |
|---|---|
| ユーザーまたはワークロードID | 対象ユーザーやグループに含まれているか |
| ターゲットリソース | 実際に要求されたリソースが対象か |
| ネットワークまたは場所 | 接続元が対象条件に一致しているか |
| デバイスプラットフォーム | Windows、iOS、Androidなどが対象か |
| クライアントアプリ | ブラウザー、モバイルアプリ、デスクトップクライアントなど |
| デバイスフィルター | 端末属性が条件に一致しているか |
| アクセス制御 | ブロック、準拠デバイス、認証要件など、何が要求されているか |
条件付きアクセスポリシーは、設定された条件がすべて満たされるか、条件が未構成の場合に適用されます。ポリシー詳細では、サインイン時に収集された情報と、ポリシー側の条件判定を対照して確認します。([Microsoft Learn][2])
端末準拠が原因かを確認する
ポリシーに「デバイスを準拠としてマークする必要がある」などの要件が含まれている場合は、サインインイベントの「デバイス情報（Device Info）」を確認します。
見るべきポイントは次のとおりです。
- デバイス情報が取得されているか
- 対象となった端末が想定した会社端末か
- ポリシーが要求する参加状態と一致しているか
- 準拠状態がポリシー要件を満たしているか
- OSやブラウザーが想定したものか
たとえば、会社管理PCのみ許可するポリシーがある状態で、私物PCや管理登録されていない端末からアクセスすると、必要なデバイス条件を満たせない可能性があります。
ただし、「デバイス情報が空欄だった」「準拠していなかった」という一点だけで、端末故障と判断してはいけません。ポリシーがその端末状態を実際に要求していたか、失敗したポリシーの設定と必ず照合します。
サインインイベントでは、「基本情報」「場所」「デバイス情報」「認証の詳細」「追加情報」から、条件付きアクセスの評価に使われたクライアントやデバイスの情報を確認できます。([Microsoft Learn][2])
認証条件が原因かを確認する
認証に関する要件が設定されている場合は、「認証の詳細（Authentication Details）」を確認します。
ここでは、ポリシーが要求した認証制御と、実際のサインインで成立した認証内容を対照します。確認の考え方は次のとおりです。
- ポリシー側で何の認証が要求されているか
- 利用者がその認証操作を完了したか
- 別のサインインセッションや既存の認証状態が使われていないか
- 対象アプリやリソースまで認証結果が適用されているか
- 認証処理より前に「アクセスをブロック」が適用されていないか
明示的な「アクセスをブロック」が適用されている場合、認証をやり直すだけでは解決しません。一方、必要な認証操作が完了していない場合は、利用者側の再認証や登録状況の確認が必要になることがあります。
ログの情報だけで理由を特定できない場合は、サインインイベントの診断機能や条件付きアクセスのWhat Ifツールを補助的に利用できます。([Microsoft Learn][2])
Teamsなどではアプリ名だけでなくResourceを確認する
Microsoft 365では、画面上で利用しているアプリと、条件付きアクセスが評価したリソースが異なる場合があります。
たとえば、利用者はTeamsを開いているだけでも、処理の途中で次のようなリソースへアクセスすることがあります。
- Teamsのチャット
- Outlookの予定表
- SharePoint上のファイル
- Excelドキュメント
- その他のMicrosoft 365リソース
このとき、Teams自体を対象にしたポリシーではなく、SharePointなどの依存先リソースを対象にしたポリシーによってブロックされることがあります。Microsoft Learnでも、アプリケーション名だけでなく、サインインによって呼び出されたリソースを確認するよう案内されています。([Microsoft Learn][1])
調査時は、次の2つを分けて記録してください。
| 項目 | 意味 |
|---|---|
| Application | 利用者が操作したクライアントやアプリ |
| Resource | そのアプリがアクセストークンを要求した対象サービス |
条件付きアクセスのポリシー名にTeamsと書かれていなくても、Teamsから呼び出されたリソースがポリシー対象なら、利用者にはTeamsのエラーとして見えることがあります。
対応する画面で利用できる場合は、ポリシー詳細のResourceやAudienceも確認します。Audience情報は、そのサインイン処理で要求された複数のリソースのうち、どれがポリシーの対象になったかを調べる手掛かりになります。([Microsoft Learn][2])
よくある原因の読み分け方
次の表は、ログを読む際の判断例です。実際の原因は、対象イベントとポリシー設定の組み合わせで確定してください。
| ログとポリシーの状態 | 考えられる原因 | 次に確認すること |
|---|---|---|
| 失敗したポリシーのアクセス制御が「ブロック」 | 意図的なアクセス拒否 | 対象ユーザー、リソース、場所などの割り当てが適切か |
| 準拠デバイスが必要で、端末が要件を満たしていない | 端末管理または準拠状態の問題 | Intune管理状態、準拠判定、対象端末が正しいか |
| ハイブリッド参加済み端末が必要 | 端末の参加状態が要件と不一致 | Device Infoとポリシー要件を照合 |
| アプリ保護ポリシーが必要 | 利用アプリや端末が保護対象外 | クライアントアプリと適用される管理ポリシーを確認 |
| 認証要件を満たしていない | 必要な認証が成立していない | Authentication Detailsと要求された制御を照合 |
| アプリ名とResourceが異なる | 依存先サービスのポリシーで拒否 | Resource、Audience、同時刻の関連イベントを確認 |
| 場所やネットワーク条件に一致 | 接続元が許可対象外 | IPアドレス、場所、VPNの利用状況を確認 |
初手で全利用者のポリシーを解除してはいけない
原因が分からないまま、全利用者を対象に条件付きアクセスポリシーを無効化するのは避けるべきです。まず対象イベントから失敗したポリシーを特定し、影響範囲と必要な変更を確認します。
特に「すべてのユーザー」「すべてのリソース」を対象とした設定は、組織全体や管理者自身をロックアウトする危険があります。準拠デバイスやアプリ保護ポリシーを全体へ一律に要求すると、設定を修正する管理者まで管理画面へ戻れなくなる可能性があります。([Microsoft Learn][2])
変更が必要な場合も、次の順で対応します。
- 原因になったサインインイベントを保存する
- 失敗したポリシーを特定する
- 対象ユーザー、リソース、条件を確認する
- 本来許可すべきアクセスかを業務面から判断する
- 必要最小限の設定変更を行う
- 同じ条件で再度サインインを確認する
- 変更後のサインインログを確認する
「一時的に通すため」という理由だけで対象を広く除外すると、別の利用者やアプリにも意図しないアクセスを許可する可能性があります。
緊急アクセス用管理者の締め出しも防ぐ
条件付きアクセスの変更では、通常の管理者だけでなく、緊急アクセス用アカウントまで同じポリシーでブロックしないようにします。
Microsoftは、サインインをブロックまたは制限する条件付きアクセスポリシーから緊急アクセス用アカウントを除外し、定期的にサインインできることを検証するよう案内しています。通常の管理者が全員利用できなくなった際に、緊急アクセス用アカウントまで使えなければ、組織の設定を復旧できなくなるためです。([Microsoft Learn][3])
ポリシーを変更する前に、最低限次の点を確認します。
- 緊急アクセス用アカウントが用意されているか
- ブロックまたは制限ポリシーの対象外になっているか
- 資格情報を安全に保管しているか
- 現在もサインインできるか
- 使用時の監視と記録方法が決まっているか
利用者が管理者へ渡す情報のテンプレート
利用者自身でサインインログを確認できない場合は、次の形式で情報システム担当者へ連絡すると調査が進みやすくなります。
件名：AADSTS53003によるサインイン拒否の調査依頼
発生日時：
<日付・時刻・タイムゾーン>
利用アカウント：
<会社のメールアドレス>
対象アプリ：
<Teams、Outlook、社内Webアプリなど>
エラーコード：
AADSTS53003
Correlation ID：
<エラー詳細に表示された値>
Request ID：
<表示されている場合>
利用端末：
<会社PC、私物PC、スマートフォンなど>
利用方法：
<ブラウザー名、デスクトップアプリ、モバイルアプリなど>
接続環境：
<社内、在宅、出張先、VPN利用の有無>
実施済みの操作：
<再サインイン、アプリ再起動など>エラー画面のスクリーンショットを添付する場合は、パスワード、確認コード、個人情報などが写っていないことを確認してください。
AADSTS53003は該当時刻のサインインイベントから原因を確定する
AADSTS53003が表示された場合、最初に行うべきことは端末の初期化やパスワード変更ではありません。発生時刻、アカウント、対象アプリ、Correlation IDを記録し、Microsoft Entra IDのサインインログから該当イベントを特定します。
対象イベントを開いたら、次の順で確認してください。
- 「条件付きアクセス」タブで失敗したポリシーを特定する
- ポリシーが要求する条件とアクセス制御を確認する
- Device Infoで端末状態を照合する
- Authentication Detailsで認証内容を照合する
- アプリケーションだけでなくResourceとAudienceを確認する
- 原因に対応した最小限の修正を行う
53003は「条件付きアクセスが拒否した」という入口の情報です。正確な原因は、エラー番号ではなく、その時刻のサインインイベントとポリシー評価結果に記録されています。([Microsoft Learn][1])
[1]: https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/troubleshoot-conditional-access “条件付きアクセスでのサインインに関する問題のトラブルシューティング – Microsoft Entra ID | Microsoft Learn”
[2]: https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access “Troubleshooting sign-in problems with Conditional Access – Microsoft Entra ID | Microsoft Learn”
[3]: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access “Manage emergency access admin accounts – Microsoft Entra ID | Microsoft Learn”
コメント