1с до данного пользователя нет доступных ролей. Самое непонятное диалоговое окно в Active Directory

29.10.2012 Тим Спрингстон

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

Тим Спрингстон ([email protected]) – старший инженер службы технической поддержки подразделения 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 предлагаются альтернативные имена, которые можно было бы им дать.

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

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

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

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

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

«Сделай сам»

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

2 ответов

решаемые.

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

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

Концептуальная модель была построена с помощью EdmxWriter для синтаксического анализа DbContext и ее основных частей.

Затем модель была использована для генерации сценариев SQL для перевода схемы в новую базу данных. Фокус в том, что база данных - это Oracle.

Oracle - ребенок и не принимает длинные имена столбцов. Таким образом, сгенерированные сценарии EDMX и SQL пришлось модифицировать, чтобы создавать и сопоставлять части концептуальной модели с укороченными именами столбцов.

Не очень большое дело. Он работает нормально. Так где же все пошло не так?

Oracle не поддерживает "код сначала". И хотя это было сделано вручную, использование EdmxWriter представляет собой кодовый подход в Oracle. Поэтому, когда была разобрана первая схема EDMX, она бинала о логических сопоставлениях. Решение заключалось в том, чтобы временно удалить bools из моих моделей С#, добавить их в EDMX вручную и сделать отображение web.config Oracle (сопоставление bool до NUMBER(1,0)).

Все снова groovy. Но почему он продолжает повторяться?

В разное время на протяжении всего процесса разработки некоторые концы соглашения - либо С#, EDMX, либо Oracle - изменяются. И каждый раз, кажется, столбцы были автоматически переназначены, и я не знал. Если модель EDMX была обновлена от Oracle, сопоставления указывали на свойства С#, которых не было (короткие имена столбцов). Если модель была обновлена из кода С#, сопоставления не сохранялись, и они пытались сопоставить длинные имена столбцов, которые не были в Oracle.

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

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

На таком сайте «живут» 3 роли со своими правами и обязанностями:

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

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

3. Администратор

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

Как тестируем и на что обращаем внимание?

В первую очередь постараемся не удалить «Супер-админа», играясь с настройками.

Создаем безопасного персонажа

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

Проверяем в нескольких браузерах

Делаем одновременно: в одном изменяем ПД, в другом проверяем применение прав для юзера, таким образом разделяя пользовательские сессии.

Проходим по прямой ссылке

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

Тестируем блокировку сущностей

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

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

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

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

Используем тестовую матрицу

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

А вот и простейший пример тестовой матрицы:

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