ALLUSERS property

The ALLUSERS property configures the installation context of the package. The Windows Installer performs a per-user installation or per-machine installation depending on the access privileges of the user, whether elevated privileges are required to install the application, the value of the ALLUSERS property, the value of the MSIINSTALLPERUSER property and the version of the operating system.

The value of the ALLUSERS property, at installation time, determines the installation context.

An ALLUSERS property value of 1 specifies the per-machine installation context.

An ALLUSERS property value of an empty string («») specifies the per-user installation context.

If the value of the ALLUSERS property is set to 2, the Windows Installer always resets the value of the ALLUSERS property to 1 and performs a per-machine installation or it resets the value of the ALLUSERS property to an empty string («») and performs a per-user installation. The value ALLUSERS=2 enables the system to reset the value of ALLUSERS, and the installation context, dependent upon the user’s privileges and the version of Windows.

Windows 7: Set the ALLUSERS property to 2 to use the MSIINSTALLPERUSER property to specify the installation context. Set the MSIINSTALLPERUSER property to an empty string («») for a per-machine installation. Set the MSIINSTALLPERUSER property to 1 for a per-user installation. If the package has been written following the development guidelines described in Single Package Authoring, users having user access can install into the per-user context without having to provide UAC credentials. If the user has user access privileges, the installer performs a per-machine installation only if Admin credentials are provided to the UAC dialog box.

Windows Vista: Set the ALLUSERS property to 2 and Windows Installer complies with User Account Control (UAC). If the user has user access privileges, and ALLUSERS=2, the installer performs a per-machine installation only if Admin credentials are provided to the UAC dialog box. If UAC is enabled and the correct Admin credentials are not provided, the installation fails with an error stating that administrator privileges are required. If UAC is disabled by the registry key, group policy, or the control panel, the UAC dialog box is not displayed and the installation fails with an error stating that administrator privileges are required.

Windows XP: Set the ALLUSERS property to 2 and Windows Installer performs a per-user installation if the user has user access privileges.

If the value of the ALLUSERS property does not equal 2, the Windows Installer ignores the value of the MSIINSTALLPERUSER property.

Example

Default Value

The recommended default installation context is per-user. If ALLUSERS is not set, the installer does a per-user installation. You can ensure the ALLUSERS property has not been set by setting its value to an empty string («»), ALLUSERS=»».

Windows Server 2012 R2 Remote Desktop Services — Настраиваем пользовательский интерфейс на серверах RD Session Host

После развёртывания новой фермы RD Connection Broker на базе Windows Server 2012 R2 встаёт вопрос настройки пользовательского окружения на серверах RD Session Host. В целом общий процесс настройки почти полностью совпадает с тем, что уже описывалось ранее в заметке Remote Desktop Services — Настраиваем пользовательский интерфейс на серверах RD Session Host . Исключением является лишь пара пунктов, которые будут здесь описаны.

Метод описанный в пункте Скрываем излишние папки в профиле пользователя применительно к Windows Server 2012 R2 работать не будет. Вместо него воспользуемся вариантом, описанным здесь Windows 8 Forums — This PC — Add or Remove «Folders» in Windows 8.1

Видимостью рабочих папок пользователя можно управлять с помощью наличия под-ключей в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace , где каждый отдельный ключ отвечает за какую-то папку, в частности:

Предположим мы хотим удалить папки “Музыка”, “Загрузки” и “Видео”. Для этого нам можно либо вручную удалить соответствующие ключи реестра, либо создать GPP, удаляющие эти ключи (если нужно одинаково конфигурировать несколько серверов). Например, создадим для этой цели параметры GPP в разделе Computer Configuration\Preferences\Windows Settings\Registry

Соответствующие параметры для удобства объединены в группу, которая в нашем примере называется WS-2012R2 . В свойствах этой группы параметров сделано нацеливание на семейство ОС – Windows Server 2012 R2 Family. Результат виден сразу после применения GPO (перезагрузка ОС при этом не требуется):

Метод описанный ранее в пункте Настраиваем стартовый экран Windows применительно к Windows Server 2012 R2 работать вполне возможно и будет, но более правильно использовать другой метод, доступный в новой ОС для управления стартовым экраном (Start Screen) Windows и описанный в документе Customize Windows 8.1 Start Screens by Using Group Policy :

1) После того, как на все сервера RD Session Host установлено и настроено однотипное программное обеспечение, входим на любой из этих серверов и настраиваем стартовый экран Windows в том виде, в котором мы хотим его представить всем пользователям без возможности последующей модификации.

2) Все сделанные настройки стартового экрана сохраняются на общедоступный сетевой ресурс в формате XML с помощью PowerShell командлета Export-StartLayout

Если интересно заглянуть в результирующий XML файл, может потребоваться какой-нибудь текстовый редактор с подсветкой синтаксиса XML и автоматическим форматированием, например Notepad++ с плагином XML Tools

3) Указать путь к выгруженным настройкам стартового экрана можно с помощью параметра групповых политик Start Screen Layout в разделе User Configuration\Policies\Administrative Templates\Start Menu and Taskbar

Однако если для разных категорий пользователей требуются разные настройки стартового экрана, то можно более гибко сконфигурировать этот параметр с помощью Group Policy preferences (GPP). Для этого в разделе GPP User Configuration\Preferences\Windows Settings\Registry
нам потребуется настроить параметры LockedStartLayout и StartLayoutFile в ключе реестра
HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer

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

Однако при централизованной раздаче настроек стартового экрана, как и в прошлой версии ОС, отображаться будут только те приложения, которые используют хорошо известные AppID (см.выгруженный файл XML).

Интересную информацию по этому вопросу можно найти например в заметке Windows 8.1 Start Screen – Behind the Scenes . Отсюда можно почерпнуть, что в ряде случаев в составе AppID используются идентификаторы известных папок описанных в документе Dev Center — Desktop — KNOWNFOLDERID . Эксперименты с размещением как ярлыков так и самих исполняемых файлов в указанных каталогах с последующей подменой GUID папок AppID в XML-файле настроек стартового экрана желаемого результата не дали. Фактически могу констатировать, что метод описанный в статье применительно к Windows Server 2012 R2 не работает.

В ходе разного рода экспериментов в руки так же попала одна интересная утилита — OblyTile v0.9.9 . Она позволяет создавать плитки стартового экрана с форсированным назначением для всех пользователей системы, но опять же, она не умеет размещать эти плитки в нужных группировках. И опять же, несмотря на то, что здесь есть такая хорошая штука как экспорт и импорт плиток, эти функции не получится использовать для полноценного копирования плиток между разными серверами, так как при экспорте плиток теряется связь с AppID исходной системы.

Поэтому, по существу вопроса, в плане управляемости плитками стартового экрана в новой ОС принципиально ничего не изменилось, что на мой взгляд, весьма печально, так как стартовый экран никак не получается использовать как отправную точку доступа пользователей ко всем ресурсам, как это было например со старым добрым меню “Пуск”.

Политики управления доступом в Windows Server 2012 R2 и Windows Server 2012 AD FS Access Control Policies in Windows Server 2012 R2 and Windows Server 2012 AD FS

Политики, описанные в этой статье, используют два типа утверждений. The policies described in this article make use of two kinds of claims

Утверждения AD FS создаются на основе информации, которую AD FS и прокси веб-приложения могут проверять и проверять, например IP-адрес клиента, подключающегося напрямую к AD FS или WAP. Claims AD FS creates based on information the AD FS and Web Application proxy can inspect and verify, such as the IP address of the client connecting directly to AD FS or the WAP.

Утверждения AD FS создаются на основе сведений, пересылаемых клиентом в AD FS в виде HTTP-заголовков. Claims AD FS creates based on information forwarded to AD FS by the client as HTTP headers

Важно. политики, описанные ниже, блокируют сценарии приподключения к домену Windows 10 и сценариев входа, которым требуется доступ к следующим дополнительным конечным точкам. Important: The policies as documented below will block Windows 10 domain join and sign on scenarios that require access to the following additional endpoints

AD FS конечных точек, необходимых для приподключения к домену Windows 10 и входа в систему AD FS endpoints required for Windows 10 Domain Join and sign on

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

Важно. конечные точки/ADFS/Services/Trust/2005/windowstransport и/ADFS/Services/Trust/13/windowstransport должны быть включены только для доступа к интрасети, так как они предназначены для конечных точек в интрасети, использующих привязку WIA на HTTPS. Important: /adfs/services/trust/2005/windowstransport and /adfs/services/trust/13/windowstransport endpoints should only be enabled for intranet access as they are meant to be intranet facing endpoints that use WIA binding on HTTPS. Предоставление доступа к экстрасети может позволить запросам к этим конечным точкам обходить защиту блокировок. Exposing them to extranet could allow requests against these endpoints to bypass lockout protections. Эти конечные точки должны быть отключены на прокси-сервере (т. е. отключены из экстрасети) для защиты блокировки учетных записей AD. These endpoints should be disabled on the proxy (i.e. disabled from extranet) to protect AD account lockout.

Чтобы устранить эту проблему, обновите политики, которые запрещаются на основе утверждения конечной точки, чтобы разрешить исключения для указанных выше конечных точек. To resolve, update any policies that deny based on the endpoint claim to allow exception for the endpoints above.

Например, следующее правило: For example, the rule below:

будет обновлен до: would be updated to:

Утверждения из этой категории следует использовать только для реализации бизнес-политик, а не в качестве политик безопасности для защиты доступа к сети. Claims from this category should only be used to implement business policies and not as security policies to protect access to your network. Неавторизованные клиенты могут отправить заголовки с ложными сведениями как способ получения доступа. It is possible for unauthorized clients to send headers with false information as a way to gain access.

