Exchange SE - Hybrid - Modern Authentication - Conditional Access

Question

Exchange SE - Hybrid - Modern Authentication - Conditional Access

HanakJ 86

I enabled Modern Authentication on Exchange On-premise (version SE) according to Microsoft’s procedure. I would therefore like to use Conditional Access. However, when I use Microsoft Outlook on iOS, an Exchange (hybrid) profile is created during sign-in, which I believe is expected behavior.

The problem is that in the Entra Sign-in log, I only see a sign-in to the Microsoft Authentication Broker application, not to the Outlook application. Because of this, I'm unable to configure Conditional Access policies targeting the Office 365 Exchange Online resource (ID: 00000002-0000-0ff1-ce00-000000000000).

When I tried the native Apple Mail app, the logs show Apple Internet Accounts (which is perfect) attempting to access the Office 365 Exchange Online resource. This is great, but Conditional Access stopped working after I updated the Outlook app on iOS. Is there any way to make this work as expected?

Thanks a lot

https://v4.hkg1.meaqua.org/en-us/exchange/clients/outlook-for-ios-and-android/use-hybrid-modern-auth

1 answer

Your answer

Answer 1

Hani-Ng 5,865 Microsoft External Staff Moderator

Hi HanakJ

Thank you for posting your question in the Microsoft Q&A forum regarding Conditional Access in your hybrid Exchange environment after enabling Modern Authentication.

Based on your description, I would like to share some information from my side, which I hope proves useful and kindly let me know if I’m mistaken.

In a Hybrid Modern Authentication (HMA) configuration, Outlook for iOS uses a distinct architecture compared to native mail apps. When signing in, Outlook utilizes the Microsoft Authentication Broker. Consequently, Entra ID sign-in logs display the Broker application rather than the specific "Office 365 Exchange Online" resource.

Because the initial authentication request is handled by the Broker (often scoped to the wider Office 365 suite or device management), Conditional Access policies that strictly target the Exchange Online resource ID often result in a "Not Applied" status.

By contrast, Apple Mail uses Exchange ActiveSync (EAS) and connects directly to the Exchange Online endpoint, which is why your existing policies work there.

Outlook for iOS does not connect directly to the on-premises server for authentication. It routes through the Outlook Mobile Cloud Service in Azure, using the Microsoft Authentication Broker to handle the token exchange.

The Broker requests access to a broader scope (the Office 365 suite) to handle Exchange, OneDrive (attachments), and Intune protection simultaneously. A policy targeting only "Exchange Online" is too narrow for this initial handshake.

Here are some recommendations you can try:

Adjust Conditional Access Scope: To ensure the policy triggers for the Authentication Broker, you can consider widening the Target Resource. In your Conditional Access policy, change the Target Resource from "Office 365 Exchange Online" to "Office 365" (which includes Exchange, SharePoint, and Teams). This catches the Broker's authentication request regardless of which underlying service it contacts first.
Enforce "Require Approved Client App" or "App Protection": Once the scope is widened, you can enforce security > Under Grant controls, select Require approved client app. This blocks the "Apple Internet Accounts" (native mail) if desired, and forces the use of Outlook for iOS, ensuring the session is managed.
Verify Client App Conditions: Kindly ensure your policy targets Mobile apps and desktop clients and specifically checks Modern authentication clients.

(Please do not select "Exchange ActiveSync" if you are trying to target the Outlook app itself, as Outlook uses Modern Auth)

For additional information related to your mentioned resource (ID: 00000002-0000-0ff1-ce00-000000000000), you can refer: Resolve interaction issues between Teams and Exchange Server - Microsoft Teams | Microsoft Learn

I hope my answer is helpful to you. If you have any further concerns, please let me know in the comment section.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

HanakJ 86 Reputation points

2025-11-20T08:09:58.83+00:00

Hi, thanks for reply.

So, to summarize, I cannot set up conditional access per individual application. This is because MS Teams, Outlook, OneDrive, etc., all authenticate through the Authenticator app in the same way. Therefore, I cannot say that if a user signs into MS Teams, an App Protection Policy is not required, but if they sign into their mail, then an App Protection Policy is mandatory. Is there a workaround for this, because I believe that before the update of the Outlook application on iOS, I was able to see the sign-in via Outlook Mobile in the sign-in log.
HanakJ 86 Reputation points

