===== Установка роли ADFS =====

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. После установки запустим конфигурирование роли. 

;#;
{{:wiki:adfs_configure_role.png?400|}}
;#;


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

;#;
{{:wiki:first_adfs_configure_role.png?600|}}
;#;

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

;#;
{{:undefined:adfs_configure_admin_account.png?600|}}
;#;

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

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

//adfs.arasaka.local//

//Arasaka Labs ADFS//

;#;
{{:wiki:adfs_cert_name_parameters.png?600|}}
;#;

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

;#;
{{:wiki:adfs_service_fgmsa_acoount.png?600|}}
;#;

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

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

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

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

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

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

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

<WRAP prewrap>
<code>
Set-AdfsProperties -CertificateDuration 3650
Set-ADFSProperties -AutoCertificateRollover $true
Update-AdfsCertificate -CertificateType Token-Decrypting
Update-AdfsCertificate -CertificateType Token-Signing 
</code>
</WRAP>

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

   Set-ADFSProperties -AutoCertificateRollover $false
Управление сертификатами в консоли:

;#;
{{:wiki:adfs_signing_certs_console.jpg?600|}}
;#;

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

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

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

Открыть в браузере URL: https://adfs.arasaka.local/federationmetadata/2007-06/federationmetadata.xml
{{tag>ADFS Certificates PKI Microsoft Windows WindowsServer ADCS PowerShell Exchange}}