Политики контроль доступа клиента в AD FS 2.0

Политики доступа клиентов в службы федерации Active Directory (AD FS) 2.0 позволяют ограничить или предоставить пользователям доступ к ресурсам. В этом документе описывается, как включить политики доступа клиентов в AD FS 2.0 и как настроить наиболее распространенные сценарии.

Включение политики доступа клиентов в AD FS 2.0

Чтобы включить политику доступа клиента, выполните указанные ниже действия.

Шаг 1. Установка пакета обновления 2 для AD FS 2.0 на серверах AD FS

Скачайте пакет обновления 2 для службы федерации Active Directory (AD FS) (AD FS) 2.0 и установите его на всех прокси-серверах федерации и серверах федерации.

Шаг 2. Добавление пяти правил утверждений в доверие поставщика утверждений Active Directory

После установки накопительного пакета обновления 2 на всех серверах и прокси-серверах AD FS и прокси-серверах используйте следующую процедуру, чтобы добавить набор правил утверждений, которые делают новые типы утверждений доступными для подсистемы политик.

Для этого вы добавите пять правил преобразования принятия для каждого из новых типов утверждений контекста запроса, используя следующую процедуру.

В доверии поставщика утверждений Active Directory создайте новое правило преобразования принятия для передачи каждого из новых типов утверждений контекста запроса.

Чтобы добавить правило утверждения в доверие поставщика утверждений Active Directory для каждого из пяти типов утверждений контекста:

  1. Нажмите кнопку "Пуск", наведите указатель на программы, наведите указатель на Администратор istrative Tools, а затем щелкните AD FS 2.0 Management.

  2. В дереве консоли в разделе AD FS 2.0\Отношения доверия щелкните "Отношения поставщика утверждений", щелкните active Directory правой кнопкой мыши и выберите пункт "Изменить правила утверждений".

  3. В диалоговом окне "Изменение правил утверждений" выберите вкладку "Правила преобразования принятия" и нажмите кнопку "Добавить правило", чтобы запустить мастер правил.

  4. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Сквозь" или "Фильтровать входящее утверждение" из списка и нажмите кнопку "Далее".

  5. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя для этого правила; В поле "Входящий тип утверждения" введите следующий URL-адрес типа утверждения, а затем выберите "Сквозь все значения утверждений".
    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

  6. Чтобы проверить правило, выберите его в списке и нажмите кнопку "Изменить правило", а затем нажмите кнопку "Просмотреть язык правил". Язык правила утверждения должен отображаться следующим образом: c:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip"] => issue(claim = c);

  7. Нажмите кнопку «Готово».

  8. В диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК", чтобы сохранить правила.

  9. Повторите шаги 2–6, чтобы создать дополнительное правило утверждения для каждого из оставшихся четырех типов утверждений, показанных ниже, пока не будут созданы все пять правил.

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

    https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

Шаг 3. Обновление доверия платформы удостоверений Microsoft Office 365

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

Сценарии политики доступа клиента для AD FS 2.0

В следующих разделах описаны сценарии, которые существуют для AD FS 2.0

Сценарий 1. Блокировка всех внешних доступа к Office 365

Этот сценарий политики доступа клиента позволяет получить доступ со всех внутренних клиентов и блокирует все внешние клиенты на основе IP-адреса внешнего клиента. Набор правил основан на правиле авторизации выдачи по умолчанию, разрешая доступ ко всем пользователям. Для добавления правила авторизации выдачи в доверие проверяющей стороны Office 365 можно использовать следующую процедуру.

Создание правила для блокировки всего внешнего доступа к Office 365

  1. Нажмите кнопку "Пуск", наведите указатель на программы, наведите указатель на Администратор istrative Tools, а затем щелкните AD FS 2.0 Management.
  2. В дереве консоли в разделе AD FS 2.0\Отношения доверия щелкните "Отношения доверия проверяющей стороны", щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".
  3. В диалоговом окне "Изменение правил утверждений" выберите вкладку "Правила авторизации выдачи" и нажмите кнопку "Добавить правило", чтобы запустить мастер правил утверждений.
  4. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".
  5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила. В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения: exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. Нажмите кнопку «Готово». Убедитесь, что новое правило отображается сразу под правилом "Разрешить доступ ко всем пользователям" в списке правил авторизации выдачи.
  7. Чтобы сохранить правило, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК".

Примечание.

Необходимо заменить приведенное выше значение для "регулярного выражения общедоступного IP-адреса" допустимым IP-выражением; Дополнительные сведения см. в статье "Создание выражения диапазона IP-адресов".

Сценарий 2. Блокировать весь внешний доступ к Office 365, кроме Exchange ActiveSync

В следующем примере разрешен доступ ко всем приложениям Office 365, включая Exchange Online, из внутренних клиентов, включая Outlook. Он блокирует доступ от клиентов, находящихся за пределами корпоративной сети, как указано IP-адресом клиента, за исключением клиентов Exchange ActiveSync, таких как смарт-телефоны. Набор правил основан на правиле авторизации выдачи по умолчанию с названием "Разрешить доступ ко всем пользователям". Используйте следующие действия, чтобы добавить правило авторизации выдачи в доверие проверяющей стороны Office 365 с помощью мастера правил утверждений:

Создание правила для блокировки всего внешнего доступа к Office 365

  1. Нажмите кнопку "Пуск", наведите указатель на программы, наведите указатель на Администратор istrative Tools, а затем щелкните AD FS 2.0 Management.
  2. В дереве консоли в разделе AD FS 2.0\Отношения доверия щелкните "Отношения доверия проверяющей стороны", щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".
  3. В диалоговом окне "Изменение правил утверждений" выберите вкладку "Правила авторизации выдачи" и нажмите кнопку "Добавить правило", чтобы запустить мастер правил утверждений.
  4. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".
  5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила. В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения: exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value=="Microsoft.Exchange.Autodiscover"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value=="Microsoft.Exchange.ActiveSync"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. Нажмите кнопку «Готово». Убедитесь, что новое правило отображается сразу под правилом "Разрешить доступ ко всем пользователям" в списке правил авторизации выдачи.
  7. Чтобы сохранить правило, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК".

Примечание.

Необходимо заменить приведенное выше значение для "регулярного выражения общедоступного IP-адреса" допустимым IP-выражением; Дополнительные сведения см. в статье "Создание выражения диапазона IP-адресов".

Сценарий 3. Блокировка всех внешних доступа к Office 365, кроме приложений на основе браузера

Набор правил основан на правиле авторизации выдачи по умолчанию с названием "Разрешить доступ ко всем пользователям". Используйте следующие действия, чтобы добавить правило авторизации выдачи в доверенный сервер платформы удостоверений Microsoft Office 365 с помощью мастера правил утверждений:

Примечание.

Этот сценарий не поддерживается сторонним прокси-сервером из-за ограничений заголовков политик доступа клиента с пассивными (веб-запросами).

Создание правила для блокировки всех внешних доступа к Приложениям на основе браузера Office 365

  1. Нажмите кнопку "Пуск", наведите указатель на программы, наведите указатель на Администратор istrative Tools, а затем щелкните AD FS 2.0 Management.
  2. В дереве консоли в разделе AD FS 2.0\Отношения доверия щелкните "Отношения доверия проверяющей стороны", щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".
  3. В диалоговом окне "Изменение правил утверждений" выберите вкладку "Правила авторизации выдачи" и нажмите кнопку "Добавить правило", чтобы запустить мастер правил утверждений.
  4. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".
  5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила. В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения: exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. Нажмите кнопку «Готово». Убедитесь, что новое правило отображается сразу под правилом "Разрешить доступ ко всем пользователям" в списке правил авторизации выдачи.
  7. Чтобы сохранить правило, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК".

Сценарий 4. Блокировка всех внешних доступа к Office 365 для назначенных групп Active Directory

В следующем примере предоставляется доступ из внутренних клиентов на основе IP-адреса. Он блокирует доступ от клиентов, находящихся за пределами корпоративной сети с внешним IP-адресом клиента, за исключением тех, кто находится в указанной группе Active Directory. Набор правил основан на правиле авторизации выдачи по умолчанию с заголовком "Разрешить доступ ко всем пользователям". Используйте следующие действия, чтобы добавить правило авторизации выдачи в доверенный сервер платформы удостоверений Microsoft Office 365 с помощью мастера правил утверждений:

Создание правила для блокировки всего внешнего доступа к Office 365 для назначенных групп Active Directory

  1. Нажмите кнопку "Пуск", наведите указатель на программы, наведите указатель на Администратор istrative Tools, а затем щелкните AD FS 2.0 Management.
  2. В дереве консоли в разделе AD FS 2.0\Отношения доверия щелкните "Отношения доверия проверяющей стороны", щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".
  3. В диалоговом окне "Изменение правил утверждений" выберите вкладку "Правила авторизации выдачи" и нажмите кнопку "Добавить правило", чтобы запустить мастер правил утверждений.
  4. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".
  5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила. В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения: exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"]) && exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"]) && NOT exists([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~"customer-provided public ip address regex"]) => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "true");
  6. Нажмите кнопку «Готово». Убедитесь, что новое правило отображается сразу под правилом "Разрешить доступ ко всем пользователям" в списке правил авторизации выдачи.
  7. Чтобы сохранить правило, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК".

Описание синтаксиса языка правила утверждения, используемого в приведенных выше сценариях

Description Синтаксис языка правила утверждения
Правило AD FS по умолчанию для разрешения доступа ко всем пользователям. Это правило уже должно существовать в списке правил авторизации удостоверений Microsoft Office 365 проверяющей стороны. => issue(Type = "<https://schemas.microsoft.com/authorization/claims/permit>", Value = "true");
Добавление этого предложения в новое пользовательское правило указывает, что запрос был получен из прокси-сервера федерации (т. е. имеет заголовок x-ms-proxy).
Рекомендуется включить все правила. exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy>"])
Используется для установления того, что запрос от клиента с IP-адресом в определенном допустимом диапазоне. NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip>", Value=~"customer-provided public ip address regex"])
Это предложение используется для указания того, что если доступ к приложению не является Microsoft.Exchange.ActiveSync, запрос должен быть отклонен. NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application>", Value=="Microsoft.Exchange.ActiveSync"])
Это правило позволяет определить, был ли вызов через веб-браузер и не будет отклонен. NOT exists([Type == "<https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path>", Value == "/adfs/ls/"])
Это правило указывает, что только пользователи в определенной группе Active Directory (на основе значения SID) должны быть отклонены. Добавление NOT в эту инструкцию означает, что группа пользователей будет разрешена независимо от расположения. exists([Type == "<https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid>", Value =~ "{Group SID value of allowed AD group}"])
Это обязательное предложение для выдачи запрета при выполнении всех предыдущих условий. => issue(Type = "<https://schemas.microsoft.com/authorization/claims/deny>", Value = "true");

Создание выражения диапазона IP-адресов

Утверждение x-ms-forwarded-client-ip заполняется из заголовка HTTP, который в настоящее время задается только Exchange Online, который заполняет заголовок при передаче запроса проверки подлинности в AD FS. Значение утверждения может быть одним из следующих значений:

Примечание.

В настоящее время Exchange Online поддерживает только IPV4 и не IPV6-адреса.

Один IP-адрес: IP-адрес клиента, который напрямую подключен к Exchange Online

Примечание.

IP-адрес клиента в корпоративной сети будет отображаться как IP-адрес внешнего интерфейса исходящего прокси-сервера или шлюза организации.

Клиенты, подключенные к корпоративной сети через VPN или Microsoft DirectAccess (DA), могут отображаться как внутренние корпоративные клиенты или внешние клиенты в зависимости от конфигурации VPN или DA.

Один или несколько IP-адресов: если Exchange Online не может определить IP-адрес подключающегося клиента, он будет задавать значение на основе значения заголовка x-forwarded-for, нестандартного заголовка, который может быть включен в HTTP-запросы и поддерживается многими клиентами, подсистемами балансировки нагрузки и прокси-серверами на рынке.

Примечание.

Несколько IP-адресов, указывающих IP-адрес клиента и адрес каждого прокси-сервера, передаваемого запросом, будут разделены запятой.

IP-адреса, связанные с инфраструктурой Exchange Online, не отображаются в списке.

Regular Expressions

При сопоставлении диапазона IP-адресов необходимо создать регулярное выражение для сравнения. В следующей серии шагов мы предоставим примеры того, как создать такое выражение для сопоставления следующих диапазонов адресов (обратите внимание, что эти примеры необходимо изменить в соответствии с диапазоном общедоступных IP-адресов):

  • 192.168.1.1 – 192.168.1.25
  • 10.0.0.1 – 10.0.0.14

Во-первых, базовый шаблон, соответствующий одному IP-адресу, выглядит следующим образом: \b#.###b

Расширяя это, можно сопоставить два разных IP-адреса с выражением OR следующим образом: \b#B|#

Таким образом, пример сопоставления только двух адресов (например, 192.168.1.1 или 10.0.0.1) будет: \b192.168.1.1\b|\b10.0.0.1\b

Это дает вам метод, с помощью которого можно ввести любое количество адресов. Если необходимо разрешить диапазон адресов, например 192.168.1–192.168.1.25, сопоставление должно быть выполнено символом: \b192.168.1. ([1-9]|1[0-9]|2[0-5])\b

Примечание.

IP-адрес обрабатывается как строка, а не число.

Правило разбито следующим образом: \b192.168.1.

Это соответствует любому значению, начиная с 192.168.1.

Ниже приведены диапазоны, необходимые для части адреса после последней десятичной запятой:

  • ([1-9] Совпадения адресов, заканчивающиеся на 1-9
  • |1[0-9] Совпадения адресов, заканчивающиеся 10-19
  • |2[0-5]) Совпадения адресов, заканчивающиеся 20-25

Примечание.

Круглые скобки должны быть правильно расположены, чтобы вы не начали соответствовать другим частям IP-адресов.

При сопоставлении блока 192 можно написать аналогичное выражение для блока 10: \b10.0.0. ([1-9]|1[0-4])\b

И объединить их, следующее выражение должно соответствовать всем адресам для "192.168.1.1~25" и "10.0.0.1~14": \b192.168.1. ([1-9]|1[0-9]|2[0-5])\b|\b10.0.0. ([1-9]|1[0-4])\b

Тестирование выражения

Выражения regex могут стать довольно сложными, поэтому мы настоятельно рекомендуем использовать средство проверки регулярных выражений. Если вы выполняете поиск в Интернете построитель выражений в Интернете, вы найдете несколько хороших онлайн-служебных программ, которые позволят вам попробовать выражения для выборки данных.

При тестировании выражения важно понимать, что ожидать соответствия. Система Exchange Online может отправлять много IP-адресов, разделенных запятыми. Приведенные выше выражения будут работать для этого. Однако важно думать об этом при тестировании регулярных выражений. Например, для проверки приведенных выше примеров можно использовать следующие входные данные:

192.168.1.1, 192.168.1.2, 192.169.1.1. 192.168.12.1, 192.168.1.10, 192.168.1.25, 192.168.1.26, 192.168.1.30, 1192.168.1.20

10.0.0.1, 10.0.0.5, 10.0.0.10, 10.0.1.0, 10.0.1.1, 110.0.0.1, 10.0.0.14, 10.0.0.15, 10.0.0.10, 10,0.0.1

Проверка развертывания

Журналы аудита безопасности

Чтобы убедиться, что новые утверждения контекста запроса отправляются и доступны конвейеру обработки утверждений AD FS, включите ведение журнала аудита на сервере AD FS. Затем отправьте некоторые запросы проверки подлинности и проверка для значений утверждений в стандартных записях журнала аудита безопасности.

Чтобы включить ведение журнала событий аудита в журнал безопасности на сервере AD FS, выполните действия по настройке аудита для AD FS 2.0.

Ведение журнала событий

По умолчанию неудачные запросы записываются в журнал событий приложения, расположенный в журналах приложений и служб \ AD FS 2.0 \ Администратор. Дополнительные сведения о ведении журнала событий для AD FS см. в разделе "Настройка ведения журнала событий AD FS 2.0".

Настройка подробных журналов трассировки AD FS

События трассировки AD FS записываются в журнал отладки AD FS 2.0. Сведения о включении трассировки см. в разделе "Настройка трассировки отладки для AD FS 2.0".

После включения трассировки используйте следующий синтаксис командной строки, чтобы включить подробный уровень ведения журнала: wevtutil.exe sl "AD FS 2.0 Трассировка/отладка" /l:5

Дополнительные сведения о новых типах утверждений см. в разделе Типы утверждений AD FS.