Ограничение прав пользователя windows server 2012

Микрософт с большим отставанием от разработчиков реализовал на терминальном сервере публикацию отдельных приложений. Технологию назвали RemoteApp. Пока речь идет о доступе к опубликованным приложениям через web-интерфейс, все выглядит красиво, но пользователям не удобно заходить в браузер (а браузер – это значит медленно), да и сам подход непривычен, а непривычное, как правило, воспринимается большинством пользователей негативно. Микрософт решил этот вопрос раздачей юзерам на рабочий стол готовых значков, настроенных на запуск конкретного приложения. Но тут все начинают понимать, что web-интерфейс – это оболочка, а под ней все тот же старый добрый DOS, пардон, RDP. И сразу хочется понять, а что там с правами доступа. Жмем Win+R, mstsc, Enter. Оп-па-на!  Мы сделали для конкретного пользователя возможность запускать только одну единственную программу, а он спокойно погуливает по серверу, как у себя дома…

Права доступа на терминальный сервер и к RemoteApp

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

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

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

Для кого-то это не имеет никакого значения, но это в любом случае ненормально, а в большинстве организаций – неприемлемо.

Штатного решения найти не удалось, но есть обходные пути.

А. Можно в AD в свойствах учетной записи на вкладке «Среда» задать запуск нужной программы при входе. Но тогда пользователь сможет работать только с одной программой на ТС.

Б. Можно там же на вкладке «Среда» задать запуск logoff.exe, а программы раздавать через настроенные значки. Тогда при входе через mstsc сеанс такого пользователя будет сразу же автоматически завершаться.

Надо понимать, что настройка из пунктов (А) и (Б) будет касаться входа на любой терминальный сервер, а их в общем случае может быть несколько, на каждом свои программы, где-то просто нужен доступ к рабочему столу сервера.

Чувствуется, что это надо разруливать через GPO, но параметры пользователя применяются только к пользователям, а не к серверам, а нам надо, чтобы параметры, заданные для пользователя (например, напуск при входе logoff.exe) применялись к конкретным пользователям на конкретных серверах. Тут на помощь приходит волшебный параметр Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy ⇒ User Group Policy loopback processing mode.

Последовательность действий

1. Создаем в AD группу безопасности, назовем её «TS1_Restrict_Obj».

2. Добавляем в группу «TS1_Restrict_Obj» пользователей, для которых нужно сделать ограничения. (Возможно, для конкретных задач потребуются более мягкие ограничения, а не logoff.exe. Или наоборот, нужно сделать что-то хорошее, скажем, отключить на терминальном сервере пароль на хранитель экрана, чтобы юзерам не приходилось вводить пароль дважды: на своей рабочей станции и на терминале.)

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

4. В групповых политиках создаем новый GPO (например, «TS1_Restrict») и связываем его с контейнером, в котором находится наш терминальный сервер(ы). Можно сделать отдельный контейнер (OU), в который вынести этот сервер(ы).

5. В SecurityFilteringдля вновь созданного GPO«TS1_Restrict» Удаляем записи, которые там создаются по умолчанию и добавляем нашу группу «TS1_Restrict_Obj».

6. Открываем на редактирование GPO «TS1_Restrict»

Computer Configuration ⇒ Policies ⇒ Administrative Templates ⇒ System ⇒ Group Policy ⇒ User Group Policy loopback processing mode = Merge (или Replace)

User Configuration ⇒ Policies ⇒ Administrative Templates ⇒ Windows Components ⇒ Remote Desktop Services ⇒ Remote Desktop Session Host ⇒ Remote Session Environment ⇒ Program path and file name = logoff.exe
Или делаем здесь другие ограничения, в зависимости от решаемой задачи.

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

Теперь при попытке пользователей, входящих в группу «TS1_Restrict_Obj», войти на данный терминальный сервер сразу же после входа будет происходить завершение сеанса. При этом опубликованные для этих пользователей приложения RemoteApp будут работать как через web-интерфейс, так и через файлы .RDP.

Примечание:

Не обязательно включать параметры пользователей и параметр User Group Policy loopback processing mode в один и тот же GPO. Просто если «замыкание» (loopback) включено для какого-то сервера, то политики пользователя будут применяться к этому серверу.

Разрешение	Возможности	Permission	Capability	Value	Meaning
Запрос сведений	Запрос сведений о сеансах и серверах Узел сеансов удаленных рабочих столов	Query Information	Query sessions and RD Session Host servers for information	WINSTATION_QUERY 0	Permission to query information about a session.
Установка сведений	Настройка свойств подключения	Set Information	Configure properties of the connection	WINSTATION_SET 1	Permission to modify connection parameters.
Удаленное управление	Просмотр или активное управление сеансом другого пользователя	Remote Control	View or actively control another user’s session	WINSTATION_SHADOW 4	Permission to shadow or remotely control another user’s session.
«Вход»	Вход в сеанс на сервере Узел сеансов удаленных рабочих столов	Logon	Log on to a session on the RD Session Host server	WINSTATION_LOGON 5	Permission to log on to a session on the server.
Выход из системы	Выход пользователя из сеанса	Logoff	Log off a user from a session	WINSTATION_LOGOFF 2	Permission to log off a user from a session.
Сообщение	Отправка сообщения сеансу пользователя	Message	Send a message to a user session	WINSTATION_MSG 7	Permission to send a message to another user’s session.
Подключение	Подключение к сеансу другого пользователя	Connect	Connect to another user session	WINSTATION_CONNECT 8	Permission to connect to another session.
Отключение	Отключение сеанса пользователя	Disconnect	Disconnect a user session	WINSTATION_DISCONNECT 9	Permission to disconnect a session.
Виртуальные каналы	Использование в сеансе виртуального канала, обеспечивающего перенаправление локальных устройств и ресурсов	Virtual Channels	Use a virtual channel in a session, which provides local device and resource redirection	WINSTATION_VIRTUAL | STANDARD_RIGHTS_REQUIRED 3	Permission to use virtual channels. Virtual channels provide access from a server program to client devices.
				WINSTATION_RESET 6	Permission to reset or end a session or connection. Windows Server 2003:  This value is not supported.

Если необходимо удалить данную группу с сервера, выполните следующие команды в PowerShell:

