Web Application Proxy в Server 2012 R2, функционал и использование на примере публикации приложений Exchange 2013 (часть 5)

Внимание! Материал, изложенный в этой статье не актуален. Ниже обновлённая версия:

Публикация Exchange Server с помощью ADFS / Web Application Proxy

В завершающей статье посвященной обзору Web Application Proxy, я рассмотрю непосредственно публикацию приложений Exchange Server 2013. Напомню, в предыдущих статьях, было рассмотрено назначение этой технологии, так же сконфигурированы службы федерации Active Directory и WAP. Все эти шаги носили подготовительных характер, и теперь позволят в этой статье непосредственно произвести публикацию.

В качестве публикуемых Exchange каталогов, будет выполнена публикация OWA, ECP, EWS, Autodiscover, Activesync, RPC, OAB, Powershell. Каталоги OWA, ECP, в качестве метода преаутентификации, будут использовать ADFS, остальные – сконфигурированы через Pass-through Структура статьи будет иметь следующий вид:

  • публикация Exchnage
  • проверка и тестирование
  • выводы

Публикация Exchange

Для этого, я перейду на сервер Web Application Proxy, в моем демо-стенде это srv-wap.office365.local, и открою консоль Remote Access Management

1-19-2014 4-01-13 PM

В консоле, выбираем Publish

1-19-2014 4-15-57 PM

В окне мастера, на моменте выбора метода преаутентификации, оставлю по умолчанию на ADFS

1-19-2014 4-18-45 PM

На следующем шаге, нужно выбрать в качестве ADFS relying party, поставщика услуг созданного под наш Exchange сервер. Процесс создания самого поставщика услуг был описан в предыдущей части.

1-19-2014 4-27-05 PM

Далее, в качестве имени указываем OWA, в поле External URL записываем внешний URL публикуемого приложения, в моем случае https://mail.office365.kiev.ua/owa/ В External certificate определим SSL сертификат под которым приложение будет опубликовано во внешний мир. В Backend URL определим внутренний URL публикуемого приложения, в моем случае это https://srv-ex.office365.local/owa/ И в качестве Backend server SPN необходимо внести SPN почтового сервера, в моем случае это http/srv-ex.office365.local

1-19-2014 4-48-26 PM

Аналогичным образом, необходимо настроить публикацию ECP

1-19-2014 4-56-45 PM

После создания публикации OWA и ECP, должно получится следующее:

1-19-2014 4-57-27 PM

Оставшиеся каталоги, будут опубликованы так же, только метод преаутентификации будет изменен на Pass-through

1-19-2014 5-11-35 PM

По аналогии, опубликуем оставшиеся каталоги,

Powershell:

1-19-2014 7-36-03 PM

RPC:

1-19-2014 7-36-45 PM

EWS:

1-19-2014 7-38-13 PM

OAB:

1-19-2014 7-38-44 PM

Autodiscover:

1-19-2014 7-39-53 PM

Activesync:

1-19-2014 7-43-18 PM

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

1-19-2014 7-44-14 PM

Проверка и тестирование

Exchange server опубликован под внешним доменом mail.office365.kiev.ua, по этому для доступа к Outlook Web Access будет использоваться URL https://mail.office365.kiev.ua/owa При переходе по нему, браузер автоматически будет перенаправлять на https://adfs.office365.kiev.ua/adfs/

1-19-2014 8-08-28 PM

где необходимо ввести логин и пароль для доступа к OWA

1-19-2014 8-13-37 PM

После аутентификации, я получил доступ к опубликованному приложению.

1-19-2014 9-22-58 PM

Возможность подключения клиентов, я проверял используя Outlook 2013 на внешней машине настройкой нового аккаунта.

1-19-2014 9-34-13 PM

1-19-2014 9-36-37 PM

1-19-2014 9-37-58 PM

Успешные результаты на скриншотах говорят о том, что службы autodiscover, rpc, oab опубликованы корректно.

Выводы

Релиз Windows Server 2012 R2 принес много вкусностей, в том числе и средство публикации Web Application Proxy. Когда я узнал, что сначала Forefront TMG а потом и UAG выводят из разработки, мне не было понятно какими продуктами Microsoft закроет дырку в продуктах. Выход WAP расставил все по местам, и сей час я вижу платформу готовую к использованию в корпоративной среде. Конечно же, если сей час сравнивать WAP и TMG в вопросах более тонкой публикации, TMG будет превосходить, но в будущем, скорее всего, стоит ожидать исправления этой ситуации.

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

14 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
Boris Ni
17.02.2014 08:43

В продолжение вопроса по публикации Exchange 2010 (начало в теме Развертывание Windows Server 2012 R2 Essentials)
Все таки “допиливание” сайта OWA exchange 2010 c ADFS авторизацией требуется.
http://www.theidentityguy.com/articles/2010/10/15/access-owa-with-adfs.html?currentPage=2
http://allmsft.blogspot.ru/2012/02/owa-sp2-and-adfs.html

Alexander Tkachenko
17.02.2014 09:38
Ответить на  Boris Ni

Борис, спасибо. Как раз у меня в ближайшие дни будет тестовый стенд с 2010 Эксом, как раз протестирую)

Игорь Глушков
26.02.2014 08:28

Добрый день!
Спасибо за подробное описание. Но возникло пару вопросов по настройке внешнего DNS и использовании внешних ИП. При использовании WAP и SSO пытаюсь настроить WAP при схеме нахождения его в области периметра безопасности, а не в DMZ(пока что нет возможности организовать). Получается для организации такой схемы необходимо два внешних ИП и соответствующие настройки внешнего ДНС: один для SSO.contoso.com, а второй для MAIL,contoso.com?

Alexander Tkachenko
26.02.2014 09:44
Ответить на  Игорь Глушков

Добрый день,
Не совсем так, вы размещаете WAP сервер в переделах периметра и на него пробрасываете 443 порт. Далее на внешнем ДНС сервере делаете 2 записи SSO.contoso.com и MAIL,contoso.com указывающие на 1 и тот же ИП адрес. Когда клиент будет обращаться на MAIL,contoso.com его будет перебрасывать на SSO.contoso.com там будут введены учетные данные и далее его обратно перебросит на MAIL,contoso.com. Причем коммуникация все время будет идти через WAP сервер.

Игорь Глушков
26.02.2014 13:09

Вроде теперь получаю доступ к авторизации. Но после авторизации перекидывает на пустую страницу.
При этом на сервере WAP лезут подряд две ошибки: “13019 Прокси-серверу веб-приложений не удалось получить билет Kerberos от имени пользователя из-за следующей общей ошибки API: Указано неизвестное расположение или оно недоступно” и “12027 Прокси-сервер веб-приложений обнаружил неожиданную ошибку при обработке запроса.
Ошибка Указано неизвестное расположение или оно недоступно”
Как можно проверить свои SPN-записи для owa и ecp? Прошу прощения за глупый вопрос, но, возможно, дело в этом?

Alexander Tkachenko
26.02.2014 14:40
Ответить на  Игорь Глушков

Игорь,
Проверьте, вы точно разрешили керберос делегирование на учетной записи компьютера WAP сервера для учетной записи компьютера вашего Exchange в AD как показано в конце статьи http://ait.in.ua/2014/01/17/web-application-proxy4/ ?

Игорь Глушков
26.02.2014 17:43

Вроде разобрался. Поставил зачем-то двоеточие при указании SPN.
Теперь столкнулся с новой бедой. Подключение мобильных устройств на базе Android не осуществляется. Ругается на сертификат, галка “принимать все” не спасает. Вы сталкивались с таким?
И ещё вопрос, если не затруднит. Основная причина использования WAP – это возможность использования Exchange + Office Web Application на одном внешнем ИП. Вы сталкивались с настройкой или публикацией второго через WAP, возможно подскажете другие решения просмотра вложений браузером?

Alexander Tkachenko
26.02.2014 18:13
Ответить на  Игорь Глушков

