У меня тут проблема, я бьюсь головой о стену. Настраиваю новый тенант 365, и требование организации — чтобы все пользователи подключались через VPN или находились на месте для доступа к ресурсам 365.
Я создал простую политику блокировки CA, которая исключает диапазон IP офисов и включает/блокирует всех остальных, и она хорошо работает в офисе. Однако при тестировании открытия Outlook через VPN кажется, что Entra отмечает соединение как заблокированное, потому что он видит два разных IP: IP-адрес: <офисный WAN IP> и IP-адрес из приложения: <IP моего локального шлюза сети>. Я пробовал перезагружать тестовую машину и т. п., но он всё равно получается определить IP моего шлюза как “IP-адрес (видимый ресурсом)” в логах входа Entra, из-за чего он блокирует. В разрешённом браузерном трафике эта информация не отображается. Понимаю, что Outlook использует другой тип аутентификации, а именно Modern Auth.
Чтобы было ясно, здесь НЕ происходит split tunneling. Всё трафик идёт через VPN на все 100%. Я запустил Wireshark и тройной проверил, что никакой трафик не просачивается через мой WAN во время VPN. Так как же он продолжает получать этот IP-адрес для попытки аутентификации клиента Outlook (классический, кстати) через условный доступ? Как на это реагирует Entra?
редактирование: Это также блокируется при входе в аккаунт через Word для доступа к OneDrive и т. п., так что явно проблема в офисном клиенте.
Кто-нибудь может пояснить, что происходит? Я даже пробовал отзывать все сессии, думая, что это что-то сбросит. Нет изменений. Заранее спасибо за любые идеи!
Я знаю, что ты сказал, что это новый тенант, но там ведь нет политики для управляемых устройств, и ты используешь неуправляемое устройство или что-то вроде этого?
Глупый вопрос, но ты тестируешь это через офисную сеть и используешь VPN?
Что показывают логи входа при сбое? Если это политика CA, детали скажут тебе, какая именно (если их несколько).
Хотел бы обновить о решении. Оказывается, у меня была еще одна политика, которая мешала контролью сеансов — она не предназначалась для использования (и, следовательно, игнорировалась в моем анализе применяемых политик). Она фактически устанавливала Настройку постоянной оценки (Continuous Evaluation) в жесткий режим. Отключение этой политики решило проблему. Однако при дальнейшем тестировании я понял, что причина не в этой конкретной настройке, а в области действия. Она была установлена только для доверенных сетей. Неизвестно, почему эта дополнительная политика, когда применена так, вызывает застревание толстого клиента в лимбе отказа CA. После изменения политики CE на “любой” сетевой локации, всё работает отлично при повторном подключении через VPN.
Это интересный вопрос. Я использую неуправляемое устройство, не присоединенное к домену. Я проверил еще раз, но ни политика Intune, ни политика CA Entra не проверяют принадлежность устройства или соответствие его требованиям. Мой план — найти устройство на базе домена в другой сети, когда появятся ресурсы. Тенант еще не запущен в продуктив, только тестирую сценарии перед миграцией.
Нет, я работаю вне сети на виртуальной машине, которая сама по себе находится внутри NAT-сети, связанной с другой NAT-сетью (фактически двойной NAT). Однако это никак не отображается в логах входа или связанных с CA логах, и весь трафик точно идет через VPN (использовал Wireshark для захвата пакетов и проверил, что ничего не идет “локально”).
Да, это первая основная политика отказа, которая содержит только одно условие. Включить все сети, исключить доверенные сети. В логах IP-адрес показывает офис, но IP-адрес, видимый ресурсом, каким-то образом привязан к внешнему IP моего тестового устройства.
Хотел бы найти больше информации в документации о том, как учитывается “IP, видимый ресурсом”.
Извиняюсь за возврат к старому посту, но можете подробнее объяснить? Я не думаю, что использую CE для моей политики CA, и у меня похожая проблема. Завтра почитаю про CE.
Я блокирую весь внешний доступ и добавил статические WAN IP-адреса своей сети в доверенные сети. Когда пользователи подключаются к VPN (настроен на полное туннелирование Sophos SSL VPN), а затем пытаются получить доступ к office.com или Outlook, их просят войти, и им говорят, что это не доверенное место. VPN-клиент и сетевой адаптер в ipconfig показывают статический IP, который я добавил в доверенные сайты как шлюз. Логи входа в O365 показывают другой IP, не VPN IP (у меня есть мобильные пользователи, работающие из дома, в кафе или на hotspots, так что статические WAN IP отсутствуют). Я ранее создавал обращение в техподдержку MS, но они закрыли его без помощи.