К основному контенту

Технология Dynamic Access Control в Windows Server 2012 (часть 2)

В предыдущей статье мы рассмотрели теоретические аспекты технологии Dynamic Access Control. Настало время перейти к практике, поэтому сегодня мы рассмотрим настройку динамического контроля доступа для ограничения доступа к файловому ресурсу.

Перед развертыванием Dynamic Access Control в организации необходимо учесть некоторые требования.

Доменные службы Active Directory

В первую очередь для Dynamic Access Control обязательно наличие домена Active Directory. Функциональный уровень домена не влияет на возможность использования DAC, хотя от него и зависят некоторые нюансы, о которых я расскажу чуть позже.

Контроллеры домена

Если в домене включена поддержка утверждений, то при аутентификации клиент, их поддерживающий, ищет домен-контроллер, который ему эти утверждения предоставит. Поэтому необходимо наличие в домене хотя бы одного доступного домен-контроллера Windows Server 2012.

Также стоит иметь в виду, что клиент осуществляет поиск «правильного» контроллера домена путем последовательного перебора имеющихся в наличии контроллеров, до тех пор пока не найдет нужный. Если в организации недостаточное количество контроллеров Windows Server 2012, то поиск может занять определенное время, из за чего неизбежно увеличится задержка при входе пользователя в систему. Этот момент надо учитывать при планировании DAC в организации.

И отдельно стоит упомянуть о домен-контроллерах только для чтения (RODC). Хотя RODC Windows Server 2012 и поддерживают утверждения, однако все запросы на аутентификацию с их использованием пересылают на полноценный контроллер домена Windows Server 2012.

Файловый сервер

Применять утверждения можно только к файлам, хранящимся на файловых серверах Windows Server 2012.

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

Это значит, что компоненты файл-сервера, такие как локальная система безопасности (LSA) и клиент Kerberos, должны поддерживать утверждения. Поэтому наличие файлового сервера Windows Server 2012 — еще одно обязательное требование для развертывания DAC.

Клиентский компьютер

Из клиентских операционных систем утверждения поддерживает пока только Windows 8. Однако это вовсе не означает, что DAC нельзя использовать с более ранними операционными системами, например Windows 7 или XP.

В том случае, если клиент, не поддерживающий утверждения, пытается получить доступ к файловому ресурсу с поддержкой утверждений, файловый сервер может сам обратиться к службе KDC и от своего имени запросить для клиента необходимую информацию. Эта технология носит название S4UToSelf (Service-for-User-To-Self) и является расширением протокола Kerberos.

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

Включение поддержки утверждений

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

Чтобы активировать поддержку новых возможностей на контроллерах домена, надо открыть Default Domain Controllers Policy, в разделе Computer configuration\Policies\Administrative Templates\System\KDC выбрать параметр «KDC support for claims, compound authentication and Kerberos armoring» и поставить переключатель в положение Enabled. После этого надо выбрать одно из четырех значений:

• Not Supported (Не поддерживается) — значение по умолчанию, при котором контроллеры домена не объявляют о том, что домен поддерживает утверждения, комплексные удостоверения и технология FAST. То же самое действие производится при не сконфигурированной (Not Configured) или выключенной (Disabled) политике;
• Supported (Поддерживается) — при выборе этого значения все контроллеры домена информируют клиентов о поддержке утверждений, комплексных удостоверений и технологии FAST. Это значение считается универсальным и не зависит от уровня функционирования домена;

Следующие значения работают только при функциональном уровне домена Widnows Server 2012. Если уровень домена ниже, то эти параметры будут проигнорированы и политика отработает как при значении Supported:

• Always provide claims (Всегда поддерживать утверждения) — при этом значении KDC будет всегда предоставлять утверждения для клиентов (которые это поддерживают) вне зависимости от их настроек;
• Fail unarmored authentication request (Отклонять незащищенные запросы на проверку подлинности) — в этом случае контроллеры домена в обязательном порядке будут требовать защищенного соединения для аутентификации пользователя. При этом все клиенты, не поддерживающие технологию FAST, не смогут аутентифицироваться в домене.


включение поддержки claims для контроллеров домена

