Короткий ответ — то, с чем вы столкнулись, — это ожидаемое/известное поведение: в чисто on‑premise сценарии (Exchange 2019 + только AD FS, без Azure AD) возможность «Modern Auth» для ActiveSync/EAS жестко завязана на сервер‑side flight/allowlist и на набор поддерживаемых client_id; это нельзя просто «включить» публичным PowerShell‑ключом. Теперь подробнее по пунктам.
1) Что контролирует «Flighting» и можно ли его включить самостоятельно?
- Сообщение "Flighting is not enabled for domain '…' / OAuthNotAvailable" означает, что Exchange проверил внутренний gate/flight для функции EAS OAuth и обнаружил, что для данного домена/конфигурации эта возможность выключена. Этот gate — не локальный флажок в ActiveSyncVirtualDirectory, а логика сценария/проверки, которая в продуктах Microsoft связывается с набором разрешённых/поддерживаемых конфигураций (включая регистрацию в облаке/гибридную конфигурацию).
- На публично документированных и поддерживаемых cmdlet’ах (типа New‑FlightOverride) для включения EAS OAuth в чистом on‑prem нет. Нету официального сценария «включить flight для произвольного домена при работе только с AD FS». Microsoft проектно ориентирует Modern Auth / EAS OAuth на работу через Azure AD (или через гибридную интеграцию), и в подавляющем большинстве случаев требуемый «флаг» устанавливается/согласуется через облачную/гибридную регистрацию/контроль.
- На практике есть два поддерживаемых варианта: перевести сервер в поддерживаемый гибрид/Azure AD сценарий (настроить Azure AD + Hybrid Modern Authentication), либо обращаться в Microsoft Support — в отдельных случаях внутренняя служба Microsoft может включить/разблокировать какие‑то полёты, но это не общедоступная/документированная настройка.
2) Поддерживаются ли произвольные OAuth‑клиенты для EAS в этом сценарии?
- Нет, это не «универсальный» OAuth: сервер — и особенно реализация EAS OAuth — работает с ограниченным набором известных/разрешённых клиентов (client_id, redirect_uri и т. п.). В реальности Microsoft/Exchange allowlist’ит клиенты (Outlook, Apple Mail и т. д.). Для произвольного generic OAuth‑клиента (или стороннего EAS‑приложения) потребуется, чтобы Exchange «знал» и разрешил соответствующий client_id и поток; в on‑prem сценарии без Azure AD это как правило не происходит.
- Поэтому сторонние клиенты (Nine и т. п.) обычно либо реализуют собственную логику OAuth к Azure AD (Office 365), либо остаются на Basic auth, либо требуют специально согласованной интеграции с сервером/поставщиком почты. Для Nine конкретно — они поддерживают OAuth для Office 365/Azure AD, но при чисто on‑prem + AD FS они не получат OAuth‑challenge от Exchange.
3) Почему нативная iOS Mail всё-таки перенаправляется на AD FS без authorization_uri в 401‑challenge?
- Нативная почта iOS реализует дополнительные клиентские механизмы обнаружения/авторизации, отличные от «чистого» EAS 401‑WWW‑Authenticate challenge. Поведение, которое вы видите, объясняется тем, что Apple Mail использует расширенный Autodiscover / предварительные проверки и специальные heuristics: она сначала выполняет автообнаружение/проверку учётной записи (Autodiscover, возможные федеративные discovery endpoints, web redirection), может выполнить пользовательский realm discovery / web sign‑in probe и затем открыть встроенный браузер/контекст для AD FS‑веб‑аутентификации. Это позволяет iOS Mail начать интерактивный OAuth‑flow до того, как Exchange вернёт OAuth authorization_uri в 401 для конкретного ActiveSync запроса.
- Этот путь — поведение конкретного клиента (Apple) и не является универсальным механизмом, на который можно положиться для любого EAS‑клиента. Другие клиенты (Nine) могут не делать тех же предварительных запросов/heuristics и потому никогда не увидят OAuth challenge от Exchange в вашем окружении.
Рекомендации / что можно сделать практически
- Если хотите поддержать Modern Auth для мобильных сторонних клиентов — самый надёжный/поддерживаемый путь — настроить гибрид/Azure AD (Hybrid Modern Authentication) и использовать Azure AD как провайдера токенов. Тогда Exchange on‑prem сможет корректно выполнять OAuth для EAS, и сторонние клиенты, поддерживающие стандартный OAuth/OIDC потоки к Azure AD, будут работать.
- Если гибрид невозможен, обсудите с Microsoft Support возможность включения конкретного flight для вашего домена (это частный путь, не гарантируется и вне поддержки).
- Альтернатива для пользователей — рекомендовать клиентам использовать Outlook (он поддерживается) или клиентам/вендору (Nine) реализовать специфичную поддержку AD FS/OAuth в on‑prem среде (но без поддержки со стороны Exchange это маловероятно).
- Для диагностики: проверьте Autodiscover/ServiceDiscovery ответы, логи IIS/Exchange для Autodiscover и ActiveSync, и сравните последовательность запросов iOS vs Android‑клиента. Но имейте в виду: отсутствие параметра -OAuthAuthentication в ActiveSyncVirtualDirectory и ошибка OAuthNotAvailable указывают именно на то, что сервер функцию EAS OAuth для этого домена не предлагает.
Если хотите, могу:
- подсказать конкретные проверки/логи для Autodiscover и EAS (какие URL/ответы смотреть), или
- расписать шаги по переходу на гибридную MА (High level), или
- подготовить пример цепочки запросов/ответов (из логов), которые надо вытащить для обращения в Microsoft Support.