для локальной группы на сервере
$obj
=
@(gwmi
—Namespace
RootCIMv2TerminalServices
—query
«select * from Win32_TSAccount where
TerminalName=’RDP-TCP’ AND AccountName=’ServerName\Group'»)

$obj.Delete()

для доменной группы
$obj = @(gwmi -Namespace RootCIMv2TerminalServices -query "select * from Win32_TSAccount where 
TerminalName='RDP-TCP' AND AccountName='Domain\Group'")

$obj.Delete()

Для тех, кто считает данное количество полномочий избыточным и неоправданным с точки зрения безопасности, остальная часть статьи. 
Колонки «Value» и «Meaning» для Вас.Например, чтобы запретить пользователю отправку сообщений или теневое подключение, достаточно выполнить следующие команды: запретить отправку сообщений

$obj =
@(gwmi
—Namespace
RootCIMv2TerminalServices
—query
«select * from Win32_TSAccount where

TerminalName=’RDP-TCP’ AND AccountName=’Domain\Group'»)

$obj.ModifyPermissions(7,0)
в методе
ModifyPermissions  используется значение 7, которое предоставляет право отправки соообщений, значение 0 — запрещает это действие 

запретить теневое подключение
$obj =
@(gwmi
—Namespace
RootCIMv2TerminalServices
—query
«select * from Win32_TSAccount where

TerminalName=’RDP-TCP’ AND AccountName=’Domain\Group'»)

$obj.ModifyPermissions(4,0)
в методе
ModifyPermissions  используется значение 4, которое предоставляет право теневого подключения, значение 0 — запрещает это действие. 

Аналогичным образом, можно запретить остальные действия.

Если необходимо разрешить ранее запрещенную операцию, необходимо
в методе ModifyPermissions  установить значение равное 1.   

разрешить теневое подключение
$obj
=
@(gwmi
—Namespace
RootCIMv2TerminalServices
—query
«select * from Win32_TSAccount where

TerminalName=’RDP-TCP’ AND AccountName=’Domain\Group'»)

$obj.ModifyPermissions(4,1)


В заметке использованы материалы библиотеки MSDN, где можно ознакомиться с описанием классов Win32_TSAccount class,

Win32_TSPermissionsSetting class и их методами, и библиотеки TechNet —
Настройка разрешений для подключений к службам удаленных рабочих столов

В одном из прошлых видео мы рассматривали процесс поднятия роли сервера терминалов.

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

Регистрируйся на следующий вебинар по системному администрированию!

>> Подробнее о вебинаре <<

Так что стоит детально проанализировать, что пользователю делать можно, а что нет!!!

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

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

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

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

— доступ к системным дискам

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

— запустить диспетчер серверов

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

— доступ к диспетчеру задач

— доступ к командной строке

Давайте приступим к устранению этих недостатков.

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

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

1) Доступ к жестким дискам сервера

Запретить доступ к данным системных дисков можно через групповую политику, но, если мы попытаемся её изменить через Выполнить gpedit.msc то мы изменим групповую политику для всех пользователей на данном сервере, так что изменения затронут как терминальных пользователей, так и административные учетные записи.

А нам нужно ограничить в правах именно учетные записи, которые не имеют административные права на сервере. Для этого запустим редактор групповой политики через консоль (Выполнить mmc Файл Добавить Редактор объектов групповой политики Обзор Пользователи Не администраторы ОК Готово ОК) При желании таким образом можно настроить политики для отдельных пользователей.

Конфигурация пользователя Административные шаблоны Компоненты Windows Проводник Запретить доступ к дискам через Мой компьютер Включена Выполнить cmd gpupdate /force

Входим на сервер под удаленным пользователем и при попытке получить доступ к диску выдается сообщение «Операция отменена из-за ограничений, действующих на этом компьютере»

Причем у вас не получится не просто получить доступ к корню диска, а к любой папке через проводник (Рабочий стол, Загрузки и т.д. Даже если на рабочем столе создать папку и зайти в неё) В общем, везде где есть путь к расположению файла.

Однако, через файловые менеджеры, например тотал коммандер получить доступ к файлам можно. Или через командную строку

Поэтому, более тонко можно настроить через редактирование NTFS прав на файлы и папки (Диск D ПКМ Свойства Безопасность Удалить Все и Пользователи Добавить к нужной папке пользователя в права, как правило это папка с базой данных и т.д.

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

Если какая-то нужная папка, то можно разместить ярлык на рабочем столе, где будет фактический путь и поместить в папку для всех пользователей (C:UsersPublicDesktop Разрешить отображение скрытых файлов и папок Копировать туда ярлык с папкой и у всех удаленных пользователей появится на рабочем столе эта папка)

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

2) Запрет запуска приложений (Административные шаблоны Система Не запускать указанные приложения Windows TOTALCMD.EXE)

3) Запретить элементы панели управления (Административные шаблоны Панель управления Запретить доступ к панели управления и параметрам компьютера)

4) Запретить диспетчер серверов (Административные шаблоны Система Не запускать указанные приложения Windows ServerManager.exe)

5) Запретить диспетчер задач (Административные шаблоны Система Варианты действий после нажатия CTRL+ALT+DEL Удалить диспетчер задач Включено)

6) Запрет командной строки (Административные шаблоны Система Запретить использование командной строки)

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

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

В Windows Server 2012 появилась технология динамического контроля доступа (Dynamic Access Control), предназначенная для разграничения доступа к файловым ресурсам. Технология перспективная и заслуживающая внимания, поэтому я предлагаю вам посветить ее изучению некторое количество времени. В первой части мы разберем теоретические основы работы Dynamic Access Control.

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

Утверждения

Работа Dinamic Access Control основывается на утверждениях, или клаймах (claims). Для утверждений существует множество определений, приведу наиболее короткое. Утверждение – это информация об объекте, полученная из достоверного источника. В нашем случае объектом служит учетная запись пользователя или компьютера в Active Directory, а в качестве достоверного источника выступает служба KDC (Key Distribution Service), расположенная на контроллере домена.

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