с Android не работал но есть подозрение что эта платформа пока не поддерживает аутентификацию ADFS. На всякий пожарный, если вы используете частный центр сертификации, попробуйте импортировать на устройство рутовый сертификат ЦС. Так же AIA и CDP центра сертификатов должны быть доступны из вне.
Касаемо второго вопроса, еще не довелось публиковать WEB APP Server, но чисто теоретически опубликовать можно. Если WEB APP Server не поддерживает ADFS аутентификацию публикуйте его через Pass-through.

Vladimir
29.04.2014 22:21
Ответить на  Alexander Tkachenko

Android поддерживается, только он не понимает wildcard сертификаты и не правильно понимает SNI, видит только первый сертификат… Если прибиндить первым(default) сертификатом тот в котором у тебя все доменные имена публикуемых приложений, то все заработает! Set default SNI binding sleep 15 # sleep for 15 seconds to allow WAP bindings to be set $certsList = @() $certs = netsh http show sslcert | where {$_ -match “:port” -or $_ -match “Certificate Hash” -or $_ -match “Application ID”} $certs = $certs.replace(” : “,”#”).replace(” “,””) $certs | foreach { if ($_ -match “:port”) { $tempObject = New-Object -Type PSObject $tempObject | Add-Member -Type… Подробнее »

aiadmin
aiadmin
29.04.2014 22:27
Ответить на  Vladimir

Владимир спасибо! Вот такого скрипта на момент написания статьи не было! Очень скоро мне предстоит мигрировать с ТМГ на WAP, как раз проверю в бою)

Vladimir
29.04.2014 22:31
Ответить на  aiadmin

Ну этого его часть только, я его видел давно делал все мастерами, после мук с RDS через WAP на Android – да сложная схема 🙂
Начал пользовать только скрипты для настройки ADFS + WAP, получается очень быстро… 🙂
Скрипт взят и адаптирован под себя от сюда http://blog.kloud.com.au/2013/08/14/powershell-deployment-of-web-application-proxy-and-adfs-in-under-10-minutes/

Vladimir
29.04.2014 22:52
Ответить на  aiadmin

Блин наконец на TechNet появилось нормальное описание, когда я это ковырял, вообще никакой инфы не было, А ковырял я в конце сентября 2013 года… Что касается преждевременного закрытия сессии то решается так: Get-WebApplicationProxyApplication ‘Exchange ActiveSync’ | Set-WebApplicationProxyApplication -InactiveTransactionsTimeoutSec 930 У Microsoft есть статья по поводу времени сессии и ActiveSync и что нужно сделать с Firewall, но она старая и там ни слова про WAP. Сам чудом победил. Их кстати несколько 🙂 http://support.microsoft.com/kb/905013/en-us (Это вообще древняя) http://technet.microsoft.com/en-us/library/ff459598.aspx (Эта более-менее свеженькое ))) Написано четко: Set the firewall’s idle connection timeouts: Microsoft recommends that mobile operators set the idle connection timeouts on outgoing… Подробнее »

Vladimir
29.04.2014 22:57
Ответить на  aiadmin

И еще, если после настройки скриптом все получилось и заработало, и опубликовать что-то через консоль WAP – сертификат дэфолтный слетает и все ломается на Android!
Решение: если нужно что-то добавить или изменить – правь скрипт и юзай его!

Vladimir
29.04.2014 22:03
Ответить на  Игорь Глушков

Проблема с Android из за того что он не правильно работает с SNI сертификатом, прибинди дефолтный сертификат (там где прописаны домены публикуемых приложений) на 0.0.0.0:443 и тогда заработает.
netsh http show sslcert | where {$_ -match “ip:port”}
$command = “http add sslcert ipport=$SniIPport certhash=$CertificateHash appid=$ApplicationID”
write-host -ForegroundColor Yellow “nnAdding Certificate”
$command | netsh

А так же Android не понимает Wildcard сертификат.
Кроме это у тебя будут валиться куча ошибок ActiveSync на Exchange… Решение тоже есть…