Одна из малоизвестных функций служб Active Directory Domain Services (AD DS) в Windows Server 2012 — проверка подлинности на основе утверждений. Однако неизвестность не умаляет важности этой функции для будущего Active Directory (AD) и взаимодействия AD с многочисленными веб-службами.

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

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

Утверждения появились в Windows вместе со службами Active Directory Federation Services (ADFS), коннектором для внешних веб-служб. В версиях, предшествующих Server 2012, службы ADFS формировали утверждения из групп безопасности AD и запросов LDAP, посылаемых в AD. В Server 2012 службы ADFS 2.1 получают утверждения напрямую из AD. Первое время я описывал ADFS как технологию, не имеющую применения в бизнесе, поскольку в то время практически не было необходимости в проверке подлинности на основе утверждений в мире Windows. Однако ситуация изменилась с развитием «облачных» служб и в особенности SaaS. Федеративные службы, как локальные (ADFS), так и размещенные в «облаке» (управление идентичностями), обеспечивают шлюз между миром AD с Kerberos и миром веб-служб с утверждениями.

Утверждения введены в AD специально для динамического управления доступом и условных выражений в списках ACL файловых служб. Как уже отмечалось, утверждения также востребованы службами ADFS 2.1. Поэтому для реализации динамического управления доступом, ADFS 2.1 или условных выражений для управления доступом к данным на файловых серверах Windows необходимо внедрить утверждения AD. Server 2012 AD поддерживает утверждения как пользователя, так и устройства.

Принципы архитектуры утверждений Active Directory

В результате обновления схемы для Active Directory в Server 2012 появилось несколько новых объектов классов:

  • msDS-ValueType;
  • msDS-ClaimTypePropertyBase;
  • msDS-ClaimType;
  • msDS-ResourceProperty;
  • msDS-ResourcePropertyList;
  • msDS-ClaimsTransformationPolicyType.

Централизованные политики доступа (и составляющие их правила), используемые в процессе динамического управления доступом, поддерживаются следующими объектами классов:

  • msAuthz-CentralAccessRule;
  • msAuthz-CentralAccessPolicy.

Утверждения, сформированные в AD, хранятся в разделе Configuration, под CN=Services,CN=Claims Configuration (экран 1).

 

Созданные в AD заявки хранятся в разделе Configuration
Экран 1. Созданные в AD заявки хранятся в разделе Configuration

Как утверждения попадают из AD к клиенту? Через Kerberos, стандартный протокол проверки подлинности и авторизации, используемый в Windows. Kerberos — самое логичное место для вставки утверждений; в противном случае пришлось бы разработать второй протокол безопасности в системе безопасности Windows (задача немалого масштаба).

Тот, кто знаком с протоколом Kerberos, знает, что единственное место, в которое можно поместить такие данные (то есть утверждения) — сертификат привилегированной учетной записи Privilege Account Certificate (PAC). PAC — элемент расширения поля данных авторизации, содержащегося в билете предоставления билета ticket-granting ticket (TGT) Kerberos клиента. Структура PAC передает данные авторизации, предоставляемые контроллерами домена клиентам Windows. В версиях, предшествующих Server 2012, PAC содержал такую информацию, как идентификатор SID, членство в группах (также в формате SID), профиль пользователя и пароль.

В Server 2012 к указанной выше информации о безопасности добавились утверждения пользователя и устройства. Возможно, вас беспокоит увеличение числа токенов Kerberos: Microsoft добавляет все больше данных в PAC, в то время как большие компании уже сталкиваются с ограничениями хранилища PAC. Microsoft решает эту проблему несколькими способами. Так, MaxTokenSize (величина буфера, выделенного для хранения данных авторизации) вырос с 12 Кбайт в предшествующих версиях до 48 Кбайт в Server 2012, что поможет исключить сбои авторизации в таких приложениях, как Microsoft IIS. Существует также параметр групповой политики, предупреждающий о билетах Kerberos.

Наконец, в Server 2012 применяется сжатие SID, очевидное усовершенствование для экономии пространства PAC. Подробнее о сжатии SID я еще буду рассказывать в своих статьях.

Почему не все атрибуты AD автоматически представляются в утверждениях? Простейшее объяснение: если каждый задействованный атрибут объекта пользователя или устройства будет доступным как утверждение, то эти утверждения войдут в Kerberos PAC независимо от того, применяются они или нет. А большинство не используется, поэтому такое решение привело бы к увеличению числа избыточных данных. Гораздо более аккуратное решение — определить атрибуты, которые необходимо сделать доступными в качестве утверждений, в зависимости от условных выражений и требований динамического управления доступом, а затем создать для них типы утверждений.

Файловые службы и службы хранилища Windows Server 2012 — единственная роль сервера, в которой используется управление доступом на основе утверждений в первой реализации этой технологии, хотя нет сомнений, что в будущих версиях операционной системы управление доступом на основе утверждений появится и в других ролях. Windows 8 в меньшей степени представляет интерес для администраторов серверов, но в ней также используется управление доступом на основе утверждений (об этом чуть ниже).