В Windows Server 2012 используются утверждения трех типов:

1. Утверждения для пользователей (user claim) — в качестве утверждений используется аттрибуты учетной записи пользователя в Active Directory, например департамент или должность;
2. Утверждения для устройств (device claim) — здесь в качестве утверждений используется аттрибуты учетной записи компьютера, такие как операционная система или состояние здоровья;
3. Утверждения преобразования (transformation claim) — этот тип используется для трансформации утверждений при прохождении через доверительные отношения между лесами. Утверждения этого типа не базируются на атрибутах AD.

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

Условные выражения

Условные выражения (conditional expressions) представляют из себя сочетание из нескольких (двух и более) утверждений, разделенных логическим оператором. По сути это логические выражения, в котором мы производим сравнение правой и левой части и в качестве результата получаем одно из двух значений — TRUE или FALSE. Выражения используются как при авторизации, так и для проверки доступа к ресурсу.

Примечание. Кроме TRUE и FALSE существует еще один тип значения — UNKNOWN. Это значение возможно получить например в том случае, если соответствующий атрибут пользователя в AD не заполнен.

Напомню, что из себя представляют операторы. Скорее всего они вам знакомы, поэтому подробно описывать не буду, а просто перечислю их значения: равно (==), не равно (!=), больше чем (>), меньше чем (<), больше или равно (>=),  меньше или равно (<=), не (!), и (&&), или (||), содержит (Contains), любой из (Any_of), член группы (MemberOf) и любой член группы (MemberOf_Any).

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

User.Title==″Sales Manager″ && (User.Department==″Management″ || User.Department==″Sales″)

Это выражение условно можно разбить на 3 части, каждая из которых использует утверждения. В соответствии с правилами обработки условных выражений, первыми обрабатываются выражения в скобках. И поскольку из двух операторов первым должен обрабатываться  оператор ==,  выражение в скобках обрабатывается слева направо.

В качестве утверждения пользователя идет User.Department, отвечающее за департамент, в котором работает сотрудник. Предположим, наш пользователь является сотрудником отдела продаж (Sales). В этом случае левая часть выражения в скобках для него принимает значение FALSE, а правая TRUE и наше выражение примет вид:

User.Title==″Sales Manager″ && (FALSE || TRUE)

Так как для оператора || достаточно наличия в скобках хотя бы одного значения TRUE, то наше выражение сокращается до такого:

User.Title==″Sales Manager″ && TRUE

Теперь проверяем левую часть выражения. В ней используется атрибут User.Title, отвечающий за должность предполагаемого сотрудника. Если он является менеджером отдела продаж (Sales Manager), то выражение примет вид:

TRUE && TRUE

Для оператора && требуется, чтобы оба условия были истинными. В нашем примере это так, следовательно все выражение примет значение TRUE и пользователь получит доступ к ресурсу.

Свойства ресурсов

Ресурсами, которые можно защитить с помощью Dinamic Access Control, являются файлы. На файловых серверах Windows Server 2012 появилась возможность классифицировать ресурсы, указав для каждого файлового ресурса определенные свойства, а затем использовать эти свойства для определения разрешений доступа.

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

Share Permission

Для каждой папки, находящейся на сетевом ресурсе, действуют разрешения на шару (Share Permission). Когда то давно, до появления NTFS, это был единственный способ ограничить доступ к файловым ресурсам. На данный момент этот механизм устарел, поэтому хорошей практикой считается в Share Permissions давать полный доступ (Full Access) для всех (Everyone), а контроль доступа осуществлять с помощью разрешений NTFS.

NTFS Permissions

В файловой системе NTFS к каждому объекту  (файлу или папке) привязан список контроля доступа (Access Control List, ACL). В ACL хранятся идентификаторы безопасности (SID) пользователей и групп, которым явным образом разрешен (или запрещен) доступ к объекту. Соответственно, если пользователь или группа, членом которой он является, не указаны в ACL, то такой пользователь доступ не получит.

