Требования AD FS для Windows Server

Ниже приведены различные требования, которые должны соответствовать при развертывании AD FS:

Требования к сертификатам

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

Сертификаты сервера федерации

Тип сертификата Требования, поддержка и сведения
Сертификат SSL: это стандартный SSL-сертификат, используемый для защиты связи между серверами федерации и клиентами. — Этот сертификат должен быть общедоступным доверенным* сертификатом X509 версии 3.
— Все клиенты, обращаюющиеся к любой конечной точке AD FS, должны доверять этому сертификату. Настоятельно рекомендуется использовать сертификаты, выданные общедоступным (сторонним) центром сертификации (ЦС). Самозаверяющий SSL-сертификат можно использовать на серверах федерации в тестовой лабораторной среде. Однако для рабочей среды рекомендуется получить сертификат из общедоступного центра сертификации.
— поддерживает любой размер ключа, поддерживаемый Windows Server 2012 R2 для SSL-сертификатов.
— не поддерживает сертификаты, использующие ключи CNG.
— При использовании вместе со службой регистрации рабочих мест или регистрации устройств альтернативное имя SSL-сертификата для службы AD FS должно содержать значение корпоративной регистрации, за которой следует суффикс имени участника-пользователя (UPN) вашей организации, например enterpriseregistration.contoso.com.
— Поддерживаются сертификаты wild карта. При создании фермы AD FS вам будет предложено указать имя службы для службы AD FS (например, adfs.contoso.com.
— Настоятельно рекомендуется использовать тот же SSL-сертификат для прокси веб-приложения. Однако это необходимо для обеспечения поддержки конечных точек встроенной проверки подлинности Windows через прокси-сервер веб-приложения, а также при включении расширенной проверки подлинности (параметр по умолчанию).
— Имя субъекта этого сертификата используется для представления имени службы федерации для каждого развернутого экземпляра AD FS. По этой причине имеет смысл выбрать имя субъекта на вновь изданных ЦС сертификатах, наиболее полно отражающее имя компании или организации для партнеров.
Удостоверение сертификата должно соответствовать имени службы федерации (например, fs.contoso.com). Удостоверение является расширением альтернативного имени субъекта типа dNSName или, если нет записей альтернативного имени субъекта, имя субъекта, указанное в качестве общего имени. Несколько записей альтернативного имени субъекта могут присутствовать в сертификате, если один из них соответствует имени службы федерации.
- Важно: настоятельно рекомендуется использовать один и тот же SSL-сертификат на всех узлах фермы AD FS, а также все прокси-серверы веб-приложений в ферме AD FS.
Сертификат связи службы. Этот сертификат обеспечивает безопасность сообщений WCF для защиты обмена данными между серверами федерации. — По умолчанию SSL-сертификат используется в качестве сертификата связи службы. Но у вас также есть возможность настроить другой сертификат в качестве сертификата связи службы.
- Важно: если вы используете SSL-сертификат в качестве сертификата связи службы, когда срок действия SSL-сертификата истекает, обязательно настройте обновленный SSL-сертификат в качестве сертификата связи службы. Это не происходит автоматически.
— Этот сертификат должен быть доверенным клиентами AD FS, используюющими безопасность сообщений WCF.
— Рекомендуется использовать сертификат проверки подлинности сервера, выданный общедоступным (сторонним) центром сертификации (ЦС).
— Сертификат связи службы не может быть сертификатом, использующим ключи CNG.
— Этот сертификат можно управлять с помощью консоли управления AD FS.
Сертификат подписывания токенов: это стандартный сертификат X509, который используется для безопасной подписи всех маркеров, проблем с сервером федерации. — По умолчанию AD FS создает самозаверяющий сертификат с 2048-разрядными ключами.
— Сертификаты, выданные ЦС, также поддерживаются и могут быть изменены с помощью оснастки управления AD FS
— Сертификаты, выданные ЦС, должны храниться и получать доступ через поставщика шифрования CSP.
— Сертификат подписи маркера не может быть сертификатом, использующим ключи CNG.
— AD FS не требует внешних зарегистрированных сертификатов для подписи маркеров.
AD FS автоматически продлевает эти самозаверяющие сертификаты до истечения срока их действия, сначала настраивая новые сертификаты в качестве вторичных сертификатов, чтобы позволить партнерам использовать их, а затем перевернуться на первичный в процессе, называемом автоматической откатом сертификатов. Рекомендуется использовать сертификаты по умолчанию, автоматически созданные для подписи маркеров.
Если в организации есть политики, требующие настройки различных сертификатов для подписи маркеров, можно указать сертификаты во время установки с помощью PowerShell (используйте параметр -SigningCertificateThumbprint командлета Install-AdfsFarm). После установки вы можете просматривать сертификаты подписи маркеров и управлять ими с помощью консоли управления AD FS или командлетов PowerShell Set-AdfsCertificate и Get-AdfsCertificate.
При использовании внешних зарегистрированных сертификатов для подписи маркеров AD FS не выполняет автоматическое продление или откат сертификатов. Этот процесс должен выполняться администратором.
Чтобы разрешить откат сертификата при истечении срока действия одного сертификата, можно настроить сертификат подписи дополнительного маркера в AD FS. По умолчанию все сертификаты подписывания маркеров публикуются в метаданных федерации, но только первичный сертификат подписи маркеров используется AD FS для фактических подписывания маркеров.
Сертификат шифрования и расшифровки маркеров: это стандартный сертификат X509, используемый для расшифровки и шифрования всех входящих маркеров. Она также публикуется в метаданных федерации. — По умолчанию AD FS создает самозаверяющий сертификат с 2048-разрядными ключами.
— Сертификаты, выданные ЦС, также поддерживаются и могут быть изменены с помощью оснастки управления AD FS
— Сертификаты, выданные ЦС, должны храниться и получать доступ через поставщика шифрования CSP.
— Сертификат расшифровки и шифрования токена не может быть сертификатом, использующим ключи CNG.
— По умолчанию AD FS создает и использует собственные, внутренние и самозаверяющие сертификаты для расшифровки маркеров. Ad FS не требует внешних зарегистрированных сертификатов для этой цели.
Кроме того, AD FS автоматически обновляет эти самозаверяемые сертификаты до истечения срока их действия.
Рекомендуется использовать сертификаты по умолчанию, автоматически созданные для расшифровки маркеров.
Если у вашей организации есть политики, требующие настройки разных сертификатов для расшифровки маркеров, можно указать сертификаты во время установки с помощью PowerShell (используйте параметр –DecryptionCertificateThumbprint командлета Install-AdfsFarm). После установки вы можете просматривать сертификаты расшифровки маркеров и управлять ими с помощью консоли управления AD FS или командлетов PowerShell Set-AdfsCertificate и Get-AdfsCertificate.
При использовании внешних зарегистрированных сертификатов для расшифровки маркеров AD FS не выполняет автоматическое продление сертификата. Этот процесс должен выполняться администратором..
— учетная запись службы AD FS должна иметь доступ к закрытому ключу сертификата подписи маркеров в личном хранилище локального компьютера. Это заботится о настройке. Вы также можете использовать оснастку управления AD FS, чтобы обеспечить этот доступ при последующем изменении сертификата подписи маркеров.

Внимание

Сертификаты, используемые для подписывания маркеров и расшифровки маркеров и шифрования, критически важны для стабильности службы федерации. Клиенты, управляющие собственными сертификатами подписывания маркеров и расшифровки маркеров и шифрования, должны убедиться, что эти сертификаты резервируются и доступны независимо во время события восстановления.

Примечание.

В AD FS можно изменить уровень безопасного хэш-алгоритма (SHA), который используется для цифровых подписей на SHA-1 или SHA-256 (более безопасный). AD FS не поддерживает использование сертификатов с другими хэш-методами, такими как MD5 (алгоритм хэша по умолчанию, используемый с средством командной строки Makecert.exe). В целях безопасности рекомендуется использовать алгоритм SHA-256 (настроенный по умолчанию) для всех подписей. SHA-1 рекомендуется использовать только в сценариях, в которых необходимо взаимодействовать с продуктом, который не поддерживает обмен данными с помощью SHA-256, таких как продукт, отличный от Майкрософт, или устаревшие версии AD FS.

Примечание.

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

Требования к аппаратному обеспечению

Следующие минимальные и рекомендуемые требования к оборудованию применяются к серверам федерации AD FS в Windows Server 2012 R2:

Требования к оборудованию Минимальное значение Рекомендуемое значение
Скорость ЦП 64-разрядный процессор с тактовой частотой 1,4 ГГц четырехъядерный с частотой 2 ГГц
ОЗУ 512 МБ 4 ГБ
Место на диске 32 Гб 100 ГБ

Требования к программному обеспечению

Следующие требования AD FS предназначены для функций сервера, встроенных в операционную систему Windows Server® 2012 R2:

  • Для доступа к экстрасети необходимо развернуть службу роли прокси веб-приложения — часть роли сервера удаленного доступа Windows Server® 2012 R2. Предыдущие версии прокси-сервера федерации не поддерживаются с AD FS в Windows Server® 2012 R2.

  • Сервер федерации и служба прокси-роли веб-приложения не могут быть установлены на одном компьютере.

Требования к AD DS

Требования к контроллеру домена

Контроллеры домена во всех доменах пользователей и домене, к которому присоединены серверы AD FS, должны работать под управлением Windows Server 2008 или более поздней версии.

Примечание.

Все поддержку сред с контроллерами домена Windows Server 2003 завершатся после даты окончания расширенной поддержки для Windows Server 2003. Клиентам настоятельно рекомендуется обновить контроллеры домена как можно скорее. Дополнительные сведения о жизненном цикле служба поддержки Майкрософт см. на этой странице. При обнаружении проблем, относящихся к средам контроллера домена Windows Server 2003, исправления будут выданы только для проблем безопасности и если исправление может быть выдано до истечения срока действия расширенной поддержки Windows Server 2003.

Примечание.

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

Требования к функциональному уровню домена

Все домены учетных записей пользователей и домены, к которым присоединяются серверы AD FS, должны работать на функциональном уровне домена Windows Server 2003 или более поздней версии.

Для использования большинства функций AD FS не требуются модификации AD FS функционального уровня. Однако для успешной аутентификации клиентских сертификатов (если сертификат явно сопоставлен учетной записи пользователя в AD DS) требуется функциональный уровень домена Windows Server 2008 или выше.

Требования к схеме

  • AD FS не требует изменений схемы или функциональных изменений в AD DS.

  • Чтобы использовать функцию присоединения к рабочему месту, схема леса, к которому присоединены серверы AD FS, должна иметь значение Windows Server 2012 R2.

Требования к учетным записям служб

  • Любую стандартную учетную запись службы можно использовать в качестве учетной записи службы для AD FS. Кроме того, поддерживаются учетные записи управляемых служб группы. Для этого требуется по крайней мере один контроллер домена (рекомендуется развернуть два или более) под управлением Windows Server 2012 или более поздней версии.

  • Для проверки подлинности Kerberos между присоединенными к домену клиентами и AD FS необходимо зарегистрировать в качестве имени субъекта-службы в учетной записи службы .HOST/<adfs_service_name>. По умолчанию AD FS настраивает это при создании новой фермы AD FS, если у нее есть достаточные разрешения для выполнения этой операции.

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

Требования к домену

  • Все серверы AD FS должны быть присоединены к домену AD DS.

  • Все серверы AD FS в ферме должны быть развернуты в одном домене.

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

Требования к нескольким лесам

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

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

Требования к базе данных конфигурации

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

WID

  • Ферма WID имеет ограничение на 30 серверов федерации, если у вас есть 100 или меньше доверия проверяющей стороны.

  • Профиль разрешения артефактов в SAML 2.0 не поддерживается в базе данных конфигурации WID. Обнаружение воспроизведения маркеров не поддерживается в базе данных конфигурации WID. Эта функция используется только в сценариях, когда AD FS выступает в качестве поставщика федерации и использует маркеры безопасности от внешних поставщиков утверждений.

  • Развертывание серверов AD FS в разных центрах обработки данных для отработки отказа или географической балансировки нагрузки поддерживается, если количество серверов не превышает 30.

В следующей таблице приведена сводка по использованию фермы WID. Используйте его для планирования реализации.

От 1 до 100 отношений доверия с проверяющей стороной Более 100 отношений доверия с проверяющей стороной
1–30 узлов AD FS: поддерживается WID 1–30 узлов AD FS: не поддерживается использование WID — требуется SQL
Более 30 узлов AD FS: не поддерживается с помощью WID — требуется SQL Более 30 узлов AD FS: не поддерживается с помощью WID — требуется SQL

SQL Server

Для AD FS в Windows Server 2012 R2 можно использовать SQL Server 2008 и более поздних версий.

Требования к браузерам

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

  • Должно быть разрешено выполнение JavaScript.

  • Файлы cookie должны быть включены

  • Указание имени сервера (SNI) должно поддерживаться.

  • Для проверки подлинности сертификата пользователя и сертификата устройства (функциональность присоединения к рабочему месту) браузер должен поддерживать проверку подлинности сертификата SSL-клиента.

Несколько ключевых браузеров и платформ прошли проверку для отрисовки и функциональных возможностей, которые перечислены ниже. Браузеры и устройства, которые не рассматриваются в этой таблице, по-прежнему поддерживаются, если они соответствуют приведенным выше требованиям:

Браузеров Платформы
IE 10.0 Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
IE 11.0 Windows7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
Брокер веб-проверки подлинности Windows Windows 8.1
Firefox [v21] Windows 7, Windows 8.1
Safari [v7] iOS 6, Mac OS-X 10.7
Chrome [v27] Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7

Внимание

Известная проблема — Firefox: функция присоединения к рабочему месту, которая определяет устройство с помощью сертификата устройства, не работает на платформах Windows. Firefox в настоящее время не поддерживает проверку подлинности SSL-сертификата клиента с помощью сертификатов, подготовленных для хранилища сертификатов пользователя на клиентах Windows.

Файлы cookie

AD FS создает файлы cookie для отдельных сеансов и сохраняемые файлы cookie, которые необходимо сохранять на клиентских компьютерах для использования функций входа, выхода, единого входа и т. д. Следовательно, необходимо настроить клиентский браузер для приема файлов cookie. Файлы cookie, используемые для аутентификации, всегда представляют собой файлы cookie HTTPS-сеанса, которые записываются для исходного сервера. Если клиентский браузер не настроен для разрешения этих файлов cookie, AD FS не может работать правильно. Сохраняемые файлы cookie используются для сохранения выбранного пользователем поставщика утверждений. Их можно отключить, воспользовавшись параметром конфигурации в файле конфигурации для страниц входа AD FS. По соображениям безопасности требуется поддержка TLS/SSL.

Требования к экстрасети

Чтобы обеспечить доступ экстрасети к службе AD FS, необходимо развернуть службу роли прокси веб-приложения в качестве роли экстрасети, которая сталкивается с ролью прокси-сервера, которая запрашивает проверку подлинности прокси-сервера в службе AD FS. Это обеспечивает изоляцию конечных точек службы AD FS, а также изоляцию всех ключей безопасности (например, сертификатов подписи маркеров) от запросов, поступающих из Интернета. Кроме того, для таких функций, как блокировка учетной записи Обратимой экстрасети, требуется использование прокси веб-приложения. Дополнительные сведения о прокси-сервере веб-приложения см. в разделе "Прокси веб-приложения". `

Требования к сети

Настройка следующих сетевых служб имеет решающее значение для успешного развертывания AD FS в организации:

Настройка корпоративного брандмауэра

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

Кроме того, если требуется проверка подлинности сертификата пользователя клиента (проверка подлинности clientTLS с использованием сертификатов пользователей X509), ad FS в Windows Server 2012 R2 требует, чтобы tcp-порт 49443 был включен входящий трафик брандмауэра между клиентами и прокси-сервером веб-приложения. Это не обязательно для брандмауэра между прокси-сервером веб-приложения и серверами федерации.

Примечание.

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

Настройка DNS

  • Для доступа к интрасети все клиенты, обращающиеся к службе AD FS в внутренней корпоративной сети (интрасети), должны разрешать имя службы AD FS (имя, предоставленное SSL-сертификатом) для серверов AD FS или сервера AD FS.

  • Для доступа к экстрасети все клиенты, обращающиеся к службе AD FS за пределами корпоративной сети (экстрасети или Интернета), должны иметь возможность разрешать имя службы AD FS (имя, предоставленное SSL-сертификатом) для подсистемы балансировки нагрузки для серверов прокси веб-приложений или прокси-сервера веб-приложения.

  • Для правильного доступа к экстрасети каждый прокси-сервер веб-приложения в DMZ должен иметь возможность разрешать имя службы AD FS (имя, предоставленное SSL-сертификатом) в подсистему балансировки нагрузки для серверов AD FS или сервера AD FS. Это можно сделать с помощью альтернативного DNS-сервера в сети DMZ или изменения разрешения локального сервера с помощью ФАЙЛА HOSTS.

  • Чтобы встроенная проверка подлинности Windows работала внутри сети и вне сети для подмножества конечных точек, предоставляемых через прокси веб-приложения, необходимо использовать запись A (не CNAME), чтобы указать подсистемы балансировки нагрузки.

Сведения о настройке корпоративной службы DNS для службы федерации и службы регистрации устройств см. в разделе "Настройка корпоративного DNS для службы федерации и аварийного восстановления".

Сведения о настройке корпоративных DNS для прокси-серверов веб-приложений см. в разделе "Настройка DNS" на шаге 1. Настройка инфраструктуры прокси-сервера веб-приложения.

Сведения о настройке IP-адреса кластера или полного доменного имени кластера с помощью NLB см. в разделе "Указание параметров кластера".http://go.microsoft.com/fwlink/?LinkId=75282

Требования к хранилищу атрибутов

AD FS требует, чтобы для проверки подлинности пользователей и извлечения утверждений безопасности для этих пользователей использовалось хотя бы одно хранилище атрибутов. Список хранилищ атрибутов, поддерживаемых AD FS, см. в разделе "Роль хранилищ атрибутов".

Примечание.

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

Хранилища атрибутов LDAP

При работе с другими хранилищами атрибутов на базе протокола LDAP необходимо подключаться к серверу LDAP, поддерживающему интегрированную аутентификацию Windows. Строка подключения LDAP должна записываться в формате URL-адреса LDAP в соответствии со стандартом RFC 2255.

Кроме того, требуется, чтобы учетная запись службы службы AD FS получила право получить сведения о пользователе в хранилище атрибутов LDAP.

Хранилища атрибутов SQL Server

Для успешной работы AD FS в Windows Server 2012 R2 компьютеры с хранилищем атрибутов SQL Server должны работать под управлением Microsoft SQL Server 2008 или более поздней версии. При работе с хранилищами атрибутов на базе SQL необходимо также настроить строку подключения.

Пользовательские хранилища атрибутов

Хранилища настраиваемых атрибутов позволяют реализовывать более сложные сценарии.

  • Язык политик, интегрированный в AD FS, может ссылаться на хранилища настраиваемых атрибутов, тем самым расширяя возможности перечисленных ниже сценариев.

    • Создание утверждений для прошедшего локальную аутентификацию пользователя

    • Добавление утверждений для прошедшего внешнюю аутентификацию пользователя

    • Авторизация пользователя на получение токена

    • Авторизация службы на получение токена для поведения пользователя

    • Выдача дополнительных данных в маркерах безопасности, выданных AD FS проверяющим сторонам.

  • Все пользовательские хранилища атрибутов должны быть созданы на основе .NET 4.0 или более поздней версии.

При работе с пользовательским хранилищем атрибутов также может потребоваться настроить строка подключения. В этом случае можно ввести пользовательский код, который позволяет подключиться к пользовательскому хранилищу атрибутов. Строка подключения в этой ситуации — это набор пар "имя-значение", которые интерпретируются как реализованные разработчиком пользовательского хранилища атрибутов. Дополнительные сведения о разработке и использовании пользовательских хранилищ атрибутов см. в разделе "Обзор хранилища атрибутов".

Требования приложений

AD FS поддерживает приложения с поддержкой утверждений, использующие следующие протоколы:

  • WS-Federation

  • WS-Trust

  • Протокол SAML 2.0 с помощью профилей IDPLite, SPLite и eGov1.5.

  • Профиль предоставления авторизации OAuth 2.0

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

Требования к проверке подлинности

Проверка подлинности AD DS (первичная проверка подлинности)

Для доступа к интрасети поддерживаются следующие стандартные механизмы проверки подлинности для AD DS:

  • Встроенная проверка подлинности Windows с помощью согласования для Kerberos и NTLM

  • Проверка подлинности форм с помощью имени пользователя и паролей

  • Проверка подлинности сертификата с использованием сертификатов, сопоставленных с учетными записями пользователей в AD DS

Для доступа к экстрасети поддерживаются следующие механизмы проверки подлинности:

  • Проверка подлинности форм с помощью имени пользователя и паролей

  • Проверка подлинности сертификата с использованием сертификатов, сопоставленных с учетными записями пользователей в AD DS

  • Встроенная проверка подлинности Windows с помощью согласования (только NTLM) для конечных точек WS-Trust, которые принимают встроенную проверку подлинности Windows.

Для проверки подлинности сертификата:

  • Расширяется до смарт-карта, которые можно закрепить.

  • Графический интерфейс пользователя для ввода пин-кода не предоставляется AD FS и должен быть частью клиентской операционной системы, отображаемой при использовании TLS клиента.

  • Считывающий механизм и поставщик служб шифрования (CSP) для смарт-карты должен работать на компьютере, на котором расположен браузер.

  • Смарт-карта сертификат должен быть цепочкой до доверенного корневого каталога на всех серверах AD FS и прокси-серверах веб-приложения.

  • Сертификат должен сопоставляться с учетной записью пользователя в AD DS одним из следующих методов.

    • Имя субъекта сертификата соответствует различающемуся имени LDAP учетной записи пользователя в AD DS.

    • Расширение altname субъекта сертификата имеет имя участника-пользователя (UPN) учетной записи пользователя в AD DS.

Для простой интегрированной проверки подлинности Windows с помощью Kerberos в интрасети

  • Это необходимо для того, чтобы имя службы было частью доверенных сайтов или сайтов локальной интрасети.

  • Кроме того, в учетной записи службы, на которой выполняется ферма AD FS, должна быть задана имя участника-службы узла или< adfs_service_name> .

Многофакторная идентификация

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

Каждый адаптер MFA должен быть построен на основе .NET 4.5.

Дополнительные сведения об MFA см. в статье "Управление рисками с помощью дополнительной многофакторной проверки подлинности для конфиденциальных приложений".

Проверка подлинности устройства

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

Требования к присоединению к рабочему месту

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

  • AD FS поддерживает присоединение к рабочему месту для устройств Windows 8.1 и iOS 5+

  • Чтобы использовать функцию присоединения к рабочему месту, схема леса, к которому присоединены серверы AD FS, должна быть Windows Server 2012 R2.

  • Альтернативное имя SSL-сертификата для службы AD FS должно содержать значение корпоративной регистрации, за которым следует суффикс имени участника-пользователя (UPN) вашей организации, например enterpriseregistration.corp.contoso.com.

Требования к шифрованию

В следующей таблице приведены дополнительные сведения о поддержке шифрования для подписи маркеров AD FS, функции шифрования и расшифровки маркеров:

Алгоритм Длина ключа Протоколы, приложения и комментарии
TripleDES — по умолчанию 192 (поддерживается 192 – 256) — http://www.w3.org/2001/04/xmlenc#tripledes-cbc >= 192 Поддерживаемый алгоритм расшифровки маркера безопасности. Шифрование маркера безопасности с помощью этого алгоритма не поддерживается.
AES128 — http://www.w3.org/2001/04/xmlenc#aes128-cbc 128 Поддерживаемый алгоритм расшифровки маркера безопасности. Шифрование маркера безопасности с помощью этого алгоритма не поддерживается.
AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc 192 Поддерживаемый алгоритм расшифровки маркера безопасности. Шифрование маркера безопасности с помощью этого алгоритма не поддерживается.
AES256 — http://www.w3.org/2001/04/xmlenc#aes256-cbc 256 По умолчанию. Поддерживаемый алгоритм шифрования маркера безопасности.
TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes Все размеры ключей, поддерживаемые .NET 4.0+ Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
AES128KeyWrap — http://www.w3.org/2001/04/xmlenc#kw-aes128 128 Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
AES192KeyWrap — http://www.w3.org/2001/04/xmlenc#kw-aes192 192 Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
AES256KeyWrap — http://www.w3.org/2001/04/xmlenc#kw-aes256 256 Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 1024 Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p 1024 По умолчанию. Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности.
SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html Н/П Используется сервером AD FS в поколении sourceId артефакта. В этом сценарии служба STS использует SHA1 (на основе рекомендаций в стандарте SAML 2.0) для создания короткого 160-разрядного значения для артефакта sourceiD.

Кроме того, используется веб-агентом AD FS (устаревшим компонентом из временных интервалов WS2003) для идентификации изменений в значении времени последнего обновления, чтобы он знал, когда следует обновлять сведения из stS.
SHA1withRSA-

http://www.w3.org/PICS/DSig/RSA-SHA1_1_0.html

 Н/П Используется в случаях, когда СЕРВЕР AD FS проверяет подпись SAML AuthenticationRequest, подписывает запрос на разрешение артефактов или ответ, создает сертификат подписи маркеров.

В этих случаях SHA256 используется по умолчанию, а SHA1 используется только в том случае, если партнер (проверяющая сторона) не может поддерживать SHA256 и должен использовать SHA1.

Требования к разрешениям

Администратор, выполняющий установку и начальную конфигурацию AD FS, должен иметь разрешения администратора домена в локальном домене (иными словами, домен, к которому присоединен сервер федерации.)

См. также

Руководство по разработке служб федерации Active Directory в Windows Server 2012 R2