Часто задаваемые вопросы о прокси приложений Microsoft Entra

Нет, следующие элементы конфигурации используются прокси приложениями и не должны быть изменены или удалены:

• Включить или отключить "Разрешить потоки общедоступных клиентов".
• CWAP_AuthSecret (секреты клиента).
• Разрешения API. Изменение любого из указанных выше элементов конфигурации на странице регистрации приложений прерывает предварительную проверку подлинности для прокси приложения Microsoft Entra.

Нет, следует удалить приложение-прокси приложения из области корпоративных приложений Центра администрирования Microsoft Entra. Если удалить приложение-прокси приложения из области Регистрация приложений центра администрирования Microsoft Entra, могут возникнуть проблемы.

Чтобы использовать прокси приложения Microsoft Entra, необходимо иметь лицензию Microsoft Entra ID P1 или P2. Дополнительные сведения о лицензировании см. в ценах на Microsoft Entra

Если срок действия лицензии истекает, прокси приложения автоматически отключается. Сведения о приложении сохраняются до одного года.

Убедитесь, что у вас установлена по крайней мере лицензия Microsoft Entra ID P1 или P2 и соединитель частной сети Microsoft Entra. После успешной установки первого соединителя служба прокси приложения Microsoft Entra включена автоматически.

Да, соединитель частной сети Microsoft Entra используется как прокси приложения, так и Частный доступ Microsoft Entra. Дополнительные сведения о соединителе см. в статье Microsoft Entra private network connector. Сведения об устранении неполадок с конфигурацией соединителей см. в статье об устранении неполадок соединителей.

Хотя эти суффиксы отображаются в списке суффиксов, их не следует использовать. Эти суффиксы домена не предназначены для использования с прокси-сервером приложения Microsoft Entra. Если вы используете эти суффиксы домена, созданное приложение прокси приложения Microsoft Entra не будет работать. Можно использовать стандартный суффикс домена msappproxy.net или личный домен.

Идентификатор Microsoft Entra имеет службу прокси приложения, которая позволяет пользователям получать доступ к локальным приложениям, выполнив вход с помощью учетной записи Microsoft Entra. Если у вас установлены соединители в разных регионах, можно оптимизировать трафик, выбрав ближайший регион облачной службы прокси приложения для использования с каждой группой соединителей, см. статью "Оптимизация потока трафика с помощью прокси приложения Microsoft Entra".

После передачи SSL-сертификата вы получите сообщение "Недопустимый сертификат, возможно, неверный пароль" на портале.

Ниже приведены некоторые советы по устранению этой ошибки.

• Проверьте наличие проблем с сертификатом. Установите его на локальном компьютере. Если проблем не возникает, то с сертификатом все в порядке.
• Убедитесь, что пароль не содержит специальных символов. Пароль должен содержать только символы 0-9, A-Z и a-z.
• Если сертификат был создан с помощью поставщика хранилища ключей программного обеспечения Майкрософт, необходимо использовать алгоритм RSA.

Длина по умолчанию составляет 85 секунд. "Длинное" ожидание составляет 180 секунд. Предел времени ожидания не может быть увеличен.

Нет, в настоящее время такая возможность не поддерживается.

Секрет клиента, также называемый CWAP_AuthSecret, автоматически добавляется в объект приложения (регистрация приложения) при создании прокси-приложения Microsoft Entra.

Секрет клиента действителен в течение одного года. Новый секрет клиента в течение одного года создается автоматически до истечения срока действия текущего действительного секрета клиента. Три CWAP_AuthSecret секреты клиента всегда хранятся в объекте приложения.

Нет, необходимо использовать исходный резервный домен.

Статья, упоминание вопрос: добавление и замена резервного домена onmicrosoft.com в Microsoft 365

На странице регистрации приложений можно изменить URL-адрес домашней страницы на требуемый внешний URL-адрес целевой страницы. Указанная страница загружается при запуске приложения с Мои приложения или портала Office 365. Инструкции по настройке см. в разделе "Настройка пользовательской домашней страницы для опубликованных приложений с помощью прокси приложения Microsoft Entra"

