Публикация приложений с помощью SharePoint, Exchange и RDG

Данный материал относится к локальной версии прокси-сервера веб-приложения. Чтобы обеспечить безопасный доступ к локальным приложениям в облаке, см . содержимое прокси приложения Microsoft Entra.

В этом разделе описываются задачи, необходимые для публикации SharePoint Server, Exchange Server или шлюза удаленных рабочих столов (RDP) через прокси веб-приложения.

Публикация SharePoint Server

Вы можете опубликовать сайт SharePoint через прокси веб-приложения, если сайт SharePoint настроен для проверки подлинности на основе утверждений или встроенной проверка подлинности Windows. Если вы хотите использовать службы федерации Active Directory (AD FS) (AD FS) для предварительной проверки подлинности, необходимо настроить проверяющую сторону с помощью одного из мастеров.

• Если на сайте SharePoint используется аутентификация на основе утверждений, воспользуйтесь мастером добавления отношения доверия с проверяющей стороной, чтобы настроить для приложения отношения доверия с проверяющей стороной.

• Если на сайте SharePoint используется встроенная аутентификация Windows, воспользуйтесь мастером добавления отношений доверия с проверяющей стороной, не поддерживающей утверждения, чтобы настроить для приложения отношения доверия с проверяющей стороной. Если настроен центр KDC, с веб-приложением, поддерживающим утверждения, можно использовать аутентификацию IWA.

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

  Необходимо настроить приложение для поддержки ограниченного делегирования Kerberos. Эту настройку можно выполнить на контроллере домена для любого приложения. Вы также можете настроить приложение непосредственно на сервере серверной части, если оно работает в Windows Server 2012 R2 или Windows Server 2012. Дополнительные сведения см. в разделе Новые возможности аутентификации Kerberos. Кроме того, необходимо убедиться, что прокси-серверы веб-приложения настроены для делегирования имени субъекта-службы серверных серверов. Пошаговое руководство по настройке прокси веб-приложения для публикации приложения с помощью интегрированных проверка подлинности Windows см. в статье "Настройка сайта для использования интегрированных проверка подлинности Windows".

Если сайт SharePoint настроен с помощью альтернативных сопоставлений доступа (AAM) или коллекций сайтов с именем узла, для публикации приложения можно использовать различные URL-адреса внешних и внутренних серверов. Однако если настройка сайта SharePoint с использованием альтернативных сопоставлений доступа или коллекций сайтов с именем узла не выполнена, необходимо использовать те же URL-адреса внешних и внутренних серверов.

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

В следующей таблице описаны службы Exchange, которые можно опубликовать с помощью прокси веб-приложения и поддерживаемую предварительную проверку подлинности для этих служб:

Чтобы опубликовать приложение Outlook Web App, используя интегрированную аутентификацию Windows, воспользуйтесь мастером добавления отношений доверия с проверяющей стороной, не поддерживающей утверждения, и настройте для приложения отношения доверия с проверяющей стороной.

Чтобы разрешить пользователям проходить проверку подлинности с помощью ограниченного делегирования Kerberos, необходимо присоединить сервер прокси веб-приложения к домену.

Необходимо настроить приложение для поддержки проверки подлинности Kerberos. Кроме того, необходимо зарегистрировать имя субъекта-службы (SPN) в учетной записи, в которую выполняется веб-служба. Это можно сделать на контроллере домена или на внутренних серверах. В среде Exchange с балансировкой нагрузки это потребуется с помощью альтернативной учетной записи службы, см . инструкции по настройке проверки подлинности Kerberos для серверов клиентского доступа с балансировкой нагрузки

Вы также можете настроить приложение непосредственно на сервере серверной части, если оно работает в Windows Server 2012 R2 или Windows Server 2012. Дополнительные сведения см. в разделе Новые возможности аутентификации Kerberos. Кроме того, необходимо убедиться, что прокси-серверы веб-приложения настроены для делегирования имени субъекта-службы серверных серверов.

Публикация шлюза удаленных рабочих столов с помощью прокси веб-приложения

