Самое непонятное диалоговое окно в Active Directory

Тим Спрингстон (tim.springston@microsoft.com) – старший инженер службы технической поддержки подразделения Commercial Technical Support в Microsoft, отвечает за систему безопасности и авторизацию

Одна из наиболее активно обсуждаемых в блогах технологий Microsoft – аутентификация по протоколу Kerberos. Это странно, если учесть, что сама технология и ее функции не претерпели значительных изменений с момента выпуска Windows Server 2003. И все же Kerberos остается предметом для составления дополнительной документации.

Постоянная необходимость изучать технический аспект работы Kerberos и причину возникновения ошибок обусловлена тем, что, хотя сама технология остается неизменной, использующие ее службы и способы ее применения часто уникальны. Однако в каждом сценарии постоянным остается назначение установочных параметров Active Directory (AD) и смысл сообщений об ошибках.

В этой статье я попытаюсь прояснить некоторые аспекты «самого непонятного диалогового окна в AD», каковым является вкладка «Делегирование» в окне свойств объекта оснастки Active Directory Users and Computers консоли управления Microsoft (MMC) (dsa.msc). Мы рассмотрим значения атрибутов для различных конфигураций. Понимание назначения установочных параметров позволит правильно выполнить настройку в AD приложений и служб, использующих делегирование Kerberos.

Простой интерфейс

Зачем тратить время на изучение «простого» интерфейса? Углубляться в детали необходимо, потому что понимание технического аспекта работы различных параметров позволит более успешно исправлять ошибки в их настройке. Поэтому начнем с постижения смысла установок. Если вы откроете оснастку Active Directory Users and Computers и перейдете к свойствам учетной записи компьютера, то увидите вкладку делегирования Delegation (при условии, что ваш лес находится на функциональном уровне Server 2003). Эта вкладка показана на экране 1. Для пояснения назначения переключателей этой вкладки на экране 2 предлагаются альтернативные имена, которые можно было бы им дать.

Экран 1. Вкладка Delegation

Экран 2. Имена, которые можно было бы дать переключателям на вкладке Delegation

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

Два верхних варианта («Не доверять компьютеру делегирование» и «Доверять компьютеру делегирование любых служб») на экране 1 не требуют разъяснений. Третий вариант – это ограниченное делегирование Kerberos Constrained Delegation (KCD), практически аналогичное простому делегированию, но оно предусматривает делегирование олицетворяемого удостоверения только указанным службам или компьютерам. Этот вариант обеспечивает более высокий уровень безопасности, ограничивая сферу делегирования идентичности олицетворяемого пользователя, так что в случае компрометации служебного удостоверения, доверенного для делегирования, последствия ограничиваются способностью получать доступ лишь к тем ресурсам на удаленных серверах, которые выбраны вручную для ограниченного делегирования.

Четвертый вариант на экране 1 разрешает KCD и расширение Services for User (или S4U). Расширение S4U предусматривает более широкие функции, например смену протокола. Смена протокола происходит тогда, когда клиент сначала выполняет аутентификацию по протоколу, отличному от Kerberos, при входящем подключении, а затем переключается на Kerberos. Подробное описание S4U содержится в документации «Exploring S4U Kerberos Extensions in Windows Server 2003» (msdn.microsoft.com/en-us/magazine/cc188757.aspx) и «Protocol Transition with Constrained Delegation Technical Supplement» (msdn.microsoft.com/en-us/library/ff650469.aspx). Эти ресурсы ориентированы на программистов, а не на администраторов, но для администратора также важно понимать, что такое S4U, как выполнять его настройку и когда следует его использовать. Для этой цели приведем предназначенный для администратора краткий список возможностей S4U.

-Получение информации о маркере пользователя без фактического получения этого маркера и без получения доверенной службой билета предоставления билета ticket-granting ticket (TGT) от доверяющего пользователя или доступа к учетным данным. Полученная информация затем может использоваться, например, для проверок авторизации. Это расширение известно как Services-For-User-To-Self (S4U2Self).

-Получение билетов без необходимости получения служебного билета Kerberos, без доступа к учетным данным, передачи TGT или вообще без аутентификации — Services-For-User-To-Proxy (S4U2Proxy).

-Выполнение упомянутой ранее смены протокола. Клиент, обращающийся к корпоративной службе, изначально выполняет аутентификацию с использованием метода, отличного от Kerberos, а S4U позволяет доверенной службе переключать сеанс пользователя, уже прошедшего аутентификацию, на использование Kerberos. Именно здесь чаще всего случаются отказы, вызванные ошибками конфигурации, поскольку документация приложений часто не содержит четких пояснений относительно того, нужна ли смена протокола и как выполнить ее настройку в AD. Однако эта тема актуальна, поскольку сегодня практически ни одна статья не обходится без упоминания «облака». Клиенты, подключающиеся через «облако», чаще всего будут применять NTLM-аутентификацию из-за отсутствия контроллеров домена (DC), обрабатывающих запросы о выдаче служебного билета Kerberos по Интернету. Смена протокола позволяет пользователю данного домена подключаться через программное обеспечение сетевого экрана или прокси-сервера с помощью одного из методов аутентификации (например, NTLM), а затем переключаться на аутентификацию Kerberos для выполнения дальнейших действий внутри корпоративной сети. Поскольку «облако» означает подключение через Интернет, можете не сомневаться, что если вы используете какое-либо «облачное» решение, то рано или поздно вы придете к применению смены протокола Kerberos.

Под внешней оболочкой