И для включения поддержки утверждений клиентами надо открыть Default Domain Policy, перейти в раздел Computer configuration\Policies\Administrative Templates\System\Kerberos и открыть параметр «Kerberos client support for claims, compound authentication and Kerberos armoring». Здесь всего два значения — включено (Enabled) или отключено (Disabled). Включение данной политики означает, что те клиенты, которые это поддерживают, будут при аутентификации в домене запрашивать клаймы и использовать технологию FAST.


включение поддержки claims для клиентов

Планирование

Настройка DAC производится из оснастки Active Directory Administrative Center. Открыть ее можно из меню Tools в Server Manager, либо командой dsac. Все шаги по настройке по пунктам расписаны прямо на главной странице Administrative Center.


Active Directory Administrative Center

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

1) Находятся в г. Москва;
2) Работают в центральном офисе компании;
3) Принадлежат к отделу управления или продаж.

Открываем свойства пользователя, переходим в раздел Organization и находим соответствующие атрибуты. Итак, наша задача дать доступ тем пользователям, у которых атрибут Sity имеет значение Moscow, атрибут Office имеет значение Central, а атрибут Department может иметь значение Management или Sales.


атрибуты пользователя

Создание утверждений

Определившись с критериями отбора, идем создавать утверждения для пользователей. Переключаем режим просмотра «Tree View», открываем раздел Dynamic Access Control и переходим к подразделу Claim Type (Типы утверждений).  Кликаем правой клавишей мыши в поле и в открывшемся меню выбираем пункт New – Claim Type.


создание нового утверждения

Поскольку утверждения базируются на атрибутах пользователя (или компьютера), то нам нужно выбрать в поле Source Attribute (Атрибут источника) необходимые атрибуты. Обратите внимание, что атрибуты пользователя, показанные в графической оснастке, не всегда соответствуют названиям атрибутов схемы AD. Посмотреть их соответствие можно на странице User Object User Interface Mapping на сайте MSDN. Для нашего случая я выбрал следующие атрибуты:

l — Sity
phisicalDeliveryOfficeName — Office
department — Department

В поле «Display Name» для каждого утверждения вводим понятное название, под которым оно будет отображаться в списке утверждений, а в поле «Description» можно добавить его описание.

Также есть некоторые дополнительные опции, о которых стоит упомянуть:

• Claims of this type can be issued for the following class — определяет, к какому типу объектов относится данный тип утверждения: только к пользователям (User),  только к компьютерам (Computer), либо к обоим типам учетных записей.
• Set ID to a semanticaly identical claim type in a trusted forest — опция, предназначенная для определения метода создания идентификатора типа утверждения. Если не устанавливать флаг, то идентификатор будет назначен автоматически. Формируется он следующим образом: стандартное начало идентификатора ad://ext, затем имя выбранного атрибута и после двоеточия случайное число в шестнадцатеричном формате. В результате получается что то вроде этого: ad://ext/Department: 88d068e84e256c9f.
Если вы создаете утверждения для разных лесов, связанных доверительными отношениями, то по умолчанию метаданные для каждого типа утверждений будут созданы уникальными для каждого леса, в следствие чего контроллеры домена доверяющего леса не смогут обработать утверждения из доверенного леса. В этом случае и нужен данный параметр. Однако создавая идентификатор вручную помните, что он должен соответствовать указанному формату — иметь стандартное начало, состоять из не более чем 32 символов, не содержать в названии спец. символов и не заканчиваться обратным слешем. Кроме того, такие идентификаторы обязательно должны быть уникальными.
• Protect from accidental deletion — служит для защиты утверждения от случайного удаления. Флаг этот стоит по умолчанию, и для того чтобы удалить какое либо утверждение его надо предварительно снять.


выбор атрибутов для утверждения

Перейдя в секцию под названием Suggested Values (Предложенные значения), мы можем для  утверждения задать набор предопределенных значений. По умолчанию для всех типов утверждений значения не предопределены, т.е. предполагается, что эти значения будут задаваться вручную при создании условных выражений. Однако есть возможность изменить подобное поведение, для чего надо выбрать утверждение, включить для него опцию «The following value are suggested» и с помощью кнопки Add добавить необходимые значения.

Как видите, в нашем случае я взял утверждение Department и задал для него два предопределенных значения: Management и Sales.


предопределенные значения для утверждений

Добавление значений происходит следующим образом: при нажатии кнопки Add открывается окно, в котором надо ввести значение (Value), имя (Display Name) и описание (Description) для каждого предопределенного значения.


создание предопределенных значений

Итак, в результате у нас получилось три утверждения — Department, Office и Sity. При необходимости мы можем отредактировать их, удалить (предварительно сняв защиту) или отключить. Отключенное утверждение так и останется со всеми своими настройками, но использовать его мы не сможем. Все вновь созданные утверждения включены по умолчанию, отключить их можно, кликнув правой клавишей мыши и выбрав из контекстного меню пункт Disable.


управление утверждениями

И несколько слов о PowerShell. Если вы раскроете секцию Windows PowerShell History, скрытую внизу, то найдете все команды PowerShell, с помощью которых производились операции с клаймами. Их можно скопировать и использовать при написании скриптов.


PowerShell History

Создание свойств ресурсов

Переходим  раздел Resource Properties и приступаем к созданию свойств ресурсов. Здесь уже есть некоторое количество готовых свойств. По умолчанию они не активны, для их включения надо выбрать нужное свойство и в поле Tasks нажать «Enable». Однако мы не ищем легких путей, поэтому не будем использовать готовые свойства, а создадим свои. Для этого в поле Tasks выбираем пункт New – Resource Property.


создание свойств ресурсов

Даем название свойству, затем выбираем тип данных (Value Type), который это свойство может принимать. В качестве типа можно указать:

• Single-valued Choice — свойство может принимать одно единственное значение;
• Multi-valued Choice — свойство может принимать разные значения;
• Ordered List —  свойство может принимать значения из упорядоченного списка;
• Number — свойство может принимать числовое значение;
• Text — свойство может принимать текстовое значение;
• Multi-Valued Text — свойство может принимать одно из нескольких текстовых значений;
• Date Time — свойство представляет из себя дату и время. Этот тип нельзя использовать для ограничения доступа к ресурсу;
• Yes\No — свойство представляет из себя булево значение типа True или False.

Дополнительные опции:

• Set ID to a semanticaly identical claim type in a trusted forest — так же как и для клаймов, эта опция отвечает за определения метода создания идентификатора, автоматически или вручную;
• Is used for autorization — определяет, будет ли данное свойство использоваться в условных выражениях для ограничения доступа к ресурсам. Для каждого создаваемого свойства объекта (кроме свойств типа Date Time) включена по умолчанию;
• Protect from accidental deletion — защита от случайного удаления. Флаг этот стоит по умолчанию, и чтобы удалить свойство ресурса, предварительно надо его снять.

Если в качестве типа свойства ресурса выбрано Single-Valued Choice, Multi-Valued Choice или Ordered List, то для них можно указать предопределенные значения. Для этого надо в поле Suggested Values нажать кнопку Add и в открывшемся окне ввести имя и значение.

Для нашего примера создадим два свойства — Sity и Office. Укажем для Sity предопределенное значение Moscow, а для Office значение Central.


настройка свойств ресурсов

Выбрав в меню пункт Reference Resource Properties, можно создать свойства ресурсов ссылочного типа. Эти свойства базируются на готовых утверждениях, имеющих предопределенные свойства. На предыдущем этапе мы как раз создали одно такое утверждение по имени Department. Теперь выберем его из списка, сопоставим с создаваемым свойством ресурса и назовем это свойство Departments.


настройка ссылочных свойств ресурсов

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


создание списка

Обзовем наш список Managenent and Sales Documents, чтобы было понятно для чего он предназначен. Затем жмем по кнопке Add и добавляем в список нужные свойства ресурсов.


добавление в список свойств ресурсов

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


выбор свойств ресурсов

Классификация файлов

Итак, мы создали нужные свойства объектов и объединили их в список. Теперь применим этот список к файловому серверу, то есть произведем классификацию файлов. Переходим на файловый сервер, запускаем консоль PowerShell  и обновляем классификацию файлов на сервере командой:

Update-FSRMClassificationPropertyDefinition

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


классификация объектов

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


тоже классификация объектов

Создание правил доступа

Произведя классификацию, возвращаемся на контроллер домена. Теперь нам надо создать правила доступа к объектам, или Central Access Rule. Переходим в раздел Central Access Rule, кликаем правой клавишей в пустом поле и выбираем пункт New – Central Access Rule.


создание правил доступа

В поле Name указываем имя создаваемого правила, дополнительно в поле Description можно добавить его описание. Затем опускаемся в раздел Target Resources и жмем кнопку Add.