Если вы хотите ограничить доступ к шлюзу удаленного доступа и добавить предварительную проверку подлинности для удаленного доступа, его можно развернуть через прокси веб-приложения. Это действительно хороший способ убедиться, что у вас есть богатая предварительная проверка подлинности для RDG, включая MFA. Публикация без предварительной проверки подлинности также является вариантом и предоставляет единую точку входа в системы.

Публикация приложения в RDG с помощью сквозной проверки подлинности прокси веб-приложения

1. Установка будет отличаться в зависимости от того, находятся ли роли веб-доступа удаленных рабочих столов (/rdweb) и шлюза удаленных рабочих столов (RPC) на одном сервере или на разных серверах.

2. Если роли веб-доступа и шлюза удаленных рабочих столов размещаются на одном сервере RDG, можно просто опубликовать корневое полное доменное имя в прокси-сервере веб-приложения, например https://rdg.contoso.com/.

   Вы также можете опубликовать два виртуальных каталога по отдельности, напримерhttps://rdg.contoso.com/rdweb/https://rdg.contoso.com/rpc/.

3. Если веб-доступ к удаленным рабочим столам и шлюзу удаленных рабочих столов размещаются на отдельных серверах RDG, необходимо опубликовать два виртуальных каталога по отдельности. Вы можете использовать одинаковые или разные внешние полные доменные имена, например https://rdweb.contoso.com/rdweb/ https://gateway.contoso.com/rpc/.

4. Если полное доменное имя внешнего и внутреннего полного доменного имени отличается, не следует отключить преобразование заголовков запроса в правиле публикации RDWeb. Это можно сделать, выполнив следующий сценарий PowerShell на прокси-сервере веб-приложения, но его следует включить по умолчанию.

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$false
   

   Примечание.

   Если вам нужно поддерживать широкие возможности клиентов, таких как подключения RemoteApp и классические подключения или подключения к удаленному рабочему столу iOS, они не поддерживают предварительную проверку подлинности, поэтому необходимо опубликовать RDG с помощью сквозной проверки подлинности.

Публикация приложения в RDG с помощью прокси веб-приложения с предварительной проверкой подлинности

1. Предварительная проверка подлинности прокси веб-приложения с помощью RDG работает путем передачи файла cookie предварительной проверки подлинности, полученного Internet Explorer в клиент подключения к удаленному рабочему столу (mstsc.exe). Затем это используется клиентом подключения к удаленному рабочему столу (mstsc.exe). Затем это используется клиентом подключения к удаленному рабочему столу в качестве подтверждения проверки подлинности.

   Следующая процедура сообщает серверу коллекции включить необходимые настраиваемые свойства RDP в файлы удаленного приложения RDP, которые отправляются клиентам. Они сообщают клиенту о необходимости предварительной проверки подлинности и передаче файлов cookie для адреса сервера предварительной проверки подлинности клиенту подключения к удаленному рабочему столу (mstsc.exe). В сочетании с отключением функции HttpOnly в приложении прокси веб-приложения это позволяет клиенту подключения к удаленному рабочему столу (mstsc.exe) использовать файл cookie прокси веб-приложения, полученный через браузер.

   Проверка подлинности на сервере веб-доступа к удаленным рабочим столам по-прежнему будет использовать вход в форму веб-доступа к удаленным рабочим столам. Это обеспечивает минимальное количество запросов проверки подлинности пользователей, так как форма входа в веб-доступ к удаленным рабочим столам создает клиентское хранилище учетных данных, которое затем можно использовать клиентом подключения к удаленному рабочему столу (mstsc.exe) для любого последующего запуска удаленного приложения.

2. Сначала создайте ручное доверие проверяющей стороны в AD FS, как если бы вы публиковали приложение с учетом утверждений. Это означает, что необходимо создать фиктивное доверие проверяющей стороны, которое требуется для принудительной предварительной проверки подлинности, чтобы получить предварительную проверку подлинности без ограниченного делегирования Kerberos на опубликованный сервер. После проверки подлинности пользователя все остальное передается.

   Предупреждение

   Возможно, использование делегирования предпочтительнее, но оно не полностью решает требования единого входа mstsc и возникают проблемы при делегировании в каталог /rpc, так как клиент ожидает обрабатывать проверку подлинности шлюза удаленных рабочих столов.

