Настройка единого входа на основе kerberos из службы power bi в локальные источники данных

Справочные материалы

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

Причина

Эта проблема возникает при настройке дочернего домена (или только клиента) следующим образом:

Вы отключите тип шифрования RC4_HMAC-MD5, оставив включенными типы шифрования AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96.
Вы отключаете проверку подлинности NTLM.

Типы шифрования Kerberos

Шифрование RC4 считается менее безопасным, чем более новые типы шифрования AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96. Руководства по безопасности, такие как руководство по технической реализации безопасности Windows 10, содержат инструкции по повышению безопасности компьютера путем его настройки на использование только шифрования AES128 и (или) AES256 (см. сведения о том, как настроить типы шифрования Kerberos, чтобы предотвратить использование наборов шифрования DES и RC4).

Такой клиент может продолжать подключаться к службам в собственном домене, которые используют шифрование AES128 или AES256. Однако другие факторы могут препятствовать подключению клиента к аналогичным службам в другом доверенном домене, даже если эти службы также используют шифрование AES128 или AES256.

На очень высоком уровне контроллер домена отвечает за управление запросами на доступ в собственном домене. В рамках процесса проверки подлинности Kerberos контроллер домена проверяет, могут ли клиент и служба использовать один и тот же тип шифрования Kerberos. Однако, когда клиент запрашивает доступ к службе в другом надежном домене, контроллер домена клиента должен «ссылаться» клиента на контроллер домена в домене службы. Когда контроллер домена создает запрос ссылок, вместо сравнения типов шифрования клиента и службы сравнивает типы шифрования клиента и доверия.

Проблема возникает из-за конфигурации самого доверия. В Active Directory объект домена имеет связанные доверенные объекты домена (TDO), которые представляют каждый домен, которому он доверяет. Атрибуты TDO описывают отношение доверия, включая типы шифрования Kerberos, поддерживаемые доверием. Связь по умолчанию между дочерним доменом и родительским доменом — это двунамерное транзитивное доверие, которое поддерживает тип шифрования RC4. Как родительский, так и дочерний домен имеют объекты TDO, описывающих эту связь, включая тип шифрования.

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

Проверка подлинности NTLM

После сбоя проверки подлинности Kerberos клиент пытается вернуться к проверке подлинности NTLM. Однако если проверка подлинности NTLM отключена, у клиента нет других альтернатив. Поэтому попытка подключения завершается сбоем.

Protocol Transition

Существует два подвида простого KCD. Первый это KCD with Protocol transition (any authentication), второй — KCD without Protocol transition (kerberos only).

KCD without protocol transition (Kerberos only):

Cервису, настроенному на KCD without protocol transition нужно, чтобы пользователь прошел аутентификацию. В последствии мы будем иметь возможность представляться от его лица во время s4u2proxy.
Не может олицетворять любого пользователя без аутентификации.

KCD with protocol transition (any auth):

Cервис, настроенный на KCD with protocol transition, делает s4u2self вместо ожидания аутентификации. Это именно тот момент, где происходит имперсонализация, поэтому мы можем представляться другим пользователем.
ST полученный в результате s4u2self будет являться доказательством s4u2proxy того, что пользователь, которым мы представляемся, уже аутентифицировался.

Подведем ИТОГ нашей теоретической части.

Если KCD было настроено без Protocol transition, то просто так имперсонализировать других пользователей у нас не получится.

Полученный билет без Forwardable флага

Чтобы все получилось, нам нужен Forwardable флаг ИЛИ RBCD бит в зашифрованной части билета (TGS-REQ’s PAPACOPTIONS)

Как выяснилось, что при RBCD, KDC не столь важно наличие forwardable флага. KDC будет смотреть, есть ли в зашифрованной части билета rbcd бит и если он там будет, то мы получим то, что нам нужно

Флаг forwardable отсутствует, но билет с помощью s4u2proxy мы получили

Таким образом, чтобы обойти эти ограничения, нужно использовать s4u2proxy. Тогда можно будет получить билет, который будет соответствовать требованиям s4u2proxy, так как s4u2proxy постоянно вырабатывает билеты с флагом forwardable.

