Dynamic Access Control для Windows 7

В своих новых (некогда) ОС Windows 8 и Windows Server 2012 Microsoft реализовала ряд технологий, получивших общее маркетинговое название «динамическое управление доступом» (Dynamic Access Control, DAC). В частности, динамическое управление доступом включает в себя использование для авторизации доступа к файл-серверу не только SID учётных записей пользователей и групп безопасности, в которые эти записи входят, но и других атрибутов учётных  записей в каталоге Active Directory (таких, как принадлежность к определённому подразделению) через посредство утверждений (claims) о пользователе. Технологии эти, похоже, оказались интересными пользователям, но, к сожалению, Microsoft плохо озаботилась тем, чтобы подробно их документировать в Technet Library — ограничившись, по существу, лишь описанием типовых сценариев развёртывания. И теперь время от времени на различных форумах я натыкаюсь на вопрос, вынесенный в заголовок — можно ли использовать динамическое управление доступом для клиентов файл-сервера, работающих под управленем более ранних версий ОС Windows — такими, как Windows 7.

К сожалению, в Technet Library крайне сложно найти чёткий и ясный ответ на этот вопрос. А потому в Сети бытует заблуждение (прокравшееся даже на форумы Technet), что DAC для клиентов Windows 7 не поддерживается, и, чтобы использовать DAC, необходим клиент под Windows 8 и выше. Это, вроде бы, является прямым следствием из того, что клиенты с  ранними версиями Windows не поддерживают расширения Kerberos, необходимые для передаче файл-серверу утверждений о пользователе, а потому в переданном ими файл-серверу билете доступа к службе сервера утверждений о пользователе содержаться не может. Подкрепляет это рассуждение и тот факт, что динамический контроль доступа, развёрнутый в простейшем варианте, без централизованных политик доступа, не работает «из коробки» для более ранних ранних, чем Windows 7,  версий Windows.

Но на самом деле, это не так — использование динамического контроля доступа для клиентов под ранними версиями Windows (в частности, Windows 7) возможно, правда — с определёнными ограничениями: авторизация на основе утверждений об устройствах для клиентов под ранними версиями Windows невозможна.

Существует крайне полезное, но весьма глубоко запрятанное руководство по Dynamic Access Control под названием «Understand and Troubleshoot Dynamic Access Control in Windows Server 2012».  В нём можно найти и сведения о том, что клиенты Windows 7 поддерживаются, и об упомянутом выше ограничении, и о том, как настроить файл-сервер на поддержку клиентов под ранними версиями Windows, и, главное, на мой взгляд, — о том как же это всё работает.

Прежде всего, читаем в разделе Prerequisits (стр.5 руководства) требования к клиенту: Windows 8 client (required when using device claims) — то есть, новая версия Windows на клиенте требуется только для использования при авторизации утверждений об устройстве, с которого осуществляется доступ. Вне этого сценария никаких специальных требований к клиенту нет. Чуть далее, в пояснениях требований к клиенту на странице 7 указано, что для поддержки динамического управления доступом доступа с клиента под управлением предыдущих версий Windows необходимо включить (установить в значение Enabled) на файл-сервере параметр политики «Microsoft network server: Attempt S4U2Self to obtain claim information» (он находится находится в разделе Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options). Если на файл-сервере применяется политика централизованного доступа, то этот делать не обязательно: файл-сервер в этом случае по умолчанию будет вести себя, так, будто этот параметр включен.

Продемонстрирую как включить этот параметр и его эффект в лабораторных условиях. Для тестирования Dynamic Access Control я в своё время собрал стенд, включающий в себя контроллер домена под управлением Windows Server 2012 R2, файл-сервер, также под управлением Windows Server 2012 R2 и клиентские компьютеры. В демонстрации используются два таких компьютера — под управлением Windows 8.1 и под управлением Windows 7.  В домене было настроено динамическое управление доступом на файловом сервере в конфигурации для смешанной среды (Windows 8/Server 2012 и Windows предыдущих версий) и создано утверждение для пользователя с именем department, которое создаётся на основе содержимого одноимённого атрибута (в нём хранится название отдела или другого подразделения) учётной записи пользователя в Active Directory. Как именно это делается, я в данной статье останавливаться не буду (это можно найти практически в любом руководстве по развертыванию Dynamic Access Control), остановлюсь лишь на шагах, требующихся для демонстрации.

В Active Directory был создан пользователь Sales1 со значением атрибута Department=Sales. На файл-сервере была создана общая папка SHARED3, доступ к которой на просмотр (только для этой папки) был разрешён всем прошедшим проверку пользователям. В в ней была создана папка Sales, для которой было настроено условное разрешение Modify для всех, прошедших проверку, с условием User.department=»Sales»:

DAC-WIN7-1

С клиентского компьютера под управлением Windows 8.1, на котором зарегистрирован пользователь Sales1 эта папка отлично открывается:

DAC-WIN7-2

но с компьютера под управлением Windows 7, на котором зарегистрирован тот же пользователь — нет: пользователь получил сообщение о том, что доступ запрещён:

DAC-WIN7-3

Установка же указанного выше параметра локальной политики файлового сервера в Enabled —

DAC-WIN7-4

позволила получить доступ и с компьютера под управлением Windows 7.

DAC-WIN7-5

Как это работает? Ответ на этот вопрос неочевиден: ведь реализация Kerberos для Windows 7 действительно не поддерживает расширения, появившиеся в Windows 8 и необходимые для передачи файл-серверу утверждений о пользователе (user claims) в билете службы.  Описание ответа, однако, будет по необходимости кратким, а потому мне придётся положиться на то, что читатель знает, как происходят процессы аутентификации по протоколу Kerberos.

Ключом к ответу на этот вопрос является слово S4U2Self в названии упомянутого выше параметра политики: оно отражает те дополнительные действия, который при включенной этой политике предпринимает файл-сервер, если в результате аутентификации пользователя он не получает утверждений о пользователе — как, например, в рассматриваемом случае аутентификации с помощью Kerberos клиента предыдущей версии Windows.

Факт наличия утверждений о пользователе в авторизационной информации (PAC) в билете Kerberos   отмечается контроллером домена путём добавления в эту информацию специального, введённого в Windows 2012 идентификатора безопасности — CLAIMS_VALID SID (S-1-5-21-0-0-0-497). В свою очередь, Диспетчер учётных записей безопасности в процессе создания маркера безопасности, который получает служба файл-сервера при олицетворении клиента, добавляет этот SID в маркер безопасности. Таким образом, проверив наличие этого SID, служба файл-сервера имеет возможность определить, были ли получены в процессе аутентификации утверждения о пользователе.

Если упомянутая ранее политика «Microsoft network server: Attempt S4U2Self to obtain claim information» включена (или находится в состоянии по умолчанию, а на файл-сервере развернуты централизованные политики доступа), а утверждения о пользователе получены не были, то файл-сервер самостоятельно запрашивает эти утверждения у контроллера домена. Для этого как раз и используется то, что называется словом S4U2Self.

S4U2Self — это название появившегося ещё в Windows Server 2003 расширения протокола Kerberos, которое позволяет службе запросить билет службы для произвольного пользователя (которого служба аутентифицировала любым удобным ей способом) для доступа к себе самой. При этом в запросе к Kerberos TGS (службе выдачи билетов) используется не билет TGT пользователя (которого у службы нет), а билет TGT самой службы. Использование этого расширения требует наличия у службы разрешения на чтение вычисляемого (constructed) атрибута tokenGroupsGlobalAndUniversal учетной записи пользователя, которое обычно у файл-сервера есть (при настройках по умолчанию оно есть у всех прошедших проверку субъектов безопасности).

Так вот, обнаружив необходимость получения информации об утверждениях о пользователе, служба файл-сервера обращается к Диспетчеру учётных записей безопасности с запросом на получение этой информации. Диспетчер учётных записей, в свою очередь, получив эту информацию путём использования расширения S4U2Self протокола Kerberos, возвращает новый маркер безопасности для пользователя, который уже содержит в себе утверждения о пользователе. И теперь служба файл-сервера может использовать для проверки доступа не только SID пользователя и групп, в которые он входит, но и утверждения о пользователе (User Claims).

Из описания этого механизма становится понятным и требование к версии клиента при использовании утверждений об устройстве (Device Claims): файл-сервер при подключении к нему устаревшего клиента не может запросить добавление в билет службы для доступа к себе информацию об устройстве, с которого подключается клиент. Эта информация должна сразу содержаться в представляемом клиентом билете службы — на что способны только клиенты под управлением Windows 8 и выше.

Изложенный выше механизм работает и в случае, когда клиент под управлением Windows 8 и выше использует в качестве протокола аутентификации не Kerberos, а NTLM — например, при подключении к серверу по IP-адресу или с компьютера, не входящего в домен. В этих случаях точно так же для использования утверждений о пользователе требуется включать указанную выше политику, а утверждения об устройстве использоваться не могут.

Вот, собственно,  и всё, что я хотел рассказать.

Реклама
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: