Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Signins: Login status = success but Conditional access = failed?

Steel Contributor

 

When looking at the Sign-in logs, I see entries with Status = success while the Conditional Access = failure.

 

Shouldn't the status say Failure as well when the conditional access is blocking the sign-in?

 

bartvermeersch_1-1631711789490.png

bartvermeersch_2-1631711811890.png

 

 

9 Replies
Also have a lot of these on my tenants.
To my understanding, and I can be wrong :), when you see a status of Success, it's because the credentials were valid. Regardless of the CP.
If I see the entry you shared I conclude that the sign-in was allowed, it is just that the CP failed to match the condition.

@Andres Gorzelany Thank you for your feedback. It is a bit ambiguous because the conditions do match in this case, but the result of the CP is to block access.

 

bartvermeersch_0-1631714949611.png

 

Oh I see what you mean... maybe the "status" should honor also what happened with the CP, but appears not to be the case
I think we can only conclude that a sign-in was successful to the user when Status = Success and Conditional Policy != Failure (Success or Not Applied)

@bart vermeersch Did you ever figure out an answer for this one?

I encountered the same issue while setting up a CA to disable legacy auth for Exo.

After adding the user to the CA, login status was success but conditional access result was failure

(policy setting was to block access when using legacy auth protocols).

 

To countercheck the results I went to Exo PowerShell to check the status of the mobile device the user was using and generating this error:

Connect-ExchangeOnline

Get-MobileDevice -Mailbox "<upn>" | fl deviceuseragent,deviceaccessstate,DeviceAccessStateReason,clienttype,whenchanged


DeviceUserAgent : Android-SAMSUNG-SM-N960F/101.10
DeviceAccessState : Quarantined
DeviceAccessStateReason : AadBlockDueToAccessPolicy
ClientType : EAS
WhenChanged : 2022. 01. 14. 10:02:18

 

As you can see in the results, the access was blocked due to the CA

 

@bart vermeersch I realize this is an old post but Conditional Access policies are enforced after first-factor authentication is completed, which might explain things :)

I ended up talking through this with support. The only situation where I was seeing this was connections using ActiveSync. Support told me basically the due to Exchange not being not being aware of the CA results, that's why there is this disconnect/mismatch. I'm told the end result is the connection actually gets blocked, but have not manually tested to verify it. There's a request into the appropriate teams to make the logging more coherent.
I have a similar case, perhaps even more confusing.
Status: Success
Failure reason: Other.
Conditional Access: Not Applied
Client App: Browser
MFA result: empty
MFA auth method: empty
MFA Auth detail: empty
Sign-in Error: empty

So, how to interpret this correctly, was this a successful login? Was this a blocked login?
Inconclusive?
I believe i can explain this behavior.

The Conditional Access block action for ActiveSync is unique. It does not fail the sign in with Azure AD, it signals Exchange to perform a quarantine on the device. The user is able to successfully configure the AS connection, but rather than get access to anything they see a single email stating that ActiveSync is not permitted. This is very similar to the 'Require approved client app' condition.

Rest assured that the user is effectively blocked from setting up a working AS account, but since the sign in is not immediately failed like most CA policies it is technically correct for it to show as a successful sign-in. It will also result in frequent sign-ins if the user doesn't remove the account, which may look like active usage.

I'm not sure how this will be handled when Microsoft finally block legacy protocols permanently, but this is the current behavior as tested in October 2022.