После развёртывания роли ADFS, описанном в статье Установка роли ADFS, мы можем создать отношения доверия и подключить ADFS в качестве способа аутентификации в Exchange.

Дальнейшие действия мы будем производить в разделе Relying Party Trusts в консоли ADFS. Для создания полноценных отношений доверия все действия повторяются в данном случае ДВАЖДЫ: для OWA и для ECP (админка Exchange).

1. Выполняем Add Relying Party Trust и выбираем Claims Aware.

2. Выбираем опцию ввести вручную детали отношений доверия.

3. Выбираем отображаемое имя отношений (делаем понятные имена для OWA и ECP).

4. На этапе сертификата ничего не выбираем и пропускаем этот шаг.

5. Далее выбираем опцию Enable support for the WS-Federation Passive protocol и указываем полный URL OWA/ECP, ВКЛЮЧАЯ слеш.

6. Нажимаем next на шаге Configure identifiers.

7. На этапе выбора политики - отмечаем Permit everyone.

8. В пункте Ready to add trust - также кликаем next.

Теперь необходимо отредактировать политику подачи запросов. Данные действия также выполняются ДВАЖДЫ - для OWA и для ECP. Кликаем на отношение доверия и выбираем Edit claim insurance policy.

Нам необходимо создать два правила. Вот их пример.

Правило с именем: ActiveDirectoryUserSID.

Слдержание правила:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);

Правило с именем: ActiveDirectoryUPN.

Содержание правила:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

Предполагаю, что сертификат подписи ADFS был импортирован в Exchange, как описано в материале Установка роли ADFS. В этом случае нам необходимо получить отпечаток данного сертификата. Сделаем это следующим образом на Exchange:

 Set-Location Cert:\LocalMachine\Root; Get-ChildItem | Sort-Object Subject | sls ADFS

Получив отпечаток, сконфигурируем настройку ADFS на уровне организации:

Set-OrganizationConfig -AdfsIssuer https://adfs1.arasaka.local/adfs/ls/ -AdfsAudienceUris "https://exch1.arasaka.local/owa/","https://exch1.arasaka.local/ecp/" -AdfsSignCertificateThumbprint "0EFB56DD0FC460B9B310A08065667A67514FD0D8"

Конфигурировать виртуальные директории обязательно в данном порядке: сначала ECP, затем OWA.

Конфигурируем ECP:

Set-EcpVirtualDirectory -Identity "exch1\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false

Точное название виртуальной директории ECP можно получить так:

 Get-EcpVirtualDirectory

Конфигурируем OWA:

Set-OwaVirtualDirectory -Identity "exch1\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false

Точное название виртуальной директории OWA можно получить так:

 Get-OWAVirtualDirectory

Теперь необходимо перезапустить IIS на сервере Exchange. Сделаем это так:

 net stop w3svc /y
 net start w3svc

Заходим на OWA или ECP: https://exch1.arasaka.local/owa или https://exch1.arasaka.local/ecp

Видим, что нас заредиректило на страницу авторизации ADFS.

Если при открытии ящика мы обнаруживаем ошибку следующего содержания: WrongAudienceUriOrBadSigningCert

В первую очередь стоит проверить - что в свойствах сертификата подписи ADFS в настройках организации Exchange и правильно ли он задан. А также - импортирован ли верный сертификат в хранилище корневых сертификатов.

 Get-OrganizationConfig | select AdfsSignCertificateThumbprint