Exchange Hybrid – Подготовка серверов федерации

Подготовка серверов федерации – обязательный этап, который вы должны пройти перед началом создания связки локального каталога с Azure AD. Несмотря на отличную степень освещенности вопроса в официальной документации, никто не дает гарантий, что когда вы лично будете все настраивать, то процесс пойдет как надо. Вот и сейчас я хочу рассказать про все подводные камни, на которые пришлось нарваться.

---

Если вам интересна тематика облачных технологий, рекомендую обратиться к тегу Cloud на моем блоге.

---

Подготовка серверов федерации

Я планирую развернуть Azure AD Connect в связке с AD FS (а потом поднять гибридный эксч, но это уже следующий этап). Мастер установки AADC позволяет сконфигурировать ферму серверов федерации автоматически. Чтобы это прошло успешно, нужно выполнить ряд подготовительных задач, чем и займемся в этой статье.

Инфраструктура

В минимальной конфигурации нужен всего лишь один сервер AD FS и один прокси-сервер WAP. В будущем вы сможете развернуть дополнительные ресурсы, если это вдруг потребуется. На данный момент у меня уже присутствует инфраструктура со всеми необходимыми серверами в начальной конфигурации (сразу после установки ОС):

• Сервер AD FS внутри периметра локальной сети, введенный в домен – ADFS01,bq.local (172.16.0.11);
• Прокси-сервер WAP, расположенный в DMZ, в домен не введен – RPX01.bq.local (10.16.0.51).

Именно на этих серверах и будем выполнять все необходимые задачи.

C полным списком условий для развертывания AADC & ADFS вы можете ознакомиться на официальном сайте ¹.

Настройка

Настройка будет проходить согласно официальной документации ². Однако даже точно следуя инструкции, на свежеустановленной системе настроить удаленное управление сервером у меня, к сожалению, не получилось (кто бы сомневался). Потому и появилась мысль написать эту статью.

Серверы AD FS и WAP

Запускаем консоль PowerShell с правами администратора и переходим к настройке. Первым делом активируем удаленное управление командой, сделать это надо на обоих серверах:

А вот все действия ниже нужно выполнять только на сервере WAP, который расположен в DMZ. Итак, убедимся, что служба WinRM запущена:

И сразу сконфигурируем её ³:

На всплывающий вопрос отвечаем утвердительно.

Не забудьте открыть нужные порты ⁴ между WAP и серверами внутри локальной сети.

Сервер AADC

Чтобы сервер AADC доверял серверу WAP, который не является членом домена, необходимо выполнить на AADC команду в PowerShell:

где rpx01.bq.local – fqdn сервера прокси.

Теперь проверим подключение и запуск консоли. Позволю себе скопировать порядок шагов из официальной документации, ссылку на которую я давал выше. В диспетчере серверов:

• Добавьте узел DMZ WAP в пул компьютеров (Диспетчер серверов -> Управление -> Добавление серверов -> DNS (вкладка)).
• В диспетчере серверов на вкладке «Все серверы» щелкните правой кнопкой мыши WAP-сервер и выберите параметр «Управлять как», введите локальные учетные данные (не домена) для WAP-компьютера.
• Чтобы проверить возможность удаленного подключения из PSH, в диспетчере серверов на вкладке «Все сервера» щелкните правой кнопкой мыши WAP-сервер и выберите Windows PowerShell. Должен открыться удаленный сеанс PSH для проверки возможности создания удаленных сеансов PowerShell.

Работы на серверах AD FS и WAP на этом завершены.

Получение сертификата

Есть возможность использовать самозаверенный сертификат, но тогда придется добавить его в хранилище доверенных сертификатов на каждом сервере.

Вопросы управления сертификатами я рассматривал в отдельных статьях под тегом SSL certificate на своем блоге (например Запрос сертификата IIS). Если у вас вдруг возникают вопросы, обратитесь к этим записям. Тем не менее, ниже я все же пробегусь по основным моментам получения сертификата.

Запрос CSR

Сгенерировать запрос вы можете на любом сервере, где у вас уже установлен IIS (либо поставьте роль вручную в минимальной конфигурации). Откройте Диспетчер служб IIS – Сертификаты сервера:

Далее Создать запрос сертификата – заполните все необходимые поля (потом они будут видны в свойствах выданного сертификата):

Сохраняем запрос в обычный текстовый файл. Дальше вам нужно передать его в любой коммерческий центр сертификации.

На следующих этапах вам придется как минимум подтвердить факт владения доменом, получив на его админские почтовые адреса (например postmaster@domain.tld) ссылку на сайт и уникальный код.

Сертификат получен

Как только запрос CSR отправлен в публичный центр сертификации и пройдены все проверки, вы должны получить письмо с архивом. В архиве будет набор файлов, включая сертификаты промежуточных центров, например:

Возвращайтесь в оснастку IIS и завершите запрос на получение сертификата. Вам понадобится всего лишь один файл (на скриншоте выше это adfs_bissquit.com.crt). Итак, проваливаемся снова в раздел Сертификаты сервера как в предыдущих главах. Справа нажимаем Запрос установки сертификатов… и указываем путь к файлику (ничего, что его формат будет отличаться от того, который требует визард):

После этого прямо из текущей оснастки вы сможете экспортировать только что появившийся сертификат куда вам требуется. Не забудьте указать криптостойкий пароль для закрытого ключа.

Экспортированный сертификат должен быть в формате .pfx (в противном случае есть вероятность, что вы забыли включить в него закрытый ключ). Далее скопируйте и установите данный сертификат на обоих серверах федерации – сервере WAP-прокси и сервере AD FS.

Настройка DNS

Одним из основных моментов является настройка DNS. Хотя и этот процесс коротко освещен в документации, но невнятная формулировка и отсутствие акцента на важности конфигурации оставляет много вопросов. Вот что написано в пререквизитах по настройке AD FS:

Set up DNS records for the AD FS federation service name (for example sts.contoso.com) for both the intranet (your internal DNS server) and the extranet (public DNS through your domain registrar). For the intranet DNS record, ensure that you use A records and not CNAME records. This is required for windows authentication to work correctly from your domain joined machine.

Если попытаться передать смысл, то получится примерно следующее: необходимо, чтобы основное имя службы федерации (у меня это adfs.bissquit.com) разрешалось в адрес, который ведет на сервер AD FS. Для внешних клиентов это внешний адрес сервера WAP (который сидит внутри DMZ). Для внутренних клиентов это адрес самого сервера AD FS.

Из всего этого следует неочевидный вывод, что сервер WAP и клиенты внутри локальной сети должны разрешать имя adfs.bissquit.com в локальный адрес сервера AD FS (adfs01.bq.local). Вот такая хитрая ситуация. Самым разумным вариантом решения проблемы будет настройка Split DNS для основного имени федерации.

Если же вы не настроите корректное разрешение DNS-имен, то уже в процессе установки Azure AD Connect можете натолкнуться на такую ошибку:

Из её описания не очевидно, что проблема именно в DNS, а сообщения в логах о проблемах с WinRM вообще направят процесс траблшутинга в неверном направлении.

На этом все работы завершены, можно приступать к развертыванию облачной интеграции.