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

Статья
02/21/2025

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

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

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

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

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

Схема потока проверки подлинности Microsoft Entra

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

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

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

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

Настройка Active Directory

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

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

В Active Directory выберите Средства>Пользователи и компьютеры.
Выберите сервер, на котором работает соединитель.
Щелкните его правой кнопкой мыши и выберите Свойства>Делегирование.
Выберите Доверять этому компьютеру делегирование только указанных служб.
Выберите "Использовать любой протокол проверки подлинности".
В разделе Службы, с которыми эта учетная запись может использовать делегированные учетные данные добавьте значение SPN для идентификации сервера приложений. Это позволяет соединителю частной сети входить от имени пользователей в Active Directory (AD) для взаимодействия с приложениями, указанными в списке.

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

Список предварительных требований для работы с ограниченным делегированием Kerberos в разных доменах см. в статье Ограниченное делегирование Kerberos в разных доменах.
principalsallowedtodelegateto Используйте свойство служебной учетной записи (компьютер или учетная запись пользователя, назначенная для домена) веб-приложения, чтобы включить делегирование аутентификации Kerberos из прокси приложения (коннектор). Сервер приложений выполняется в контексте 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
```

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

Опубликуйте приложение в соответствии с инструкциями, описанными в разделе "Публикация приложений с помощью прокси приложения". Обязательно выберите идентификатор Microsoft Entra в качестве метода предварительной проверки подлинности.
Когда приложение появится в списке корпоративных приложений, выберите его и щелкните Единый вход.
Выберите режим единого входа Встроенная проверка подлинности Windows.
Введите SPN внутреннего приложения сервера приложений. В этом примере SPN для нашего опубликованного приложения будет http/www.contoso.com. Это SPN должно входить в список служб, в который соединитель может использовать делегированные учетные данные.
Выберите делегированную идентификацию для входа, которую соединитель сможет использовать от имени пользователей. Дополнительные сведения см. в статье "Работа с разными локальными и облачными удостоверениями".

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

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

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

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

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

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

Откройте командную строку от имени администратора.
В командной строке выполните следующие команды на серверах соединителя, требующих 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)
Используйте разные псевдонимы на локальных серверах и в облаке. Например, joe-johns@contoso.com и joej@contoso.com.

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

Снимок экрана параметра

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

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

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

Настройте параметры Microsoft Entra Connect, чтобы основной идентификатор был адресом электронной почты (email). Для этого при настройке следует изменить поле Имя субъекта-пользователя в параметрах синхронизации. Эти параметры также определяют способ входа пользователей в Microsoft 365, компьютеры Windows и другие приложения, использующие идентификатор Microsoft Entra в качестве хранилища удостоверений.
В параметрах конфигурации приложения для приложения, которое вы хотите изменить, выберите нужное значение параметра Делегированное удостоверение для входа :
- Имя пользователя (например, joe@contoso.com)
- альтернативное основное имя пользователя (например, joed@contoso.local)
- Часть имени пользователя в основном имени пользователя (например, joe)
- Часть имени пользователя в альтернативном основном имени пользователя (например, joed)
- имя локальной учетной записи SAM (в зависимости от локальной конфигурации контроллера домена).

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

Когда в процессе единого входа возникает ошибка, она заносится в журнал событий на компьютере соединителя, как описано в разделе Устранение неполадок. Но в некоторых случаях запрос успешно отправляется внутреннему приложению, пока оно обрабатывает другие HTTP-ответы. Устранение неполадок этих случаев должно начинаться с изучения номера события 24029 на компьютере соединителя в журнале событий сеанса прокси приложения. Удостоверение пользователя, которое использовалось для делегирования, отображается в поле "Пользователь" в сведениях о событии. Чтобы включить журнал сеанса, выберите пункт Отобразить аналитический и отладочный журналы в меню "Вид" средства просмотра событий.

Поделиться через