Боль и страдания в работе с Conditional Access

Когда вы читаете статьи про Conditional Access на каких то блогах, например тут, вы видите как все легко и просто настраивается и работает. И это действительно так.

Но в работе с CA вы столкнетесь с некоторыми проблемами, которые приведут вас в отчаяние и вы захотите админить 1С. Далее я опишу некоторые примеры, чтобы пояснить как все иногда запутано.

Важно! Все описание актуально на момент написания статьи. Инструменты обновляются достаточно часто, поэтому написанное может потерять актуальность.

OneDrive

Например вы захотите заблокировать OneDrive на не корпоративных машинах.

Руководствуясь логикой, вы создадите политику для приложения “OneDrive for Business”, выберете необходимые для вас условия, добавите тестовую группу (вы же всегда тестируете изменения).

И произойдет ничего.

Вы пойдете в Sign-in logs и увидите, что клиент синхронизации использует приложение под названием OneDrive SyncEngine и использование никак не тригерит политику.

Вы попробуете посмотреть, что происходит если вы идете в OneDrive через другие офисные приложения или браузер. И увидите мешанину из приложений. Можете увидеть подключение напрямую к Microsoft Sharepoint, так и через Microsoft Office.

Почему это происходит? Потому что OneDrive это просто обертка для SharePoint. Когда человек идет в OneDrive, он на самом деле подключается к Sharepoint’у.

Ну ок, допустим мы готовы заблокировать и SharePoint заодно. Добавляем политику, и видим, что пользователи перестали видеть документы в Teams, так как Teams тоже отчасти обертка для Sharepoint.

Так что всегда перепроверяйте какие сервисы связаны и как они друг на друга влияют.

https://docs.microsoft.com/en-gb/azure/active-directory/conditional-access/technical-reference#supported-mobile-applications-and-desktop-clients

Внутренние приложения.

Представим, что у вас есть внутри команда разработчиков, которые создают приложения для внутренних нужд. Вы друг друга особо не трогаете, но внезапно они приходят с тем, что их приложения перестали работать. А вы незадолго до этого ограничивали Exchange на мобильных приложениях, чтобы можно было использовать только Outlook Mobile. И теперь в логах вы видите, что приложение отваливается из-за вашей политики. А приложение вообще не должно подключаться в Exchange.

Вы как заправский сыщик начинаете копаться в коде приложения в попытках найти тот самый Graph API endpoint, который все портит, так как только обращение в Exchange может тригернуть политику.

И не находите в коде ничего.

В приступе непонимания и бессилия вы ковыряете настройки приложения в Azure AD и обнаруживаете права на User.Read.Write, которые относятся к доступу в Exchange. И вроде бы это только права, никто же не подключается к нему.

Но не тут то было.

Оказалось, что на моменте подключения к приложению, приложение долбится по всем выданным правам, что и тригерит срабатывание политики.

Выводы.

Я по прежнему считаю, что Conditional Access это отличный инструмент и нужно его использовать, но со временем встречаются проблемы о которых сложно предположить и не всегда есть актуальная информация. Так что тесты, тесты и еще раз тесты.

%d bloggers like this: