Глава 11. Реализация решений федеративной подлинности и доступа

В данном разделе мы обсудим как применять Федеративные службы Active Directory для управления федеративными средами. Во- первых мы те новые процессы обновления, которые могут применяться в AD FS. Мы также объясним новые методы управления аутентификацией, включая политики управления доступом, многофакторную аутентификацию, а также регистрацию устройств. Другой новой возможностью в Windows Server 2016 является включение устройств Windows Hello for Business для Windows 10. Наконец, мы рассмотрим новых возможностей интеграции с Azur, Office 365 и прочими каталогами LDAP.

Данный раздел опишет как:

Чтобы гарантировать чтобы новые введённые в Windows Server 2016 свойства AD FS можно было применять в ферме AD FS, для определения того, какие свойства могут использоваться, а какие нет, был введён Уровень поведения фермы (FBL, farm behavior level). Некая включающая в себя хосты Windows Server 2012 R2 ферма AD FS имеет FBL Windows Server 2012 R2.

FBL работает аналогично уровню вашего домена или леса для Active Directory. При довалении некоего хоста Windows Server 2016 в ферму, такая ферма рассматривается как работающая в смешанном режиме. Все новые свойства доступные в Windows Server 2016 не могут применяться пока FBL не будет повышен до Windows Server 2016. Такой FBL не может быть повышен, пока все серверы Windows Server 2012 R2 не будут удалены из этой фермы.

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

Общий процесс обновления такой фермы включает в себя:

При добавлении Relying Party Trust вы можете сделать выбор между доверительными отношениями на основе осведомлённости о правах (claims aware) или без неё (non-claims aware). Осведомлённые о правах приложения используют в качестве процесса аутентификации и авторизации маркеры (tokens) безопасности. Не осведомлённые о правах приложения могут применяться с WAP (Web Application Proxy, Представления веб приложений) через Интегрированную в Windows аутентификацию (Windows Integrated Authentication). Создание Relying Party Trust может быть выполнено в оснастке AD FS. Рисунок 11-1 показывает начальное окно данного мастера, а именно выбор осведомлённости о правах или без неё.

Следующий шаг настройки Доверительного траста (relying party trust) состоит в определении источника данных для доверительной стороны. Эта информация может быть предоставлена тремя путями:

Рисунок 11-2 показывает доступные опции для представления подробностей настройки.

При определении подробностей вручную данная необходимая информация включает в себя:

После определения всех подобностей доверительных отношений следующим настраиваемым элементом будет устаналивать ли политики управления доступом. Эти политики могут быть настроены в данный момент, либо позже. Обычным методом доступа является разрешение всем (everyone), однако при наличии требования многофакторной аутентификации при осуществлении внешнего запроса. Рисунок 11-3 отображает выбор политики управления доступом.

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

В оснастке управления AD FS вы можете также определять персонально настраиваемые политики управления доступом. Имеющиеся параметры для разрешения:

Вы также можете разрешать этих пользователей или группы со следующими исключениями:

Рисунок 11-5 отображает определение персональных политики доступа.

Использование многофакторной аутентификации Azur (MFA) посредством AD FS имеет определённые предварительные требования:

Итого, весь процесс общей настройки для использования MFA с Azur включаетв себя:

Генерация сертификата для Azur MFA осуществляется путём выполнения cmdlet New-AdfsAzureMfaTenantCertificate. Данный сертификат создаётся и помещается в хранилище сертификатов данной машины в её сервере AD FS. Именем субъекта для данного сертификата является TenantID для каталога Azure AD.

Чтобы добавить полномочия в SPN для Azur MFA, получите соответствующие полномочия от созданного сертификата. Добавьте эти полномочия применив cmdlet New-MsolServicePrincipalCredential, определив GUID для своего Azure MFA Auth Client.

Наконец, вы должны настроить свою ферму AD FS воспользовавшись cmdlet Set-AdfsAzureMfaTenant. Этот cmdlet потребует TenantId и ClientId для вашей подписки Azur. По окончанию выполнения изменений настроек, ваша служба AD FS должна перезапуститься на всех серверах в данной ферме. После повторного запуска MFA Azur доступен в качестве метода аутентификации. Рисунок 11-6 отображает применение в качестве метода аутентификации Azure MFA.

AD FS в Windows Server 2016 расширяет регистрацию устройств, делая возможной подпись и управление доступом на основе соответствия состояния устройства. Когда аутентификация пользователей применяет полномочия устройства, данное соответствие устройства вычисляется повторно чтобы гарантировать, что политики применены надлежащим образом. Это может включать в себя:

Рисунок 11-7 иллюстрирует применение регистрации устройств посредством AD FS или Microsoft Intune. Обе службы используют Azure AD с устройствами Azure AD Connect отложенной записи. Эти устройства могут присоединяться к расположенным на площадке службам, которые также должны иметь условные политики доступа, аутентификацию устройств или MFA.

Уровень доверия устройств должен быть одного из трёх уровней:

Windows Hello for Business делает возможной для организаций замену паролей пользователей неким PIN или биометрическими телодвижениями. AD FS поддерживает эти возможности Wndows 10 для предоставления аутентификации без необходимости какого бы то ни было пароля. Общие шаги для разрешения Windows Hello применительно к AD FS включают в себя:

Ранее в данной главе мы объяснили что вы можете зачислить устройства в политики MDM через Azur AD и включить многофакторную аутентификацию (MFA) при помощи Azur AD. AD FS может также интегрироваться с Azur и Office 365 для отправки заявок окончания срока действия паролей приложениям, которые федерализованы с AD FS. В Office 365 уведомление об истечении срока действия пароля может отправлено в Exchange и Outlook для уведомления пользователей о скором времени окончания срока действия пароля.

На момент написания, такие заявки доступны только для аутентификации с применением имени пользователя и пароля, либо при использовании Windows Hello for Business, в прочих вариантах уведомление об истечении срока действия пароля не отображается. Кроме того, уведомление об истечении действия пароля отображается только если такой срок истечения действия пароля наступает в последующие 14 дней.

Для настройки AD FS на включение отправки заявок об истечении срока действия пароля добавьте следующее правило заявки в соответствующий доверительный траст (relying party trust):

c1:[Type == &qout;http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime&qout;] => issue(store = &qout;_PasswordExpiryStore&qout;, types = (&qout;http://schemas.microsoft.com/ws/2012/01/passwordexpirationtime&qout;, &qout;http://schemas.microsoft.com/ws/2012/01/passwordexpirationdays&qout;, &qout;http://schemas.microsoft.com/ws/2012/01/passwordchangeurl&qout;), query = &qout;{0};&qout;, param = c1.Value);
 	   

В Windows Server 2016 AD FS представляет поддержку трёх новых сценариев LDAP:

Вы можете создать некое соединение из AD FS к каталогу LDAP воспользовавшись cmdlet New-AdfsLdapServerConnection. Рисунок 11-8 показывает создание нового соединения с сервером LDAP.

Затем вы можете привести в соответствие атрибуты LDAP для AD FS применяя cmdlet New-AdfsLdapAttributeToClaimMapping. например, вы можете поставить в соответствие поля имени, фамилии и отображаемого имени соответствующим заявкам AD FS. Наконец, зарегистрируйте хранилище LDAP в ферме AD FS как поставщика заявок воспользовавшись cmdlet Add-AdfsLocalClaimProviderTrust. {Прим. пер.: в качестве стороннего LDAP можно применять, например, OpenLDAP.}

В данном разделе мы объясним как устанавливать и настраивать обратное представление (reverse proxy) с помощью WAP (Web Application Proxy, Представления веб приложений). Wab полезен для интеграции с AD FS и для обеспечения доступа к внешним приложениям. WAP позволяет организациям применять либо проброс, либо предварительную аутентификацию AD FS в некоторой сетевой среде периметра для внешних пользователей.

Данный раздел опишет как:

Пока служба роли WAP AD FS, данная служба роли AD FS сама по себе является частью роли сервера Удалённого доступа (Remote Access). Установка этой службы роли осуществляется с применением мастера Добавления ролей или свойств, либо с использованием Windows PowerShell. Когда она добавлена, примените мастер настройки WAP, как это отображено на Рисунке 11-9 для настройки соответствующей службы.

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

Кроме того, вы можете настроить Представление веб приложений (WAP) воспользовавшись cmdlet Install-WebApplicationProxy. Этот cmdlet должен определить имя федеративной службы и подлежащий применению отпечаток (thumbprint) сертификата:

Install-WebApplicationProxy -CertificateThumbprint 'A142A369FC60C7984A70A56A17E31228546D85D8' -FederationServiceName 'host02.contosoforest.com'
 	   

режим проброса предписывает вашему WAP не выполнять никакой аутентификации. Все получаемые WAP запросы автоматически передаются далее соответствующему приложению получателю. Рисунок 11-11 отображает выбор проброса в качестве метода аутентификации.

Кроме того, вы можете воспользоваться cmdlet Add-WebApplicationProxyApplication и определить в качестве параметра ExternalPreAuthentication PassThrough:

Add-WebApplicationProxyApplication -BackendServerURL 'https://app1.contosoforest.com/' -ExternalCertificateThumbprint '1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b' -ExternalURL 'https://app1.contosoforest.com/' -Name 'App1 (no preauthentication)' -ExternalPreAuthentication PassThrough
 	   

Имеются два раздела ваших навыков, которые включают применение WAP с AD FS, которые мы объединили в данном пункте. Рисунок 11-10 также отображает второй вариант предварительной аутентификации для WAP, которым является AD FS. Если ваш WAP получает не аутентифицированный запрос, тогда этот запрос перенаправляется в вашу ферму AD FS. После выполнения аутентификации со стороны AD FS этот запрос затем отправляется серверу приложения. Если данный клиент применяет интегрированную аутентификацию Windows, тогда данный WAP может переправить далее имеющиеся полномочия соответствующему серверу приложения. Рисунок 11-12 отображает поддерживаемого клиента, который может применяться с представлением (proxy) AD FS, включая:

Единственным требованием для настройки WAP с AD FS состоит в том, чтобы некая ферма была настроена с каким- то Доверительным трастом (relying party trust). Без соответствующего оверительного траста у вас не будет возможности какой бы то ни было публикации для её применения с вашим WAP.

Публикация некоторого приложения выполняется в Консоли управления Удалённым доступом (Remote Access Management Console) при помощи мастера Публикации нового приложения. При публикации некоего приложения вы должны определить специфическую для этого приложения информацию:

Рисунок 11-13 отображает те настройки публикации, которые должны быть определены для некоторого приложения.

Кроме того, для публикации нового приложения вы можете воспользоваться cmdlet Add-WebApplicationProxyApplication:

Add-WebApplicationProxyApplication -BackendServerUrl 'https://app1.contosoforest.com' -ExternalCertificateThumbprint '2FC38D0224B0A6412F450A9597271179878708B0' -EnableHTTPRedirect:$true -ExternalUrl 'https://app1.contosoforest.com' -Name 'App1' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'AD FS'
 	   

Публикация некоторого Шлюза удалённых рабочих мест (RDG, Remote Desktop Gateway) позволяет вам ограничить доступ к такому RDG и добавить некий уровень предварительной аутентификации с использованием какого- то WAP. Это в особенности полезно для включения MFA с RDG. Такой процесс публикации RDG через WAP зависит от того, настроен ли RD Web Access и RD Gateway на том же самом сервере, либо на разных серверах. Применение одного сервера позволяет вам публиковать только имеющиеся FQDN корня (root). Применение различных серверов означает, что вы должны публиковать два каталога по отдельности.

Как и спрочими публикуемыми приложениями, вы должны создать соответствующий Доверительный траст (relying party trust) при помощи имеющегося в вашем RDG FQDN. Затем вы можете опубликовать свой корень имеющегося сайта в данном WAP. Вы также должны запретить в этом WAP свойство cookie HttpOnly для публикуемого приложения.

Windows Server 2016 и WAP предоставляют новую возможность для автоматического перенаправления запросов пользователя с небезопасных HTTP на безопасные соединения HTTPS. Настройка такого перенаправления управляется на основе публикуемого приложения и просто включается или отключается для данного приложения.

При использовании cmdlet Add-WebApplicationProxyApplication параметр EnableHTTPRedirect принимает либо $True, либо $False для включения или отключения перенаправления запросов клиента.

Как это отображает Рисунок 11-13, имеется два адреса FQDN, которые настраиваются с неким приложением. URL лежащего в основе сервера является FQDN внутреннего ресурса, по которому доступно это приложение.

В большинстве сценариев эти URL являются одними и теми же. Если FQDN различаются для внешних и внутренних запросов, тогда также должна быть настроена трансляция URL для обеспечения правильного перенаправления запросов. Чтобы включить трансляцию URL, воспользуйтесь cmdlet Set-WebApplicationProxyApplication:

Set-WebApplicationProxyApplication –ID AppID -DisableTranslateUrlInRequestHeaders:$False
 	   

Некая организация имеет ферму Windows Server 2012 R2 AD FS. Они планируют обновление на соответствующую ферму Windows Server 2016. После обновления они также планируют реализовать для своих приложений Azure MFA. Эта организация в настоящее время не имеет в своей среде никакого дополнительно настроенного программного обеспечения. Решения MFA также должны работать совместно с биометрическими опциями. После обновления они планируют централизовать пользовательские запросы с применением обратного представления (reverse proxy). Все пользовательские запросы должны быть безопасными.

Применяя описанный сценарий, ответьте на следующие вопросы:

1. Как организации следует выполнить такое обновление?

2. Какое дополнительное программное обеспечение должна применять эта организация для интеграции с Azur MFA?

3. Какую технологию следует применять данной организации для включения биометрического MFA?

4. Как этой организации гарантировать что все запросы безопасны?

1 Предприятию следует выполнять индивидуальные обновления для повышения общего Уровня поведения фермы (FBL) в данной ферме AD FS. Им не следует выполнять повторную установку AD FS и экспорт всей настройки.

2 Им следует применять Диспетчер настройки Системного центра (System Center Configuration Manager) для упрощения настройки Azur MFA и управления им.

3 Для обеспечения того, чтобы биометрическую аутентификацию можно было применять для общедоступных приложений, следует воспользоваться Windows Hello for Business.

4 Им следует настроить WAP для перенаправления всех запросов HTTP в HTTPS для каждого из публикуемых приложений.