В ACL содержатся записи управления доступом (Access control entry, ACE), которые и определяют разрешения пользователя при доступе к объекту. Каждый ACE представляет из себя:

• SID доверенного лица — идентификатор пользователягруппы, доступ которого мы контролируем;
• Маску доступа — тип доступа (чтение, запись, выполнение и т.д);
• Флаги — определяют тип ACE (разрешение или запрет), а также параметры наследования.

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

ACE располагаются в ACL в определенном приоритетном порядке:

• Первыми идут ACE, назначенные на объект явным образом (т.е. вручную), сначала запрещающие ACE, потом разрешающие;
• Затем следуют разрешения, наследуемые напрямую от родительского объекта, также сначала запрещающие, потом разрешающие;
• И затем идут разрешения, наследуемые от других вышестоящих объектов.

С появлением Windows Server 2012 ситуация изменилась. ACE значительно расширились и появилась возможность включать в них утверждения. На рисунке приведен стандартный дескриптор безопасности (он же ACE) папки. В терминах языка SDDL (Security Definition Descriptor Language) он означает следующее:

O:BA — владельцем объекта (Owner) является встроенная группа BuiltinAdministrators;
G:DU — основная группа Domain Users;
D:PAI — дескриптор имеет тип DACL (D), в нем заблокировано наследование от вышестоящих объектов (P), но разрешено для нижестоящих объектов (AI);
A — Allow, означает разрешающий ACE;
OICI — флаги наследования для дочерних объектов;
0x1301bf — разрешения Modify и Synchronize в шестнадцатеричном виде;
AU — группа Authenicated Users.

Проще говоря, пользователи, входящие в группу Authenicated Users, имеют разрешение на изменение содержимого этой папки.

А вот тот же ACE, но уже с использованием утверждений. Рассмотрим поподробней, что изменилось. Во первых, появилась буква X, которая означает, что в ACE используются утверждения, а во вторых, в скобках содержится условное выражение. В этом выражении говорится, что доступ к объекту cмогут получить только те пользователи, у которых атрибут Department имеет значение Sales, а атрибут Office — значение Central. То есть доступ разрешен для сотрудников отдела продаж, работающих в центральном офисе.

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

Центральные политики доступа

Итак, мы имеем с одной стороны утверждения пользователей и устройств, а с другой — классификацию ресурсов. Для объединения этих технологий используются централизованные политики доступа (Central Access Policy, CAP). CAP хранятся в службе Active Directory, в разделе конфигурации и являются общими для всего леса.

Типичный пример центральной политики доступа приведен на следующем рисунке.

Процесс создания и применения CAP состоит из нескольких этапов:

• Сначала создаются необходимые утверждения для пользователей и устройств;
• Затем создаются свойства ресурсов;
• Свойства ресурсов применяются к файловым серверам, и на их основании производится классификация файлов;
• На основе утверждений создаются централизованные правила доступа (Central Access Rule), которые представляют из себя набор условных выражений наподобие описаных ранее;
• Создается CAP, в которую входят одно или несколько централизованных правил доступа;
• CAP публикуется в Active Directory и распространяется на файловые сервера с помощью групповых политик.

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

Kerberos

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

Напомню в общих чертах, как происходит доступ к ресурсу с использованием Kerberos.

1. Пользователь пытается войти в систему, для чего вводит свои учетные данные — имя пользователя, пароль и домен. Клиент Kerberos на рабочей станции обращается к службе KDC на контроллере домена и отправляет ей запрос на аутентификацию (KRB_AS_REQ). В запросе содержится имя пользователя, имя домена и специальный аутентификатор — текущее время на рабочей станции, зашифрованное хешем пароля пользователя.

2. Служба KDC находит пользователя в AD, извлекает его секретный ключ и расшифровывает аутентификатор, получая таким образом время отправки запроса. Если расшифровка прошла успешно и полученное время не расходится с временем на контроллере домена более чем на 5 минут (политика Kerberos по умолчанию), KDC выдает ответное сообщение (KRB_AS_REP). В ответе содержится сессионный ключ и отметка времени окончания билета, зашифрованные секретным ключом пользователя, а также билет TGT (Tiсket Granting Ticket), который зашифрован секретным ключом службы KDC.

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