Политики, описанные в этой статье, всегда следует использовать с другим методом проверки подлинности, например с именем пользователя и паролем или многофакторной проверкой подлинности. The policies described in this article should always be used with another authentication method, such as username and password or multi factor authentication.

Сценарии политик клиентского доступа Client Access Policies Scenarios

Сценарий Scenario	Описание Description
Сценарий 1. Блокирование всех внешних обращений к Office 365 Scenario 1: Block all external access to Office 365	Доступ к Office 365 разрешен со всех клиентов во внутренней корпоративной сети, но запросы от внешних клиентов отклоняются на основе IP-адреса внешнего клиента. Office 365 access is allowed from all clients on the internal corporate network, but requests from external clients are denied based on the IP address of the external client.
Сценарий 2. Блокирование всех внешних доступов к Office 365, кроме Exchange ActiveSync Scenario 2: Block all external access to Office 365 except Exchange ActiveSync	Доступ к Office 365 разрешен со всех клиентов во внутренней корпоративной сети, а также с любых внешних клиентских устройств, таких как смарт-телефоны, которые используют Exchange ActiveSync. Office 365 access is allowed from all clients on the internal corporate network, as well as from any external client devices, such as smart phones, that make use of Exchange ActiveSync. Все другие внешние клиенты, такие как, использующие Outlook, блокируются. All other external clients, such as those using Outlook, are blocked.
Сценарий 3. Блокирование всех внешних доступов к Office 365 за исключением браузерных приложений Scenario 3: Block all external access to Office 365 except browser-based applications	Блокирует внешний доступ к Office 365, за исключением пассивных (основанных на браузерах) приложений, таких как Outlook Веб-доступ или SharePoint Online. Blocks external access to Office 365, except for passive (browser-based) applications such as Outlook Web Access or SharePoint Online.
Сценарий 4. блокировка внешнего доступа к Office 365, кроме назначенных групп Active Directory Scenario 4: Block all external access to Office 365 except for designated Active Directory groups	Этот сценарий используется для тестирования и проверки развертывания политики клиентского доступа. This scenario is used for testing and validating client access policy deployment. Он блокирует внешний доступ к Office 365 только для членов одной или нескольких групп Active Directory. It blocks external access to Office 365 only for members of one or more Active Directory group. Он также может использоваться для предоставления внешнего доступа только членам группы. It can also be used to provide external access only to members of a group.

Включение политики клиентского доступа Enabling Client Access Policy

Чтобы включить политику клиентского доступа в AD FS в Windows Server 2012 R2, необходимо обновить отношение доверия с проверяющей стороной платформы удостоверений Microsoft Office 365. To enable client access policy in AD FS in Windows Server 2012 R2, you must update the Microsoft Office 365 Identity Platform relying party trust. Выберите один из приведенных ниже примеров сценариев, чтобы настроить правила утверждений для отношения доверия с проверяющей стороной платформы Microsoft Office 365 , которое наилучшим образом соответствует потребностям вашей организации. Choose one of the example scenarios below to configure the claim rules on the Microsoft Office 365 Identity Platform relying party trust that best meets the needs of your organization.

Сценарий 1. Блокирование всех внешних обращений к Office 365 Scenario 1: Block all external access to Office 365

Этот сценарий политики клиентского доступа разрешает доступ со всех внутренних клиентов и блокирует все внешние клиенты на основе IP-адреса внешнего клиента. This client access policy scenario allows access from all internal clients and blocks all external clients based on the IP address of the external client. Следующие процедуры используются для добавления правильных правил авторизации выдачи в отношение доверия с проверяющей стороной Office 365 для выбранного сценария. You can use the following procedures to add the correct Issuance Authorization rules to the Office 365 relying party trust for your chosen scenario.

Создание правил для блокировки внешнего доступа к Office 365 To create rules to block all external access to Office 365

В Диспетчер сервера выберите Сервис, а затем — Управление AD FS. From Server Manager, click Tools, then click AD FS Management.

В дереве консоли в разделе отношения AD фс\труст щелкните отношения доверия с проверяющей стороной, щелкните правой кнопкой мыши Microsoft Office 365 удостоверение платформы удостоверения и выберите пункт изменить правила утверждений. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

В диалоговом окне изменение правил утверждений перейдите на вкладку правила авторизации выдачи и нажмите кнопку Добавить правило , чтобы запустить мастер правил для утверждений. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется утверждение IP-адресов за пределами нужного диапазона,» запретить «. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is any IP claim outside the desired range, deny”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил обработки заявок (замените значение выше для x-MS-forwardd-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»); Under Custom rule, type or paste the following claim rule language syntax (replace the value above for “x-ms-forwarded-client-ip” with a valid IP expression): 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»);

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи, прежде чем перейти к правилу Разрешить доступ для всех пользователей по умолчанию (правило запрета будет иметь приоритет, даже если оно присутствует в списке ранее). Verify that the new rule appears in the Issuance Authorization Rules list before to the default Permit Access to All Users rule (the Deny rule will take precedence even though it appears earlier in the list). Если у вас нет правила разрешения доступа по умолчанию, вы можете добавить его в конце списка, используя язык правил утверждений, следующим образом: If you do not have the default permit access rule, you can add one at the end of your list using the claim rule language as follows:

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

Чтобы сохранить новые правила, в диалоговом окне изменение правил утверждений нажмите кнопку ОК. To save the new rules, in the Edit Claim Rules dialog box, click OK. Полученный список должен выглядеть следующим образом. The resulting list should look like the following.

Сценарий 2. Блокирование всех внешних доступов к Office 365, кроме Exchange ActiveSync Scenario 2: Block all external access to Office 365 except Exchange ActiveSync

В следующем примере предоставляется доступ ко всем приложениям Office 365, включая Exchange Online, от внутренних клиентов, включая Outlook. The following example allows access to all Office 365 applications, including Exchange Online, from internal clients including Outlook. Он блокирует доступ клиентов, находящихся за пределами корпоративной сети, как указано IP-адресом клиента, за исключением клиентов Exchange ActiveSync, таких как Интеллектуальные телефоны. It blocks access from clients residing outside the corporate network, as indicated by the client IP address, except for Exchange ActiveSync clients such as smart phones.

Создание правил для блокировки внешнего доступа к Office 365, кроме Exchange ActiveSync To create rules to block all external access to Office 365 except Exchange ActiveSync

В Диспетчер сервера выберите Сервис, а затем — Управление AD FS. From Server Manager, click Tools, then click AD FS Management.

В дереве консоли в разделе отношения AD фс\труст щелкните отношения доверия с проверяющей стороной, щелкните правой кнопкой мыши Microsoft Office 365 удостоверение платформы удостоверения и выберите пункт изменить правила утверждений. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

В диалоговом окне изменение правил утверждений перейдите на вкладку правила авторизации выдачи и нажмите кнопку Добавить правило , чтобы запустить мастер правил для утверждений. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется утверждение IP-адресов за пределами нужного диапазона, выдайте ипаутсидеранже утверждение». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is any IP claim outside the desired range, issue ipoutsiderange claim”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил обработки заявок (замените значение выше для x-MS-forwardd-Client-IP на допустимое выражение IP): Under Custom rule, type or paste the following claim rule language syntax (replace the value above for “x-ms-forwarded-client-ip” with a valid IP expression):

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»);

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется IP-адрес за пределами нужного диапазона, а также не-EAS x-MS-Client-Application утверждений, Deny». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is an IP outside the desired range AND there is a non-EAS x-ms-client-application claim, deny”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил для утверждений: Under Custom rule, type or paste the following claim rule language syntax:

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «проверить, существует ли утверждение приложения». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “check if application claim exists”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил для утверждений: Under Custom rule, type or paste the following claim rule language syntax:

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «запретить пользователям с ипаутсидеранже true и сбой приложения». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “deny users with ipoutsiderange true and application fail”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил для утверждений: Under Custom rule, type or paste the following claim rule language syntax:

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается непосредственно под предыдущим правилом, и до значения правила разрешения доступа ко всем пользователям по умолчанию в списке правила авторизации выдачи (правило запрета будет иметь приоритет, даже если оно отображается ранее в списке). Verify that the new rule appears immediately below the previous rule and before to the default Permit Access to All Users rule in the Issuance Authorization Rules list (the Deny rule will take precedence even though it appears earlier in the list).

Если у вас нет правила разрешения доступа по умолчанию, вы можете добавить его в конце списка, используя язык правил утверждений, следующим образом: If you do not have the default permit access rule, you can add one at the end of your list using the claim rule language as follows:

Чтобы сохранить новые правила, в диалоговом окне изменение правил утверждений нажмите кнопку ОК. To save the new rules, in the Edit Claim Rules dialog box, click OK. Полученный список должен выглядеть следующим образом. The resulting list should look like the following.

Сценарий 3. Блокирование всех внешних доступов к Office 365 за исключением браузерных приложений Scenario 3: Block all external access to Office 365 except browser-based applications

Создание правил для блокирования всех внешних доступов к Office 365 за исключением браузерных приложений To create rules to block all external access to Office 365 except browser-based applications

В Диспетчер сервера выберите Сервис, а затем — Управление AD FS. From Server Manager, click Tools, then click AD FS Management.

В дереве консоли в разделе отношения AD фс\труст щелкните отношения доверия с проверяющей стороной, щелкните правой кнопкой мыши Microsoft Office 365 удостоверение платформы удостоверения и выберите пункт изменить правила утверждений. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

