Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Ниже приведены разнообразные требования, которым вы должны соответствовать при развертывании AD FS:
Требования к сертификату
Сертификаты играют наиболее важную роль в защите обмена данными между серверами федерации, прокси веб-приложениями, приложениями с поддержкой утверждений и веб-клиентами. Требования к сертификатам зависят от того, настраивается ли сервер федерации или прокси-компьютер, как описано в этом разделе.
Сертификаты сервера федерации
| Тип сертификата | Требования, поддержка и сведения |
|---|---|
| Сертификат SSL : Это стандартный SSL-сертификат, используемый для защиты обмена данными между серверами федерации и клиентами. | — Этот сертификат должен быть общедоступным доверенным* сертификатом X509 версии 3. — Все клиенты, обращаюющиеся к любой конечной точке AD FS, должны доверять этому сертификату. Настоятельно рекомендуется использовать сертификаты, выданные общедоступным (сторонним) центром сертификации (ЦС). Самоподписанный SSL-сертификат можно успешно использовать на серверах федерации в тестовой лабораторной среде. Однако для рабочей среды мы рекомендуем получить сертификат, выданный общедоступным удостоверяющим центром. — поддерживает любой размер ключа, поддерживаемый Windows Server 2012 R2 для SSL-сертификатов. — не поддерживает сертификаты, использующие ключи CNG. — При использовании вместе с сервисом Workplace Join/службы регистрации устройств альтернативное имя SSL-сертификата для сервиса AD FS должно содержать значение enterpriseregistration, за которым следует суффикс имени участника-пользователя (UPN) вашей организации, например enterpriseregistration.contoso.com. — Поддерживаются сертификаты подстановочных карт. При создании фермы 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. |
| Сертификат подписывания токенов: Это стандартный сертификат X.509, используемый для безопасной подписи всех токенов, которые выдает сервер федерации. | — По умолчанию AD FS создает самозаверяющий сертификат с 2048-разрядными ключами. — Сертификаты, выданные УЦ, также поддерживаются и могут быть изменены с помощью оснастки для управления AD FS. — Сертификаты, выданные ЦС, должны храниться и получать доступ через поставщика шифрования CSP. — Сертификат подписи токена не может быть сертификатом, использующим ключи CNG. — AD FS не требует сертификатов, зарегистрированных извне, для подписи токенов. AD FS автоматически продлевает эти самозаверенные сертификаты до истечения срока их действия, сначала настраивая новые сертификаты в качестве вторичных сертификатов, чтобы позволить партнёрам использовать их, а затем смена на основной в процессе, называемом автоматическим переключением сертификатов. Рекомендуется использовать сертификаты по умолчанию, автоматически созданные для подписи токенов. Если в вашей организации существуют политики, требующие настройки различных сертификатов для подписи токенов, можно указать сертификаты во время установки с помощью PowerShell (используйте параметр -SigningCertificateThumbprint командлета PowerShell 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, чтобы обеспечить доступ, если впоследствии будет изменён сертификат подписи маркеров. |
Caution
Сертификаты, используемые для подписи, расшифровки и шифрования токенов, имеют критическое значение для стабильности службы федерации. Клиенты, управляющие своими сертификатами для подписывания, расшифровки и шифрования токенов, должны обеспечить их резервное копирование и независимую доступность при восстановлении системы.
Note
В AD FS можно изменить уровень безопасного хэш-алгоритма (SHA), который используется для цифровых подписей на SHA-1 или SHA-256 (более безопасный). AD FS не поддерживает использование сертификатов с другими хэш-методами, такими как MD5 (алгоритм хэша по умолчанию, используемый с средством командной строки Makecert.exe). Рекомендуется использовать SHA-256 (который устанавливается по умолчанию) для всех подписей. SHA-1 рекомендуется использовать только в сценариях, в которых необходимо взаимодействовать с продуктом, который не поддерживает обмен данными с помощью SHA-256, таких как продукт, отличный от Майкрософт, или устаревшие версии AD FS.
Note
После получения сертификата из ЦС убедитесь, что все сертификаты импортируются в личное хранилище сертификатов локального компьютера. Сертификаты можно импортировать в личное хранилище с помощью оснастки "Сертификаты MMC".
Требования к оборудованию
Следующие минимальные и рекомендуемые требования к оборудованию применяются к серверам федерации AD FS в Windows Server 2012 R2:
| Требования к оборудованию | Минимальные требования | рекомендуемое требование |
|---|---|---|
| CPU speed | 1,4 ГГц 64-разрядный процессор | Четыре ядра, 2 ГГц |
| RAM | 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 или более поздней версии.
Note
Все поддержку сред с контроллерами домена Windows Server 2003 завершатся после даты окончания расширенной поддержки для Windows Server 2003. Клиентам настоятельно рекомендуется обновить контроллеры домена как можно скорее. На этой странице приведены дополнительные сведения о жизненном цикле поддержки Майкрософт. При обнаружении проблем, относящихся к средам контроллера домена Windows Server 2003, исправления будут выданы только для проблем безопасности и если исправление может быть выдано до истечения срока действия расширенной поддержки Windows Server 2003.
Note
AD FS требует полностью доступного для записи контроллера домена в отличие от контроллера домена Read-Only. Если плановая топология включает контроллер домена Read-Only, контроллер домена Read-Only можно использовать для проверки подлинности, но для обработки утверждений LDAP потребуется подключение к контроллеру домена, доступного для записи.
Требования к функциональному уровню домена
Все домены учетной записи пользователя и домен, к которому присоединены серверы AD FS, должны работать на функциональном уровне домена Windows Server 2003 или более поздней версии.
Большинство функций AD FS не требуют изменения функционального уровня AD DS для успешной работы. Однако для успешной работы сертификата клиента требуется уровень функциональности домена Windows Server 2008 или более поздней версии, если сертификат явно сопоставлен с учетной записью пользователя в AD DS.
Требования к схеме
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 доверительных фондов RP | Более 100 трастов RP |
|---|---|
| 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 должен быть включен
Куки-файлы должны быть включены
Указание имени сервера (SNI) должно поддерживаться.
Для проверки подлинности сертификата пользователя и сертификата устройства (функциональность присоединения к рабочему месту) браузер должен поддерживать проверку подлинности сертификата SSL-клиента.
Несколько ключевых браузеров и платформ прошли проверку на рендеринг и функциональность, детали которых перечислены далее. Браузеры и устройства, которые не рассматриваются в этой таблице, по-прежнему поддерживаются, если они соответствуют приведенным выше требованиям:
| Browsers | Platforms |
|---|---|
| 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 |
Important
Известная проблема — Firefox: функция присоединения к рабочему месту, которая определяет устройство с помощью сертификата устройства, не работает на платформах Windows. Firefox в настоящее время не поддерживает проверку подлинности SSL-сертификата клиента с помощью сертификатов, подготовленных для хранилища сертификатов пользователя на клиентах Windows.
Cookies
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 для входящего трафика. Это не обязательно для брандмауэра между прокси-сервером веб-приложения и серверами федерации.
Note
Кроме того, убедитесь, что порт 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, см. в разделе "Роль хранилищ атрибутов".
Note
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 или более поздней версии.
При работе с пользовательским хранилищем атрибутов может потребоваться также настроить строку подключения. В этом случае можно ввести пользовательский код, который позволяет подключиться к пользовательскому хранилищу атрибутов. Строка подключения в этой ситуации представляет собой набор пар name/value, которые интерпретируются разработчиком пользовательского хранилища атрибутов. Дополнительные сведения о разработке и использовании пользовательских хранилищ атрибутов см. в разделе "Обзор хранилища атрибутов".
Требования к приложениям
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 с использованием Negotiate (только NTLM) для конечных точек WS-Trust, которые поддерживают встроенную проверку подлинности Windows.
Для проверки подлинности сертификата:
Расширяется до смарт-карт, которые могут быть защищены PIN-кодом.
Графический интерфейс пользователя для ввода пин-кода не предоставляется AD FS и должен быть частью клиентской операционной системы, отображаемой при использовании TLS клиента.
Поставщик служб чтения и шифрования (CSP) для смарт-карты должен работать на компьютере, где находится браузер.
Сертификат смарт-карты должен восходить к доверенному корневому сертификату на всех серверах AD FS и прокси-серверах веб-приложений.
Сертификат должен сопоставляться с учетной записью пользователя в AD DS с помощью любого из следующих методов:
Имя субъекта сертификата соответствует отличительному имени учетной записи пользователя в AD DS.
Расширение альтернативного имени субъекта сертификата имеет основное имя пользователя (UPN) учетной записи в AD DS.
Для простой интегрированной проверки подлинности Windows с помощью Kerberos в интрасети
Это необходимо для того, чтобы имя службы было частью доверенных сайтов или сайтов локальной интрасети.
Кроме того, для учетной записи службы, на которой работает ферма AD FS, должно быть установлено SPN (имя участника-службы) HOST/<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.
Альтернативное имя субъекта (Subject Alternative Name) SSL-сертификата для службы AD FS должно содержать значение enterpriseregistration, за которым следует суффикс имени пользователя (UPN) вашей организации, например, enterpriseregistration.corp.contoso.com.
Требования к шифрованию
В следующей таблице приведены дополнительные сведения о поддержке криптографии для подписывания токенов AD FS, функций шифрования и расшифровки токенов:
| Algorithm | Длина ключа | Protocols/Applications/Comments |
|---|---|---|
| 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 | Default. Поддерживаемый алгоритм шифрования маркера безопасности. |
| 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 | Default. Поддерживаемый алгоритм шифрования симметричного ключа, который шифрует маркер безопасности. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | N/A | Используется сервером AD FS для генерации sourceId артефакта. В этом сценарии STS использует SHA1 (в соответствии с рекомендациями стандарта SAML 2.0) для создания короткого 160-битового значения для sourceId артефакта. Кроме того, используется веб-агентом AD FS (устаревшим компонентом времён WS2003) для идентификации изменений в данных «Последнее обновление», чтобы знать, когда обновлять сведения из STS. |
| SHA1withRSA- | N/A | Используется в случаях, когда сервер AD FS проверяет подпись запроса аутентификации SAML, подписывает запрос на разрешение артефактов или ответ, а также создает сертификат подписи токенов. В этих случаях SHA256 используется по умолчанию, а SHA1 используется только в том случае, если партнер (проверяющая сторона) не может поддерживать SHA256 и должен использовать SHA1. |
Требования к разрешениям
Администратор, выполняющий установку и начальную конфигурацию AD FS, должен иметь разрешения администратора домена в локальном домене (иными словами, домен, к которому присоединен сервер федерации.)
См. также
Руководство по проектированию AD FS в Windows Server 2012 R2