Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 4)
В предыдущих статьях были рассмотрены вопросы касаемо развертывания служб федерации 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, сервера. В следующей и завершающей статье цикла мы приступим публикации и проверим работоспособность
Комментариев нет:
Отправить комментарий