Kerberos настройка windows server 2012
Обновлено: 08.07.2024
Аутентификация в системах Windows. Часть 2 - Kerberos
В прошлой части нашего цикла мы рассмотрели работу протоколов семейства NTLM, отметив ряд их существенных недостатков, которые невозможно решить в рамках протокола. Поэтому вместе с Active Directory на смену им пришел более совершенный протокол Kerberos, который продолжает успешно применяться до сих пор. В данном материале мы рассмотрим общие принципы функционирования данного протокола, что позволит получить начальные знания в этой области самым широким массам читателей.
Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.
Основным недостатком протокола NTLM служит то, что он не предусматривает взаимную аутентификацию клиента и сервера, это во многом обусловлено тем, что протокол изначально разрабатывался для небольших сетей, где все узлы считаются легитимными. Несмотря на то, что в последних версиях протокола сделаны серьезные улучшения безопасности, но направлены они в основном на усиление криптографической стойкости, не устраняя принципиальных недостатков.
В доменных сетях протоколы NTLM вызывают повышенную нагрузку на контроллеры домена, так как всегда обращаются к ним для аутентификации пользователя. При этом также отсутствует взаимная идентификация узлов и существует возможность накопления пакетов для последующего анализа и атаки с их помощью.
В отличии от NTLM Kerberos изначально разрабатывался с условием, что первичная передача информации будет производиться в открытых сетях, где она может быть перехвачена и модифицирована. Также протокол предусматривает обязательную взаимную аутентификацию клиента и сервера, а взаимное доверие обеспечивает единый удостоверяющий центр, который обеспечивает централизованную выдачу ключей.
Перед тем как продолжить, следует прийти к соглашению по поводу используемых в статье терминов. Так под термином клиент будет рассматриваться любой узел сети, обращающийся к любому иному узлу - серверу - с целью доступа к любому из его ресурсов.
Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) - пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.
Центр распространения ключей содержит долговременные ключи для всех принципалов, в большинстве практических реализаций Kerberos долговременные ключи формируются на основе пароля и являются так называемым "секретом для двоих". С помощью такого секрета каждый из его хранителей может легко удостовериться, что имеет дело со своим напарником. При этом долговременные ключи не при каких обстоятельствах не передаются по сети и располагаются в защищенных хранилищах (KDC), либо сохраняются только на время сеанса.
Для принципалов, которые не являются членами домена AD, могут использоваться специальные keytab-файлы, которые содержат сведения о клиенте, домене и его долговременный ключ. В целях безопасности keytab-файл нельзя передавать по незащищенным каналам, а также следует обеспечить его безопасное хранение у принципала.
В структуре Active Directory центр распространения ключей располагается на контроллере домена, но не следует путать эти две сущности, каждая из них является самостоятельной и выполняет свои функции. Так Kerberos отвечает только за аутентификацию клиентов, т.е. удостоверяет, что некто является именно тем, за кого себя выдает. Авторизацией, т.е. контролем прав доступа, занимается контроллер домена, в свою очередь разрешая или ограничивая доступ клиента к тому или иному ресурсу.
Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.
Желая пройти проверку подлинности в сети, клиент передает KDC открытым текстом свое имя, имя домена и метку времени (текущее время клиента), зашифрованное долговременным ключом клиента. Метка времени в данном случае выступает в роли аутентификатора - определенной последовательности данных, при помощи которой узлы могут подтвердить свою подлинность.
Получив эти данные KDC извлекает долговременный ключ данного пользователя и расшифровывает метку времени, которую сравнивает с собственным текущим временем, если оно отличается не более чем на 5 минут (значение по умолчанию), то метка считается действительной. Эта проверка является дополнительной защитой, так как не позволяет использовать для атаки перехваченные и сохраненные данные.
Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.
Клиент в первую очередь расшифровывает сеансовый ключ, затем при помощи этого ключа метку времени и сравнивает ее с той, что он отправил KDC, если метка совпала, значит KDC тот, за кого себя выдает, так как расшифровать метку времени мог только тот, кто обладает долговременным ключом. В этом случае клиент принимает TGT и помещает его в свое хранилище.
Чтобы лучше понять этот механизм приведем небольшой пример. Если злоумышленник перехватил посланный KDC запрос, то он может на основе открытых данных послать клиенту поддельный сеансовый ключ и TGT, но не сможет расшифровать метку времени, так как не обладает долговременным ключом. Точно также, он может перехватить отправленные клиенту TGT и сеансовый ключ, но также не сможет расшифровать последний, не имея долговременного ключа. Перехватить долговременный ключ он не может, так как они по сети не передаются.
Теперь рассмотрим ситуацию, когда клиент хочет обратиться к серверу.
Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.
Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.
Таким образом клиент получает сессионный ключ для работы с сервером и сессионный билет. Получить содержимое билета, как и TGT, он не может, так как не располагает нужными долговременными ключами.
Теперь, имея новый ключ и билет, клиент обращается непосредственно к серверу:
Он предъявляет ему сеансовый билет и метку времени, зашифрованную сессионным ключом. Сервер расшифровывает билет, извлекает оттуда свой экземпляр ключа и сведения о клиенте, затем расшифровывает метку времени и сравнивает ее с текущим. Если все нормально, то он шифрует полученную метку своим экземпляром сессионного ключа и посылает назад клиенту. Клиент расшифровывает ее своим сеансовым ключом и сравнивает с тем, что было послано серверу. Совпадение данных свидетельствует о том, что сервер тот, за кого себя выдает.
Как можно заметить, сеансовые ключи никогда не передаются по незащищенным каналам и не передаются узлам, с которыми нет доверительных отношений. У KDC нет доверительных отношений с сервером, и он не может передать ему сессионный ключ, так как нет уверенности, что ключ будет передан кому надо. Но у него есть долговременный ключ этого сервера, которым он шифрует билет, это гарантирует, что никто иной не прочитает его содержимое и не получит сессионный ключ.
Клиент имеет билет и свой экземпляр ключа, доступа к содержимому билета у него нет. Он передает билет серверу и ждет ответ в виде посланной метки времени. Сервера, как и KDC, не хранят сеансовые ключи, а, следовательно, расшифровать метку времени сервер может только в том случае, если сможет расшифровать билет и получить оттуда сеансовый ключ, для чего нужно обладать долговременным ключом. Получив ответ и расшифровав его, клиент может удостоверить подлинность сервера, так как прочитать аутентификатор и извлечь из него метку времени сервер сможет только при условии расшифровки билета и получения оттуда сеансового ключа.
Несмотря на то, что мы рассмотрели крайне упрощенную модель протокола Kerberos, надеемся, что данная статья поможет устранить пробелы и получить первоначальные знания, которые затем можно расширить и углубить уже осмысленно подойдя к прочтению более серьезных материалов.
Kerberos — это протокол проверки подлинности, который используется для проверки удостоверения пользователя или узла. в этом разделе содержатся сведения о проверке подлинности Kerberos в Windows Server 2012 и Windows 8.
Описание компонента
Операционные системы Windows Server реализуют протокол проверки подлинности Kerberos версии 5 и расширения для проверки подлинности с помощью открытого ключа, переноса данных авторизации и делегирования. Клиент проверки подлинности Kerberos реализуется в качестве поставщика поддержки безопасности (SSP). Получить к нему доступ можно через интерфейс поставщика поддержки безопасности (SSPI). Начальная проверка подлинности пользователя интегрирована в архитектуру единого входа Winlogon.
Центр распространения ключей Kerberos (KDC) встроен в другие службы безопасности Windows Server, работающие на контроллере домена. В качестве базы данных учетных записей безопасности в KDC используется база данных домен Active Directory Services домена. Доменные службы Active Directory необходимы для реализации Kerberos по умолчанию в рамках домена или леса.
Практическое применение
Проверка подлинности Kerberos на уровне домена обеспечивает следующие преимущества.
Делегированная проверка подлинности.
службы, работающие в операционных системах Windows, могут олицетворять клиентский компьютер при доступе к ресурсам от имени клиента. Во многих случаях служба может выполнить свою работу для клиента путем доступа к ресурсам на локальном компьютере. Когда клиентский компьютер проходит проверку подлинности в службе, протоколы NTLM и Kerberos предоставляют сведения авторизации, которые требуются службе для локального олицетворения клиентского компьютера. Однако некоторые распределенные приложения спроектированы таким образом, что интерфейсная служба должна использовать удостоверение клиентского компьютера при подключении к серверным службам на других компьютерах. Проверка подлинности Kerberos поддерживает механизм делегирования, позволяющий службе действовать от имени клиента при подключении к другим службам.
Единый вход.
Использование проверки подлинности Kerberos в домене или в лесу позволяет пользователю или службе получать доступ к ресурсам, разрешенным администраторами, без многократного ввода учетных данных. После первоначального входа в систему домена через функцию Winlogon протокол Kerberos управляет учетными данными по всему лесу при каждой попытке доступа к ресурсам.
Возможность взаимодействия.
Реализация протокола Kerberos V5 Майкрософт основана на стандартных спецификациях отслеживания, рекомендованных IETF. Поэтому в операционных системах Windows протокол Kerberos лежит в основе взаимодействия с другими сетями, в которых для проверки подлинности также используется протокол Kerberos. Кроме того, корпорация Майкрософт публикует документацию "Протоколы Windows", содержащую сведения о реализации протокола Kerberos. документация содержит технические требования, ограничения, зависимости и поведение протокола, зависящего от Windows, для реализации протокола Kerberos корпорацией майкрософт.
Более эффективная проверка подлинности на серверах.
Перед применением Kerberos можно использовать проверку подлинности NTLM, которая требует подключения сервера приложений к контроллеру домена для проверки подлинности каждого клиентского компьютера или службы. При использовании протокола Kerberos возобновляемые билеты сеанса заменяют сквозную проверку подлинности. Серверу не требуется переходить к контроллеру домена (если только не требуется проверка сертификата атрибута привилегий). Вместо этого сервер может проверить подлинность клиентского компьютера путем проверки учетных данных, предоставленных клиентом. Клиентские компьютеры могут получить учетные данные для определенного сервера однократно и затем использовать их в течение всего сеанса после входа в сеть.
Взаимная проверка подлинности.
С помощью протокола Kerberos сторона на любом конце сетевого подключения может проверить, что сторона на противоположном конце является субъектом, за которого себя выдает. NTLM не позволяет клиентам проверять удостоверение сервера или включать один сервер для проверки удостоверения другого. Проверка подлинности NTLM предназначена для сетевой среды, в которой серверы считаются подлинными. В протоколе Kerberos такого допущения нет.
Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.
На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).
Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.
Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.
Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).
Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.
Проверить настройки SPN у учетной записи можно так:
setspn /l iis_service
Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.
Выберите Application Pool сайта (в нашем примере это DefaultAppPool).
Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.
Измените его с ApplicationPoolIdentity на contoso\iis_service.
Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.
В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication
Измените useAppPoolCredentials на True.
Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.
Перезапустим IIS командой:
Аналогичную настройку нужно выполнить на всех серверах веб-фермы.
Примечание. В моем примере, на IE11 сразу авторизоваться не получилось. Пришлось добавить адрес в доверенные и в настройках Trusted Zones Sites выставить значение параметра User Authentication -> Logon на Automatic logon with current user name and passwordЗапускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.
Майк Стивенс — старший инженер поддержки в группе Microsoft Commercial Technical Support. Имеет сертификаты Microsoft Certified IT Professional (MCITP-EA) и Microsoft Certified Trainer (MCT)
. В первой части статьи я расскажу о преимуществах применения ограниченного делегирования Kerberos и Windows Server 2012 по сравнению с предыдущими версиями Windows Server.
Что такое ограниченное делегирование?
Ограниченное делегирование позволяет ограничить внутренние службы, для которых внешняя служба может запросить билеты от имени другого пользователя. Типичный пример ограниченного делегирования – процесс взаимодействия браузер-IIS-SQL Server. В этой ситуации пользователь переходит к серверу веб-отчетов, размещенному на Microsoft IIS, который извлекает данные с помощью проверенного подключения к системе Microsoft SQL Server. Серверу IIS необходимо пройти проверку на компьютере SQL Server от имени пользователя. Через делегирование Kerberos сервер (то есть внешняя служба) может запросить билет службы для любой службы (то есть внутренней службы) — не только SQL Server — от имени пользователя. Это означает, что сервер IIS, в сущности, может выполнить проверку подлинности от имени пользователя в SQL Server, на файловом ресурсе с общим доступом или в веб-службе. С помощью ограниченного делегирования можно ограничить сервер IIS (внешний компонент), чтобы он мог представлять пользователя только в SQL Server (внутренний компонент) и ни в одной другой службе или приложении.
Ограниченное делегирование Kerberos было частью операционной системы со времен Windows Server 2003. Администратор должен настроить список разрешенных полных имен пользователя (SPN) для объектов пользователей и компьютеров в Active Directory (AD). Вы добавляете список имен SPN, представляющий внутренние службы, из которых внешней службе позволено запрашивать билеты от имени пользователя к атрибуту ms-DS-Allowed-To-Delegate-To субъекта, который выполняет приложение или службу на внешнем сервере. В предшествующем примере внешняя служба — IIS, а внутренняя — SQL Server. Чтобы ограничить делегирование для IIS, следует добавить имена SPN для экземпляров SQL Server, выполняемых на компьютере SQL Server, к атрибуту ms-DS-Allowed-To-Delegate-To учетной записи компьютера IIS в AD (или учетной записи пользователя, от имени которой запущен пул приложений IIS). В этой модели внешняя служба ограничена лишь возможностью запрашивать билеты службы, перечисленные в атрибуте ms-DS-Allowed-To-Delegate-To. Недостаток этой модели делегирования — зависимость от имен SPN.
Полные имена пользователя SPN
Имена SPN отличаются сложностью управления. Несмотря на концептуальную простоту, имена SPN могут стать причиной значительных трудностей, связанных с уникальными ограничениями.
На первый взгляд, ограниченное делегирование противоречит основному правилу регистрации дублированных имен SPN; но это только кажется. KDC не обращается к атрибуту ms-DS-Allowed-To-Delegate-To при попытке сопоставить SPN субъекту безопасности. Поэтому требование уникальности SPN ограничено лишь значениями в атрибуте servicePrincipalName. Чтобы ограничить делегирование службы или приложения, необходимо составить список имен SPN службы на субъекте безопасности, который запускает приложение на внешнем сервере.
Управлять количеством имен SPN, знать место и время их регистрации, и избегать дубликатов — трудоемкая задача. Поэтому ограниченное делегирование сложно реализовать, обслуживать и диагностировать.
Точка делегирования
Ограниченное делегирование — модель, которая управляет делегированием на внешнем сервере. Большинство моделей делегирования управляют точкой делегирования, ближайшей к ресурсу (то есть внутреннему компоненту). При реализации делегирования на внешнем компоненте обязанности управления изымаются у администратора ресурса и передаются администратору внешнего сервера (или приложения). Такая модель не позволяет администратору ресурса управлять доступом к ресурсу. В существующей модели для изменения атрибута ms-DS-Allowed-To-Delegate-To необходимы права администратора домена. Таким образом, требуются дополнительные административные усилия для управления ограниченным делегированием.
Область делегирования
Область делегирования определяет предел распространения делегирования с внешнего сервера на внутренний. Область существующей модели ограниченного делегирования не выходит за рамки домена, то есть субъект безопасности, выполняющий приложение, может передавать билеты ограниченного делегирования только приложению или службе, выполняемой субъектом безопасности в том же домене. Нельзя использовать ограниченное делегирование в доверенных доменах или лесах.
Новшества Windows Server 2012
В Server 2012 появился новый тип ограниченного делегирования Kerberos, в котором устранены многие недостатки предшествующей модели. В новой реализации ограниченного делегирования удалены зависимости схемы делегирования от имен SPN, устранена необходимость в административных правах домена, администратору ресурса разрешается самостоятельно выполнять делегирование, а также расширена область делегирования.
В ограниченном делегировании в Server 2012 появилась концепция управления делегированием билетов службы с использованием дескриптора безопасности вместо списка разрешенных имен SPN. В результате упрощается делегирование благодаря предоставляемой ресурсу возможности определить, каким субъектам безопасности разрешено запрашивать билеты от имени другого пользователя.
.jpg) |
| Рисунок. Ограниченное делегирование в Server 2012 |
Ограниченное делегирование на основе ресурсов функционирует корректно, независимо от функционального уровня домена и числа контроллеров домена, работающих с версией Windows Server, предшествующей Server 2012, при наличии, по крайней мере, одного контроллера домена Server 2012 в том же домене, в котором расположен внешний сервер, и одного контроллера домена Server 2012 в домене, содержащем внутренний сервер. Если домен гибридный (имеются как контроллеры домена Server 2012, так и контроллеры с предшествующей версией Windows Server), то компьютеры Windows 8 и Windows 2012 работают с контроллером домена Server 2012 для ограниченного делегирования на основе ресурсов, целенаправленно обнаруживая контроллер домена Server 2012.
Требования
Для новой реализации ограниченного делегирования Kerberos необходимо выполнить следующие требования:
- центры распространения ключей KDC Server 2012 должны находиться в домене внешней учетной записи;
- центры KDC Server 2012 должны находиться в домене внутренней учетной записи;
- внешний сервер должен работать с Server 2012.
Необходимость в центрах KDC Server 2012 объясняется тем, что это единственные центры KDC, обеспечивающие возвращение ссылочных запросов S4U2Proxy, и использованием нового атрибута msDS-AllowedToActOnBehalfOfOtherIdentity для учетной записи службы. Для внешнего сервера требуется Server 2012, так как версия Kerberos на этих серверах распознает необходимость получить ссылки S4U2Proxy на доверенные домены и леса.
Управление
Для управления ограниченным делегированием Kerberos в Server 2012 применяется Windows PowerShell. Используйте следующие команды Windows PowerShell для управления ограниченным делегированием. Обычно приходится задействовать Get-ADUser, Get-ADComputer или Get-ADServiceAccount субъекта, выполняющего внешнюю службу, и передавать этот объект субъекта в качестве значения для аргумента -PrincipalsAllowedToDelegateToAccount.
В этой статье я перечислил проблемы, возникающие перед ИТ-администраторами, внедряющими ограниченное делегирование Kerberos. Убедительный ответ на эти проблемы дает Server 2012 благодаря ограниченному делегированию Kerberos на основе ресурсов. Во второй части статьи будут приведены дополнительные подробности о принципах ограниченного делегирования на основе ресурсов и последовательности действий при проверке подлинности, совершаемых между компьютерами с операционной системой Server 2012.
Динамический контроль доступа представляет собой наиболее фундаментальное изменение в плане безопасности, которое включено в Server 2012. Динамический контроль доступа интегрирует в себе модель контроля доступа на основе заявок (claims-based access control — CBAC) с моделью ОС Windows и AD. Заявки (claims) представляют собой своеобразные утверждения о пользователях или устройствах (например, “Имя моей учетной записи JanDC”, “Я состою в отделе продаж” и т.д.), которые выпускаются доверенными источниками (trusted authority). Microsoft впервые представила CBAC в Active Directory Federation Services v 1.0 (ADFS v1) в Windows Server 2003.
Заявки могут представить гибкий механизм для обмена доверенными идентификационными атрибутами между ADFS серверами. Организации теперь могут использовать заявки для защиты данных в файле и папке, хранящихся на доменных (domain-joined) машинах под Windows Server 2012 или Windows 8. Контроллеры домена в Server 2012 могут выпускать заявки (claim statements) в ходе аутентификации пользователя или машины; осуществляется это путем включения заявки в аутентификационный билет (authentication ticket) пользователя или машины. (Более подробная информация о заявках и том, как Microsoft использует их, находится на MSDN A Guide to Claims-based Identity and Access Control.)
- Классификации и тегирования данных
- Применения настроек контроля доступа на основе заявок (CBAC)
- Аудита доступа к данным
- Шифрования данных.
- Расширение логики контролера домена и Kerberos Key Distribution Center (KDC) для того, чтобы активировать выпуск заявок и токенах аутентификации (authentication tokens)
- Изменение формата токена Kerberos для осуществления транспортировки заявок
- Добавлены альтернативные потоки данных (alternate data streams — ADS) в NTFS, добавлена поддержка кастомных свойств для файлов и папок
- Включено хранение конфиденциальных выражений в ACL файла и папки для осуществления гибкого контроля доступа и настройки аудита
- Расширена схема AD, что теперь позволяет осуществлять централизованное хранение свойств и политик динамического контроль доступа.
Политики центрального доступа
Динамический контроль доступа может использовать AD для хранения политик центрального доступа (central access policies — CAP); делается это для того, чтобы применить эти политики к членам домена. В диалоговом окне Advanced Security Settings для папок была добавлена вкладка Central Policy (показано на рисунке 1). Из этой вкладки, администраторы могут выбрать политику центрального доступа (CAP), которую они хотят присвоить заданной папке. Теперь можно задавать политику доступа к файлам и папкам в вашем домене или лесе, основываясь на значениях стандартных и кастомных атрибутов ваших объектов AD (пользователи или компьютеры). Например, вы можете отказать пользователю в доступе к сетевой папке на файловом сервере, если атрибут Department пользовательского объекта AD не содержит значение “Sales" или «Marketing.» Эта гибкая логика авторизации очень отличается от той логики, которая была раньше (SID пользователя и группы).
Центральные политики доступа (CAP) можно задать из контейнера динамического контроля доступа (DAC), который представлен в обновленном Active Directory Administrative Center (ADAC), что показан на рисунке 2, или c помощью PowerShell комендлетов. С помощью тех же инструментов можно активировать поддержку заявок (claim statements) для объектов AD (пользователи и компьютеры) и добавить значения этим атрибутам. Контроллер домена Server 2012 добавит заявки (claim statements) к токенам авторизации пользователя и компьютера только в том случае, если атрибуты этих объектов действительно содержат информацию и связаны с активированным типом заявки. Перед тем как ваш контроллер домена в Windows Server 2012 сможет выпускать заявки, эту фунцию необходимо включить; имейте ввиду, что КД в Server 2012 по умолчанию не активны для использования CBAC. Чтобы включить CBAC, используйте настройку объекта групповой политики Domain Controller support for Dynamic Access Control and Kerberos armoring в контейнере \Computer Configuration\Policies\Administrative Templates\System\KDC. Чтобы использовать объекты групповых политик для распространения CAP на ваши машины, вы можете использовать опцию объекта групповой политики Central Access Policy в контейнере \Computer Configuration\Policies\Windows Settings\Security Settings\File System.
Аудит доступа к файлам и папкам в Windows Server 2012
С введением динамического контроля доступа заявки можно гибко использовать не только для делегирования доступа к файлам и папкам, но и для аудита доступа к ним. Например, в Server 2012 мы можете настроить правило аудита для отслеживания всех пользователей, которым был предоставлен или запрещен доступ к папкам, которые помечены как “конфиденциальные” (свойство “confidential”). Чтобы централизованно задать настройки аудита для файлов и папок на основании заявок, используйте объект групповой политики Global Object Access Auditing, который Microsoft представила в Windows Server 2008 R2 и который теперь расширен с помощью динамического контроля доступа.
Администраторы могут задавать гибкие настойки контроля доступа и аудита доступа к файлам и папкам; это осуществлять как в качестве добавления, так и независимо от централизованно определённых CAP’ов. Были изменены диалоговые окна в Advanced Security Settings в Windows 8 и Server 2012, чтобым можно было задавать условные выражения (conditional expressions) при настройке авторизации и аудита файлов и папок. Рисунок 3 показывает этот новый интерфейс, иллюстрируя тем самым определение разрешения, которые включает условное выражение в папку, названную SharedData.
Классификация данных
Помимо аудита и контроля доступа Dynamic Access Control также дает новые гибкие механизмы классификации данных. Теперь можно добавить кастомные свойства файлу или папке, которые получили название свойства глобальных ресурсов (global resource properties); это осуществляется через диалоговые окна настроек аудита и контроля доступа. Снова, вы можете сделать то же самое с помощью ADAC или PowerShell командлетов. Чтобы распространить (propagate) эти кастомные свойства на ваши доменные компьютеры, Microsoft оснастила клиенты Windows 8 и Server 2012 специальными расширениями, которые используют LDAP, чтобы подключиться к AD и извлечь эти свойства. Эта новая функция классификации дает вам осуществлять гибкую классификацию данных на основе выбранных вами атрибутов и, соответственно, применять защиту.
Вы можете классифицировать файлы и папки вручную, используя вкладку Classification в свойствах файла или папки, как показано на рисунке 4. Эта вкладка появляется только в системах, в которых присутствует установленная функция Desktop Experience и которая хостит (host) File Server Resource Manager role service
Автоматизация процесса классификации файлов
Процесс классификации файлов можно автоматизировать, если использовать функцию File Classification Infrastructure (FCI). FCI была представлена в Server 2008 R2 и позволяет администраторам определять кастомные классификационные ярлыки (теги), устанавливать правила классификации и истечения ее срока и формировать отчеты по классификациям. Администраторы могут управлять FCI прямо из File Server Resource Manager (FSRM). FCI может быть использована с RMS Bulk Protection Tool, чтобы автоматически применять RMS защиту к файлам.
Это довольно короткое введение в динамический контроль доступа. Подробную информацию (настройка, конфигурирование, решение проблем) можно найти в white paper от Microsoft ("Understand and Troubleshoot Dynamic Access Control in Windows Server 8 Beta".)
Читайте также: