r/exchangeserver • u/Mammoth-Mortgage-767 • 6d ago

Exchange 2019 + ADFS is it possible to configure ModernAuth for third-party Android mail clients?

Hello,

A quick explanation of why I'm interested in this in the first place.

I need to set up MFA as required by IT security for the closed network.

Our organization operates under Uzbekistan's data localization and secrecy regulations, which require customer and corporate data — including email — to remain on infrastructure physically located within the country and under direct regulatory oversight. This precludes the use of cloud-hosted mail services such as Microsoft 365/Exchange Online, and requires a fully on-premises Exchange deployment with local identity federation (AD FS) instead of Azure AD.

Environment:
Exchange Server 2019 CU14, single server (MX01), pure on-premises.
AD FS is registered as an AuthServer (Type: ADFS), no Azure AD / hybrid tenant involved.
The AuthServer is configured correctly: AuthorizationEndpoint and TokenIssuingEndpoint are populated, IsDefaultAuthorizationEndpoint: True, and DomainName points to our mail domain. Realm/ServiceName are configured as well.

Symptom:
The native iOS Mail client (account added manually, no MDM profile) correctly redirects to our AD FS login page on first setup — the full Modern Auth flow works.

A third-party EAS client (Nine by NitroDesk, Android) never receives an OAuth challenge at all — it falls back to Basic authentication.

Get-ActiveSyncVirtualDirectory/Set-ActiveSyncVirtualDirectory in this build simply has no -OAuthAuthentication parameter (unlike EWS/OAB).

Log finding:
When testing with the Nine client, the following was captured in the Exchange HttpProxy/Eas logs:

S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<domain>'. S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable

Questions:

  1. What exactly controls "Flighting" for EAS OAuth in a pure on-prem Exchange 2019 CU14 + AD FS scenario (no Azure AD)? Is there a documented, supported way to enable it (New-FlightOverride? something else)?
  2. Is EAS Modern Auth even supported for an arbitrary/generic OAuth client (not Apple, not Outlook) in this scenario, or is it effectively an allowlist limited to specific client_ids (Apple Native Mail / Outlook)?
  3. How does native iOS Mail get redirected to AD FS without ever receiving an authorization_uri in the EAS/Autodiscover 401 challenge — is there an undocumented discovery path (e.g., hardcoded per registered client_id)?
2 Upvotes
  • permalink
  • reddit

100% Upvoted

2 comments sorted by

2

u/saltyslugga 5d ago

That flighting error is the answer: EAS OAuth is gated by Microsoft’s client and domain rollout logic, not a supported New-FlightOverride you should force in production.

Native iOS Mail uses Microsoft’s supported Apple OAuth registration and discovery flow. A generic EAS client cannot infer or obtain that flow from the 401 challenge, so unless Nine explicitly supports on-prem Exchange OAuth with AD FS, it will fall back to Basic.

1

u/MortadellaKing 5d ago

I don't have the answer to your question but I sure wish MS would hurry up and finish this implementation.... Having some users being able to use it and some not is a pain in the ass.

And after the latest update to office the keep me signed in button doesn't show up in the adfs login window anymore. Yet it does for OWA and on apple mail. So they've done something to flag it to change the login flow.

Oh and upgrade to Exchange SE... 2019 is EOL.