3. Теперь пользователю требуется получить доступ к ресурсам, находящимся на файловом сервере. В Kerberos любой объект, к которому требуется получить доступ, называется службой. Клиент опять обращается к службе KDC с запросом (KRB_TGS_REQ), в котором содержится имя службы, к которой нужен доступ, имя пользователя и отметка времени, зашифрованные сессионным ключом, а также билет TGT.

4. KDC расшифровывает TGT, используя свой собственный ключ, а метка времени расшифровывается копией сессионного ключа. Если со временем все впорядке и билет TGT не просрочен, клиенту отправляется ответ (KRB_TGS_REP), содержащий две копии билета TGS (Ticket Granting Service), один для клиента и один для службы. При этом билет службы шифруется секретным ключом этой службы и вкладывается в клиентский билет, который шифруется сессионным ключом пользователя.

В билет TGS входят имя пользователя, имя службы, маркер времени и срок жизни билета, а также новый сессионный ключ. Кроме того, в TGS есть раздел данных, известный как сертификат атрибута привилегий PAC (Privilege Attribute Certificate). В PAC содержатся SID пользователя и SIDы всех групп безопасности, членом которых он является.

5. Клиент получает ответ службы KDC, расшифровывает его сессионным ключом и извлекает новый сессионный ключ. Этим ключом он шифрует метку времени и отправляет ее вместе с именем пользователя и билетом службы TGS на сервер запросом (KRB_AP_REQ). Сервер принимает запрос, расшифровывает билет TGS своим секретным ключом и извлекает свою копию сессионного ключа. Этим ключом он расшифровывает метку времени и таким образом устанавливает подлинность клиента.

Подсистема безопасности на сервере извлекает из PAC данные пользователя. Затем она обращается в локальную базу данных и проверяет, не является ли пользователь членом локальной группы на данном компьютере, и если да, то добавляет полученные SIDы к списку данных, извлеченных из билета. На основе полученного списка формируется маркер доступа (Access token), который привязывается к сессии пользователя.

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

6. В некоторых случаях требуется передача дополнительного сообщения от сервера к клиенту (KRB_AP_REP). Этот процесс называется взаимной аутентификацией и используется в том случае, если клиент требует у службы подтверждение подлинности.

В Windows Server 2012 в протокол Kerberos были внесены некоторые изменения, призванные обеспечить поддержку Dynamic Access Control.

Kerberos Security Support Provider (SSP) — основа клиентской службы Kerberos. В Windows Server 2012 и Windows 8 библиотека Kerberos.dll была переработана для поддержки утверждений пользователя и данных авторизации устройства в атрибуте PAC.

PAC также был переработан и может включать в себя следующие данные:

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

Составные удостоверения (Compound Identity) — еще одна новая технология, позволяющая включать в билет TGS не только авторизационные данные пользователя, но и данные его компьютера. Это позволяет предоставлять доступ как на основании того, кем является пользователь, так и на основании устройства, на котором он работает.

Защита Kerberos (Kerberos armoring) — технология создания защищенного канала между клиентом и службой KDC, ее еще называют FAST (Flexible Authentication Secure Tunnel). Суть этой технологии в следующем: перед аутентификацией пользователя его компьютер тоже должен пройти аутентификацию в домене и получить от службы KDC билет TGT. FAST использует этот билет для того, чтобы зашифровать дальнейший обмен данными между пользователем и KDC, создавая безопасный канал связи между ними и делая невозможным перехват сообщений.

И наконец в службу KDC (Kdcsvc.dll) Windows Server 2012 также включена поддержка утверждений и составных удостоверений.

С учетом всех этих новых возможностей процесс авторизации несколько изменился. Когда клиент отправляет запрос на контроллер домена, служба KDC получает запрос и проверяет значение флага claims в структуре PA-PAC-OPTION. Если он имеет значение TRUE, то значит клиенту требуются утверждения. KDC извлекает из базы Active Directory необходимые атрибуты и добавляет их в PAC. Клиент получает билет TGS, содержащий утверждения, и с этим билетом обращается к службе. Соответственно служба, получив билет TGS, извлекает из него утверждения и добавляет их в маркер доступа, на основании которого предоставляется доступ к ресурсу.

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

