Azure conditional access policies provide a broad range of settings that administrators can utilize to enforce protections in their environment. It is common to see policies that attempt to control mobile device access to Exchange Online – and apply to a common protocol Exchange Active Sync.
I recently worked an interesting escalation where a customer was reporting a behavior I had not previously noticed. In this case the customer created a policy that applied to mobile devices and Exchange Active Sync – the policy contained a set of criteria to block access. The specifics of the overall policy did not matter – just that it contained a block action and applied to Exchange Active Sync.
When we reviewed the sign on events for a particular user – we discovered the following:
- The sign on was successful.
-
Conditional access failed due to meeting a policy where a block was applied.
Here is a sample logon from the sign on logs we were able to gather from the customer.
Date:2021-06-21 02:30:18
User:UPN
User Name:NAME
Application:Office 365 Exchange Online
Status:Success (0)
Is Interactive:True
IP address:IPAddress
Client App:Exchange ActiveSync
Device ID:N/A
Device OS:Android
Device Browser:N/A
Location:El Progreso, Yoro, HN
Correlation Id:af236446-b0f4-47e5-9b00-ddbcce28baba
Conditional Access:failure
Request Id:73ceb107-3015-496e-9715-1882316c7301
MFA Required:No
Risk State:none
Risk Level (aggregate):none
Risk Level (real-time):none
Risk Detail:none
Risk Event Types:N/A
Alternate SignIn Name:UPN
Naturally this lead to the question of how a sign on could be “success” and conditional access “failed”. Typically when conditional access encounters a policy that applies with a block action – the sign on is “failed” and conditional access is “failed”. The expectation in this instance was that the sign on would be blocked in Azure Active Directory – this information seems to contradict that expectation.
In this particular instance what we were observing is expected. When a conditional access policy applies to Exchange Active Sync and contains a block action – Azure Active Directory does not block the access. In this instance a good user name and password was passed so an access token was granted. When the conditional access policy was evaluated and a determination that a block should occur was made – the overall request was tagged with a blocked action. Unlike other conditions where Azure Active Directory performs the block – the request is forwarded to Exchange Online tagged with the blocked action. Azure AD relies on Exchange Online to process the block and prevent the device from accessing any data.
Why is this by design? When it comes to mobile devices Azure Active Directory and Exchange Online share some overlap. In Exchange Online you also have the concept of approved devices, quarantined devices, and other device policies. By passing the flags into Exchange Online this allows Exchange Online to evaluate the device and any policies that may exist there. For example, repeated bad logon attempts or bad user name / passwords may result in the device being quarantined in Exchange Online.
Ultimately this issue was discovered because the user was flagged in Cloud App Security. Cloud App Security was identifying a successful logon from a location where logons were not desired. In this instance – that’s correct. The logon was successful and did occur from a location the user was prevented access.
In the long term a change is being evaluate to more accurately reflect the conditions. The anticipated change will log a failure for the sign on when the protocol is Exchange Active Sync and the conditional access status is failed. This should allow for more accurate reporting and less ambiguity about the outcome of the sign on operation from an Azure Active Directory standpoint.