политики контроль доступа в Windows Server 2012 R2 и Windows Server 2012 AD FS

• Применяется к:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Политики, описанные в этой статье, используют два типа утверждений

1. Утверждения AD FS создаются на основе сведений, которые прокси-сервер AD FS и веб-приложение могут проверять и проверять, например IP-адрес клиента, подключающегося непосредственно к AD FS или WAP.

2. Утверждения AD FS создаются на основе информации, пересылаемой в AD FS клиентом в качестве заголовков HTTP

Важно. Политики, описанные ниже, блокируют присоединение к домену Windows 10 и войдите в сценарии, требующие доступа к следующим дополнительным конечным точкам.

Конечные точки AD FS, необходимые для присоединения к домену Windows 10 и входа

• [имя службы федерации]/adfs/services/trust/2005/windowstransport
• [имя службы федерации]/adfs/services/trust/13/windowstransport
• [имя службы федерации]/adfs/services/trust/2005/usernamemixed
• [имя службы федерации]/adfs/services/trust/13/usernamemixed
• [имя службы федерации]/adfs/services/trust/2005/certificatemixed
• [имя службы федерации]/adfs/services/trust/13/certificatemixed

Важно: /adfs/services/trust/2005/windowstransport и /adfs/services/trust/13/windowstransport конечные точки должны быть включены только для доступа к интрасети, так как они предназначены для интрасети с конечными точками, использующими привязку WIA на HTTPS. Предоставление их экстрасети может позволить запросам к этим конечным точкам обойти защиту блокировки. Эти конечные точки должны быть отключены на прокси-сервере (т. е. отключены из экстрасети) для защиты блокировки учетной записи AD.

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

Например, следующее правило:

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[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 = " DenyUsersWithClaim");

будет обновлено до:

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value != "(/adfs/ls/)|(/adfs/services/trust/2005/windowstransport)|(/adfs/services/trust/13/windowstransport)|(/adfs/services/trust/2005/usernamemixed)|(/adfs/services/trust/13/usernamemixed)|(/adfs/services/trust/2005/certificatemixed)|(/adfs/services/trust/13/certificatemixed)"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");

Примечание.

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

Политики, описанные в этой статье, всегда должны использоваться с другим методом проверки подлинности, таким как имя пользователя и пароль или многофакторная проверка подлинности.

Сценарии политик доступа клиентов

Сценарий	Description
Сценарий 1. Блокировка всех внешних доступа к Office 365	Доступ к Office 365 разрешен от всех клиентов во внутренней корпоративной сети, но запросы от внешних клиентов запрещены на основе IP-адреса внешнего клиента.
Сценарий 2. Блокировать весь внешний доступ к Office 365, кроме Exchange ActiveSync	Доступ к Office 365 разрешен со всех клиентов во внутренней корпоративной сети, а также с любых внешних клиентских устройств, таких как смарт-телефоны, которые используют Exchange ActiveSync. Все остальные внешние клиенты, такие как пользователи Outlook, блокируются.
Сценарий 3. Блокировка всех внешних доступа к Office 365, кроме приложений на основе браузера	Блокирует внешний доступ к Office 365, за исключением пассивных (браузерных) приложений, таких как Outlook Web Access или SharePoint Online.
Сценарий 4. Блокировать весь внешний доступ к Office 365, кроме назначенных групп Active Directory	Этот сценарий используется для тестирования и проверки развертывания политики доступа клиента. Он блокирует внешний доступ к Office 365 только для участников одной или нескольких групп Active Directory. Его также можно использовать для предоставления внешнего доступа только членам группы.

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

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

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

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

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

1. В диспетчер сервера щелкните "Сервис", а затем щелкните "Управление AD FS".

2. В дереве консоли в разделе "Отношения доверия AD FS\Trusts" щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".

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

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

5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила, например "Если есть любое утверждение IP за пределами требуемого диапазона, запретить". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения (замените приведенное выше значение x-ms-forwarded-client-ip допустимым выражением IP): c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = " DenyUsersWithClaim");
   

6. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи до правила разрешения доступа ко всем пользователям по умолчанию (правило запрета будет иметь приоритет, даже если оно отображается ранее в списке). Если у вас нет правила доступа по умолчанию, его можно добавить в конце списка с помощью языка правила утверждения следующим образом:
   

   c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

7. Чтобы сохранить новые правила, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК". Результирующий список должен выглядеть следующим образом.

   

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

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

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

1. В диспетчер сервера щелкните "Сервис", а затем щелкните "Управление AD FS".

2. В дереве консоли в разделе "Отношения доверия AD FS\Trusts" щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".

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

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

5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила, например "Если есть любое утверждение IP за пределами требуемого диапазона, проблема с утверждением ipoutsiderange". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения (замените приведенное выше значение x-ms-forwarded-client-ip допустимым выражением IP):

   c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");

6. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

8. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

9. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя для этого правила, например "Если ip-адрес вне требуемого диапазона и есть утверждение, отличное от EAS x-ms-client-application, запретить". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения:

   c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value != "Microsoft.Exchange.ActiveSync"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
   

10. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

12. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

13. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя этого правила, например "проверьте, существует ли утверждение приложения". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения:

    NOT EXISTS([Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application"]) => add(Type = "http://custom/xmsapplication", Value = "fail");
    

14. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

16. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

17. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя этого правила, например "запретить пользователям с ipoutsiderange true и сбоем приложения". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения:

    c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/xmsapplication", Value == "fail"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");
    

18. Нажмите кнопку Готово. Убедитесь, что новое правило отображается сразу под предыдущим правилом и до правила разрешения доступа ко всем пользователям по умолчанию в списке правил авторизации выдачи (правило запрета будет иметь приоритет, хотя оно отображается ранее в списке).

    Если у вас нет правила доступа по умолчанию, его можно добавить в конце списка с помощью языка правила утверждения следующим образом:

    c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");
    

19. Чтобы сохранить новые правила, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК". Результирующий список должен выглядеть следующим образом.

    

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

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

1. В диспетчер сервера щелкните "Сервис", а затем щелкните "Управление AD FS".

2. В дереве консоли в разделе "Отношения доверия AD FS\Trusts" щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".

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

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

5. На странице "Настройка правила" в поле "Имя правила утверждения" введите отображаемое имя для этого правила, например "Если есть любое утверждение IP за пределами требуемого диапазона, проблема с утверждением ipoutsiderange". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения (замените приведенное выше значение x-ms-forwarded-client-ip допустимым выражением IP):

c1:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] && c2:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");

1. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

3. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

4. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя этого правила, например "Если ip-адрес вне требуемого диапазона, а конечная точка не /adfs/ls, запретить". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения:

   c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[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 = " DenyUsersWithClaim");`
   

5. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи до правила разрешения доступа ко всем пользователям по умолчанию (правило запрета будет иметь приоритет, даже если оно отображается ранее в списке).
   
   Если у вас нет правила доступа по умолчанию, его можно добавить в конце списка с помощью языка правила утверждения следующим образом:

c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

11. Чтобы сохранить новые правила, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК". Результирующий список должен выглядеть следующим образом.

    

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

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

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

1. В диспетчер сервера щелкните "Сервис", а затем щелкните "Управление AD FS".

2. В дереве консоли в разделе "Отношения доверия AD FS\Trusts" щелкните правой кнопкой мыши доверие платформы удостоверений Microsoft Office 365 и выберите пункт "Изменить правила утверждений".

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

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

5. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя для этого правила, например "Если есть любое утверждение IP за пределами требуемого диапазона, проблема с утверждением ipoutsiderange". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения (замените приведенное выше значение x-ms-forwarded-client-ip допустимым выражением IP):

   `c1:[Type == "https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "^(?!192\.168\.1\.77|10\.83\.118\.23)"] && c2:[Type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://custom/ipoutsiderange", Value = "true");`
   

6. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

8. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

9. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя этого правила, например "check group SID". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения (замените "groupsid" фактическим идентификатором безопасности используемой группы AD):

   NOT EXISTS([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-32-100"]) => add(Type = "http://custom/groupsid", Value = "fail");
   

10. Нажмите кнопку Готово. Убедитесь, что новое правило отображается в списке правил авторизации выдачи.

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

12. На странице "Выбор шаблона правила" в разделе "Правило утверждения" выберите "Отправить утверждения с помощью настраиваемого правила" и нажмите кнопку "Далее".

13. На странице "Настройка правила" в разделе "Имя правила утверждения" введите отображаемое имя этого правила, например "запретить пользователям с ipoutsiderange true и groupid fail". В разделе "Пользовательское правило" введите или вставьте следующий синтаксис языка правила утверждения:

c1:[Type == "http://custom/ipoutsiderange", Value == "true"] && c2:[Type == "http://custom/groupsid", Value == "fail"] => issue(Type = "https://schemas.microsoft.com/authorization/claims/deny", Value = "DenyUsersWithClaim");

14. Нажмите кнопку Готово. Убедитесь, что новое правило отображается сразу под предыдущим правилом и до правила разрешения доступа ко всем пользователям по умолчанию в списке правил авторизации выдачи (правило запрета будет иметь приоритет, хотя оно отображается ранее в списке).
    
    Если у вас нет правила доступа по умолчанию, его можно добавить в конце списка с помощью языка правила утверждения следующим образом:

c:[] => issue(Type = "https://schemas.microsoft.com/authorization/claims/permit", Value = "true");

15. Чтобы сохранить новые правила, в диалоговом окне "Изменение правил утверждений" нажмите кнопку "ОК". Результирующий список должен выглядеть следующим образом.

    

Создание выражения диапазона 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-запросы и поддерживается многими клиентами, подсистемами балансировки нагрузки и прокси-серверами на рынке.

Примечание.

1. Несколько IP-адресов, указывающих IP-адрес клиента и адрес каждого прокси-сервера, передаваемого запросом, будут разделены запятой.
2. 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#

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

  Таким образом, пример для сопоставления всего двух адресов (например, 192.168.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\. ([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\.0\. ([1-9]|1[0-4])\b

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

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

Выражения regex могут стать довольно сложными, поэтому мы настоятельно рекомендуем использовать средство проверки регулярных выражений. Если вы выполняете поиск в Интернете построитель выражений 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 в Windows Server 2012 R2 предоставляет сведения о контексте запроса, используя следующие типы утверждений:

X-MS-Forwarded-Client-IP

Тип утверждения: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

Это утверждение AD FS представляет собой "лучшую попытку" при определении IP-адреса пользователя (например, клиента Outlook), выполняющего запрос. Это утверждение может содержать несколько IP-адресов, включая адрес каждого прокси-сервера, который перенаправил запрос. Это утверждение заполняется http-адресом. Значение утверждения может быть одним из следующих значений:

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

Примечание.

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

• Один или несколько IP-адресов

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

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

Примечание.

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

Предупреждение

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

X-MS-Client-Application

Тип утверждения: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

Это утверждение AD FS представляет протокол, используемый конечным клиентом, который слабо соответствует используемому приложению. Это утверждение заполняется заголовком HTTP, который в настоящее время задается только Exchange Online, который заполняет заголовок при передаче запроса проверки подлинности в AD FS. В зависимости от приложения значение этого утверждения будет одним из следующих значений:

• В случае устройств, использующих Exchange Active Sync, значением является Microsoft.Exchange.ActiveSync.

• Использование клиента Microsoft Outlook может привести к любым из следующих значений:

  • Microsoft.Exchange.Autodiscover

  • Microsoft.Exchange.OfflineAddressBook

  • Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices

  • Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices

• Ниже приведены другие возможные значения для этого заголовка:

  • Microsoft.Exchange.Powershell

  • Microsoft.Exchange.SMTP

  • Microsoft.Exchange.Pop

  • Microsoft.Exchange.Imap

X-MS-Client-User-Agent

Тип утверждения: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

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

Ниже приведены примеры того, что значение агента x-ms-user-agent может содержать для клиента, приложение x-ms-client-application которого — Microsoft.Exchange.ActiveSync.

• Вихрь/1.0

• Apple-iPad1C1/812.1

• Apple-iPhone3C1/811.2

• Apple-iPhone/704.11

• Moto-DROID2/4.5.1

• SAMSUNGSPHD700/100.202

• Android/0.3

  Это значение также может быть пустым.

X-MS-Proxy

Тип утверждения: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

Это утверждение AD FS указывает, что запрос прошел через прокси-сервер веб-приложения. Это утверждение заполняется прокси-сервером веб-приложения, который заполняет заголовок при передаче запроса проверки подлинности в серверную службу федерации. Ad FS преобразует его в утверждение.

Значение утверждения — DNS-имя прокси веб-приложения, передаваемого запросом.

InsideCorporateNetwork

Тип утверждения: https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

Как и в приведенном выше типе утверждения x-ms-proxy, этот тип утверждения указывает, прошел ли запрос через прокси-сервер веб-приложения. В отличие от x-ms-proxy, insidecorporatenetwork — логическое значение с значением True, указывающее запрос непосредственно в службу федерации из корпоративной сети.

X-MS-Endpoint-Absolute-Path (активный и пассивный)

Тип утверждения: https://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

Этот тип утверждения можно использовать для определения запросов, исходящих из "активных" (богатых) клиентов и "пассивных" (на основе веб-браузеров). Это позволяет разрешить внешние запросы из браузерных приложений, таких как Outlook Web Access, SharePoint Online или портал Office 365, когда запросы, исходящие от богатых клиентов, таких как Microsoft Outlook, блокируются.

Значение утверждения — это имя службы AD FS, которая получила запрос.

См. также

Операции AD FS