В диалоговом окне изменение правил утверждений перейдите на вкладку правила авторизации выдачи и нажмите кнопку Добавить правило , чтобы запустить мастер правил для утверждений. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется утверждение IP-адресов за пределами нужного диапазона, выдайте ипаутсидеранже утверждение». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is any IP claim outside the desired range, issue ipoutsiderange claim”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил обработки заявок (замените значение выше для x-MS-forwardd-Client-IP на допустимое выражение IP): Under Custom rule, type or paste the following claim rule language syntax(replace the value above for “x-ms-forwarded-client-ip” with a valid IP expression):

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется IP-адрес за пределами нужного диапазона, а конечная точка не/адфс/ЛС, запретите». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is an IP outside the desired range AND the endpoint is not /adfs/ls, deny”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил для утверждений: Under Custom rule, type or paste the following claim rule language syntax:

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи, прежде чем перейти к правилу Разрешить доступ для всех пользователей по умолчанию (правило запрета будет иметь приоритет, даже если оно присутствует в списке ранее). Verify that the new rule appears in the Issuance Authorization Rules list before to the default Permit Access to All Users rule (the Deny rule will take precedence even though it appears earlier in the list). Если у вас нет правила разрешения доступа по умолчанию, вы можете добавить его в конце списка, используя язык правил утверждений, следующим образом: If you do not have the default permit access rule, you can add one at the end of your list using the claim rule language as follows:

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

Чтобы сохранить новые правила, в диалоговом окне изменение правил утверждений нажмите кнопку ОК. To save the new rules, in the Edit Claim Rules dialog box, click OK. Полученный список должен выглядеть следующим образом. The resulting list should look like the following.

Сценарий 4. блокировка внешнего доступа к Office 365, кроме назначенных групп Active Directory Scenario 4: Block all external access to Office 365 except for designated Active Directory groups

В следующем примере предоставляется доступ с внутренних клиентов на основе IP-адреса. The following example enables access from internal clients based on IP address. Он блокирует доступ клиентов, находящихся за пределами корпоративной сети, имеющей внешний IP-адрес клиента, за исключением тех, которые входят в указанную группу Active Directory. чтобы добавить правильные правила авторизации выдачи в отношение доверия с проверяющей стороной платформы удостоверений Microsoft Office 365 с помощью мастера правил утверждений, выполните следующие действия. It blocks access from clients residing outside the corporate network that have an external client IP address, except for those individuals in a specified Active Directory Group.Use the following steps to add the correct Issuance Authorization rules to the Microsoft Office 365 Identity Platform relying party trust using the Claim Rule Wizard:

Создание правил для блокировки внешнего доступа к Office 365 за исключением назначенных групп Active Directory To create rules to block all external access to Office 365, except for designated Active Directory groups

В Диспетчер сервера выберите Сервис, а затем — Управление AD FS. From Server Manager, click Tools, then click AD FS Management.

В дереве консоли в разделе отношения AD фс\труст щелкните отношения доверия с проверяющей стороной, щелкните правой кнопкой мыши Microsoft Office 365 удостоверение платформы удостоверения и выберите пункт изменить правила утверждений. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

В диалоговом окне изменение правил утверждений перейдите на вкладку правила авторизации выдачи и нажмите кнопку Добавить правило , чтобы запустить мастер правил для утверждений. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «Если имеется утверждение IP-адресов за пределами нужного диапазона, выдайте заявку ипаутсидеранже». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “If there is any IP claim outside the desired range, issue ipoutsiderange claim.” В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил обработки заявок (замените значение выше для x-MS-forwardd-Client-IP на допустимое выражение IP): Under Custom rule, type or paste the following claim rule language syntax(replace the value above for “x-ms-forwarded-client-ip” with a valid IP expression):

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «проверить идентификатор безопасности группы». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “check group SID”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правила для утверждений (замените «граупсид» фактическим идентификатором безопасности используемой группы Active Directory): Under Custom rule, type or paste the following claim rule language syntax (replace «groupsid» with the actual SID of the AD group you are using):

Нажмите кнопку Готово. Click Finish. Убедитесь, что новое правило отображается в списке правила авторизации выдачи . Verify that the new rule appears in the Issuance Authorization Rules list.

Затем в диалоговом окне изменение правил утверждений на вкладке правила авторизации выдачи нажмите кнопку Добавить правило , чтобы снова запустить мастер правил утверждений. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

На странице Выбор шаблона правила в разделе шаблон правила утверждения выберите Отправить утверждения с помощью настраиваемого правила, а затем нажмите кнопку Далее. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

На странице Настройка правила в разделе имя правила утверждения введите отображаемое имя для этого правила, например «запретить пользователям с ипаутсидеранже true и граупсид Fail». On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “deny users with ipoutsiderange true and groupsid fail”. В разделе настраиваемое правило введите или вставьте следующий синтаксис языка правил для утверждений: Under Custom rule, type or paste the following claim rule language syntax:

Чтобы сохранить новые правила, в диалоговом окне изменение правил утверждений нажмите кнопку ОК. To save the new rules, in the Edit Claim Rules dialog box, click OK. Полученный список должен выглядеть следующим образом. The resulting list should look like the following.

Создание выражения диапазона IP-адресов Building the IP address range expression