2025-11-20T17:52:17.0666667+00:00
I've been thinking, and a few things came to mind.

Device Compliance and App Restrictions

I have a question regarding the following condition: The device must have App Restriction. In the case of iOS, does the Authenticator app have to be installed on the device? And in the case of Android, does the Company Portal app have to be installed, and must the device be enrolled into Intune?

Hybrid Modern Authentication and Sign-in Logs

I would also like to ask: If I have Hybrid Modern Authentication (HMA) enabled, and users are signing in to their On-Premise mailbox, I see the Bearer method in the Outlook authentication instead of Nego*. This is likely correct (the user signs into the mailbox and everything works). My question is, should I see this sign-in in the Sign-in log in Entra ID (formerly Azure AD)?

Thanks for help
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-11-21T06:37:54.82+00:00
Hi HanakJ

Thank you for your response.

I would like to share some information based on my research and knowledge regarding your concerns.

Device Compliance and App Restrictions

iOS: If your Conditional Access policy includes “Require App Protection Policy” or “Require approved client app”, the Microsoft Authenticator app must be installed for sign-in because it handles brokered authentication and MFA. However, device enrollment into Intune is not mandatory unless your policy also requires “Require compliant device”.

Android: For app protection and brokered authentication, the Company Portal app must be installed. If your policy requires device compliance, then the device must be enrolled in Intune. If you only require app protection (MAM without enrollment), enrollment is not required, but Company Portal is still needed for the app protection policy to apply.

Hybrid Modern Authentication and Sign-in Logs

When Hybrid Modern Authentication (HMA) is enabled and users sign in to their on-premises mailbox, Outlook uses Bearer tokens instead of legacy Nego* methods. This is expected and confirms Modern Auth is working.

Sign-in logs in Entra ID: You will only see sign-ins for cloud resources (ex: Exchange Online, Authentication Broker). If the mailbox is on-premises, the authentication happens locally after token validation, so you will not see the mailbox access in Entra logs only the initial token issuance.

And you’ve summarized the situation correctly. In the current architecture, Outlook for iOS/Android, Teams, OneDrive, and other Microsoft apps authenticate through the Microsoft Authentication Broker, not directly via their own app identity. Because Conditional Access evaluates the resource and the broker handles the sign-in, you cannot apply different App Protection Policy (APP) requirements per app based on sign-in logs.

Previously, older versions of Outlook mobile used a direct OAuth flow, so you could see “Outlook” in the sign-in logs. After updates, the broker-based flow became standard for security and consistency across apps.

You are concerned about whether there is a workaround. Yes, there is, but not through Conditional Access alone. Here are some recommendations you can consider:

App Protection Policies via Intune: Instead of relying on sign-in logs, you can scope APP policies by app name in Intune. For example, apply stricter policies to Outlook while leaving Teams less restrictive. Microsoft Docs – App Protection Policies

Conditional Access “Require approved client app”: This ensures only Microsoft-approved apps (like Outlook, Teams) can access resources. However, it cannot differentiate between apps for different policy requirements. Microsoft Docs – Require Approved Client Apps

Combine CA and Intune

Use CA for baseline access control (ex: require approved apps, MFA).

Use Intune APP for granular data protection per app.

I hope what I’ve shared is helpful to you, and if you have any further questions, please feel free to leave a comment.
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-11-24T02:10:03.3233333+00:00

Hi HanakJ

I just wanted to quickly check in to see if you need any additional information regarding this matter. Please don’t hesitate to reach out!
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-11-26T01:22:05.5733333+00:00

Hi HanakJ

I hope you’re doing well.

Just checking in to see if you've had a chance to check my previous reply. Please let me know if you have any further questions.
HanakJ 86 Reputation points

2025-12-01T12:04:55.0166667+00:00

Thank you very much for all your answers. I have one more question — I would like to configure the following setup.

If a user has an iOS/Android device enrolled in Intune, they should be allowed to use native applications (of course they must meet the required conditions and the device must be compliant). If the device is not compliant or is not enrolled in Intune, the user should only be allowed to use Outlook for iOS/Android, because the App Protection Policy works only with this application.

I tried creating a Conditional Access policy where the grant conditions were “Require device to be marked as compliant” + “Require approved client app,” and I selected the option “Require one of the selected controls.” However, this doesn’t work at all. I also considered creating a dynamic group to automate the logic, but most likely we will end up switching the user between two different Conditional Access policies based on the compliance state check.
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-02T06:38:24.3266667+00:00
Hi HanakJ

Thank you for your response.

Based on my understanding, the reason your previous attempt "Require one of the selected controls" likely failed or acted unpredictably is usually due to Exchange ActiveSync (EAS).

Native mail apps often use the EAS protocol, which does not support the "Require Approved Client App" or "App Protection Policy" controls. If you mix EAS and Modern Auth traffic in a single policy with those controls, the policy tends to block traffic that should be allowed.

To achieve your expected behavior, Allow Native Apps only if Compliant, Allow Outlook on any device (via MAM) you need to split this into two separate Conditional Access policies: one for legacy ActiveSync (Native Mail) and one for Modern Authentication (Outlook).

Here is the recommended configuration you can consider:

Policy 1: Secure Native Mail (ActiveSync)

Target Resource: Office 365 Exchange Online

Conditions:

Client Apps: Select only "Exchange ActiveSync clients". (Uncheck everything else).

Grant:

Select "Require device to be marked as compliant".

Note do NOT select App Protection here.

Then, unmanaged devices trying to use Native Mail via ActiveSync are blocked immediately. Managed devices are allowed.

Policy 2: Modern Auth (Outlook & Modern Native): This policy handles Outlook and modern native mail connections. This is where we use the "OR" logic.

Target Resource: Office 365 (Suite)

Conditions:

Device Platforms: iOS, Android.

Client Apps: Select only "Mobile apps and desktop clients" + "Modern authentication clients".

Grant:

Select "Require device to be marked as compliant" and "Require app protection policy".

Select "Require one of the selected controls".

And the way these apply to your users:

Unmanaged Device using Outlook: Allowed. Even though the device is not compliant, Outlook satisfies the "App Protection" requirement > the sign-in is accepted.

Managed Device using Native Mail: Allowed. Even though Native Mail does not support App Protection, the device is compliant > the sign-in is accepted.

Unmanaged Device using Native Mail: Blocked. The device is not compliant, and the app does not support App Protection. Since neither condition is met, access is denied

I hope this information proves helpful.
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-03T06:45:35.3633333+00:00

Hi HanakJ

May I ask if you have any further questions regarding this matter? If yes, please feel free to reach out!
Dora-T 8,520 Reputation points Microsoft External Staff Moderator

2025-12-05T07:23:55.2566667+00:00

Hi HanakJ

I’m following up to see if you’ve had a chance to review Hani's suggestion. Let us know if you need further assistance.
HanakJ 86 Reputation points

2025-12-05T09:26:59.3733333+00:00
Scenario:

iOS – the device is not enrolled in Intune. Launching the native Mail application (iOS)

I select the Microsoft Exchange provider.

The application prompts: “Do you want to sign in to your Exchange account ‘domain’ using Microsoft?”

I choose Sign in → I am redirected to the Entra sign-in page.

The policy enforces that the device must be enrolled in Intune. So I proceed through the Company Portal, the device becomes enrolled, and everything works correctly.

In the on-premises Exchange, I can see the iPhone device in Mobile Device Details, model iPhone15C2.

A question came to my mind:

If I want users to authenticate only through these two Conditional Access policies, what prevents them from manually entering the ActiveSync server address into the app and signing in that way—effectively bypassing the Entra sign-in?

Microsoft’s documentation states that if I want to block this, I should configure:

Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

and then:

