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

В завершающей статье посвященной обзору 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 будет превосходить, но в будущем, скорее всего, стоит ожидать исправления этой ситуации.

Pin It

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

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

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

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

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

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

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

      • 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 noteproperty -Name Binding -value $.split(“#”)[1]
        }
        elseif ($
        -match “CertificateHash”) {
        $tempObject | Add-Member -Type noteproperty -Name CertificateHash -value ($.split(“#”)[1]-replace ” “)
        }
        else {
        $tempObject | Add-Member -Type noteproperty -Name ApplicationID -value ($
        .split(“#”)[1]-replace ” “)
        $certsList += $tempObject
        }
        }

        $match = $certsList | where {$_.Binding -match $CertificateWAPsubject}
        $CertificateHash = $match.CertificateHash
        $ApplicationID = $match.ApplicationID

        write-host -ForegroundColor Green “nnDefault bindings before changes”
        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

        Кстати по этой же причине не будет работать и родной MS RDP клиент для Android
        Server 2012 R2 RD Services – отлично публикуется через WAP в полной комплектации RDWeb + RDGW + RDS

        Так же если ты заставишь работать ActiveSync через WAP то полезет другая проблема на всех устройствах, WAP будет слишком рано закрывать сессию, в принципе то все работает, но огромное количество ошибок в Exchange напрягает…

        Решение тоже есть, выковырял на MSDN и переделал под себя…
        Когда ошибки достанут…. пиши… :)

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

          • Ну этого его часть только, я его видел давно делал все мастерами, после мук с 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/

          • Блин наконец на 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 firewalls to 30 minutes
            Organizations need to set timeouts on their incoming firewalls to 30 minutes

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

    • Проблема с 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… Решение тоже есть…

Leave a Reply