Утверждение x-MS-Forwarded-Client-IP заносится из заголовка HTTP, который в настоящее время задается только Exchange Online, который заполняет заголовок при передаче запроса на проверку подлинности в AD FS. The x-ms-forwarded-client-ip claim is populated from an HTTP header that is currently set only by Exchange Online, which populates the header when passing the authentication request to AD FS. Значение утверждения может быть одним из следующих: The value of the claim may be one of the following:

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

• Один IP-адрес: IP-адрес клиента, подключенного непосредственно к Exchange Online. A single IP address: The IP address of the client that is directly connected to Exchange Online

• IP-адрес клиента в корпоративной сети будет отображаться как IP-адрес внешнего интерфейса исходящего прокси-сервера или шлюза Организации. The IP address of a client on the corporate network will appear as the external interface IP address of the organization’s outbound proxy or gateway.
• Клиенты, подключенные к корпоративной сети с помощью VPN или Microsoft DirectAccess (DA), могут отображаться как внутренние корпоративные клиенты или как внешние клиенты в зависимости от конфигурации VPN или DA. Clients that are connected to the corporate network by a VPN or by Microsoft DirectAccess (DA) may appear as internal corporate clients or as external clients depending upon the configuration of VPN or DA.

• Один или несколько IP-адресов. Если Exchange Online не удается определить IP-адрес подключающегося клиента, он установит значение на основе значения заголовка x-forwardd-for, нестандартного заголовка, который может быть включен в HTTP-запросы и поддерживается многими клиентами, подсистемами балансировки нагрузки и прокси на рынке. One or more IP addresses: When Exchange Online cannot determine the IP address of the connecting client, it will set the value based on the value of the x-forwarded-for header, a non-standard header that can be included in HTTP-based requests and is supported by many clients, load balancers, and proxies on the market.

1. Несколько IP-адресов, указывающих IP-адрес клиента и адрес каждого прокси-сервера, который продавал запрос, будут разделены запятыми. Multiple IP addresses, indicating the client IP address and the address of each proxy that passed the request, will be separated by a comma.
2. IP-адреса, связанные с инфраструктурой Exchange Online, не будут включены в список. IP addresses related to Exchange Online infrastructure will not on the list.

Регулярные выражения Regular Expressions

Если необходимо сопоставить диапазон IP-адресов, необходимо создать регулярное выражение для выполнения сравнения. When you have to match a range of IP addresses, it becomes necessary to construct a regular expression to perform the comparison. В следующих шагах мы предложим примеры того, как создать такое выражение, которое будет соответствовать следующим диапазонам адресов (Обратите внимание, что эти примеры потребуется изменить в соответствии с диапазоном общедоступных IP-адресов): In the next series of steps, we will provide examples for how to construct such an expression to match the following address ranges (note that you will have to change these examples to match your public IP range):

192.168.1.1 — 192.168.1.25 192.168.1.1 – 192.168.1.25

10.0.0.1 – 10.0.0.14 10.0.0.1 – 10.0.0.14

Сначала базовый шаблон, который будет соответствовать одному IP-адресу, выглядит следующим образом: \b # # #. # # #. # # #. # # \ \ \ # \b First, the basic pattern that will match a single IP address is as follows: \b###\.###\.###\.###\b

Это позволяет сопоставить два разных IP-адреса с выражением или следующим образом: \b # # # \ . # # # \ . # # #. # \ # # \b| \b # # # \ . # # # \ . # # \ #. # # # \b Extending this, we can match two different IP addresses with an OR expression as follows: \b###\.###\.###\.###\b|\b###\.###\.###\.###\b

Таким образом, пример для сопоставления только двух адресов (например, 192.168.1.1 или 10.0.0.1) будет: \b192 \ .| 168 \ . \ \ \ \ So, an example to match just two addresses (such as 192.168.1.1 or 10.0.0.1) would be: \b192\.168\.1\.1\b|\b10\.0\.0\.1\b

Это дает возможность ввести любое количество адресов. This gives you the technique by which you can enter any number of addresses. Если необходимо разрешить диапазон адресов, например 192.168.1.1 – 192.168.1.25, то сопоставление должно выполняться по символу: \b192 \ . 168 \ . 1 \ . ( 9 |1 5 |2 3) \b Where a range of address need to be allowed, for example 192.168.1.1 – 192.168.1.25, the matching must be done character by character: \b192\.168\.1\.(2|13|21)\b

Обратите внимание на следующее: Please note the following:

IP-адрес рассматривается как строка, а не число. The IP address is treated as string and not a number.

Правило разбивается следующим образом: \b192 \ . 168 \ . 1 \ . The rule is broken down as follows: \b192\.168\.1\.

Это соответствует любому значению, начиная с 192.168.1. This matches any value beginning with 192.168.1.

Следующие сведения соответствуют диапазонам, необходимым для части адреса после завершающей десятичной запятой: The following matches the ranges required for the portion of the address after the final decimal point:

