Внимание! Материал, изложенный в этой статье не актуален. Ниже обновлённая версия:
Публикация Exchange Server с помощью ADFS / Web Application Proxy
В предыдущих статьях были рассмотрены вопросы касаемо развертывания служб федерации ADFS, а так же конфигурирования WAP. В этой же части, я продолжу вопросы относительно подготовительной части – конфигурировании служб федерации Active Directory для последующей публикации Exchange Server. Задача не является сложной, но обязательно требует понимания выполняемых действий.
На сегодня, план действий таков:
- Конфигурирование служб федерации Active Directory
- Конфигурирование доменных служб Active Directory
- Конфигурирование Exchange Server
- Подведение итогов
Конфигурирование ADFS
Active Directory Federation Services (ADFS) – впервые появились с релизом обновления R2 2003 сервера. Основное назначение служб федерации — это возможности по части аутентификации клиентов на различных веб приложения через сеть интернет, а так же предоставления SSO. Сама же аутентификация будет работать на основании цифровых удостоверений (Claims) В данном ключе, Claims стоит рассматривать как некоторое удостоверение которое выдано третьей доверенной стороной, которой доверяют все участники процесса. В отличии от доменных служб Active Directory, в службах федерации не применяется протокол Kerberos. Это связано с тем, что протокол разрабатывался для применения в локальных сетях, но никак в сети интернет. Основные же протоколы, использующиеся в ADFS – Security Assertion Markup Language (SAML) и Simple Web Token (SWT) Оба протокола XML ориентированы и в качестве транспорта используют SSL 3.0 или TSL 1.0
В ADFS различают два важных понятия: поставщик аутентификации (Claims Provider Trust) и поставщик ресурсов (Relying Party Trusts)
Claims Provider Trust – это организация, которая создает и управляет учетными записями ресурсов. Примером могут послужить те же самые службы ADDS, либо другие LDAP хранилища.
Relying Party Trusts – предоставляет доступ к ресурсам и управляет этим доступом. Например это может быть стороннее веб приложение расположенное вне пределах организации но настроенное на взаимодействие с поставщиком аутентификации.
В различной литературе, иногда оба понятия называют островами. В зависимости от задачи, которую будут решать службы федерации, острова могут находится в различных организациях либо в рамках одной. Задача же ADFS как раз и будет состоять в объединении этих островов.
Вернемся в рамки нашей текущей задачи. Для Claims Provider Trust будут использоваться доменные службы Active Directory, а в качестве Claims Provider Trust я создам нового поставщика услуг для Exchnage сервера.
Для этого на сервере с установленными службами ADFS, в моем демо-стенде это сервер srv-adfs.office365.local, перейдем в консоль AD FS Management.
Далее, в Trustrelationship выберем Add Non-Claims-Aware Relying Party trust, как показано на скриншоте.
В качестве имени, я выбрал Exchange.
Далее, указываем расположение нашего Exchange сервера в интрасети, в моем случае https://srv-ex.offcie365.local/
На следующем шаге мы не будем настраивать мульти-факторную аутентификацию.
После завершения работы мастера, мы настроили нового поставщика услуг для Exchange теперь нужно создать авторизационные правила, по которым будет регламентироваться доступ к опубликованным Exchange приложениям.
В качестве примера, я создам правило которое будет действовать на основе атрибута SID группы объектов Active Directory.
В качестве группы будут использоваться группа domain users.
По завершению мастера, у меня получилось простое правило разрешающее всем пользователям домена получать доступ к опубликованным приложениям Exchange. В производственной среде вы можете комбинировать различные правила, тем самым довольно точно регламентировать конечный доступ к приложения.
Конфигурирование ADDS
Со стороны ADDS, нам нужно настроить делегирование на учетной записи компьютера сервера WAP. Данный шаг нам необходим, так как поставщик ресурсов для Exchnage Server будет использовать встроенную проверку подлинности Windows в процессе аутентификации. Для этого с Server Manager запустим оснастку Active Directory Users and Computers.
В оснастке выберем свойства учетной записи компьютера WAP сервера.
Во вкладке Delegation, выставляем радиобокс напротив Trust this computer for delegation to specified services only а далее Use any authentication protocol.
Далее, как показано на скриншоте, нужно выбрать доменную учетную запись компьютера Exchnage сервера.
В качестве службы, будет использоваться HTTP.
После окончания делегирования, окно должно иметь следующий вид
Конфигурирование Exchange Server
На стороне Exchange Server нам нужно лишь поменять методы аутентификации на веб каталогах OWA и ECP с FBA на встроенную проверку подлинности Windows.
Для этого в Exchnage admin center перейдем в пункт servers
И выставим соответствующие настройки на веб каталогах после чего следует перезапустить IIS сервер.
Выводы
В этой статье мы рассмотрели базово службы ADFS а так же посмотрели необходимые условия для публикации самих приложений Exchange, сервера. В следующей и завершающей статье цикла мы приступим публикации и проверим работоспособность.
вы писали:Вернемся в рамки нашей текущей задачи. Для Claims Provider Trust будут использоваться доменные службы Active Directory, а в качестве Claims Provider Trust я создам нового поставщика услуг для Exchnage сервера.
во втором случае Relying Party Trusts
Добрый день!
Откуда взялся SRV-WAP в AD, если он находится вне домена?
Если мы публикуем Exchange при помощи Windows authentication, WAP должен быть членом домена, без этого невозможно настроить Kerberos делегирование. Есть конечно уже другой метод аутентификации, он стал доступен с Exchange 2013 SP1, где используются только ADFS аутентификация на веб каталогах. Как будет у меня время опишу эту процедурою.
Добрый день! Как сервер SRV-WAP оказался в контейнере Computers в AD? Выше же оговаривалось, что он не входит в домен. Получается не понятно как дать разрешения.
частично ответил в первом комменте. Александр, видимо я допустил опечатку. Буду очень благодарен если вы укажите на абзац в котором это нашли.
Добрый день!
Как я понимаю весь смысл в этом и есть чтобы WAP сервер был вне домена в DMZ зоне и при этом мог связаться с ADFS?
И я не могу понять связь между ADFS и Exchange, как он может ссылаться на Exchange?
И другой вопрос, изначальный сертификат который мы всюду добавляем, он должен быть выгружен с IIS Exchange? или с IIS ADFS?
1. Экс 2013 без sp1, другими словами без cu 4, через wap по другому опубликовать нельзя было. По сему wap сервер член домена с настроенным Kerberos делегированием.
3. Он ссылается на веб каталоги с настроенной аутентификацией Windows (owa и ecp).
3. Не важно от куда.
Спасибо, за быстрый ответ.
Мы добавили WAP в домен, настроили на нем Kerberos. Но у нас все равно выходит ошибка после входа по внешнему URL, мы авторизовались, но потом возникает ошибка HTTP 500.
А на ADFS доступ в интернет надо подавать по 443 порту? Мы подали только на WAP и указали для внешнего IP адреса, внешний DNS адрес ADFS, это правильно?
This is part one in a series about using Web Application Proxy to publish Exchange to the Internet. Stay tuned for part two to continue the process, which includes installing the Web Application Proxy role, configuring Active Directory, configuring Exchange and publishing Exchange.