Публикация и аутентификация доступа к Exchange с использованием AD FS и WAP (часть 1)

Введение

В этой серии, состоящей из нескольких частей, мы рассмотрим, как использовать службы федерации Active Directory (AD FS), чтобы обеспечить единый вход (SSO) и предварительную аутентификацию для Exchange Server, что обеспечивает лучшую совместимость для пользователей, использующих веб-браузер. сеанс с локальными Exchange и Office 365.

Сначала мы продемонстрируем, как это сделать, используя методы, которые работают с несколькими версиями Exchange, а затем продемонстрируем, как использовать собственные функции для интеграции AD FS с более поздними версиями Exchange.

Параметры проверки подлинности AD FS

Exchange Server поддерживает несколько вариантов публикации веб-служб для клиентов. В частности, они оба поддерживают различные параметры при использовании Microsoft Active Directory Federation Services (AD FS) и прокси-сервера веб-приложения (WAP).

AD FS тесно сотрудничает с Active Directory в качестве поставщика удостоверений (IdP) и может проверять учетные данные для многих различных поставщиков услуг (SP), работающих как локально, например Exchange, так и в облаке, например Office 365. Версия AD FS, с которой мы работаем в этой статье, — это ADFS 2012 R2, входящая в состав Windows Server 2012 R2.

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

Доступны три варианта публикации Exchange в сочетании с AD FS и WAP:

1. Используйте WAP для публикации Exchange Server с предварительной аутентификацией, но с простой интеграцией AD FS, зависящей от делегирования IIS и Kerberos. Это подходит для организаций, которым не нужны зависимости AD FS для внутренних клиентов, выполняющих вход в Outlook в Интернете (OWA) и центр администрирования Exchange (EAC), но которые хотят применять предварительную проверку подлинности для внешних клиентов.
2. Используйте WAP для публикации Exchange Server 2013 или 2016 с использованием предварительной проверки подлинности, используя встроенные функции Exchange для использования AD FS в качестве поставщика удостоверений для Exchange. Exchange можно публиковать в обычном режиме с помощью традиционного балансировщика нагрузки, и все запросы проверки подлинности OWA и ECP будут перенаправлены на сервер AD FS или WAP.
3. Используйте WAP, чтобы просто опубликовать HTTPS Exchange Server в Интернете без какой-либо предварительной аутентификации, проходящей через соединение. Это подходит для таких служб, как Exchange ActiveSync или MAPI HTTP.

Наши примеры сценариев

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

Хотя публикация Exchange через WAP строго необязательна для первого варианта, мы покажем вам, как это сделать, в рамках этой серии статей. В вашей организации вы можете обнаружить, что вам не нужно делать это, если вы уже публикуете Exchange с помощью стороннего балансировщика нагрузки или вообще не публикуете его для внешних клиентов.

Настройка нашей среды AD FS и WAP

В нашей организации, Lisa Jane Designs, мы настроили Exchange с внешним пространством имен HTTPS и используем SSL-сертификат с подстановочными знаками . Наш сервер AD FS будет использовать имя , а подстановочный SSL-сертификат будет использоваться для сервера AD FS и сервера WAP.

Предпосылки

Чтобы использовать AD FS и прокси веб-приложения, нам потребуются следующие готовые компоненты.

• Один или несколько экземпляров Windows Server 2012 R2 для запуска федеративных служб Active Directory, присоединенных к домену.
• Если вы публикуете Exchange извне, вам потребуется один или несколько экземпляров Windows Server 2012 R2 для использования в качестве прокси веб-приложения. Для нашего второго сценария мы должны убедиться, что они присоединены к домену.
• Действительные сторонние SSL-сертификаты для поддержки имени экземпляра AD FS и имен Exchange HTTPS, опубликованных извне.

Настройка сертификатов

Нашей первой задачей на серверах Windows Server 2012 R2, на которых будут размещены AD FS и WAP, является установка подстановочного SSL-сертификата.

Используя оснастку сертификатов в консоли управления Microsoft (MMC), мы обеспечим импорт подстановочного сертификата в контексте . Это должно выглядеть так, как показано ниже:

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

Установка AD FS

Для поддержки обоих сценариев нам потребуется установить и настроить AD FS для использования для предварительной проверки подлинности и сохранения конфигурации WAP.

Чтобы установить AD FS, откройте в диспетчере серверов и в разделе выберите , как показано в примере ниже.

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

После завершения установки AD FS нам нужно определить информацию о конфигурации для AD FS, а затем разрешить мастеру настройки AD FS применить правильную конфигурацию.

На первой странице мастера нам предоставляется возможность выбора типа конфигурации для выполнения. В предыдущих версиях AD FS нам было предоставлено несколько вариантов, в том числе один для создания автономной фермы. Поскольку ферма может состоять из одного члена, вы увидите, что в Windows Server 2012 R2 вариант автономной фермы удален. Таким образом, даже если мы просто добавляем один узел, мы выбираем как показано ниже.

На второй странице мастера у нас будет возможность определить свойства службы федерации. Мы выберем SSL-сертификат, предварительно установленный при подготовке сервера, и укажем имя службы федерации и отображаемое имя, как показано ниже.

При выборе полного доменного имени (FQDN) для имени службы федерации помните, что выбранное нами имя может быть абстрактным для самого имени сервера, и обычно выбирают такое имя, как (служба федерации) или (безопасность). Token Service) точно так же, как Exchange часто называют , а не именем самого Exchange Server.

В приведенном выше примере мы выбрали в качестве имени службы федерации и укажем название компании в качестве отображаемого имени.

На следующей странице мастера мы продолжим, указав учетную запись домена без специальных привилегий для запуска службы AD FS. Для большинства реализаций мы будем использовать внутреннюю базу данных Windows.

После завершения установки нам нужно будет зарегистрировать имя службы AD FS в локальной сети.

Поскольку WAP-серверу необходимо разрешить это во внутренней локальной сети, мы настроим запись DNS PinPoint в нашей DNS Active Directory, как показано ниже, чтобы указать, что разрешается во внутренний IP-адрес сервера AD FS..

Если вы не знакомы с DNS-зонами PinPoint, вы можете прочитать о них больше в моей статье Использование DNS-зон PinPoint с Exchange 2010.

Если организация, в которой вы реализуете сервер AD FS, вместо этого использует , где есть как внутренний DNS, так и внешний DNS, обслуживающий одну и ту же зону DNS, вам следует добавить запись для вашего сервера AD FS в этой внутренней зоне DNS.

Установка роли прокси веб-приложения

После установки AD FS нам потребуется установить и настроить компонент, который будет находиться в нашей сети периметра и публиковать Exchange для внешних клиентов. Мы начнем с перехода к в диспетчере серверов и выбора :

Далее на странице мы выберем :

После завершения установки мы выберем , как показано ниже:

Затем, после запуска мастера, мы введем внутреннее имя только что настроенного сервера AD FS вместе с учетными данными администратора, как показано ниже.

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

В нашем примере мы будем использовать сертификат Wildcard, который использовался ранее на нашем сервере AD FS:

После завершения настройки наш последний шаг — обеспечить доступность WAP для внешних клиентов, включив исключения брандмауэра и добавив используемое DNS-имя (в нашем случае ) во внешнюю зону DNS с внешний IP-адрес, соответствующий WAP.

В следующей части этой серии мы рассмотрим, как выполнить простую публикацию, применимую к любой поддерживаемой версии Exchange.