If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {

New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

This allows only OutlookService, but when testing the native iOS Mail application, I have to allow the device type iPhone model iPhone15C2.

This doesn’t feel right, because the Block policy loses its purpose, and the user would still be able to bypass the restriction by manually typing the AES on-prem server address.

What comes to mind is blocking HTTPS traffic to our on-prem mail server on the firewall and allowing access only to Exchange Online.

I think we will end up allowing users to use only Outlook for iOS/Android and creating a block policy on the on-premises environment.

I just wanted that if a user decides to enroll their device and it is compliant, then they can use any mail client they want, because in case the device is lost, we are able to wipe it remotely.
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-08T13:14:22.1433333+00:00
Hi HanakJ

Thank you for sharing your scenario.

You correctly observed that users can manually configure the ActiveSync server address to authenticate directly with on-premises Exchange. This method utilizes Basic Authentication, which occurs independently of Entra ID and therefore does not trigger Conditional Access evaluation

If you asked whether you should block HTTPS traffic to your on-premises server to prevent users from bypassing Conditional Access, based on my information and research, I do not recommend blocking HTTPS traffic. Native mail apps (like iOS Mail) connect directly from the phone to your on-premises server. If you block this traffic on the firewall, native mail will stop working entirely, even for your compliant, enrolled devices.

While Outlook Mobile routes traffic through Azure, native mail apps on iOS/Android connect directly from the device to your on-premises server URL. If you block this traffic at the firewall, native mail will stop functioning for your enrolled/compliant devices.

Here is my recommendation you can refer to:

Disable Basic Authentication: The manual configuration bypass works because the Exchange server currently accepts Basic Authentication (Username + Password). To force all users through your Conditional Access policies (and thus force enrollment), you must ensure that Modern Authentication (OAuth) is the only allowed method.

Disable Basic Authentication for ActiveSync (On-Premises): Configure your on-premises Exchange ActiveSync Virtual Directory to disable Basic Authentication. If a user attempts to manually configure the app using a password, the connection will be rejected by the server. They will be forced to use the "Sign in with Microsoft" option, which redirects to Entra ID, triggers your Conditional Access policy, and enforces Intune enrollment.

Utilize the Intune Exchange Connector: Instead of manually whitelisting device models (which creates security gaps), use the Intune On-Premises Exchange Connector.

Set your ActiveSync Organization Settings to Block or Quarantine.

When a user enrolls their device in Intune, the Connector automatically communicates with your Exchange server to allow that specific device ID.

This ensures that only devices that have successfully completed enrollment are permitted to sync.

By disabling Basic Authentication on the ActiveSync virtual directory, you eliminate the bypass. Users will have no choice but to authenticate via Entra ID, ensuring your Conditional Access policies are always applied.

Additionally, this summary is based on my findings from the community and several relevant threads. However, it may not accurately reflect the behavior in question. To help you reach your goal more effectively, I recommend posting a thread on the Microsoft Tech Community forum. It’s a great platform for deeper technical discussions and connecting with individuals who have hands-on experience and expertise. They’re best positioned to provide guidance and valuable insights on this topic.

Apologies for redirecting you to the related development team support as the moderators in this community have limited resources to check the backend information, and to get the fast and better assistance we requested for it.
HanakJ 86 Reputation points

2025-12-08T14:14:01.03+00:00

Hello, I found that Intune Exchange Connector is deprecated (https://v4.hkg1.meaqua.org/en-us/troubleshoot/mem/intune/device-protection/troubleshoot-exchange-connector).

If I were to disable Basic Auth on Exchange On-Premise, would the native application then use Modern Auth (and at that point Conditional Access would decide whether the user has an assigned App Policy or whether the device is compliant)?

Thanks
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-09T12:00:47.78+00:00

Hi HanakJ

Thank you for your update!

When Basic Authentication is disabled on your On-Premises Exchange, the native mail app is required to switch to Modern Authentication (OAuth).

The resulting flow will be: The sign-in request is redirected to Entra ID > Your Conditional Access policies are immediately triggered > Entra ID checks if the device is Compliant (for Native Mail) or has App Protection (for Outlook).

If the conditions are met, Entra ID issues the token. If not, Entra ID blocks the request.

Therefore, you do not need the Intune Exchange Connector. By disabling Basic Auth, your Conditional Access policies effectively become the sole gatekeeper for your On-Premises server.
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-10T12:19:08.75+00:00

Hi HanakJ

I just wanted to quickly check if you’ve had a chance to review my answer. As I mentioned above, my answers are based on my own experience and research, so if they cannot fully help you resolve your issue, you might consider posting a thread on the Microsoft Tech Community forum.

If you find my recommendations at least partially helpful, please consider marking my answer as accepted or kindly upvote it so it can serve as a helpful reference for others facing similar challenges. Your feedback also contributes to building a stronger and more supportive community.

Thank you!
Hani-Ng 5,865 Reputation points Microsoft External Staff Moderator

2025-12-11T09:12:06.2966667+00:00

Hi HanakJ

I just wanted to follow up to see whether you have already created threads on Tech Community successful. If you need any assistance from me, please feel free to let me know.

Share via

Exchange SE - Hybrid - Modern Authentication - Conditional Access

1 answer

Your answer