Ладно, все не так сложно, как кажется. Перейдём наконец к практической части статьи. Я буду делать все и c kali linux c помощью библиотеки Impacket и с помощью инструмента Rubeus. Для части где мы будем использовать пользовательскую учетку, Rubeus нужно будет немного переписать. Продублирую ссылку. Для удобства в демонстрации, я буду использовать пароли от машинных УЗ.

S4U2SELF & S4U2PROXY

Во время работы KCD в дело включаются две процедуры, которые имеют название S4U2Self и S4U2Proxy.

S4U2Self позволяет нам получить билет на себя от имени любого пользователя (необходим Forwardable флаг). Если говорить простым языком, то работает как

Тут нужно учесть, что:

Если пользователь, которого мы олицетворяем в Protected Users группе, то мы получим валидный билет, но без флага Forwardable
Если запрос не сконфигурирован для KCD, то мы получим валидный билет, но без флага Forwardable
Если запрос был сконфигурирован для KCD без protocol transition(с флагом kerberos-only), то мы получим валидный билет, но без флага Forwardable

S4U2Proxy позволяет нам получить билет для другого сервиса от имени пользователя клиента.

Если говорить простым языком, то работает как

Запрос должен содержать дополнительный билет как доказательство аутентификации.
Этот дополнительный билет должен быть с флагом forwardable или содержать rbcd bit.
Мы должны иметь возможность злоупотреблять KCD (креды пользователя или креды машины, созданной для злоупотребления rbcd).
Если пользователь, которым мы хотим представиться, находится в Protected Users, то ничего не получится.

Все вместе это выглядит вот так:

Главное помнить, что

3.1 Поиск учетных данных

Мы попали на хост, на котором развернуто большое приложение и имеем к нему доступ

Вы должны воспринимать это как «копилку» с учетными данными и другой важной информацией. Первым делом перейдем к базе данных по пути /snap/rocketchat-server/1427/bin

Подключаемся и просматриваем имеющиеся базы:

Нас интересует база , подключимся и получим ее коллекции.

Тут можно получать сообщения () или информацию о пользователях (), а можно просто изменить пароль админа и авторизоваться через веб-интерфейс. Для этого в базе поменяем хеш пароля (как сказано в документации).

Теперь мы можем авторизоваться как : . Просматривая все сообщения находим два пароля, и некоторое число пользователей.

Методов повысить привилегии на данном хосте не нашлось, поэтому сохраняем эти данные и идем далее.

CredSSP

Для проверки подлинности можно использовать протокол CredSSP. Протокол CredSSP кэширует учетные данные на удаленном сервере (ServerB), что делает их уязвимыми для атак, направленных на кражу учетных данных. Если безопасность удаленного компьютера нарушена, злоумышленник получает доступ к учетным данным пользователя.
Протокол CredSSP по умолчанию отключен на компьютерах клиента и сервера. Включать протокол CredSSP следует только в самых надежных средах. Например, при подключении администратора домена к контроллеру домена, так как контроллер домена является высоконадежным.

Дополнительные сведения о вопросах безопасности при использовании протокола CredSSP для удаленного взаимодействия PowerShell см. в статье Accidental Sabotage: Beware of CredSSP (Непреднамеренный саботаж: берегитесь CredSSP).

Дополнительные сведения об атаках, направленных на хищение учетных данных, см. в техническом документе Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

См. пример того, как включить и использовать CredSSP для удаленного взаимодействия PowerShell.

Минусы

Имеет уязвимости.
Требует настройки как клиентских, так и серверных ролей.
не работает с группой Защищенные пользователи. Дополнительные сведения см. в разделе Группа безопасности «Защищенные пользователи».

BONUS

В качестве бонуса вашему вниманию предлагается пересмотреть первый способ. Здесь будем использовать RBCD с помощью пользовательской учетки и механизма U2U. Смотреть на квоту для добавления машин в домен как вы понимаете, нам уже неинтересно.

