Ограниченное делегирование Kerberos для единого входа в ваши приложения с использованием прокси сервера для приложений

Обзор

Вы можете предоставить единый вход для локальных приложений, опубликованных через прокси-сервер приложений и защищенных с помощью интегрированной проверки подлинности Windows. Для доступа к таким приложениям нужен билет Kerberos. Прокси приложения использует ограниченное делегирование Kerberos (KCD) для поддержки этих приложений.

Дополнительные сведения об едином входе см. в статье "Что такое единый вход?".

Вы можете включить единый вход в ваши приложения с помощью интегрированной аутентификации Windows (IWA), разрешив соединителям частной сети в Active Directory выполнять имперсонификацию пользователей. Соединители используют это разрешение для отправки и получения токенов от имени пользователей.

Принцип работы единого входа с применением KCD

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

1. Пользователь вводит URL-адрес для доступа к локальному приложению через прокси приложения.
2. Прокси приложения перенаправляет запрос в службы проверки подлинности Microsoft Entra для предварительной проверки подлинности. На этом этапе идентификатор Microsoft Entra применяет любые применимые политики проверки подлинности и авторизации, такие как многофакторная проверка подлинности. Если пользователь проверен, идентификатор Microsoft Entra создает маркер и отправляет его пользователю.
3. Пользователь передает токен приложению-прокси.
4. Прокси приложения проверяет токен и извлекает имя пользователя (UPN), а затем соединитель извлекает имя пользователя (UPN) и имя службы (SPN) через двойное удостоверение защищенного канала.
5. Соединитель ведет переговоры об ограниченном делегировании Kerberos с локальным AD, выступая от имени пользователя, чтобы получить маркер Kerberos для приложения.
6. Active Directory отправляет маркер Kerberos для приложения в соединитель.
7. Соединитель отправляет исходный запрос серверу приложений с помощью маркера Kerberos, полученного от AD.
8. Приложение отправляет ответ соединителю, который затем возвращается в службу прокси приложения и, наконец, пользователю.

Предварительные условия

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

• Настройте свои приложения, например веб-приложения SharePoint, на использование Встроенной проверки подлинности Windows. Дополнительные сведения см. в статье Включение поддержки протокола проверки подлинности Kerberos или (для SharePoint) в статье Планирование проверки подлинности Kerberos в SharePoint 2013.
• Все ваши приложения имеют Имена Главных Служб.
• Сервер, на котором выполняется соединитель, и сервер, на котором запущено приложение, присоединены к домену и являются частью одного домена или доверенных доменов. Дополнительные сведения о присоединении к домену см. в разделе Присоединение компьютера к домену.
• Убедитесь, что сервер соединителя может читать TokenGroupsGlobalAndUniversal атрибут для пользователей. Защита безопасности может ограничить этот доступ. Включите серверы подключений, добавив их в группу доступа к проверке подлинности Windows.

Настройка Active Directory

Конфигурация Active Directory зависит от того, находятся ли соединитель частной сети и сервер приложений в одном домене или нет.

Соединитель и сервер приложения находятся в одном домене

1. В Active Directory выберите Средства>Пользователи и компьютеры.

2. Выберите сервер, на котором работает соединитель.

3. Щелкните его правой кнопкой мыши и выберите Свойства>Делегирование.

4. Выберите Доверять этому компьютеру делегирование только указанных служб.

5. Выберите "Использовать любой протокол проверки подлинности".

6. В списке служб, в которых эта учетная запись может использовать делегированные учетные данные, добавьте значение SPN-идентификатора сервера приложений. Параметр позволяет соединителю частной сети подменять пользователей в AD для приложений, указанных в списке.

   

Соединитель и сервер приложения находятся в разных доменах

1. Список предварительных требований для работы с ограниченным делегированием Kerberos в разных доменах см. в статье Ограниченное делегирование Kerberos в разных доменах.

2. Чтобы включить делегирование проверки подлинности Kerberos из прокси приложения (соединитель), используйте PrincipalsAllowedToDelegateTo свойство учетной записи службы веб-приложения (webserviceaccount). Сервер приложений работает с webserviceaccount, а делегированный сервер — connectorcomputeraccount. Выполните следующие команды на контроллере домена (Windows Server 2012 R2 или более поздней версии) в том же домене, что и webserviceaccount. Используйте обычные имена (не UPN) для обеих учетных записей.

   Если webserviceaccount является учетной записью компьютера, используйте следующие команды:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

   Если webserviceaccount является учетной записью пользователя, используйте следующие команды:

   $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
   
   Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
   
   Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
   

Настройка единого входа

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

2. После отображения приложения в списке корпоративных приложений выберите его и выберите единый вход.

3. Выберите режим единого входа Встроенная проверка подлинности Windows.

4. Введите SPN внутреннего приложения сервера приложений. В этом примере SPN для нашего опубликованного приложения будет http/www.contoso.com. Имя принципала службы должно находиться в списке служб, куда соединитель может передавать делегированные учетные данные.

5. Выберите делегированную идентификацию для входа, которую соединитель сможет использовать от имени пользователей. Дополнительные сведения см. в статье "Работа с разными локальными и облачными удостоверениями".

   

Единый вход для приложений не на базе Windows

Поток делегирования Kerberos в прокси приложения Microsoft Entra запускается, когда Microsoft Entra ID аутентифицирует пользователя в облаке. После поступления запроса в локальную среду соединитель частной сети Microsoft Entra выдает запрос Kerberos от имени пользователя, взаимодействуя с локальным Active Directory. Этот процесс называется ограниченной делегацией Kerberos (KCD).

На следующем этапе запрос отправляется во внутреннее приложение с этим билетом Kerberos.

Существует несколько механизмов, определяющих, как отправлять билет Kerberos в таких запросах. Большинство серверов, отличных от Windows, ожидают его получения в виде токена SPNEGO. Этот механизм поддерживается в прокси приложения Microsoft Entra, но по умолчанию отключен. Соединитель можно настроить для SPNEGO или стандартного токена Kerberos, но не для обоих.

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

Чтобы включить SPNEGO, сделайте следующее:

1. Откройте командную строку от имени администратора.

2. Выполните следующие команды на серверах соединителей, которым требуется SPNEGO.

   REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft Entra private network connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
   net stop WAPCSvc & net start WAPCSvc
   

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

Работа с различными локальными и облачными идентификациями

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

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

• Использование нескольких внутренних доменов (например, joe@us.contoso.com) joe@eu.contoso.comс одним облачным доменом (например, joe@contoso.com).
• Использование внутренних нераспределяемых доменных имен (например, joe@contoso.usa) вместе с допустимыми доменными именами в облаке.
• Работа без внутренних доменных имен (например, джо).
• Назначение различных псевдонимов для пользователей в локальной среде и в облаке (например, joe-johns@contoso.com vs. joej@contoso.com).

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

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

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

Настройка единого входа для различных учетных записей

1. Настройте параметры Microsoft Entra Connect, чтобы основной идентификатор был адресом электронной почты (email). Конфигурация выполняется как часть процесса настройки, изменяя поле имя пользователя в параметрах синхронизации. Эти параметры также определяют способ входа пользователей в Microsoft 365, компьютеры Windows и другие приложения, использующие идентификатор Microsoft Entra в качестве хранилища удостоверений.
   

2. В параметрах конфигурации приложения для приложения, которое вы хотите изменить, выберите нужное значение параметра Делегированное удостоверение для входа :

   • Имя пользователя (например, joe@contoso.com)
   • альтернативное основное имя пользователя (например, joed@contoso.local)
   • Часть имени пользователя в основном имени пользователя (например, joe)
   • Часть имени пользователя в альтернативном основном имени пользователя (например, joed)
   • имя локальной учетной записи SAM (в зависимости от локальной конфигурации контроллера домена).

Устранение неполадок SSO для различных удостоверений

Если серверное приложение отвечает с непредвиденными ответами HTTP, начните устранять неполадки, проверив событие 24029 в журнале событий сеанса прокси приложения на компьютере соединителя. В поле user сведений о событии отображается идентификатор, используемый для делегирования. Чтобы включить журналы сеансов, перейдите в средство просмотра событий, откройте меню "Вид " и выберите "Показать аналитические и отладочные журналы".

Следующие шаги

• Как сконфигурировать прокси-приложение для использования ограниченного делегирования Kerberos
• Устранение неполадок с прокси приложениями