Заметки о Windows и других программных продуктах Microsoft...

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

Технология 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.

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

 

Здесь мы с помощью условных выражений должны описать свойства ресурсов, к которым будем ограничивать доступ. Для этого в левой части выбираем свойство ресурса, в правой указываем необходимое значение, а между ними ставим логический оператор. Например, свойство ресурса (Resource) Sity эквивалентно (Equals) значению (Value) Moscow.

Значения свойств выбираются из списка (если для них были заданы предопределенные значения), либо просто вводятся вручную. Если свойство может принимать несколько значений (Multi-valued Choice), то отмечаются все возможные значения.

Правило может состоять из нескольких условий, объединенных операторами И (And) и ИЛИ (Or). Кроме того, можно нажать на кнопку «Manage grouping», отметить 2 или более условий и сгруппировать их в одно большое условное выражение. При группировке нужно учитывать, что условия должны идти один за другим, то есть имея 3 условия можно сгруппировать между собой условия 1 и 2 или 2 и 3,  но нельзя группировать условия 1 и 3.

В примере (на рисунке ниже) я указал, что создаваемое правило будет ограничивать доступ к файлам, у которых свойство Sity имеет значение Moscow, свойство Office — значение Central, а свойство Department — значение Management или Sales.

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

 

Возвращаемся в предыдущее окно и переходим в раздел Permissions. Здесь есть два пункта:

• Use following permissions as proposed permissions — использовать следующие разрешения как предполагаемые разрешения. Эта опция позволяет выяснить, как  данное правило подействует на пользователей, не изменяя текущие разрешения. При этом доступ пользователя не будет ограничен, а все попытки доступа к объекту, подпадающие под правило, регистрируются в журнале событий;
• Use following permissions as current permissions — использовать следующие разрешения как текущие разрешения. В этом случае указаные в правиле разрешения добавляются в список доступа и определяют доступ к объекту.

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

переход к редактированию разрешений

 

Нам открывается список доступа. Для добавления в него новой записи жмем кнопку «Add».

базовые разрешения

 

В открывшемся окне кликаем на ссылку «Select a principal» и выбираем доменную группу, для которой будем настраивать разрешения. Microsoft в качестве хорошей практики рекомендует выбирать группу Authenticated Users (прошедшие проверку).

В поле «Type» выбираем тип записи — Allow (разрешение) или Deny (запрет). По возможности старайтесь не использовать прямых запретов, а все доступы назначать с помощью разрешающих правил.

В поле «Basic permissions» задаются стандартные разрешения NTFS, назначаемые выбраной группе. При необходимости более тонкой настройки можно раскрыть дополнительные разрешения, кликнув по ссылке «Show advanced permissions».

В примере я дал группе Authenticated Users разрешение Modify. Это значит, что любой пользователь, прошедший проверку подлинности в домене, имеет разрешение на изменение файлов.

А теперь переходим с помощью все тех же условных выражений ограничим круг пользователей, имеющих доступ. Для добавления выражений переходим ниже и жмем «Add a condition». Принцип такой же, как и для свойств ресурсов — слева указываем атрибут пользователя (или устройства), справа —  требуемое значение, между ними оператор. Также можно указывать несколько записей, объединять их с помощью операторов И (And) и ИЛИ (Or) и производить группировку, нажав «Manage grouping».

В результате у нас получилось следующее: разрешение на доступ к файлам имеют пользователи, входящие в группу Authenticated Users, у которых атрибут Sity имеет значение Moscow, атрибут Office имеет значение Central, а атрибут Department — значение Management или Sales.

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

 

Сохраняем разрешения и смотрим, как изменился список доступа.  Как видите, в нем появилось дополнительное поле Condition, в котором и находится созданное условное выражение.

разрешения с учетом утверждений

Создание центральной политики доступа

Следующий шаг — это создание центральной политики доступа (Central Access Policy, CAP). Переходим в раздел Central Access Policies, правый клик мышкой — New — Central Access Policy.

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

 

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

выбор правил для политики доступа

 

Дадим нашей политике имя Documents и сохраним ее, нажав OK. Теперь она будет храниться в разделе Central Access Policies, при необходимости ее можно открыть и отредактировать, добавив или удалив правило доступа.

настройка центральной политики доступа

Назначение центральной политики доступа

Политика доступа создана, надо распространить ее на файловые сервера. Делается это с помощью групповых политик. Открываем консоль управления групповыми политиками (Group Policy Management), создаем новый GPO и привязываем его к подразделению, в котором расположены файловые сервера. Затем открываем GPO на редактирование.

создание GPO

 

Переходим в раздел Computer Configuration\Policies\Windows Settings\Security Settings\File System\Central Access Policy. Кликаем правой клавишей и выбираем «Manage Central Access Policies».

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

 

В левом поле выбираем нашу политику Documents, кнопкой Add переносим ее вправо и жмем OK.

применение политики доступа

Аудит

Центральные политики доступа можно использовать не только для ограничения доступа, но и для аудита попыток доступа к файлам. Если вы хотите использовать эту возможность, то надо при создании правил доступа выбрать опцию Use following permissions as proposed permissions, а затем сконфигурировать настройки аудита в групповой политике.

Для включения аудита надо перейти в раздел Computer Configuration\Policies\Windows Settings\Advanced Audit Policy Configuration\Audit Policies\Object Access и активировать следующие параметры:

Audit File System — включает общий аудит попыток доступа к файловой системе;
Audit Central Access Policy Staging — регистрирует все попытки доступа, подпадающие под планируемую центральную политику доступа, отличающуюся от текущей. Успешное событие (Success) генерируется в том случае, если текущая политика разрешает доступ, а планируемая запрещает, а отказ (Failure) — в случае если текущая запрещает доступ, а планируемая разрешает.

включение аудита файловой системы

 

Затем надо перейти в раздел Global Object Access Auditing, выбрать параметр File System и сконфигурировать настройки аудита: выбрать группу пользователей, для которых будет вестись аудит, указать отслеживаемый тип события и уровень разрешений. Кроме того, для задания параметров пользователей и ресурсов можно использовать условные выражения.

настройка аудита

 

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

Применение политики

Остается только применить созданную политику к файловому ресурсу. Заходим на файловый сервер и обновляем групповые политики командой gpupdate /force. Затем открываем свойства папки и переходим к расширенным настройкам безопасности. После применения GPO в них должна появиться вкладка Central Policy. На этой вкладке выбираем из списка нужную политику доступа и жмем OK.

применение политики к файловому ресурсу

 

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

свойства безопасности файлового ресурса

Заключение

Dynamic Access Control предоставляет множество возможностей, при этом не требуя серьезных вложений и изменений в существующей инфраструктуре. Советую попробовать.

И еще. В данной статье я описал всего один из стандартных сценариев использования Dynamic Access Control. Если вы хотите знать больше, то вот здесь есть пошаговые инструкции по развертыванию, а здесь можно загрузить подробное описание технологии (на английском).

 
 
Комментарии
Aleksey Stepanov

Огромное спасибо за статью. Все супер просто и понятно объяснено. Несмотря на мелкие опечатки типа Sity(City).

Trackbacks for this post

Ответить