Differences

This shows you the differences between two versions of the page.

--- создание_отношений_доверия_для_exchange [2025/03/26 08:39] – jp
+++ создание_отношений_доверия_для_exchange [2025/04/04 10:43] (current) – jp
@@ Line 3: / Line 3: @@
 После развёртывания роли //ADFS//, описанном в статье [[Установка роли ADFS]], мы можем создать отношения доверия и подключить //ADFS// в качестве способа аутентификации в //Exchange//.
-=== Создание отношений доверия ===
+==== Создание отношений доверия ====
 Дальнейшие действия мы будем производить в разделе //Relying Party Trusts// в консоли //ADFS//. Для создания полноценных отношений доверия все действия повторяются в данном случае ДВАЖДЫ: для //OWA// и для //ECP// (админка //Exchange//).
@@ Line 59: / Line 59: @@
 ;#;
-=== Политика подачи запросов ===
+==== Политика подачи запросов ====
 Теперь необходимо отредактировать политику подачи запросов. Данные действия также выполняются ДВАЖДЫ - для OWA и для ECP. Кликаем на отношение доверия и выбираем //Edit claim insurance policy//.
@@ Line 92: / Line 92: @@
 </code>
 </WRAP>
+==== Конфигурирование ADFS на стороне Exchange ====
+=== Конфигурирование настроек Exchange на уровне организации ===
+Предполагаю, что сертификат подписи ADFS был импортирован в Exchange, как описано в материале [[Установка роли ADFS]]. В этом случае нам необходимо получить отпечаток данного сертификата. Сделаем это следующим образом на //Exchange//:
+   Set-Location Cert:\LocalMachine\Root; Get-ChildItem | Sort-Object Subject | sls ADFS
+Получив отпечаток, сконфигурируем настройку //ADFS// на уровне организации:
+<WRAP prewrap>
+<code>
+Set-OrganizationConfig -AdfsIssuer https://adfs1.arasaka.local/adfs/ls/ -AdfsAudienceUris "https://exch1.arasaka.local/owa/","https://exch1.arasaka.local/ecp/" -AdfsSignCertificateThumbprint "0EFB56DD0FC460B9B310A08065667A67514FD0D8"
+</code>
+</WRAP>
+=== Конфигурирование настроек Exchange на уровне виртуальных директорий ===
+:!: Конфигурировать виртуальные директории обязательно в данном порядке: сначала //ECP//, затем //OWA//.
+Конфигурируем ECP:
+<WRAP prewrap>
+<code>
+Set-EcpVirtualDirectory -Identity "exch1\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
+</code>
+</WRAP>
+Точное название виртуальной директории ECP можно получить так:
+   Get-EcpVirtualDirectory
+Конфигурируем OWA:
+<WRAP prewrap>
+<code>
+Set-OwaVirtualDirectory -Identity "exch1\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -OAuthAuthentication $false -WindowsAuthentication $false
+</code>
+</WRAP>
+Точное название виртуальной директории 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.
+;#;
+{{:ms:arasaka_adfs_welcome.jpg?600|}}
+;#;
+=== Ошибка WrongAudienceUriOrBadSigningCert ===
+Если при открытии ящика мы обнаруживаем ошибку следующего содержания: //WrongAudienceUriOrBadSigningCert//
+;#;
+{{:exchange:wrong_audience_exch_adfsjpg.jpg?600|}}
+;#;
+В первую очередь стоит проверить - что в свойствах сертификата подписи //ADFS// в настройках организации //Exchange// и правильно ли он задан. А также - импортирован ли верный сертификат в хранилище корневых сертификатов.
+   Get-OrganizationConfig | select AdfsSignCertificateThumbprint
+{{tag>ADFS Certificates PKI Microsoft Windows WindowsServer PowerShell Exchange}}