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

Статья
02/01/2024

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

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

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

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

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

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

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

Необходимые компоненты

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

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

Настройка Active Directory

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

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

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

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

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

Если 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.
Введите Внутреннее имя субъекта-службы приложения сервера приложений. В этом примере таким именем для опубликованного приложения будет http/www.contoso.com. Это имя субъекта-службы должно входить в список служб, для которого соединитель может имеет делегированные учетные данные.
Выберите делегированную идентификацию для входа, которую соединитель сможет использовать от имени пользователей. Дополнительные сведения см. в статье "Работа с разными локальными и облачными удостоверениями".

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

Поток делегирования Kerberos в прокси-сервере приложения 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, чтобы основное удостоверение — адрес электронной почты (почта). Для этого при настройке следует изменить поле Имя субъекта-пользователя в параметрах синхронизации. Эти параметры также определяют способ входа пользователей в Microsoft 365, компьютеры Windows и другие приложения, использующие идентификатор Microsoft Entra в качестве хранилища удостоверений.
В параметрах конфигурации приложения для приложения, которое вы хотите изменить, выберите нужное значение параметра Делегированное удостоверение для входа :
- имя участника-пользователя (например, joe@contoso.com);
- дополнительное имя участника-пользователя (например, joed@contoso.local);
- Часть имени участника-пользователя (например, joe)
- Часть имени альтернативного участника-пользователя (например, joed)
- имя локальной учетной записи SAM (в зависимости от локальной конфигурации контроллера домена).

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

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

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