Forum Discussion
Entra ID 53003: How to identify primary authentication when Authentication Details are empty?
We are investigating repeated interactive Microsoft Entra ID sign-ins with the following pattern:
- ErrorCode: 53003 (BlockedByConditionalAccess)
- isInteractive: true
- AppDisplayName: OfficeHome
- Authentication requirement: Multifactor authentication
Conditional Access correctly blocks these requests because they originate outside our trusted locations.
We have already confirmed through controlled testing that the authentication flow can reach 53003 after the correct credentials are provided. Our current problem is different:
We need to determine what mechanism satisfied the primary/first authentication factor for the observed 53003 events.
For these events, Authentication Details are empty:
- Authentication method: empty
- Authentication method detail: empty
- Result detail: empty
Therefore, we cannot determine whether primary authentication was performed using a password, an existing token/session claim, PHS, PTA, federation, Seamless SSO, or another mechanism.
Our questions are:
1. Is there any tenant-visible telemetry that can identify the primary authentication mechanism when AuthenticationDetails is empty?
2. Can fields such as AuthenticationProcessingDetails, AuthenticationProtocol, IncomingTokenType, OriginalTransferMethod, or AuthenticationMethodsUsed reliably distinguish between password validation and reuse of an existing authentication/token?
3. If additional authentication infrastructure is used:
- can PTA Authentication Agent logs be correlated using RequestId or CorrelationId?
- should Seamless SSO generate a corresponding Kerberos 4769 event for AZUREADSSOACC$?
- should federated authentication be traceable in AD FS logs?
4. For Password Hash Synchronization, is there any tenant-visible telemetry confirming that Entra ID actually validated the password for a specific sign-in request?
5. If this information is not exposed to the tenant, can Microsoft Support retrieve backend authentication telemetry for a specific Sign-in ID / RequestId / CorrelationId and determine how primary authentication was satisfied?
Our goal is not to determine why Conditional Access generated 53003 — that part is already understood.
We specifically need to identify what satisfied primary authentication before the Conditional Access evaluation.
1 Reply
Empty authentication details on a 53003 are expected more often than not. That list is filled in as each step completes, and when Conditional Access blocks the request, the log often records the block before any method detail is written. So an empty field does not tell you the primary factor, but you can usually work it out from other evidence:
- Look at the other events with the same CorrelationId or SessionId. Earlier events in that session, such as a 50074 or 50076 (MFA required), only appear after primary authentication succeeded, and a prior successful event may show the method. Also check the non-interactive sign-ins and the service principal tabs for the same session, which are easy to miss.
- Compare these fields across events (Graph signIns, or the JSON view): tokenIssuerType (Microsoft Entra ID versus federated, which points at ADFS), incomingTokenType, authenticationProtocol, originalTransferMethod, and the user agent and client app. A federated sign-in shows ADFS as issuer, and a session or token reuse tends to show an existing token type instead of a fresh credential.
- Check the infrastructure on the other side. For Seamless SSO, the domain controller should log a Kerberos service ticket request (event 4769) for AZUREADSSOACC$ at the same time. For PTA, check the Authentication Agent event log on the agent servers around the timestamp, since agent logs do not carry the Entra CorrelationId so you have to match by time and user. For federation, check the ADFS Admin and Security logs the same way.
- Check Entra ID Protection risk detections for the same user and IP, such as password spray, unfamiliar sign-in properties or anomalous token.
One more point: if the credentials were valid and the request came from outside your trusted locations, I would treat it as a possible credential compromise even though Conditional Access stopped it. Reset the password, revoke sessions, and review that user's sign-ins for the following days.
