Авторизация в OWA
При открытии страницы OWA (Outlook Web App) https://outlook.slcloud.ru/owa/ пользователь автоматически перенаправляется (редирект) на страницу авторизации ADFS (Active Directory Federation Services). После успешной аутентификации ADFS возвращает пользователя обратно в интерфейс OWA с активным сеансом, и он продолжает работу с почтой.
Безопасность схемы авторизации в OWA через ADFS обеспечивается за счёт многоуровневой защиты: геораспределённый кластер ADFS обеспечивает отказоустойчивость и высокую доступность сервиса аутентификации, а Web Application Firewall (WAF) защищает страницу входа от внешних угроз — атак типа DDoS, брутфорса, SQL-инъекций и XSS-атак. Централизованная аутентификация в Active Directory позволяет контролировать доступ к почтовому сервису на уровне корпоративной инфраструктуры, а использование подписанных токенов безопасности (SAML/JWT) исключает возможность подделки сеансов. Пользователь вводит учётные данные только один раз на защищённой странице ADFS, после чего получает доступ к OWA без повторного ввода пароля (SSO), что снижает риск перехвата данных и упрощает управление доступом.
Ошибка 404 при подключении
Пользователи внутри сети заказчика при открытии OWA получают редирект на внешний ADFS-сервис, но после редиректа — ошибка 404, при этом из вне корпоративной инфраструктуры все корректно работает. Ошибка 404 может возникать из-за неправильного разрешения имени ADFS во внутреннем DNS или некорректной конфигурации прокси. Когда клиент внутри сети делает запрос к OWA, редирект на ADFS генерирует URL, который внутренний DNS не может корректно разрешить, либо прокси-сервер не пропускает/неправильно роутит запрос к ADFS-серверу. Снаружи работает, потому что внешний DNS и прокси настроены правильно.
Диагностика и рекомендации
1. Проверьте разрешение имени ADFS
С рабочей машины пользователя выполните запрос:
nslookup adfs.slcloud.ru
Ожидаемый результат: должен вернуться публичный IP ADFS.
Если получаете: внутренний IP, NXDOMAIN или ошибку — проблема в DNS.
2. Проверьте доступность ADFS
С рабочей машины пользователя выполните запрос, указав актуальную ссылку с актуальным ключом. Важно! В примере указана ссылка без ключа https://adfs.slcloud.ru/adfs/ls/idpinitiatedsignon.aspx , но её можно использовать для проверки в любом случае.
curl -v
https://adfs.slcloud.ru/adfs/ls/idpinitiatedsignon.aspx
Ожидаемый результат: HTTP 302 или 200.
Если получаете: 404, 403, таймаут — запрос блокируется прокси или не доходит до ADFS.
3. В качестве решения рекомендуем настроить Реверс-DNS c внешней зоны, так как URL с ключами и белые IP адреса могут меняться.
При использования Proxy:
- Добавьте домен ADFS в исключения прокси (Bypass proxy for *.slcloud.ru)
- Отключите кеширование для путей /adfs/ls/* и /adfs/oauth2/*
- Добавьте URL ADFS в зону «Надежные узлы» в браузерах клиентов
4. Вы так же можете добавить белые IP адреса ADFS (полученные через nslookup) в разрешенные для Proxy и межсетевом экране, но так как IP адреса ADFS, в будущем могут меняться, то при возникновении проблематики потребуется актуализировать список исключения.
Не нашли инструкцию?
Заполните форму, и наш специалист свяжется с вами.
Мы дополним информацию и ответим на ваш вопрос.
Оставить заявку