Реализация утверждений

Чтобы задействовать утверждения в Server 2012 AD, необходимо сделать несколько шагов.

Прежде всего, необходимо обновить схему леса до уровня Server 2012. Это можно сделать вручную с помощью утилиты Adprep, но Microsoft настоятельно рекомендует добавить роль AD DS в новый сервер Server 2012 или обновить существующий контроллер домена до уровня Server 2012. Этот процесс автоматически выполняет все необходимые операции Adprep (подробнее об этом рассказано в статье «Упрощение обновления и развертывания Active Directory в Windows Server 2012», опубликованной в Windows IT Pro/RE № 1 за 2013 год).

Обеспечив поддержку утверждений в AD, необходимо включить их через групповую политику.

  1. Из экрана Start на компьютере с правами администратора AD откройте Group Policy Management и затем организационную единицу (OU) Domain Controllers в домене, в котором нужно включить утверждения.
  2. Щелкните правой кнопкой мыши Default Domain Controllers Policy и выберите Edit.
  3. В окне редактирования перейдите к Computer Configuration, Policies, Administrative Templates, System, KDC (Key Distribution Center).
  4. Откройте KDC support for claims, compound authentication, and Kerberos armoring.
  5. Выберите переключатель Enabled. Для соответствующих параметров будет отображен режим Supported (экран 2).

 

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

Обратите внимание, что для этой политики существует четыре параметра, в порядке расширения возможностей управления: Not Supported, Supported, Always Provide Claims, and Fail unarmored authentication requests. Прежде чем настраивать эту политику, рекомендуется ознакомиться со статьей «Dynamic Access Control: Scenario Overview» (http://technet.microsoft.com/en-us/library/hh831717.aspx).

После того, как политика включена и реплицирована на все контроллеры Server 2012 в домене, необходимо создать типы утверждений. Для этого запустите Active Directory Administrative Center (экран 3).

 

Создание типа заявок в Active Directory Administrative Center
Экран 3. Создание типа заявок в Active Directory Administrative Center

Он похож на Active Directory Users and Computers, но центр администрирования Active Directory также располагает элементом для динамического управления доступом (в дополнение к домену deuby) на левой стороне панели навигации. Выберите динамическое управление доступом, а затем типы утверждений, чтобы вывести на экран типы утверждений AD (экран 4). На экране 4 показаны два ранее созданных типа утверждений.

 

Просмотр созданных типов заявок
Экран 4. Просмотр созданных типов заявок

Нажимая New («Создать») на панели задач справа, можно вывести на экран диалоговое окно Create Claim Type (экран 5).

 

Диалоговое окно создания новой заявки
Экран 5. Диалоговое окно создания новой заявки

В разделе Source Attribute отображается список атрибутов, которые могут быть представлены утверждениями. Windows создает список атрибутов из следующих объектов класса схемы:

  • User;
  • InetOrgPerson;
  • Computer;
  • ManagedServiceAccount;
  • GroupManagedServiceAccount.

По умолчанию диалоговое окно Create Claim Type показывает атрибут accountExpires, так как это первый атрибут в списке. Обратите внимание, что отображаемое имя и описание показаны справа; эти поля можно изменить, сделав их более информативными.

В качестве примера можно создать третий тип утверждения, связанный с фамилией пользователя. Код атрибута AD для фамилии — surname, отображаемое имя — sn. Ввод фамилии в поле фильтра позволяет получить этот атрибут (экран 6). Для данного примера отображаемое имя типа утверждения было заменено более удобным: Last Name.

 

Поиск отображаемого имени для атрибута заявки
Экран 6. Поиск отображаемого имени для атрибута заявки

Наконец, после нажатия кнопки OK, выводится диалоговое окно Active Directory Administrative Center с новым типом утверждения (экран 7).

 

Добавление новой заявки
Экран 7. Добавление новой заявки

Как отмечалось выше, в Server 2012 и Windows 8 можно использовать условные выражения с утверждениями, чтобы обеспечить управление доступом к папкам с высоким уровнем детализации.

На экране 8 показано, как созданные типы утверждений могут применяться в диалоговом окне безопасности для изменения доступа к config.bgi в зависимости от компании, отделения или фамилии (в дополнение к членству в группе). Таким образом, мы видим, как в Server 2012 можно управлять доступом к файлам и папкам непосредственно с помощью атрибутов AD.

 

Использование вновь созданных типов заявок для изменения разрешений доступа
Экран 8. Использование вновь созданных типов заявок для изменения разрешений доступа

Использование проверки подлинности на основе утверждений

Утверждения — малоизвестный элемент AD DS в Server 2012. Они встроены в динамическое управление доступом, но с их помощью можно упростить управление доступом к файловому серверу Windows, не внедряя динамическое управление. О принципах управления доступом на основе утверждений я расскажу в следующей статье.