Теперь рассмотрим, что фактически происходит при установке каждого из этих четырех параметров, с помощью LDP просматривая значения атрибутов, установленных для каждой из конфигураций. LDP устанавливается с ролью доменных служб AD по умолчанию и может использоваться как инструмент обработки запросов LDAP с графическим интерфейсом. LDP позволяет строить собственные запросы LDAP и просматривать результаты в удобном для восприятия виде. Дополнительное преимущество применения LDP для просмотра значений атрибутов (например, userAccountControl) заключается в переводе вычисленных значений параметров в удобочитаемую форму вместо комбинации чисел. Кстати, более поздние версии adsiedit.msc также предусматривают подобную обработку вычисленных значений параметров.

Таким образом, в Windows Server 2008 и более новых версиях ldp.exe и adsiedit.msc предусматривают автоматический перевод значений атрибутов (например, userAccountControl), что избавляет от необходимости открывать calc.exe и обращаться к онлайн-документации по MSDN или к базе знаний Microsoft.

Теперь рассмотрим изменение значений атрибутов в LDP в зависимости от выполненных установок. Начнем с учетной записи, не являющейся доверенной для делегирования. На экране 3 видно, что учетная запись Test2 не является доверенной и что шестнадцатеричное значение 1020 атрибута userAccountControl (соответствует десятичному 4128) переведено в WORKSTATION_TRUST_ACCOUNT и PASSWD_NOTREQD.

Экран 3. Учетная запись, не доверенная для?делегирования

На экране 4 показана учетная запись, доверенная для делегирования. Мы можем видеть значение атрибута userAccountControl, переведенное в TRUSTED_FOR_DELEGATION, указывающее на разрешение простого неограниченного делегирования Kerberos данному служебному удостоверению.

Экран 2. Учетная запись, доверенная для делегирования

Доверие делегирования определенным службам

Следующие установки имеют решающее значение, если предполагается использовать S4U или KCD. Первый случай соответствует выбору варианта Trust this computer for delegation to specified services only («Доверять этому компьютеру делегирование только указанных служб») и Use Kerberos only («Использовать только Kerberos»). На экране 5 видно, что при таком выборе атрибут userAccountControl вновь получает WORKSTATION_TRUST_ACCOUNT, а атрибут MsDS-AllowedToDelegateTo автоматически заполняется выбранными службами, которым разрешено делегирование. Никакой другой процедурой этот атрибут не заполняется и не затрагивается. В качестве записей перечислены определенные службы на компьютере, для которых разрешено делегирование.

Экран 5. Учетная запись, доверенная только для Kerberos

Второй вариант – менее безопасный — Use any authentication protocol («Использовать любой протокол для аутентификации»), разрешающий смену протокола и другие варианты расширений. Помимо записей у атрибута MsDS-AllowedToDelegateTo, эта установка меняет атрибут userAccountControl, который получает TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D), как показано на экране 6. Без флага T2A4D можно ожидать ошибки смены протокола. Никаким другим компонентом данный флаг не используется. Заметим, что этот простой переключатель чрезвычайно важен, поскольку, если он не выбран, то S4U2Self, S4U2Proxy и смена протокола будут вести себя по-разному, что может создать проблемы для приложений и служб, ожидающих соответствующие виды билетов. В частности, смена протокола завершится ошибкой, и билет выдан не будет. У S4U2Proxy и S4U2Self будет отсутствовать флаг forwardable (перенаправление), что приведет к ошибке: для S4U2Proxy – в любом случае, а для S4U2Self – в ситуациях, когда понадобится послать билет другой службе или узлу.

Экран 6. Учетная запись, доверенная для любого метода аутентификации

«Сделай сам»

Что произойдет, если служебная учетная запись службы, используемая приложением или службой, должна будет выполнить действие, требующее смены протокола, а на вкладке Delegation будет задана установка Use Kerberos only («Использовать только Kerberos») вместо Use any authentication protocol («Использовать любой протокол аутентификации»)? Для приложения клиента ошибка может принять форму Access Denied («Отказано в доступе») при попытке получения доступа к ресурсам по сети, или может возникнуть ошибка без уведомления NTLM-аутентификации, либо неожиданная зависящая от приложения ошибка. Неопределенность формы проявления ошибки еще больше усложняет задачу. Наиболее вероятным результатом, однако, будет Access Denied («Отказано в доступе»). В такой ситуации обязательно изучите документацию приложения или службы и выясните, не говорится ли там о том, что будут иметь место смена протокола или запросы на получение билета со стороны службы без TGT. Проблема в том, что большинство составителей документации по-настоящему не понимают смысла конфигурации KCD и поэтому дают недостаточные пояснения, либо вообще обходятся без них.

Методом выяснения причин ошибки по принципу «сделай сам» может стать простой сбор данных сетевой трассировки с сервера, доверенного для делегирования. Собранные данные отфильтруйте по Kerberos (Kerberosv5 в Microsoft Network Monitor или kerberos в Wireshark). Запрос службы на выдачу билета (TGS_REQ) передается в центр распределения ключей Kerberos Distribution Center (KDC) AD и содержит параметры KDC с установленным флагом ограниченного делегирования. При отказе в выдаче билета ответ сервера (TGS_REP) будет содержать ошибку KDC_ERR_BAD_OPTION, которую легко заметить в результатах сетевой трассировки.

Более подробную информацию о работе реализаций Microsoft Kerberos можно найти в онлайн-спецификации открытых протоколов. «Kerberos Protocol Extensions» (msdn.microsoft.com/en-us/library/cc233855%28v=PROT.13%29.aspx) содержит общую документацию по Kerberos, а «Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification» (msdn.microsoft.com/en-us/library/cc246071%28v=PROT.13%29.aspx) – документацию об ограниченном делегировании Kerberos и S4U.

Идеальный мир

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