Запрошенная операция не может быть завершена компьютер должен иметь доверие для делегирования

Обновлено: 07.07.2024

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

Учетные записи компьютеров, также, как и учетные записи пользователей, являются участниками безопасности домена. Каждому участнику безопасности автоматически присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к ресурсам домена.

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

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

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

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

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

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

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

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

Пользователи и компьютеры Active Directory

Это самый простой, но не самый быстрый и удобный способ. Открываем на любом контроллере домена оснастку Пользователи и компьютеры Active Directory, находим необходимую учетную запись компьютера и, щелкнув правой кнопкой мыши, выбираем Переустановить учетную запись.

Затем входим на потерявшем доверительные отношения компьютере под локальным администратором и выводим машину из домена.

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

Недостаток этого способа, что машину требуется выводить из домена, а также необходимость двух (одной) перезагрузки.

Утилита Netdom

Данная утилита входит в состав Windows Server начиная с редакции 2008, на пользовательские ПК ее можно установить из состава пакета RSAT (Средства удаленного администрирования сервера). Для ее использования войдите на целевой системе локальным администратором и выполните команду:

Разберем опции команды:

Server - имя любого доменного контроллера
UserD - имя учетной записи администратора домена
PasswordD - пароль администратора домена

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

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

Server - имя любого контроллера домена
Credential - имя домена / учетной записи администратора домена

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

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

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

Справочники

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

Только администраторы, которым можно доверять учетным данным компьютера и пользователей, могут настроить делегирования. Администраторы домена и Enterprise администраторы имеют эти учетные данные. Процедура, позволяющая доверять пользователю для делегирования, зависит от уровня функциональности домена.

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

Возможные значения

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

Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Значения по умолчанию

В следующей таблице перечислены фактические и эффективные значения политики по умолчанию для последних поддерживаемых версий Windows. Значения по умолчанию также можно найти на странице свойств политики.

Тип сервера или объект групповой политики	Значение по умолчанию
Default Domain Policy	Не определено
Политика контроллера домена по умолчанию	Не определено
Параметры по умолчанию для автономного сервера	Не определено
Действующие параметры по умолчанию для контроллера домена	Администраторы
Действующие параметры по умолчанию для рядового сервера	Администраторы
Действующие параметры по умолчанию для клиентского компьютера	Администраторы

Управление политикой

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

Изменение этого параметра может повлиять на совместимость с клиентами, службами и приложениями.

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

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.

Групповая политика

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

Параметры применяются в следующем порядке с помощью объекта групповой политики (GPO), который перезаписывал параметры на локальном компьютере при следующем обновлении групповой политики:

Параметры локальной политики
Параметры политики сайта
Параметры политики домена
Параметры политики подразделения

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

Дополнительные сведения о настройке политики можно найти здесь.

Вопросы безопасности

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

Уязвимость

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

Противодействие

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

Примечание: Нет причин назначать это право пользователю любому пользователю на серверах-членах и рабочих станциях, принадлежащих домену, так как оно не имеет смысла в этих контекстах. Она актуальна только для контроллеров домена и автономных компьютеров.

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

Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.

Способ первый

Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.

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

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

Способ второй

Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:

Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*

где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.

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

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

Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:

Или сбросить учетную запись компьютера:

где WKS1 — рабочая станция, которой сбрасываем учетку.

Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).

Способ третий

Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:

Nltest /query — проверить безопасное соединение с доменом;

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

Способ четвертый

PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.

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

Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair

где SRV1 — контролер домена (указывать не обязательно).

Для сброса пароля также можно также воспользоваться такой командой:

Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator

Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.

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

Изменение параметров смены пароля компьютера

Смена пароля в домене происходит следующим образом:

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

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

Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:

Disable machine account password change — отключает на локальной машине запрос на изменение пароля;

Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;

Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.

Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :

DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.

MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней .

И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters , только у контролеров домена, параметр:

RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.

Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.

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

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

В этой статье я попытаюсь прояснить некоторые аспекты «самого непонятного диалогового окна в 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), практически аналогичное простому делегированию, но оно предусматривает делегирование олицетворяемого удостоверения только указанным службам или компьютерам. Этот вариант обеспечивает более высокий уровень безопасности, ограничивая сферу делегирования идентичности олицетворяемого пользователя, так что в случае компрометации служебного удостоверения, доверенного для делегирования, последствия ограничиваются способностью получать доступ лишь к тем ресурсам на удаленных серверах, которые выбраны вручную для ограниченного делегирования.

-Получение информации о маркере пользователя без фактического получения этого маркера и без получения доверенной службой билета предоставления билета 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, которую легко заметить в результатах сетевой трассировки.

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

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

Читайте также: