1. В первую очередь (ещё перед установкой роли) для работы ADFS необходимо создать сервисную учётную запись на контроллере домена.

На КД от имени администратора запускаем PowerShell и выполняем:

 Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
 
 New-ADServiceAccount -Name FSgMSA -DnsHostName YouDnsHostName -ServicePrincipalNames http/YouDnsHostName

YouDnsHostName - меняем на хостнейм adfs-сервера и имя службы ADFS для подключения (ServicePrincipalNames).

2. Для ADFS используется два основных сертификата.

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

Для начала установки нам необходимо сгенерировать сертификат служб. Для этих целей хорошо подходит шаблон Web Server. Можно сделать его дубликат, в котором желательно на всякий случай установить возможность экспорта закрытого ключа, а также выдать в настройках безопасности право на enroll для машинного аккаунта сервера ADFS. Больше ничего специфического менять не требуется.

Примечание: для работы ADFS лучше издавать RCA сертификат, т.к. с ECC, к примеру, возникает ошибка при установке. Ошибка имеет следующее содержание:

 "ID8025 Parameter name: value"

После создания подходящего шаблона запросим сертификат у ЦС обычным образом.

Примечание: CN (Common Name) запрашиваемого сертификата должен соответствовать FQDN ADFS-сервера, иначе при попытке настроить роль ADFS мы не увидим сертификат в списке и не сможем его импортировать.

Примечание 2: Можно импортировать сертификат в сертификаты компьютера, а можно скормить установщику роли PFX-файл с сертификатом и закрытым ключом, разницы нет, главное, чтобы сертификат соответствовал указанным выше требованиям.

3. Запустим установщик роли и выберем при установке ролей Active Directory Federation Services.

Роль можно установить при помощи следующего командлета:

 Install-WindowsFeature ADFS-Federation -IncludeManagementTools

На этапе установки роли никаких подводных камней нет.

4. После установки запустим конфигурирование роли.

Если у нас первый сервер - на следующем этапе выбираем соответствующую опцию.

Если мы работаем под администратором домена - на следующем этапе подтверждаем выбор собственной УЗ, либо вводит креды админа домена.

На этапе выбора сертификата - указываем наш сгенерированный сертификат, который мы получили на этапе 2.

Выбираем имя, соответствующее CN сертификата и прописанное в свойствах DNS-сертификата, а также отображаемое имя для служб ADFS. К примеру:

adfs.arasaka.local

Arasaka Labs ADFS

На этапе выбора учётной записи службы - выбираем FSgMS-аккаунт, который создавали на этапе 1.

Именно от этой записи будет стартовать windows-служба ADFS.

В случае, если мы не создаём отказоустойчивую ферму серверов (с SQL), можем оставить в качестве БД Windows Internal Database. Всё остальное на этапе конфигурирования оставляем по умолчанию.

При появлении ошибки с таймаутом - можно проверить - достаточно ли серверу ADFS памяти и ресурсов. При тестировании такая ошибка возникала при установке сервера с минимально рекомендованным объемом RAM - 2ГБ.

При появлении ошибок конфигурирования - установщик роли предложит повторить процедуру конфигурирования. В этом случае на одном из этапов будет возможность перезаписать текущую конфигурацию ADFS. Можно это сделать.

5. А что с сертификатом подписи (signing certificate)?

Данный сертификат не хранится в стандартных хранилищах сертификатов. Посмотреть его можно, используя оснастку управления ADFS. По умолчанию ADFS генерирует самоподписанный сертификат на год. Т.к. данный сертификат необходимо экспортировать вручную на серверы-партнёры (например, Exchange, который будет использовать ADFS), хорошей идей будет перегенерировать данный сертификат, задав больший срок действия.

На сервере ADFS выполняем:

Set-AdfsProperties -CertificateDuration 3650
Set-ADFSProperties -AutoCertificateRollover $true
Update-AdfsCertificate -CertificateType Token-Decrypting
Update-AdfsCertificate -CertificateType Token-Signing 

Теперь в консоли управления ADFS на вкладке сертификаты мы скорее всего обнаружим два сертификата. При этом, первый сертификат, сгенерированный ADFS при инсталляции будет установлен в качестве primary, а только что сгенерированный на 10 лет - secondary. Функция set as primary будет не активна. Для того, чтобы мы могли вручную установить новый сертификат как primary - необходимо выключить автоматический выпуск сертификатов. Сделаем это командой:

 Set-ADFSProperties -AutoCertificateRollover $false

Управление сертификатами в консоли:

После установки нового сертификата как primary - старый можно удалить из консоли ADFS.

6. Из данной же консоли можно выгрузить сертификат и установить, к примеру, на Exchange-сервер (данные сертификаты необходио устанавливать в доверенные корневые центры сертификации).

7. Проверить работу ADFS можно так:

Открыть в браузере URL: https://adfs.arasaka.local/federationmetadata/2007-06/federationmetadata.xml