Установка 2FA на OWA/ECP

Перевод статьи с некоторыми изменениями под мою конфигурацию. Забегая вперёд скажу, что хоть в оригинальной статье присутствует слово «бесплатно», на самом деле мы ограничены 50 пользователями.

Итак, передо мной стояла задача протестировать решение privacyIDEA в конфигурации, приближенной к рабочей. А это 2 контроллера домена и 2 Exchange сервера с ролью Mailbox\CAS, объединённых в DAG.

Конфигурация тестового стенда

OS Windows Server 2019
Exchange 2019 Cumulative Update 12
Domaindom1.local
DC’s DC1\DC2; 192.168.1.10\192.168.2.10
DAG EX1\EX2; 192.168.1.11\192.168.2.11
Witnesswitness; 192.168.4.2
ADFS Service: adfs.dom1.local; computer name: fs.dom1.local
privacyIDEA IP: 192.168.1.17; Name: Ubuntu22

Допустим, домен и Exchange развёрнуты, почта ходит. Далее нужно:

1. Развернуть PrivacyIDEA сервер

2. Конфигурировать PrivacyIDEA сервера

3. Создать MFA-токены для пользователей

4. Установить сервер с ролью AD FS

5. Конфигурировать в AD FS провайдера PrivacyIDEA

6. Конфигурировать OWA использования AD FS авторизации

1. Разворачивание PrivacyIDEA сервера

Сначала подготовлю ОС — устанавливаю Ubuntu 22.04LTS. Выбрал Ubuntu, так как не ограничен какой‑то ОС и к тому же в Ubuntu есть готовый пакет. Сейчас вышла версия 24, но у меня была только 22.04.

Пакет подписан цифровой подписью. Скачиваем ключ подписи:

wget https://lancelot.netknights.it/NetKnights-Release.asc

Можно проверить отпечаток:

gpg --import --import-options show-only --with-fingerprint NetKnights-Release.asc

Отпечаток:

pub 4096R/AE250082 2017-05-16 NetKnights GmbH <release@netknights.it> Key fingerprint = 0940 4ABB EDB3 586D EDE4 AD22 00F7 0D62 AE25 0082

Переносим ключ подписи:

mv NetKnights-Release.asc /etc/apt/trusted.gpg.d/

Теперь нужно добавить репозиторий для нашего релиза (у меня jammy):

bionic 18.04LTSadd-apt-repository http://lancelot.netknights.it/community/bionic/stable focal 20.04LTSadd-apt-repository http://lancelot.netknights.it/community/focal/stable jammy 22.04LTSadd-apt-repository http://lancelot.netknights.it/community/jammy/stable

Установим пакет privacyIDEA:

apt update apt install privacyidea-apache2

Если не нравится веб сервер Apache2, вы можете установить альтернативный пакет privacyidea-nginx.

Создаём администратора PrivacyIDEA:

pi-manage admin add admin

2. Конфигурация PrivacyIDEA сервера

Теперь логинимся в privacyIDEA, настроим его на контроллер домена, и настроим MFA-токены для пользователей.

1. Открываем браузер и идём на адрес нашего сервера: https://localhost

2. Логинимся под учёткой администратора, которую создали ранее

3. Переходим на вкладку «Config», далее — вкладка «Users»

4. Теперь кликаем по «New ldapresolver» на левой панели. Эта форма создаёт ldapresolver, который сообщает privacyIDEA как получить доступ к LDAP, и где искать пользователей. Сервер privacyIDEA требует аккаунт пользователя домена для LDAP-запросов (так как анонимные LDAP запросы запрещены), так что не забудьте создать пользователя для сервиса privacyIDEA. Я позволил себе использовать пользователя dom1\Administrator (так делать не надо), так как у меня тестовая среда. Вот основные настройки моей конфигурации:

5. В остальных полях я оставил значения по умолчанию. Внизу формы можно заполнить оставшиеся поля, нажав кнопку «Preset Active Directory». На скриншоте моя конфигурация:

   

   Вы можете выполнить «Quick Resolver Test» для проверки получения одного пользователя или с помощью «Test LDAP Resolver» попробовать получить всех пользователей. Как только всплывающее сообщение уведомит об успешном получении пользователя\пользователей, можно нажать «save resolver» для сохранения конфигурации.

6. Во вкладке «Config» выберите вкладку «Realms». Там введите имя вашего realm в текстовом поле «new realm». Я использовал имя «realm1». Имя вашего realm’а потребуется далее в разделе 5.

7. Справа отметьте чекбокс «ldapresolver» и «priority» установите в 1.

8. Теперь нажмите кнопку «Create Realm»

3. Создание MFA-токенов для пользователей

Теперь, когда privacyIDEA связан с AD, нужно назначить пользователям MFA‑токен. Для этого перейдите на вкладку «Tokens» в левом верхнем углу, и нажмите «Enroll Token» — Зарегистрировать токен.

Заполняйте форму, пока не дойдёте до поля «Logginname Attribute». Ниже приведены значения, используемые для создания токена MFA с поддержкой Google Authenticator:

• Выберите TOTP в верхнем раскрывающемся меню.

• Оставьте флажок «Generate OTP Key on the Server».

• Оставьте длину OTP равной 6.

• Оставьте «timestamp» на уровне 30 секунд.

• «Description» — опционально.

• В поле «realm» должно отображаться имя области из раздела 2, шаг 6 (realm1). Если нет, то введите его.

• В поле «Assign token to user» начните вводить имя пользователя, которому вы хотите назначить токен. PrivacyIDEA будет использовать ldapresolver, созданный в разделе 2, для поиска соответствующего объекта пользователя в AD. Как только вы увидите своего пользователя в раскрывающемся списке поиска, выберите его.

• Если вы введёте PIN‑код, пользователю необходимо будет ввести свой PIN+OTP, когда будет предложено ввести OTP. Я решил оставить свой пароль пустым, чтобы моему пользователю нужно было ввести только свой OTP.

Теперь нажмите «Enroll Token». Должен открыться вот такой экран:

Отсканируйте QR-код с помощью Google Authenticator или аналогичного приложения. QR‑код содержит секретный ключ MFA‑токена пользователя. Вы должны увидеть этот токен на вкладке «Tokens» панели навигации вверху. Теперь, когда у нас есть пользователь, связанный с кодом MFA, нужно подключить этот MFA к AD FS для обработки в Exchange.

4. Установка сервера с ролью AD FS

Следующая задача — поднять подключённый к домену Windows Server с ролью AD FS. В моём случае это отдельный Sever 2019.

1. В процессе установки сервера AD FS необходимо определить имя, по которому сервер будет прослушивать подключения. Если это имя совпадает с текущим именем сервера, то дополнительных действий не требуется. Я определю имя adfs.dom1.local, что не совпадает с текущем именем сервера. Соответственно, мне нужно будет зарегистрировать дополнительное имя во внутреннем сервере DNS:

   

2. Если для сервера PrivacyIDEA использовался самозаверяющий сертификат, необходимо установить этот сертификат на сервер, который станет сервером AD FS, чтобы сертификату PrivacyIDEA доверяли:

• На сервере AD FS (или на будущем сервере AD FS) откройте любой браузер, перейдите по адресу https://<privacyIDEA server> (https://192.168.1.17).

• Сохраняем сертификат.

• Устанавливаем в «Local Machine» → «Trusted Root Certification Authorities».

3. Нам также понадобится сертификат для сервера AD FS. Если у вас есть центр сертификации, который может выдавать сертификат, используйте его. В противном случае вы можете создать самоподписанный сертификат (используя PowerShell, openssl, IIS). Я использовал PowerShell:

New-SelfSignedCertificate -Subject *.dom1.local -DnsName dom1.local, *.dom1.local -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(10)

4. Для разворачивание роли ADFS понадобится управляемая учётная запись (Group Managed Service Account — gMSA). А для возможности использования таких учётных записей в инфраструктуре Active Directory должен быть сгенерирован ключ Key Distribution Services (KDS) Root Key:

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

5. Установим роль AD FS. Мастер сам создаст нам gMSA. Ниже приведена таблица версий AD FS, интерфейс разных версий может незначительно отличаться. Так как у меня Server 2019, то соответственно версия ADFS 5.0:

6. Установили роль AD FS, теперь можно проверить правильность установки. Есть два варианта:

• Получить информацию о сервисе по url:https://localhost/adfs/fs/federationserverservice.asmx, в случае успеха увидим XML документ:

  

• Второй вариант – это включение специальной тестовой страницы для проверки:
  Set-AdfsProperties -EnableIdPInitiatedSignonPage $true и открыть тестовую страницу по url: https://localhost/adfs/ls/idpinitiatedsignon
  Откроется страница авторизации, пробуем авторизоваться. В случае успеха увидим:

7. Создание отношений доверия с проверяющей стороной в AD FS для OWA:

   1. Выбираем «Relying Party Trusts», справа в панели нажимаем «Add Relying Party Trust…»

   2. Выбираем «Claims aware», «Start»

   3. Выбираем «Enter data about the relying party manually», «Next >»

   4. Имя отношения, например, «OWA», «Next >», «Next >»

   5. Отмечаем «Enable support for the WS‑Passive Federation protocol» и устанавливаем url owa: «https://mail.dom1.local», «Next >», «Next >»

   6. Включаем MFA «Permit everyone and require MFA», «Next >», «Next >», «Close»

8. Теперь нужно добавить настраиваемые правила утверждения, для только что созданного отношения (OWA).

Нажимаем «Edit Claim Issuance Policy…» → «Add Rule» → «Send Claims Using a Custom Rule» → «Next >» и добавляем три правила:

Можно закрыть окно редактирования правил — «Edit Claim Issuance Policy for…»

5. Конфигурация в AD FS провайдера PrivacyIDEA

Когда AD FS запущен и работает, нужно связать его с PrivacyIDEA. Все описанные ниже шаги выполняются с сервера AD FS.

1. Загрузите соединитель PrivacyIDEA-ADFS и запустите установку msi пакета на сервере AD FS.

2. Укажите следующее:

   • В «PrivacyIDEA URL» — ваш сервер PrivacyIDEA, включая https://.

   • «Activate debug log» — включить лог (c:\PrivacyIDEA‑ADFS.log).

   • «DisableSSL verification» отключить проверку SSL (на время тестирования). Если использовать проверку SSL, то в Windows Server 2019 нужно включить в реестре TLS 1.x, так какTLS 1.0 устарел:
     параметр «SchUseStrongCrypto"=dword:00000001 по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 и HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319.

   • Нажимаем «Next», «Install»

Так же настройки можно изменить в реестре: HKEY_LOCAL_MACHINE\SOFTWARE\NetKnights

3. Выбираем слева «Authentication Methods», нажимаем справа в панели «Edit Primary Authentication Methods…», убеждаемся, что в обоих окошках выбрано «Forms Authentication»:

   

4. Теперь нажимаем вкладку «Additional», отмечаем чекбокс «PrivacyIDEA‑ADFSProvider_1.2.0.0», нажимаем «OK»:

   

Мы настроили AD FS для взаимодействия с нашим сервером PrivacyIDEA для проверки токенов. Теперь настроим OWA на использование AD FS для аутентификации.

6. Конфигурация OWA использования AD FS авторизации

Последний шаг — дать указание Exchange принудительно пройти аутентификацию в OWA и ECP через AD FS.

1. Нам нужно установить Signing‑сертификат AD FS в «Trusted Root Certification Authorities» на каждом сервере Exchange с ролью CAS, а также прописать его отпечаток «Thumbprint»:

• Открываем консоль управления AD FS,

• Слева выбираем «Service» → «Certificates»,

• Затем дважды щелкаем сертификат «CN‑ADFS Signing — …»

• Нажимаем вкладку «Details», выбираем «Thumbprint», копируем, затем сохраняем сам сертификат.

• Копируем на сервер Exchange

• Устанавливаем в «Local Machine» → «Trusted Root Certification Authorities».

2. На сервере Exchange CAS (EX1.dom1.local и EX2.dom1.local) войдите в систему как администратор Exchange и откройте командную консоль Exchange:

ВАЖНО: просмотрите следующие команды, замените полное доменное имя вашего сервера CAS, полное доменное имя вашего сервера ADFS и отпечаток, а затем запустите их из командной консоли Exchange.

Это моя установка:

Set-OrganizationConfig -AdfsIssuer "https://adfs.dom1.local/adfs/ls/" -AdfsAudienceUris "https://mail.dom1.local/owa/" -AdfsSignCertificateThumbprint 5843471265854bc11d7344465b76e27675d8d18d

Включаем авторизацию ADFS на конкретном сервере:

Set-OwaVirtualDirectory -Identity "owa (Default Web Site) EX1" -AdfsAuthentication $true

или на всех серверах:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true

Наконец, последний шаг — перезапустить службы IIS на сервере Exchange CAS.

iisreset /noforce

Наконец-то мы закончили! Теперь можно перейти к своему OWA, войти в систему и увидеть экран с запросом на ввод токена MFA!

Для включения 2FA для ECP выполнить пункты 4.7, 4.8, 5.3, 5.4, 6.2 по аналогии с настройкой 2FA для OWA.

Спасибо за внимание! Ваш Cloud4Y.