В Windows Server 2012 появился новая концепция централизованного управления доступом к файлам и папкам на уровне всей компании под названием Dynamic Access Control (динамический контроль доступа). Основное отличие новой системы динамического контроля доступа от старой системы доступа к файлам и папкам Access Control List (ACL — списки контроля доступа), позволяющей предоставлять доступ только на учетных записей пользователей и групп, заключается в том, что с помощью Dynamic Access Control (DAC) можно управлять доступом на основе практически любого заданного атрибута и даже критерия. С помощью Dynamic Access Control в Windows Server 2012 можно создавать целые правила управления доступа к данным, которые позволят проворить, например, входит ли пользователь в определенные группы, числится ли он в финансовом отделе и поддерживает ли его планшет шифрование RMS. Эти правила в виде политик в дальнейшем можно применить к любому (или всем) файловым серверам организации, создав тем самым единую систему безопасности.

Недостатки организации доступа на основе ACL

Каким образом реализовывался доступ к общим каталогам на файловых серверах до появления Dynamic Access Control. На общую папку на уровне NTFS и/или шары назначались определенные списки доступа, включающиеся в себя определенные группы в AD (или локальные группы сервера) или конкретные учетные записи. Чтобы пользователь получил доступ к нужному каталогу, администратор должен был включить его в соответствующую группу. Какие недостатки такой модели организации доступа?

· Доступ регулируется только на основании только членства в группе

· При большом количестве общих папок необходимо создавать большое количество групп (выливается в увеличение билета Kerberos)

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

· Невозможность реализации сложных сценариев доступа

При контроле доступа только на основе ACL нередки случаи, когда пользователь случайно выкладывает конфиденциальную информацию (зарплаты топ-менеджеров, например) на общедоступный (public) ресурс, где все желающие могут с ней познакомится.

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

Архитектура и принципы Windows Server 2012 Dynamic Access Control

В Windows Server 2012 Dynamic Access Control создает еще один уровень управления доступом к файловым объектам на уровне всего домена, причем на эти объекты продолжают действовать NTFS разрешениями
(ACL). Отметим, что правила DAC могут действовать повсеместно, независимо от того, какие NTFS права выставлены на объекте.

Одной из основных концептов модели DAC является понятие claim (заявка или утверждение). В модели управления доступом Windows Server 2012 claim представляет собой атрибут Active Directory, которой определен для использования с централизованными политиками доступа (Central Access Policies). В качестве критериев можно использовать практически любые сохранные в AD параметры, принадлежащие определенному объекту, например, ID устройства, способ входа в систему, местонахождение, личные данные и т.д. Настройка claim-ов осуществляется с помощью консоли управления Active Directory Administrative Center (ADAC) в новом контейнере Claim Based Access. В этом контейнере (изначально пустом) можно создавать собственные утверждения и связывать их с атрибутами пользователей или компьютеров. Основываясь на значениях claim-ов можно определить давать ли доступ данному пользователю/устройству к тому или иному объекту файловой системы.

Следующий компонент DAC – свойства ресурсов (Resource Properties), с помощью которых определяются свойства ресурсов, которые в дальнейшем будут использовать в правила авторизации. Resource Properties – это также отдельный контейнер в Dynamic Access Control.

Следующими элементами DAC являются правила Central Access Rules и политики Central Access Policy. CentralAccess Rules описывают какой уровень доступа предоставить к файлам, каким пользователям, с какими заданными утвержденями, с каких устройств и т.д. Central Access Policy – это политика, содержащая в себе правила Central Access Rules, которая в дальнейшем посредством GPO будет распространена по всей организации (или конкретной OU).

Каким образом можно перейти на модель управления доступом Dynamic Access Control в организации:

1. Создать один/несколько видов клаймов.