Если настроена предварительная проверка подлинности Microsoft Entra, а URL-адрес приложения содержит символ "#" при попытке доступа к приложению в первый раз, вы будете перенаправлены на идентификатор Microsoft Entra (login.microsoftonline.com) для проверки подлинности. После завершения проверки подлинности вы будете перенаправлены на URL-часть до символа "#" и все, что происходит после "#", кажется, игнорируется или удалено. Например, если URL-адрес указан https://www.contoso.com/#/home/index.html, после завершения проверки подлинности Microsoft Entra пользователь перенаправляется в https://www.contoso.com/. Это поведение обусловлено тем, как символ # обрабатывается браузером.

Возможные решения и альтернативы:

• Настройка перенаправления из https://www.contoso.comhttps://contoso.com/#/home/index.html. Пользователь должен сначала получить доступ к https://www.contoso.com.
• URL-адрес, используемый для первой попытки доступа, должен содержать символ # в кодированной форме (%23). Опубликованный сервер может не принять это.
• Настройте тип предварительной проверки подлинности (не рекомендуется).

Нет, для опубликованных приложений не требуется IIS. Можно публиковать веб-приложения, работающие на серверах, отличных от Windows Server. Однако вы не сможете использовать предварительную проверку подлинности с windows Server, в зависимости от того, поддерживает ли веб-сервер согласование (проверка подлинности Kerberos). Службы IIS не требуются на сервере, на котором установлен соединитель.

Прокси приложения не добавляет автоматически заголовок HTTP Strict-Transport-Security в ответы HTTPS, но сохраняет заголовок, если он находится в исходном ответе, отправленном опубликованным приложением. Предоставление параметра для включения этой функции входит в дальнейшие планы.

Нет, если протокол http настроен во внешнем URL-адресе, то конечная точка прокси приложения Microsoft Entra принимает входящие запросы по TCP 80 порта, если протокол https затем на tcp-порте 443.

Да. Вот некоторые примеры внутренних URL-адресов, включая порты: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

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

Рекомендуется использовать идентичные внешние и внутренние URL-адреса. Внешние и внутренние URL-адреса считаются идентичными, если protocol://hostname:port/path/ в обоих URL-адресах идентичны.

Это можно сделать с помощью функции Личные домены.

Примеры:

Идентичны:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Не идентичны:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Сделать внешние и внутренние URL-адреса идентичными вообще невозможно, если внутренний URL-адрес содержит нестандартный порт (кроме TCP 80 /443).

В некоторых сценариях изменения нужно вносить в конфигурацию веб-приложения.

Метод PrincipalsAllowedToDelegateToAccount используется, когда серверы соединителей находятся в разных доменах из учетной записи службы веб-приложений. Он требует использования ограниченного делегирования на основе ресурсов. Если серверы соединителей и учетная запись службы веб-приложения находятся в одном домене, можно использовать Active Directory — пользователи и компьютеры для настройки параметров делегирования на каждой учетной записи компьютера соединителя, что позволяет им делегировать целевому имени субъекта-службы.

Если серверы соединителей и учетная запись службы веб-приложения находятся в разных доменах, используется делегирование на основе ресурсов. Разрешения на делегирование настраиваются на целевом веб-сервере и в учетной записи службы веб-приложений. Этот метод ограниченного делегирования является относительно новым. Этот метод появился в Windows Server 2012, который поддерживает делегирование между доменами, позволяя владельцу ресурса (веб-службе) управлять тем, какие компьютеры и учетные записи служб могут быть делегированы. В этой конфигурации нет пользовательского интерфейса, поэтому необходимо использовать PowerShell. Дополнительные сведения см. в описании ограниченного делегирования Kerberos с прокси приложениями.

Проверка подлинности NTLM не может использоваться в качестве метода предварительной проверки подлинности или единого входа. Проверку подлинности NTLM можно использовать только в том случае, если ее можно согласовать непосредственно между клиентом и опубликованным веб-приложением. Использование проверки подлинности NTLM обычно приводит к отображению запроса на вход в браузере.

Нет, это не будет работать, так как гостевой пользователь в идентификаторе Microsoft Entra ID не имеет атрибута, необходимого для любого из удостоверений входа, упоминание выше.

В этом случае имеется резервная строка "Имя участника-пользователя". Дополнительные сведения о сценарии B2B см. в статье Grant B2B users in Microsoft Entra ID access to your on-premises applications.

Политики условного доступа применяются только для успешно прошедших проверку подлинности пользователей в идентификаторе Microsoft Entra. Сквозная проверка подлинности не активирует проверку подлинности Microsoft Entra, поэтому политики условного доступа не могут быть применены. При сквозной проверке подлинности политики MFA должны быть реализованы на локальном сервере, если это возможно, или путем включения предварительной проверки подлинности с помощью прокси приложения Microsoft Entra.

Нет, этот сценарий не поддерживается, так как прокси приложения завершает трафик TLS.

Сведения о публикации удаленного рабочего стола с помощью прокси приложения Microsoft Entra.

Нет, этот сценарий не поддерживается.

Да, это ожидаемо. Для сценария предварительной проверки подлинности требуется элемент activeX, который не поддерживается в сторонних браузерах.

Да, этот сценарий сейчас находится в общедоступной предварительной версии. Сведения о публикации удаленного рабочего стола с помощью прокси приложения Microsoft Entra.

Да, так и должно быть. Если компьютер пользователя присоединен к Microsoft Entra, пользователь автоматически войдет в идентификатор Microsoft Entra. Пользователь должен предоставить свои учетные данные только в форме входа RDWeb.

Этот параметр позволяет пользователю загрузить RDP-файл и использовать его другим клиентом RDP (кроме веб клиента удаленного рабочего стола). Как правило, другие клиенты RDP (например, клиент Удаленный рабочий стол (Майкрософт)) не могут обрабатывать предварительную проверку подлинности в собственном коде. Поэтому сценарий не работает.

Сведения о включении удаленного доступа к SharePoint с помощью прокси приложения Microsoft Entra.

Мобильное приложение SharePoint в настоящее время не поддерживает предварительную проверку подлинности Microsoft Entra.

Нет, прокси приложения Microsoft Entra предназначен для работы с идентификатором Microsoft Entra ИД и не соответствует требованиям, которые необходимо выполнить в качестве прокси-сервера AD FS.

Нет, это не поддерживается.

Теперь поддерживаются приложения, использующие протокол WebSocket, например QlikSense и веб-клиент удаленного рабочего стола (HTML5). Ниже известные ограничения:

• Прокси приложения отменяет файл cookie, заданный в ответе сервера, при открытии соединения WebSocket.
• Единый вход не применяется к запросу WebSocket.
• Функции (журналы событий, PowerShell и службы удаленных рабочих столов) в Центре Администратор Windows (WAC) не работают через прокси приложения Microsoft Entra.

Приложение WebSocket не имеет уникальных требований к публикации и может быть опубликовано так же, как и все другие приложения-прокси приложения.

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

Для лучшей производительности рекомендуется использовать идентичные внутренние и внешние URL-адреса, настроив личные домены. Если использование личных доменов невозможно, можно улучшить производительность преобразования ссылок с помощью расширения для безопасного входа в Мои приложения или браузера Microsoft Edge на мобильных устройствах. См . статью "Перенаправление жестко закодированных ссылок" для приложений, опубликованных с помощью прокси приложения Microsoft Entra.

Этот сценарий не поддерживается напрямую. Варианты для этого сценария таковы:

1. Опубликуйте URL-адреса HTTP и HTTPS как отдельные приложения с подстановочным знаком, но присвойте каждому из них особый личный домен. Эта конфигурация работает, так как они имеют разные внешние URL-адреса.

2. Опубликуйте URL-адрес HTTPS с помощью приложения с подстановочными знаками. Публикация HTTP-приложений отдельно с помощью этих командлетов PowerShell прокси приложения:

   • Управление приложениями прокси приложения
   • Управление соединителем частной сети