Pages Menu
Rss
Categories Menu

Опубликовано | Нет комментариев

Публикация Exchange Server 2013


Как отмечалось ранее, закат Forefront Threat Management Gateway оставил ряд администраторов Exchange в затруднительном положении относительно публикации своего сервера Exchange в Интернете. Хотя крупные организации, для выполнения этой задачи обычно могут использовать существующую инфраструктуру балансировки нагрузки оборудования, у малых и средних предприятий может не быть средств или опыта для управления балансировщиком нагрузки. Здесь может быть очень полезна роль Web Application Server.

Публикация Exchange

Основные принципы публикации Exchange 2013 Outlook Web App и Exchange Admin Center через Web Application Proxy подробно описаны на странице http://technet.microsoft.com/library/ dn635116(v=exchangeg.150).aspx. Однако, чтобы лучше понять некоторые возможности Web Application Proxy на Windows Server 2016, рассмотрите очень простой сценарий.

WebApplicationProxy_на_WindowsServer2016

Сценарий, демонстрирующий Web Application Proxy на Windows Server 2016

В этом случае, пользователь на машине, не связанной с именем CLT01, будет подключаться к Outlook Web App с помощью URL https://mail.contoso.com/owa. Запрос пользователя отправляется по внешней сети на сервер маршрутизации и Remote Access Server (RRAS01), который обеспечивает внешнее разрешение DNS для зоны contoso.com и направляет трафик на внутреннюю сеть Contoso для внешних пользователей. RRAS01 направляет запрос для https://mail.contoso.com/owa во внутреннюю сеть Contoso на сервер Web Application Proxy (WAP01), который работает под управлением Windows Server 2016.

В WAP01 Outlook Web App опубликован с использованием предварительной аутентификации AD FS. Фактически, ряд различных служб Exchange был опубликован с использованием предварительной аутентификации AD FS или сквозной аутентификации.

опубликованные_веб-приложения

Опубликованные веб-приложения

В этом случае мы предполагаем, что это разделённая конфигурация DNS, где внутренний и внешний DNS, в зависимости от местоположения пользователя, разрешают имя mail.contoso.com на разные IP-адреса.

Здесь, значение внешнего URL-адреса и URL-адрес сервера Backend Server одинаковы, но они могут быть разными, как мы покажем ниже. Таким образом, когда пользователь, находящийся во внутренней сети Contoso, переходит на https://mail.contoso.com/owa, аутентификация выполняется с помощью встроенной проверки подлинности Windows. Это требует, чтобы URL-адреса для mail.contoso.com и adfs.contoso.com были определены в доверенной зоне локальной интрасети Internet Explorer. Если это будет сделано, пользователь должен иметь возможность подключиться к своему почтовому ящику и вообще не запрашивать аутентификацию.

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

страница_аутентификации

Страница аутентификации на основе формы

И тем не менее, очень важная служба, широко используемая в почти каждой организации, здесь отсутствует - Microsoft Server ActiveSync. Вы можете определить доверие доверенных сторон для ActiveSync и настроить его для сквозной аутентификации. Это то, что вы сделали бы в Web Application Proxy Windows Server 2012 R2. Но, как отмечалось ранее, Web Application Proxy в Windows Server 2016 теперь поддерживает использование базовых клиентов HTTP для таких сервисов, как ActiveSync, которые не поддерживают перенаправление, и используют для аутентификации пользователей HTTP Basic.

