Exchange 2019 CU14 on-prem + AD FS (без Azure AD) — удаcтся ли настроить ModernAuth для внешних почтовых агентов на андроид?
Добрый день
Exchange Server 2019 CU14, один сервер (MX01), чистый on-premises
AD FS зарегистрирован как AuthServer (Type: ADFS), без Azure AD/гибридного tenant
AuthServer настроен корректно: AuthorizationEndpoint, TokenIssuingEndpoint заполнены, IsDefaultAuthorizationEndpoint: True, DomainName указывает на почтовый домен. Realm/ServiceName настроен.
Нативный клиент iOS Mail (аккаунт добавлен вручную, без MDM-профиля) корректно перенаправляет на страницу логина AD FS при первой настройке — полный Modern Auth flow работает.
Сторонний EAS-клиент (Nine от NitroDesk, Android) никогда не получает OAuth challenge — падает в Basic-аутентификацию.
ActiveSyncVirtualDirectory в этой сборке вообще нет параметра -OAuthAuthentication (в отличие от EWS/OAB)
По логам при обращении с приложения Nine ловил в логи Exchange, вот такое:
HttpProxy/Eas:
S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<домен>'.
S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable
Вопросы:
1) Что именно контролирует "Flighting" для EAS OAuth в чистом on-prem сценарии Exchange 2019 CU14 + AD FS (без Azure AD)? Есть ли документированный, поддерживаемый способ его включить (New-FlightOverride? что-то другое)?
2) Поддерживается ли вообще EAS Modern Auth для произвольного/generic OAuth-клиента (не Apple, не Outlook) в этом сценарии, или это фактически allowlist, ограниченный конкретными client_id (Apple Native Mail / Outlook)?
3)Как нативная почта iOS перенаправляется на AD FS, ни разу не получив authorization_uri в 401-challenge EAS/Autodiscover — существует ли недокументированный путь обнаружения (например, зашитый под конкретный зарегистрированный client_id)?
EAS-путь тут не HMA-флайтинг, а отдельная CU13-фича: ADFS как STS без Azure AD вообще. Официально в EAS заведён только client, зарегистрированный в ADFS как native-приложение со scope EAS.AccessAsUser.All — доки Microsoft создают такое под Apple Mail (f8d98a96-0999-43f5-8af3-69971c7bb423, тот же AppId что у Apple в Entra). Свой client_id зарегать в ADFS можно, но хендшейк под него должно уметь само приложение, это вопрос к NitroDesk, не к New-FlightOverride. А "Flighting is not enabled" я бы не считал доказанным без трейса: сравни сырой 401 для Apple и для Nine на одинаковый пустой Bearer-запрос к /Microsoft-Server-ActiveSync.
Поставил Get-Content -Wait на живой tail логов HttpProxy\Eas и HttpProxy\Autodiscover, затем:
iOS Mail: видно AuthenticationType: Bearer, HttpStatus: 401 — клиент делает нормальный запрос, получает 401 Bearer challenge, и дальше успешно уходил на ADFS.
Nine (Android): при попытке добавить аккаунт через "автоматический" Exchange-режим — в логах Exchange не появляется ни одной новой записи вообще, ни в Eas, ни в Autodiscover. Проверял 4 раза подряд, живым tail, — тишина.
Раз тишина даже в Autodiscover — Nine до Exchange вообще не долетает, дело не в OAuth-флайтинге. Глянь tcpdump/сетевой лог на самом телефоне при добавлении аккаунта — похоже клиент режется раньше, на DNS или TLS. Если не найдёшь причину — да, проще взять клиент с нормальным Modern Auth (тот же Outlook или дефолтный Android Mail).
Пума Тайланд, Ничего не режется, WAF работает в пассивном режиме.
На том же телефоне в браузере OWA спокойной цепляется. Страница с Autodiscovery тоже возвращает ответ.
На BasicAuth Nine подключается.
Я не могу брать клиенты по типу Outlook, потому что он бурится по умолчанию к майкрософт.
Ключевая проблема, что это закрытый контур и возможности постучаться к AzureAD вообще нет.
Поэтому и хотелось узнать, может у кого-то такая задача была когда-нибудь, обойти ограничения архитектуры.
Или наличие клиента поддерживающего эту систему по аналогии с IOS почтой.
Единственное решение это mTLS с сертификатами в качестве MFA, которое осталось.
DeadAurora2, тогда всё сходится: Nine в своём automatic-режиме просто не умеет стучаться никуда кроме Microsoft-облака, отсюда и тишина в логах — это ограничение клиента, а не Exchange/ADFS. mTLS с сертификатами поверх Basic для закрытого контура — вполне рабочий вариант MFA, я бы брал именно его.
Сложный
Средний