3. Чтобы создать доверие проверяющей стороны вручную, выполните действия в консоли управления AD FS:

   1. Использование мастера добавления доверия проверяющей стороны

   2. Выберите " Ввести данные о проверяющей стороне" вручную.

   3. Примите все параметры по умолчанию.

   4. Для идентификатора доверия проверяющей стороны введите внешнее полное доменное имя, используемое для доступа к RDG, например https://rdg.contoso.com/.

      Это доверие проверяющей стороны, которое будет использоваться при публикации приложения в прокси веб-приложения.

4. Опубликуйте корневой каталог сайта (например, https://rdg.contoso.com/ ) в прокси веб-приложения. Задайте для предварительной проверки подлинности AD FS и используйте доверие проверяющей стороны, созданное выше. Это позволит /rdweb и /rpc использовать тот же файл cookie проверки подлинности прокси веб-приложения.

   Можно опубликовать /rdweb и /rpc в виде отдельных приложений и даже использовать разные опубликованные серверы. Необходимо просто убедиться, что вы публикуете оба с использованием того же доверия проверяющей стороны, что и маркер прокси веб-приложения, выдан для доверия проверяющей стороны и поэтому является допустимым для приложений, опубликованных с тем же доверием проверяющей стороны.

5. Если полное доменное имя внешнего и внутреннего полного доменного имени отличается, не следует отключить преобразование заголовков запроса в правиле публикации RDWeb. Это можно сделать, выполнив следующий сценарий PowerShell на прокси-сервере веб-приложения, но его следует включить по умолчанию:

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true
   

6. Отключите свойство cookie HttpOnly в прокси-сервере веб-приложения в опубликованном приложении RDG. Чтобы разрешить RDG ActiveX доступ к файлу cookie проверки подлинности прокси веб-приложения, необходимо отключить свойство HttpOnly в файле cookie прокси-сервера веб-приложения.

   Для этого необходимо установить накопительный пакет обновления за ноябрь 2014 г. для Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 (KB3000850).

   После установки исправления выполните следующий сценарий PowerShell на прокси-сервере веб-приложения, указав соответствующее имя приложения:

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$true
   

   Отключение HttpOnly позволяет RDG ActiveX контролировать доступ к файлу cookie проверки подлинности прокси-сервера веб-приложения.

7. Настройте соответствующую коллекцию RDG на сервере сбора данных, чтобы клиент подключения к удаленному рабочему столу (mstsc.exe) знал, что предварительная проверка подлинности требуется в файле rdp.

   • В Windows Server 2012 и Windows Server 2012 R2 это можно сделать, выполнив следующий командлет PowerShell на сервере сбора RDG:

     Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"
     

     Убедитесь, что при замене собственных значений удаляются < и > квадратные скобки, например:

     Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"
     

   • В Windows Server 2008 R2выполните следующие действия.

     1. Войдите на сервер терминала с учетной записью с правами администратора.

     2. Перейдите к запуску >диспетчера терминалов>служб терминалов служб администрирования>TS RemoteApp Manager.

     3. В области "Обзор" диспетчера удаленных приложений TS рядом с параметрами RDP нажмите кнопку "Изменить".

     4. На вкладке "Пользовательские параметры RDP" введите следующие параметры RDP в поле "Настраиваемые параметры RDP":

        pre-authentication server address: s: https://externalfqdn/rdweb/

        require pre-authentication:i:1

     5. По завершении нажмите кнопку "Применить".

        Это сообщает серверу коллекции включить настраиваемые свойства RDP в файлы RDP, которые отправляются клиентам. Они сообщают клиенту о необходимости предварительной проверки подлинности и передаче файлов cookie для адреса сервера предварительной проверки подлинности клиенту подключения к удаленному рабочему столу (mstsc.exe). Это в сочетании с отключением HttpOnly в приложении прокси веб-приложения позволяет клиенту подключения к удаленному рабочему столу (mstsc.exe) использовать файл cookie проверки подлинности прокси веб-приложения, полученный через браузер.

        Дополнительные сведения о RDP см. в разделе "Настройка сценария OTP шлюза TS".

См. также

• Планирование публикации приложений с помощью прокси веб-приложения

• Диагностика прокси-службы веб-приложения

• Пошаговое руководство по прокси-серверу веб-приложений