(4 совпадает с адресами, завершающимися в 1-9 (7 Matches addresses ending in 1-9

|1 1 соответствует адресам, завершающимся в 10-19 |18 Matches addresses ending in 10-19

|2 5) соответствует адресам, завершающимся в 20-25 |24) Matches addresses ending in 20-25

Обратите внимание, что круглые скобки должны быть правильно размещены, чтобы не начинать сопоставление других частей IP-адресов. Note that the parentheses must be correctly positioned, so that you don’t start matching other portions of IP addresses.

При совпадении с блоком 192 можно написать аналогичное выражение для 10 блока: \b10 \ 0 \ . 0 \ . ( 8 |1 4) \b With the 192 block matched, we can write a similar expression for the 10 block: \b10\.0\.0\.(9|11)\b

И поместив их вместе, следующее выражение должно соответствовать всем адресам для «192.168.1.1

14″: \b192 \ . 168 \ . 1 \ . ( 8 |1 7 |2 3) \b| \b10 \ 0 \ . 0 \ . ( 8 |1 3) \b And putting them together, the following expression should match all the addresses for “192.168.1.1～25” and “10.0.0.1～14”: \b192\.168\.1\.(4|17|23)\b|\b10\.0\.0\.(9|14)\b

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

Выражения Regex могут стать довольно сложными, поэтому мы настоятельно рекомендуем использовать средство проверки регулярного выражения. Regex expressions can become quite tricky, so we highly recommend using a regex verification tool. Если вы выполняете поиск в Интернете по запросу «Построитель регулярных выражений в Интернете», вы найдете несколько хороших интерактивных служебных программ, которые позволят опробовать выражения в демонстрационных данных. If you do an internet search for “online regex expression builder”, you will find several good online utilities that will allow you to try out your expressions against sample data.

При тестировании выражения важно понимать, что должно быть найдено. When testing the expression, it’s important that you understand what to expect to have to match. Система Exchange Online может отправить несколько IP-адресов, разделенных запятыми. The Exchange online system may send many IP addresses, separated by commas. Приведенные выше выражения будут работать. The expressions provided above will work for this. Однако важно подумать об этом при тестировании выражений регулярного выражения. However, it’s important to think about this when testing your regex expressions. Например, можно использовать следующий пример входных данных для проверки приведенных выше примеров. For example, one might use the following sample input to verify the examples above:

192.168.1.1, 192.168.1.2, 192.169.1.1. 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 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 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

Типы утверждений Claim Types

AD FS в Windows Server 2012 R2 предоставляет сведения о контексте запроса, используя следующие типы утверждений: AD FS in Windows Server 2012 R2 provides request context information using the following claim types:

X-MS-Forwarded-Client-IP X-MS-Forwarded-Client-IP

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

Это утверждение AD FS представляет собой «лучшую попытку» при поиске IP-адреса пользователя (например, клиента Outlook), выполняющего запрос. This AD FS claim represents a “best attempt” at ascertaining the IP address of the user (for example, the Outlook client) making the request. Это утверждение может содержать несколько IP-адресов, включая адрес каждого прокси-сервера, который перенаправлял запрос. This claim can contain multiple IP addresses, including the address of every proxy that forwarded the request. Это утверждение заполняется по протоколу HTTP. This claim is populated from an HTTP. Значение утверждения может быть одним из следующих: The value of the claim can be one of the following:

• Один IP-адрес — IP-адрес клиента, подключенного непосредственно к Exchange Online. A single IP address — The IP address of the client that is directly connected to Exchange Online

IP-адрес клиента в корпоративной сети будет отображаться как IP-адрес внешнего интерфейса исходящего прокси-сервера или шлюза Организации. The IP address of a client on the corporate network will appear as the external interface IP address of the organization’s outbound proxy or gateway.

Один или несколько IP-адресов One or more IP addresses

Если Exchange Online не может определить IP-адрес подключающегося клиента, он установит значение на основе значения заголовка x-forwardd-for, нестандартного заголовка, который можно включить в HTTP-запросы и поддерживаемое многими клиентами, подсистемами балансировки нагрузки и прокси на рынке. If Exchange Online cannot determine the IP address of the connecting client, it will set the value based on the value of the x-forwarded-for header, a non-standard header that can be included in HTTP based requests and is supported by many clients, load balancers, and proxies on the market.

Если IP-адрес клиента и адрес каждого прокси-сервера, который продавал запрос, будут разделяться запятыми, будет использоваться несколько IP-адресов. Multiple IP addresses indicating the client IP address and the address of each proxy that passed the request will be separated by a comma.

IP-адреса, связанные с инфраструктурой Exchange Online, отсутствуют в списке. IP addresses related to Exchange Online infrastructure will not be present in the list.

В настоящее время Exchange Online поддерживает только IPV4-адреса; Он не поддерживает IPV6-адреса. Exchange Online currently supports only IPV4 addresses; it does not support IPV6 addresses.

X-MS-Client-Application X-MS-Client-Application

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

Это утверждение AD FS представляет протокол, используемый конечным клиентом, который неплотно соответствует используемому приложению. This AD FS claim represents the protocol used by the end client, which corresponds loosely to the application being used. Это утверждение заполняется из заголовка HTTP, который в настоящее время задается Exchange Online, который заполняет заголовок при передаче запроса на проверку подлинности в AD FS. This claim is populated from an HTTP header that is currently only set by Exchange Online, which populates the header when passing the authentication request to AD FS. В зависимости от приложения значение этого утверждения будет одним из следующих: Depending on the application, the value of this claim will be one of the following:

В случае с устройствами, использующими Exchange Active Sync, значением будет Microsoft. Exchange. ActiveSync. In the case of devices that use Exchange Active Sync, the value is Microsoft.Exchange.ActiveSync.

Использование клиента Microsoft Outlook может привести к любому из следующих значений: Use of the Microsoft Outlook client may result in any of the following values:

Microsoft. Exchange. автообнаружения Microsoft.Exchange.Autodiscover

Microsoft. Exchange. Оффлинеаддрессбук Microsoft.Exchange.OfflineAddressBook

Microsoft. Exchange. Рпкмикрософт. Exchange. WebService Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices

Microsoft. Exchange. Рпкмикрософт. Exchange. WebService Microsoft.Exchange.RPCMicrosoft.Exchange.WebServices

К другим возможным значениям этого заголовка относятся следующие. Other possible values for this header include the following:

Microsoft. Exchange. PowerShell Microsoft.Exchange.Powershell

Microsoft. Exchange. SMTP Microsoft.Exchange.SMTP

Microsoft. Exchange. POP Microsoft.Exchange.Pop

Microsoft. Exchange. IMAP Microsoft.Exchange.Imap

X-MS-Client-User-Agent X-MS-Client-User-Agent

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

Это утверждение AD FS предоставляет строку для представления типа устройства, который используется клиентом для доступа к службе. This AD FS claim provides a string to represent the device type that the client is using to access the service. Это можно использовать, когда клиенты хотели бы запретить доступ к определенным устройствам (например, к определенным типам смартфонов). This can be used when customers would like to prevent access for certain devices (such as particular types of smart phones). Примеры значений для этого утверждения: (но не ограничиваются ими) значениями ниже. Example values for this claim include (but are not limited to) the values below.

Ниже приведены примеры того, что может содержать значение x-MS-User-Agent для клиента, x-MS-Client-Application — Microsoft. Exchange. ActiveSync. The below are examples of what the x-ms-user-agent value might contain for a client whose x-ms-client-application is “Microsoft.Exchange.ActiveSync”

Также возможно, что это значение пустое. It is also possible that this value is empty.

X-MS-Proxy X-MS-Proxy

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

Это утверждение AD FS указывает, что запрос прошел через прокси веб-приложения. This AD FS claim indicates that the request has passed through the Web Application proxy. Это утверждение заполняется прокси-службой, которая заполняет заголовок при передаче запроса на проверку подлинности в служба федерации серверной части. This claim is populated by the Web Application proxy, which populates the header when passing the authentication request to the back end Federation Service. AD FS преобразует его в утверждение. AD FS then converts it to a claim.

Значение утверждения — это DNS-имя прокси-сервера, который передал запрос. The value of the claim is the DNS name of the Web Application proxy that passed the request.

инсидекорпоратенетворк InsideCorporateNetwork

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

Аналогично приведенному выше типу утверждения x-MS-Proxy этот тип утверждения указывает, прошел ли запрос через прокси веб-приложения. Similar to the above x-ms-proxy claim type, this claim type indicates whether the request has passed through the web application proxy. В отличие от x-MS-Proxy, инсидекорпоратенетворк — это логическое значение со значением true, которое указывает на запрос непосредственно к службе Федерации в корпоративной сети. Unlike x-ms-proxy, insidecorporatenetwork is a boolean value with True indicating a request directly to the federation service from inside the corporate network.

X-MS-Endpoint-абсолютный путь (Активный vs passive) X-MS-Endpoint-Absolute-Path (Active vs Passive)

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

Этот тип утверждения можно использовать для определения запросов, исходящих от «активных» (насыщенных) клиентов, а также от «пассивных» (на основе веб-браузеров). This claim type can be used for determining requests originating from “active” (rich) clients versus “passive” (web-browser-based) clients. Это позволяет выполнять внешние запросы из приложений на основе браузера, таких как Outlook Веб-доступ, SharePoint Online или портал Office 365, в то время как запросы, поступающие от многофункциональных клиентов, таких как Microsoft Outlook, блокируются. This enables external requests from browser-based applications such as the Outlook Web Access, SharePoint Online, or the Office 365 portal to be allowed while requests originating from rich clients such as Microsoft Outlook are blocked.

Значение утверждения — это имя службы AD FS, которая получила запрос. The value of the claim is the name of the AD FS service that received the request.