HTTP Basic - это метод авторизации, используемый многими протоколами, включая ActiveSync, для подключения множества клиентов, включая смартфоны, с почтовым ящиком Exchange. (Для получения дополнительной информации о HTTP Basic см. RFC 2617 на http://www.ietf.org/rfc/rfc2617.txt.)

Web Application Proxy традиционно взаимодействует с AD FS с использованием перенаправления, которое не поддерживается клиентами ActiveSync. Публикация приложения с помощью HTTP Basic обеспечивает поддержку клиентов ActiveSync в Web Application Proxy, позволяя HTTP-приложению получать доверенное лицо, не полагающееся на доверенность для приложения AD FS.

Протокол аутентификации для клиентов, использующих HTTP Basic, описан в следующих шагах:

  1. Пользователь пытается получить доступ к опубликованному веб-приложению через телефонный клиент.
  2. Приложение отправляет HTTPS-запрос на опубликованный Web Application Proxy URL-адрес.
  3. Если запрос не содержит учётных данных, Web Application Proxy возвращает ответ на приложение HTTP 401, содержащее URL-адрес аутентифицирующего сервера AD FS.
  4. Пользователь снова отправляет HTTPS-запрос, с полномочиями, установленными на Basic: в заголовке запроса www-authenticate имя пользователя, и зашифрованный в Base 64 пароль пользователя.
  5. Поскольку устройство не может быть перенаправлено на AD FS, Web Application Proxy отправляет запрос проверки подлинности в AD FS с учётными данными, которые у него есть: имя пользователя, пароль и, при наличии, сертификат устройства. Токен приобретается от имени устройства.
  6. Чтобы свести к минимуму количество, отправленных в AD FS, запросов, Web Application Proxy проверяет последующие клиентские запросы, используя кешированные токены до тех пор, пока токены действительны. Web Application Proxy периодически очищает кеш. Вы можете просмотреть размер кеша, используя счётчик производительности.
  7. Если токен действителен, Web Application Proxy перенаправляет запрос на, поддерживающий службу, сервер и пользователю предоставляется доступ к опубликованному веб-приложению.

Для этого вернитесь на сервер ADFS01 и создайте не относящуюся к требованиям доверенную стороннюю группу ActiveSync.

доверенная_группа

Доверенная группа

Затем перейдите на сервер WAP01, с помощью HTTP Basic опубликуйте приложение ActiveSync, и выберите не относящуюся к требованиям доверяющую сторону ActiveSync.

поддерживаемые_клиенты

Поддерживаемые клиенты

Обратите внимание, что эта доверяющая сторона видна только тогда, когда она определена на сервере AD FS.

опции_доверенных_групп

Опции доверенных групп

Завершите оставшуюся часть работы мастера, настроив поддерживающие службу внешний и серверный URL-адреса. Конечный результат показан на рисунке ниже.

все_опубликованные_веб-приложения

Все опубликованные веб-приложения

Обратите внимание, что опубликованное приложение Microsoft ActiveSync использует метод предварительной аутентификации AD FS For Rich Clients.

Определение требований

Хотя определение требований не является функцией роли Web Application Proxy в Windows Server 2016, важно понять их важность в транзакции. Требования определяются в разделе «Outlook Web App» на панели «Действия», сервера AD FS.

редактирование_правил_требований

Редактирование правил требований

Выберите доверенные группы, которым вы хотите определить требования, а затем в области «Действия» нажмите «Изменить требования».

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

Чтобы опубликовать Outlook Web App и Exchange Admin Center, в этом примере, вам необходимо создать три правила пользовательских требований:

  • SID пользователя Active Directory
  • SID группы Active Directory
  • Active Directory UPN

Когда вы настраиваете правила пользовательских требований, вам необходимо использовать синтаксис языка правил требований для этого правила. В частности, для правила требований ActiveDirectoryUserSID используйте следующее:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/
windowsaccountname", Issuer == "AD AUTHORITY"]=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/
primarysid"), query = ";objectSID;{0}", param = c.Value);

Когда вы закончите, результирующее правило будет включать имя правила требований и текст пользовательского правила.

отредактированные_правила_требований

Отредактированные правила требований

Затем настройте следующее правило запроса ActiveDirectoryGroupSID:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/
windowsaccountname", Issuer == "AD AUTHORITY"]=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/
groupsid"), query = ";tokenGroups(SID);{0}", param = c.Value);

И, наконец, настройте следующее правило требований ActiveDirectoryUPN:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/
windowsaccountname", Issuer == "AD AUTHORITY"]=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/
upn"), query = ";userPrincipalName;{0}", param = c.Value);

Когда вы закончите, нажмите «Применить», а затем «ОК». Правила преобразования отображают на вкладке «Issuance Transform Rules» диалогового окна «Edit Claim Rules», имена правил.

EditClaimRules

Диалоговое окно «Edit Claim Rules»

Примечание. Вам нужно будет сделать это для каждой из ваших доверенных сторон.

Перевод URL-адреса хоста

Ещё одна вещь, о которой следует помнить, - это то, что Web Application Proxy может переводить имена хостов в URL-адресах. Например, у вас может быть приложение, к которому ваши внешние пользователи получают доступ по адресу URL http://www.contoso.com/app01, в то время как ваши внутренние пользователи получают это приложение, переходя на http://apps.contoso.com / app01. Это приемлемо, и Web Application Proxy может обрабатывать разницу в URL-адресе, в котором внешний URL-адрес - http://www.contoso.com/app01, и URL-адрес сервера Backend - http: //apps.contoso.com/app01.

app01

app01

Внимание. Вы не можете изменить путь к внешнему http://www.contoso.com/app1 и внутреннему http://apps.contoso.com/applicationXYZ.

Это полезно знать при публикации Exchange, поскольку вы можете иметь разные пространства имён DNS для внутреннего и внешнего доступа. Поэтому вы можете опубликовать URL-адрес для Outlook Web App, который отличается для ваших внутренних пользователей, от того, который вы публикуете для внешнего доступа. На рисунке ниже показано, что Web Application Proxy, если вы сохраняете одно и то же имя пути, может удовлетворить эту потребность.

параметры_публикации_для_приложения

Параметры публикации для приложения

Чтобы разрешить этот тип перевода, вы сначала должны получить идентификатор приложения, для которого вы хотите выполнить перевод. Для этого вы можете использовать следующую команду Windows PowerShell:

Get-WebApplicationProxyApplication | Format-Table ID, Name, ExternalURL

На следующем рисунке представлен результат.

Get-WebApplicationProxyApplication

Выход для Get-WebApplicationProxyApplication

Затем введите идентификатор приложения из вывода, показанного на рисунке и следующую команду Windows PowerShell:

Set-WebApplicationProxyApplication –ID <application_ID> -DisableTranslateUrlInRequestHeaders:$false

Включение AD FS для Exchange организации

Когда вы настраиваете в Exchange 2013, AD FS для проверки подлинности на основе утверждений с помощью Outlook Web App и Exchange Admin Center, вы должны включить AD FS для Exchange своей организации. Это можно сделать с помощью командлета Set-OrganizationConfig для вашей организации. Для примера окружения вам нужно будет сделать следующее:

  • Установите эмитенту AD FS значение https://adfs.contoso.com/adfs/ls.
  • Установите URI AD FS на https://mail.contoso.com/owa и https://mail.contoso.com/ecp.
  • Найдите на сервере AD FS сертификат подписи токена AD FS с помощью командлета Windows PowerShell Get-ADFSCertificate -CertificateType «Token-signing». Затем присвойте полученный отпечаток сертификата подписи маркера.

С помощью командной консоли Exchange введите следующий код:

Get-ADFSCertificate -CertificateType "Token-signing"

Это предоставит вам отпечаток сертификата подписи маркера, на котором вы запустите следующие командлеты Set-OrganizationConfig:

$uris = @(" https://mail.contoso.com/owa","https://mail.contoso.com/ecp") Set-OrganizationConfig -AdfsIssuer "https://adfs.contoso.com/adfs/ls/" -AdfsAudienceUris $uris –AdfsSignCertificateThumbprint "1a2b3c4d5e6f7g8h9i10j11k12l13m14n15o16p17q"

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.


↓