2. Активировать одни/несколько свойств ресурсов (метки или теги у файловых объектов)

3. Создать правило Central Access Rule, в котором определяется условия предоставления доступа

4. Добавить созданные правила в политику Central Access Policy

5. С помощью групповых политик распространить CAP на файловые сервера

Естественно, перед внедрением Dynamic Access Control необходимо настроить систему классификации файлов, как это сделать описывается в статье : Классификация файлов с помощью File Classification Infrastructure в Windows Server 2012. Этап определения и классификация данных, хранящихся на файл-серверах наиболее тяжелый и трудоемкий, результатом которого будет назначение управляемым файловым объектам NTFS тэгов.

Каким образом осуществляется проверка разрешений пи доступе к файлу/каталогу конечного пользователя, ведь теперь помимо прав доступа на NTFS осуществляется еще и проверка на соответствие клаймов? Последовательность проверки разрешений следующая:

· Share ACL

· Central Access Policy

· NTFS ACL

Пример использования Dynamic Access Control в Windows Server 2012

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

С помощью консоли AD Administrative Center создадим два новых claim-a: Department и Country. Для этого перейдите в контейнер Dynamic Access Control -> Claim Types и в меню выберите пункт New:

Создадим новое утверждение с именем Department :

и Country :

В атрибуте Country укажем два предопределенных (suggested) значения (EG – Египет, и QR – Катар):

Далее создадим новое свойство ресурса (Resource Properties) для утверждения Country: New-> Resource Properties.

Затем в контейнере Resource Properties активируйте утверждение Department

Теперь создадим новое правило Central Access Rule. В этом правиле будут указаны разрешения, которые применяются к объекту, если claim совпадает с правилом, описанном в CAR.

Предположим, мы правило, определяющее, что пользовали Finance Admins (Department=Finance и County=EG), имеют полный доступ, а пользователи Finance Execs (Department=Finance) – доступ только на чтение. Это правило будет применено ко всем правилам, классифицированным, как относящиеся к финансовому департаменту:

В итоге, правило будет выглядеть так:

Затем создадим политику Central Access Policy (CAP), которая с помощью GPO будет применена ко всем файловым серверам.

В новую политику CAP, включим правило для финансового департамента, созданное ранее:

Далее правило Central Access Policy с помощью групповых политик нужно применить ко всем файловым серверам. Для этого нужно создать новую политику GPO и прилинковать ее к OU с файловыми серверами.

В окне редактора групповых политик (Group Policy Management Editor) перейдите в раздел Computer Configuration->Policies->Windows Settings->Security Settings->File System-Central Access Policy->Manage Central access policies.

В окне настроек Central Access Policies Configuration добавим политику Finance Data и нажмем OK.

Далее нужно разрешить всем доменным контроллерам назначать клаймы. Это также выполняется с помощью GPO, однако в этом случае нам нужно отредактировать политику контроллеров домена — Default Domain Controllers Policy . Перейдите в раздел Computer Configuration->Policies->Administrative Templates->System-> KDC. Откройте параметр KDC Support for claims, compound authentication and Kerberos armoring, задайте ему значение Enabled , а в выпадающем списке выберите Supported

Закройте редактор групповых политик и обновите политики на контроллере домена и файловых серверах командой

gpupdate /force

Посмотрим, что же у нас получилось.

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

Примечание: Чтобы при доступе к файлу проверялись еще и разрешения DAC, у пользователей должен быть доступ к каталогу/файлу на уровне NTFS. В этом примере мы предоставим всем полный доступ на уровне NTFS.

Проверим текущие разрешения на папку.

Перейдем на вкладку Central Policy и применим политику Finance Data.

Если у пользователя не назначены утверждения (он входит в нужную группу, но у него не определены атрибуты department и country), доступа к каталогу у него не будет.

Заключение

С помощью комбинации технологий DAC, AD RMS (позволяет организовать динамическое шифрование файлов с помощью AD RMS и FCI)и FCI можно создавать мощные схемы управления доступом к документам и зашиты конфиденциальной информации, реализуя полноценную DLP систему на базе инфраструктуры Windows Server 2012.