1. Предположим, что мы знаем пароль пользователя user1 и нам РАЗРЕШИЛИ его менять, так как в итоге пароль от этой УЗ уедет в закат.

2. Прописываем RBCD на KCD$.

3. Запрашиваем билет на host/KCD от имени доменного админа TH через процедуру U2U

4. Злоупотребляем Ограниченным делегированием

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

Раздел 2. Конфигурация для конкретной среды

Добавление учетной записи службы шлюза в группу авторизации и доступа Windows

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

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

Кроме того, вы можете добавить учетную запись службы шлюза в группу авторизации и доступа Windows, если домен или лес не защищены. Но это не обязательно.

См. сведения о .

Чтобы выполнить настройку для каждого домена, содержащего пользователей Active Directory, которым должна быть доступна учетная запись службы шлюза для олицетворения, сделайте следующее:

Войдите на компьютер в домене и запустите оснастку MMC «Пользователи и компьютеры Active Directory».
Щелкните Windows Authorization and Access Group (Группа авторизации и доступа Windows), которая обычно находится в контейнере Builtin (Встроенные).
Дважды щелкните группу и перейдите на вкладку Участники.
Щелкните Добавить и укажите домен, в котором находится учетная запись службы шлюза.
Введите имя учетной записи службы шлюза и щелкните Проверить имена, чтобы убедиться, что учетная запись службы шлюза доступна.
Нажмите кнопку ОК.
Нажмите кнопку Применить.
Перезапустите службу шлюза.

Настройка параметров конфигурации сопоставления пользователей на компьютере шлюза

Выполните действия в этом разделе, если:

У вас нет Azure AD Connect с синхронизацией учетных записей пользователей, настроенной AND
Имя участника-пользователя, используемое в Power BI для пользователей, не соответствует имени участника-пользователя в локальной среде Active Directory.

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

Откройте главный файл конфигурации шлюза . По умолчанию этот файл хранится в .
Для параметра ADUserNameLookupProperty укажите неиспользуемый атрибут Active Directory. В следующих шагах мы будем использовать . Этот атрибут доступен только в Windows Server 2012 и более поздних версиях.
Задайте для свойства ADUserNameReplacementProperty значение , а затем сохраните файл конфигурации.

Примечание

В сценариях с несколькими доменами может потребоваться задать adUserNameReplacementProperty значение , чтобы сохранить сведения о домене пользователя.
На вкладке Службы диспетчера задач щелкните службу шлюза правой кнопкой мыши и выберите команду Перезапустить.
Для каждого пользователя службы Power BI, которому потребуется единый вход Kerberos, в свойстве локального пользователя Active Directory (с разрешением единого входа для используемого источника данных) укажите полное имя пользователя службы Power BI (имя участника-пользователя). Например, если вы входите в службу Power BI с именем test@contoso.com и хотите сопоставить этого пользователя с локальным пользователем Active Directory test@LOCALDOMAIN.COM с правами на единый вход, присвойте атрибуту значение test@contoso.com.

Задать свойство можно при помощи оснастки MMC «Пользователи и компьютеры Active Directory».
1. Войдите как администратор домена и запустите средство Пользователи и компьютеры Active Directory.
2. Щелкните правой кнопкой мыши имя домена, выберите Найти и введите имя учетной записи того пользователя Active Directory, с которым нужно настроить сопоставление.
3. Выберите вкладку Редактор атрибутов.
  
  Найдите свойство и дважды щелкните его. В качестве значения введите полное имя пользователя, которое вы используете для входа в службу Power BI (имя участника-пользователя).
4. Щелкните ОК.
5. Нажмите кнопку Применить. Проверьте, правильно ли установлено значение в столбце Значение.

Выполнение шаги по настройке конкретного источника данных

Для источников данных SAP HANA, SAP BW и Teradata требуется дополнительная конфигурация для использования единого входа шлюза:

Используйте Kerberos для единого входа в SAP HANA.
Используйте единый вход Kerberos для единого входа в SAP BW с помощью CommonCryptoLib (sapcrypto.dll).
Используйте Kerberos для единого входа в Teradata.

Примечание

Другие библиотеки SNC также могут работать с единым входом для BW, но официально не поддерживаются корпорацией Майкрософт.

Пароли из SYSVOL и GPP

На каждом компьютере с Windows, который работает в сети с Active Directory, имеется встроенная учетная запись администратора, защищенная паролем. Одно из стандартных требований безопасности — регулярно менять этот пароль. Казалось бы, задача несложная. Но только не когда в сети насчитывается под сотню машин.

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

Из этого следует вывод: получение учетных данных администратора на одной из машин сделает злоумышленника админом сразу на всех. Рассмотрим два способа добиться такого результата.

Учетные данные в SYSVOL

SYSVOL — это общедоменный ресурс Active Directory, к которому у всех авторизованных пользователей есть доступ на чтение. SYSVOL содержит сценарии входа, данные групповой политики и другие данные, которые должны быть доступны везде, где распространяется политика домена. При этом SYSVOL автоматически синхронизируется и используется всеми контроллерами домена. Все групповые политики домена хранятся по адресу

Чтобы упростить управление локальной учетной записью администратора на удаленных компьютерах с Windows, для каждой из них можно использовать собственный сценарий смены пароля. Проблема в том, что часто пароль хранится в виде открытого текста в скрипте (например, в файле VBS), который, в свою очередь, находится в SYSVOL. Вот пример одного из результатов поиска сценария VBS, меняющего пароль локального администратора на сетевых машинах.

Пример VBS-скрипта с официального сайта MSDN

Этот сценарий доступен в галерее Microsoft TechNet, из-за чего нередко используется системными администраторами, которые предпочитают готовые решения. Извлечь из него пароль не составляет никакого труда. А поскольку скрипт хранится в SYSVOL, к которому у каждого пользователя домена есть доступ для чтения, наличие пароля автоматически превращает его обладателя в локального администратора на всех сетевых машинах с виндой на борту.

Настройки групповой политики

В 2006 году инструмент PolicyMaker от Microsoft Bought Desktop Standard был переименован и выпущен вместе с Windows Server 2008 как Group Policy Preferences (GPP, «предпочтения групповой политики»). Одна из наиболее полезных функций GPP — возможность создавать локальных пользователей, настраивать и изменять их учетки, а также сохранять учетные данные в нескольких файлах сценариев:

карта дисков (Drives.xml);
источники данных (DataSources.xml);
конфигурация принтера (Printers.xml);
создание/обновление сервисов (Services.xml);
запланированные задачи (ScheduledTasks.xml).

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

Теперь давай посмотрим, как эта штука работает. При создании нового предпочтения групповой политики в SYSVOL генерируется связанный XML-файл с соответствующими данными конфигурации. Если в ней указан пароль пользователя, он будет зашифрован AES 256 бит. Но в 2012 году Microsoft опубликовала в MSDN ключ AES, который можно использовать для расшифровки пароля.

Ключ шифрования, представленный MSDN

Иными словами, любой авторизованный в домене юзер может найти в общем ресурсе SYSVOL файлы XML, содержащие cpassword, то есть зашифрованный пароль AES.

Пример содержимого файла Groups.xml

Быстро найти эти значения можно следующей командой:

Для расшифровки пароля можно воспользоваться инструментом Cryptool, при этом нужно в ручном режиме декодировать Base64 и указать ключ с MSDN (подробная инструкция по расшифровке приведена в статье на Хабре). Существует и полностью автоматизированное средство под названием gpp-decrypt, которое требует только значение cpassword и уже предустановлено в Kali Linux. Аналогичная утилита для Windows называется Get-GPPPassword, ее можно отыскать в наборе программ PowerSploit.

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

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

Олицетворение в методе службы: императивная модель

Иногда вызывающему объекту требуется олицетворять не весь метод службы, а лишь его часть. В этом случае необходимо получить удостоверение Windows вызывающего объекта внутри метода службы и императивно выполнить олицетворение. Для этого необходимо с помощью свойства WindowsIdentity объекта ServiceSecurityContext возвратить экземпляр класса WindowsIdentity и вызвать метод Impersonate перед использованием этого экземпляра.

Примечание

не забудьте использовать инструкцию Visual Basic или инструкцию C# для автоматической отмены действия олицетворения. если вы не используете оператор или используете язык программирования, отличный от Visual Basic или C#, не забудьте вернуть уровень олицетворения. В противном случае возникнет угроза атаки типа «отказ в обслуживании» или «несанкционированное получение прав».

Раздел 3. Проверка конфигурации

Шаг 1. Настройка источников данных в Power BI

Выполнив все шаги настройки, на странице Управление шлюза в Power BI можно настроить источник данных для единого входа. Если вы используете несколько шлюзов, выберите тот из них, который ранее настроили для единого входа Kerberos. Затем в разделе Параметры источника данных убедитесь, что для запросов DirectQuery установлен флажок Использовать единый вход через Kerberos для запросов DirectQuery или Использовать единый вход через Kerberos для запросов DirectQuery, а для запросов импорта установлен флажок Отчеты на основе DirectQuery и Использовать единый вход через Kerberos для Запросов Импорт .

Параметры Use SSO via Kerberos for DirectQuery queries and Use SSO via Kerberos for DirectQuery And Import (Использовать единый вход через Kerberos для запросов DirectQuery и импорта ) предоставляют другое поведение для отчетов на основе DirectQuery и отчетов на основе импорта.

Использовать единый вход (SSO) через Kerberos для запросов DirectQuery.

Для отчета на основе DirectQuery используются учетные данные единого входа для пользователя.
Для отчета на основе импорта используются не учетные данные единого входа, а введенные на странице источника данных учетные данные.

Использовать единый вход (SSO) через Kerberos для запросов DirectQuery и импорта.

Для отчета на основе DirectQuery используются учетные данные единого входа для пользователя.
Для отчета на основе импорта используются учетные данные единого входа, независимо от того, кто запускает этот импорт.

Шаг 2. Проверка единого входа

Перейдите в раздел Проверка конфигурации единого входа, чтобы быстро проверить правильность настройки конфигурации и устранить распространенные проблемы.

RBCD trick

Используем RBCD чтобы имитировать валидный для нас s4u2self билет -> s4u2proxy билет будет forwardable -> s4u2proxy отработает как нужно, так как мы подсунем ему билет где будет forwardable флаг.

1. Первым делом создаем машину

2. Прописываем RBCD от нашей машины rbcd$ к машине KCD

3. Делаем s4u2self для TH

Хоть у нас и нет Forwardable флага, билет перенаправится за счет RBCD

4. Делаем s4u2proxy на host/KCD подставляя полученный выше билет

Как видим, желамый флажок появился

5. Делаем KCD подставляя этот билет и… все прекрасно отработало.

На Win

Добавляем машину rbcd$ в домен и прописываем RBCD

Rubeus

Запрашиваем TGT

Аналогично делаем и для машины rbcd$

2. Делаем s4u2self

3. Делаем s4u2proxy

4. Делаем KCD

У этого метода есть недостатки, во-первых, мы должны иметь возможность создать машину, во-вторых, должны иметь права на запись rbcd бита в атрибут KCD машины.

Self RBCD trick

Но что если мы настроим RBCD на самого себя?

1. Прописываем сами на себя RBCD

2. Делаем S4U2Proxy запрашивая билет на host/KCD для TH

3. Делаем KCD подставляя полученный выше билет

Win

1. Запрашиваем TGT

2. Делаем s2u2self на host/KCD с тикетом KCD

3. Делаем KCD c tgs полученный на шаге 2 TGT на шаге 1.

1.2 JFROG Artifactory

JFrog Artifactory — это инструмент, предназначенный для хранения результатов сборки ПО и использования их в процессах распространения и развертывания. Artifactory обеспечивает поддержку ряда форматов пакетов, таких как Maven, Debian, NPM, Helm, Ruby, Python и Docker. Первым делом проверим обязательную авторизацию.

Авторизация от имени гостя не доступна, иначе мы бы могли получить список пользователей этим скриптом.

1.2.1 Авторизация

Ничего интересного кроме известных технологий мы не нашли, поэтому попробуем побрутить учетные данные по умолчанию. В случае с JFROG Artifactory возможные три варианта пар логин-пароль:

«admin»: «password»;
«anonymous»: пустой пароль.
«access-admin»: случайный пароль;

Первые два варианта не сработали, поэтому пробуем брутить третий с помощью Burp Intruder. В итоге взяв список самых популярных паролей из Seclists мы находим верный пароль для пользователя .

1.2.2 Сбор информации

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

Мы можем просматривать структуру файлов и директорий локальной системы, перейдя к работе с репозиториями на вкладке .

А также найдем пользователей в опции .

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

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

Таким образом мы находим какой-то адрес, предположительно из внутренней сети

Это очень важно, поэтому сохраняем в заметки

1.2.3 Эксплуатация SSRF

Данная система позволяет импортировать и экспортировать репозитории. Проверим можем ли мы обратиться к собственному хосту. Для начала тестируем протокол SMB, для чего перейдем к -> -> -> . Командой открываем у себя листенер. А затем выполним импорт со своего хоста.

В окне листенера видим отстук. Теперь проверим протокол HTTP, для чего перейдем к -> -> . В качестве листенера используем простой веб-сервер python3 .

Это дает нам возможность «просканировать» внутреннюю сеть. Так мы знаем один из адресов (то есть и адрес сети), поэтому стоит всего лишь выполнить сапрос на импорт к 255 хостам.

Сначала выполним запрос на импорт через SMB, затем отловим запрос в Burp Proxy и перенаправим в Intruder. В результате атаки добавим еще один столбец, который показываем время ответа, это позволит нам определить живые хосты с открытым портом SMB.

Затем повторим атаку, только уже с протоколом HTTP, где нас будет интересовать не время, а код ответа.

Таким образом мы найдем 4 живых хоста:

192.168.125.88
192.168.125.128
192.168.125.129
192.168.125.135

Так мы имеем хосты с портом SMB, нужно все-таки попробовать импортировать репозиторий. Для этого сначала найдем его расположение. Используем тот эе метод, что и при сканировании SMB, только теперь будем перебирать и адрес хоста (88,128,129) и каталог (возьмем список директорий): . И получаем всего один успешный запрос — к каталогу development.

Теперь просто импортируем репозиторий. В нем присутствует исполняемый файл, ключ и первый флаг!

Уровень олицетворения, получаемый на основании учетных данных Windows, и олицетворение с использованием кэшированного маркера

В некоторых сценариях при использовании учетных данных клиента Windows клиент может лишь частично управлять уровнем олицетворения в службе. Один из таких сценариев имеет место, когда клиент задает уровень олицетворения Anonymous. Второй сценарий имеет место при олицетворении с использованием кэшированного маркера. Для этого задается свойство AllowedImpersonationLevel класса WindowsClientCredential , к которому происходит обращение как к свойству универсального класса ChannelFactory<TChannel> .

Примечание

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

Клиент может установить один из следующих уровней олицетворения: , , или . При этом создается только маркер на заданном уровне, как показано в следующем фрагменте кода.

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

Значение	У службы есть	Служба и клиент поддерживают делегирование	Кэшированный маркер
Анонимные	Да	Недоступно	Олицетворение
Анонимные	нет	Недоступно	Определение
Определение	Недоступно	Недоступно	Определение
Олицетворение	Да	Недоступно	Олицетворение
Олицетворение	нет	Недоступно	Определение
Делегирование	Да	Да	Делегирование
Делегирование	Да	Нет	Олицетворение
Делегирование	нет	Недоступно	Определение

Основанное на ресурсах ограниченное делегирование в доменах

Ограниченное делегирование Kerberos можно использовать для предоставления ограниченного делегирования, когда служба интерфейса и службы ресурсов находятся в разных доменах. Администраторы служб могут настроить новое делегирование, указав в домене учетные записи служб интерфейса, которые будут выполнять олицетворение пользователей в объектах учетных записей служб ресурсов.

Какой эффект дает это изменение?

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

Это также смещает решение о том, должен ли сервер доверять источнику делегированного удостоверения от администратора домена с делегированием к владельцу ресурса.

Что работает иначе?

Изменение базового протокола позволяет осуществлять делегирование между доменами. реализация Windows Server 2012 R2 и Windows Server 2012 протокола Kerberos включает в себя расширения протоколов служб для пользователей и прокси (S4U2Proxy). Данный набор расширений для протокола Kerberos позволяет службе использовать билет службы Kerberos, благодаря которому пользователь получает билет службы из центра распространения ключей (KDC) для внутренней службы.

Подробности о реализации данных расширений см. в разделе . Расширения протокола Kerberos: S4U и спецификация протокола ограниченного делегирования в библиотеке MSDN.

Дополнительные сведения об основной последовательности сообщений для делегирования Kerberos с помощью пересланного билета предоставления билета (TGT) в сравнении с расширениями Service for User (S4U) см. в разделе Обзор протокола 1.3.3 документа «. Расширения протокола Kerberos: S4U и спецификация протокола ограниченного делегирования».

Влияние ограниченного делегирования на основе ресурсов на безопасность

Ограниченное делегирование на основе ресурсов обеспечивает управление делегированием в руки администратора, владеющего ресурсом, к которому осуществляется доступ. Он зависит от атрибутов службы ресурсов, а не от доверенных для делегирования служб. В результате ограниченное делегирование на основе ресурсов не может использовать бит доверия «доверенный к проверке подлинности» для делегирования, который ранее управлял сменой протокола. KDC всегда разрешает переход по протоколу при выполнении ограниченного делегирования на основе ресурсов, как если бы бит был задан.

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

SID	Описание
AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITYS – 1-18-1	Идентификатор безопасности, означающий, что удостоверение клиента подтверждается центром проверки подлинности на основе подтверждения принадлежности учетных данных клиента.
SERVICE_ASSERTED_IDENTITYS – 1-18-2	Идентификатор безопасности, означающий, что удостоверение клиента подтверждается службой.

Серверная служба может использовать стандартные выражения ACL для определения способа проверки подлинности пользователя.

Как настроить ограниченное делегирование на основе ресурсов?

Чтобы настроить службу ресурсов для предоставления доступа к службе интерфейса от имени пользователя, используйте командлеты Windows PowerShell.

Чтобы получить список участников, используйте командлеты Get-ADComputer, Get-адсервицеаккаунти Get-ADUser с параметром PrincipalsAllowedToDelegateToAccount Properties .
Чтобы настроить службу ресурсов, используйте командлеты New-ADComputer, New-адсервицеаккаунт, New-ADUser, Set-ADComputer, Set-адсервицеаккаунти Set-ADUser с параметром PrincipalsAllowedToDelegateToAccount .

Настройка ограниченного делегирования Kerberos на основе ресурсов для учетной записи компьютера

Возьмем следующий сценарий: у вас есть веб-приложение, которое выполняется на компьютере contoso-webapp.aaddscontoso.com.

Веб-приложению необходим доступ к веб-API, который выполняется на компьютере contoso-api.aaddscontoso.com в контексте пользователей домена.

Выполните указанные далее действия, чтобы настроить этот сценарий.

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

Примечание

Учетные записи компьютеров для веб-приложения и веб-API должны находиться в настраиваемом подразделении, для которого у вас есть разрешения на настройку KCD на основе ресурсов. KCD на основе ресурсов нельзя настроить во встроенном контейнереКомпьютеры AAD DC.
Наконец, настройте ограниченное делегирование Kerberos на основе ресурсов с помощью командлета PowerShell Set-ADComputer.

На присоединенной к домену виртуальной машине управления войдите в учетную запись пользователя, принадлежащего к группе Администраторы Azure AD DC, и запустите следующие командлеты. При необходимости укажите собственные имена компьютеров.