Dynamic access control в windows server 2016 - Доктор Windows

description	ms.assetid	title	author	ms.author	manager	ms.date	ms.topic
Learn more about: Dynamic Access Control Overview	9ee8a6cb-7550-46e2-9c11-78d0545c3a97	Dynamic Access Control Overview	billmath	billmath	femila	05/31/2017	article

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2012 R2, Windows Server 2012

This overview topic for the IT professional describes Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.

Domain-based Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources.

For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a user’s permissions change dynamically without additional administrator intervention if the user’s job or role changes (resulting in changes to the user’s account attributes in AD DS).

Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.

Features and concepts associated with Dynamic Access Control include:

Central access rules
Central access policies
Claims
Expressions
Proposed permissions

Central access rules

A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy.

If one or more central access rules have been defined for a domain, file share administrators can match specific rules to specific resources and business requirements.

Central access policies

Central access policies are authorization policies that include conditional expressions. For example, let’s say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:

Identify and mark the files that contain the PII.
Identify the group of HR members who are allowed to view the PII information.
Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.

Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.

Claims

A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The user’s title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources. The following types of claims are available in the supported versions of Windows:

User claims Active Directory attributes that are associated with a specific user.
Device claims Active Directory attributes that are associated with a specific computer object.
Resource attributes Global resource properties that are marked for use in authorization decisions and published in Active Directory.

Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.

Expressions

Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions are managed through the Advanced Security Settings dialog box of the ACL Editor or the Central Access Rule Editor in the Active Directory Administrative Center (ADAC).

Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.

Proposed permissions

Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them.

Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.

Additional changes

Additional enhancements in the supported versions of Windows that support Dynamic Access Control include:

Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.

By default, devices running any of the supported versions of Windows are able to process Dynamic Access Control-related Kerberos tickets, which include data needed for compound authentication. Domain controllers are able to issue and respond to Kerberos tickets with compound authentication-related information. When a domain is configured to recognize Dynamic Access Control, devices receive claims from domain controllers during initial authentication, and they receive compound authentication tickets when submitting service ticket requests. Compound authentication results in an access token that includes the identity of the user and the device on the resources that recognize Dynamic Access Control.

Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.

Every domain controller needs to have the same Administrative Template policy setting, which is located at Computer ConfigurationPoliciesAdministrative TemplatesSystemKDCSupport Dynamic Access Control and Kerberos armoring.

Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.

Support in Active Directory to store user and device claims, resource properties, and central access policy objects.

Support for using Group Policy to deploy central access policy objects.

The following Group Policy setting enables you to deploy central access policy objects to file servers in your organization: Computer ConfigurationPolicies Windows SettingsSecurity SettingsFile SystemCentral Access Policy.

Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing

You must enable staged central access policy auditing to audit the effective access of central access policy by using proposed permissions. You configure this setting for the computer under Advanced Audit Policy Configuration in the Security Settings of a Group Policy Object (GPO). After you configure the security setting in the GPO, you can deploy the GPO to computers in your network.

Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts

You can filter or transform incoming and outgoing claims that traverse a forest trust. There are three basic scenarios for filtering and transforming claims:

Value-based filtering Filters can be based on the value of a claim. This allows the trusted forest to prevent claims with certain values from being sent to the trusting forest. Domain controllers in trusting forests can use value-based filtering to guard against an elevation-of-privilege attack by filtering the incoming claims with specific values from the trusted forest.
Claim type-based filtering Filters are based on the type of claim, rather than the value of the claim. You identify the claim type by the name of the claim. You use claim type-based filtering in the trusted forest, and it prevents Windows from sending claims that disclose information to the trusting forest.
Claim type-based transformation Manipulates a claim before sending it to the intended target. You use claim type-based transformation in the trusted forest to generalize a known claim that contains specific information. You can use transformations to generalize the claim-type, the claim value, or both.

Software requirements

Because claims and compound authentication for Dynamic Access Control require Kerberos authentication extensions, any domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows to support authentication from Dynamic Access Control-aware Kerberos clients. By default, devices must use domain controllers in other sites. If no such domain controllers are available, authentication will fail. Therefore, you must support one of the following conditions:

Every domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows Server to support authentication from all devices running the supported versions of Windows or Windows Server.
Devices running the supported versions of Windows or that do not protect resources by using claims or compound identity, should disable Kerberos protocol support for Dynamic Access Control.

For domains that support user claims, every domain controller running the supported versions of Windows server must be configured with the appropriate setting to support claims and compound authentication, and to provide Kerberos armoring. Configure settings in the KDC Administrative Template policy as follows:

Always provide claims Use this setting if all domain controllers are running the supported versions of Windows Server. In addition, set the domain functional level to Windows Server 2012 or higher.
Supported When you use this setting, monitor domain controllers to ensure that the number of domain controllers running the supported versions of Windows Server is sufficient for the number of client computers that need to access resources protected by Dynamic Access Control.

If the user domain and file server domain are in different forests, all domain controllers in the file server’s forest root must be set at the Windows Server 2012 or higher functional level.

If clients do not recognize Dynamic Access Control, there must be a two-way trust relationship between the two forests.

If claims are transformed when they leave a forest, all domain controllers in the user’s forest root must be set at the Windows Server 2012 or higher functional level.

A file server running Windows Server 2012 or Windows Server 2012 R2 must have a Group Policy setting that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is set by default to Automatic, which results in this Group Policy setting to be turned On if there is a central policy that contains user or device claims for that file server. If the file server contains discretionary ACLs that include user claims, you need to set this Group Policy to On so that the server knows to request claims on behalf of users that do not provide claims when they access the server.

Additional resource

For information about implementing solutions based on this technology, see Dynamic Access Control: Scenario Overview.

Источник

Обновлено: 03.02.2023

В этой обзорной статье для ИТ-специалистов описывается динамический контроль доступа и связанные с ним элементы, появившиеся в Windows Server 2012 и Windows 8.

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

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

Динамический контроль доступа не поддерживается в операционных системах Windows до версий Windows Server 2012 и Windows 8. Если динамический контроль доступа настроен в средах с поддерживаемыми и неподдерживаемыми версиями Windows, изменения будут применяться только в поддерживаемых версиях.

Ниже перечислены компоненты и концепции, связанные с динамическим контролем доступа.

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

Централизованное правило доступа — это выражение правил авторизации, которые могут включать одно или несколько условий, затрагивающих группы пользователей, требования пользователей и устройств, а также свойства ресурсов. Несколько централизованных правил доступа можно объединить в централизованную политику доступа.

Если для домена определены одно или несколько централизованных правил доступа, администраторы файловых ресурсов общего доступа могут сопоставлять определенные правила с определенными ресурсами и бизнес-требованиями.

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

Централизованные политики доступа — это политики авторизации, включающие условные выражения. Например, предположим, что Организация имеет бизнес-требование для ограничения доступа к личной информации (PII) в файлах только владельцу файла и членам отдела кадров, которым разрешено просматривать персональные данные. Эта политика организации применяется к файлам персональных данных, на каком бы из файловых серверов организации они ни располагались. Для реализации этой политики организация должна иметь следующие возможности:

идентифицировать и пометить файлы, содержащие персональные данные;

идентифицировать группу сотрудников отдела кадров, которой разрешен просмотр персональных данных;

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

Централизованные политики доступа служат «зонтиками» безопасности, прикрывающими все серверы. Эти политики дополняют (но не заменяют) политики локального доступа или списки управления доступом на уровне пользователей (DACL), применяемые к файлам и папкам.

Претензи

Утверждение — это уникальная деталь информации о пользователе, устройстве или ресурсе, опубликованная контроллером домена. В качестве примера утверждения можно привести название пользователя, классификация отдела для файла или состояние работоспособности компьютера. Объект может включать более одного утверждения, и любое сочетание утверждений можно использовать для авторизации доступа к ресурсам. В поддерживаемых версиях Windows доступны следующие типы утверждений:

Утверждения пользователей. Атрибуты Active Directory, связанные с конкретным пользователем.

Утверждения устройств. Атрибуты Active Directory, связанные с конкретным компьютером.

Атрибуты ресурсов. Глобальные свойства ресурсов, отмеченные для использования в решениях авторизации и публикуемые в Active Directory.

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

Выражения

Условные выражения — это усовершенствование управления доступом, разрешающее или запрещающее доступ к ресурсам при выполнении определенных условий, таких как членство в группе, расположение или состояние безопасности устройства. Этими выражениями можно управлять через диалоговое окно дополнительных параметров безопасности редактора ACL или редактор централизованных правил доступа центра администрирования Active Directory (ADAC).

Выражения помогают администраторам управлять доступом к конфиденциальным ресурсам с помощью гибких условий в бизнес-средах возрастающей сложности.

Предложенные разрешения

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

Прогнозирование действительного доступа к ресурсу помогает планировать и настраивать разрешения для него перед их реализацией.

Дополнительный ресурс

Сведения о реализации решений на основе этой технологии см. в разделе динамический контроль доступа: Обзор сценариев.

Дополнительные изменения

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

Поддержка в протоколе проверки подлинности Kerberos для надежного предоставления утверждений пользователей, утверждений устройств и групп устройств.

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

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

Каждый контроллер домена должен иметь один и тот же параметр политики административного шаблона, который расположен на компьютерной конфигурацииPoliciesAdministrative Templates\SystemKDCSupport Dynamic Access Control and Kerberos armoring.

Поддержка в Active Directory для хранения утверждений пользователей и устройств, свойств ресурсов и объектов политики центрального доступа.

Поддержка использования групповой политики для развертывания объектов политики центрального доступа.

Следующий параметр групповой политики позволяет развертывать объекты политики центрального доступа для файловых серверов в организации: Конфигурация компьютераПолитики Windows ПараметрыSecurity ПараметрыFile SystemCentral Access Policy.

Поддержка авторизации файлов на основе утверждений и аудита для файловой системы с помощью групповой политики и аудита глобального доступа к объектам

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

Поддержка преобразований или фильтрации объектов политики утверждений, которые пересекают доверия леса Active Directory

Можно фильтровать или преобразовывать входящие и исходяющие утверждения, которые пересекают лесное доверие. Существует три основных сценария фильтрации и преобразования утверждений:

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

Фильтрация на основе утверждений Фильтры основаны на типе утверждения, а не на значении утверждения. Вы определяете тип утверждения по имени утверждения. В доверяемом лесу используется фильтрация на основе типов утверждений, которая Windows отправку утверждений, раскрываюющих сведения в доверчивый лес.

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

А что для динамического контроля доступа представляют собой ресурсы?

Свойство ресурса представляет собой некую сущность, описывающую какую-либо конкретную характерную особенность ресурса, которым могут выступать такие объекты как, скажем, файлы или папки. По сути, это свойство играет роль при создании централизованных правил доступа, а именно служит для определения самих целевых ресурсов, а также непосредственно разрешений. В таких свойствах ресурса содержатся предполагаемые значения, которые определены для самого объекта, и хранятся они в атрибуте msDS-ClaimPossibleValues объекта. Помимо этого, между прочим, свойство ресурса также используется для классификации самого ресурса;
Свойство ссылочного ресурса, или – как также принято его называть – ссылочное свойство ресурса, в свою очередь, представляет собой, грубо говоря, свойство ресурса, использующее существующий тип утверждения в качестве своих предложенных значений. Что это означает? По сути, объекты ссылочных свойств ресурса отличаются от объектов свойств ресурса тем, что они не хранят свои значения, а используют их из DN ссылающегося объекта утверждения в атрибуте msDS-ClaimSharesPossibleValuesWith. Получается, что используя ссылочное свойство ресурса, сами свойства ресурса всегда будут допустимы для сравнения с типом утверждения в самих централизованных правилах доступа, на которые они ссылаются, тем самым уменьшая ручную поддержку согласованности данных.

Обзор динамического контроля доступа

В этом разделе обзор для ИТ-специалистов описывается динамическое управление доступом и связанные с ним элементы, которые были представлены в Windows Server 2012 и Windows 8.

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

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

Динамический контроль доступа не поддерживается Windows операционных системах до Windows Server 2012 и Windows 8. Если динамический контроль доступа настроен в средах с поддерживаемой и не поддерживаемой версией Windows, изменения будут реализованы только в поддерживаемых версиях.

Функции и понятия, связанные с динамическим управлением доступом, включают:

Правила центрального доступа

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

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

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

Политики центрального доступа — это политики авторизации, которые включают условные выражения. Например, предположим, что у организации есть бизнес-требование ограничить доступ к лично идентифицируемой информации (PII) в файлах только владельцу файлов и сотрудникам отдела кадров (HR), которым разрешено просматривать сведения о PII. Это представляет политику всей организации, которая применяется к файлам PII, где бы они ни находились на файловом сервере в организации. Чтобы реализовать эту политику, организация должна иметь возможность:

Определите и пометить файлы, содержащие PII.

Определите группу сотрудников отдела кадров, которым разрешено просматривать сведения о PII.

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

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

Утверждения

Утверждение — это уникальный фрагмент сведений о пользователе, устройстве или ресурсе, опубликованных контроллером домена. В качестве допустимого примера утверждения можно привести название пользователя, классификацию файла в отделе или состояние здоровья компьютера. Объект может включать несколько утверждений, и для авторизации доступа к ресурсам можно использовать любое сочетание утверждений. Следующие типы утверждений доступны в поддерживаемых версиях Windows:

Утверждения пользователей Атрибуты Active Directory, связанные с определенным пользователем.

Утверждения о устройстве Атрибуты Active Directory, связанные с определенным объектом компьютера.

Атрибуты ресурса Глобальные свойства ресурсов, помеченные для использования в решениях по авторизации и опубликованные в Active Directory.

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

Выражения

Условные выражения — это повышение доступа к управлению управлением доступом, которое позволяет или отказывает в доступе к ресурсам только при определенных условиях, например, членства в группе, расположения или состояния безопасности устройства. Выражения управляются через диалоговое окно Advanced Security Параметры редактора ACL или редактора правил центрального доступа в центре администрирования Active Directory (ADAC).

Выражения помогают администраторам управлять доступом к конфиденциальным ресурсам с гибкими условиями во все более сложных бизнес-средах.

Предлагаемые разрешения

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

Прогнозирование эффективного доступа к ресурсу помогает планировать и настраивать разрешения для этих ресурсов перед реализацией этих изменений.

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

Ты должен увидеть это сам. Не поздно отказаться. Потом пути назад не будет.
Примешь синюю таблетку — и сказке конец.
Ты проснешься в своей постели и поверишь, что это был сон.
Примешь красную таблетку — войдешь в страну чудес.
Я покажу тебе, насколько глубока кроличья нора.
К/ф. «Матрица»
В двух предыдущих статьях настоящего цикла мы с вами начали разбирать богатейшие функциональные возможности технологии динамического контроля доступа, позволяющие перевести на существенно новый уровень всю вашу модель управления ресурсами, расположенными непосредственно на файловых серверах. По большому счету, за две статьи рассмотреть мы с вами успели довольно-таки немного, а именно: я привел базовые сценарии использования этой технологии, а также вы узнали о том, что собой представляют утверждения и как можно управлять уникальными типами утверждений. Но ведь очевидно, что полученных из этих статей знаний недостаточно для того, чтобы иметь четкое представление о данной технологии и начать у себя в организациях разрабатывать свои уникальные сценарии.
В этой статье мы с вами копнем еще глубже и посмотрим на то, что же собой в концепции DAC-а представляют собой ресурсы и списки свойств ресурсов, что также является неотъемлемой частью технологии динамического контроля доступа. То есть, вероятнее всего, это статья будет предпоследней перед тем как мы начнем создавать централизованные политики доступа и переходить к сценариям, о которых я так много говорил в первой статье этого цикла. Ну что же, далее я предлагаю нам проверить, «насколько глубока эта кроличья нора»…

Управление объектами свойств ресурса при использовании Windows PowerShell

Как в случае с типами утверждений, да и практически с любыми функциональными возможностями Windows Server 2012, управлять объектами свойств ресурса вы можете не только средствами центра администрирования Active Directory, но также для написания сценариев и автоматизации ваших действий можно использовать богатейшие возможности Windows PowerShell. Для управления свойствами ресурсов используются командлеты ADResourceProperty, то есть New-ADResourceProperty для их создания, Set-ADResourceProperty для изменения существующих объектов, а также Remove-ADResourceProperty, который отвечает за удаление последних.
Итак, сейчас попробуем создать объект свойство ресурса под названием Depart, где будут указаны различные должности (в этом примере Маркетинг, Бухгалтерия, Финансисты), которые должны фигурировать при изменении условного выражения. Значит, следует использовать такой командлет:

Дополнительные изменения

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

Поддержку протокола проверки подлинности Kerberos для надежного предоставления утверждений пользователей, утверждений устройств и групп устройств.

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

Поддержка использования групповой политики центра распространения ключей (KDC) для обеспечения динамического контроля доступа в домене.

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

Поддержка использования групповой политики центра распространения ключей (KDC) для обеспечения динамического контроля доступа в домене.

Поддержка сохранения утверждений пользователей и устройств, свойств ресурсов и объектов централизованных политик доступа в Active Directory.

Поддержка использования групповых политик для развертывания объектов централизованных политик доступа.

Следующий параметр групповой политики позволяет развертывать объекты централизованной политики доступа на файловых серверах в организации: Конфигурация компьютераПолитикиПараметры WindowsПараметры безопасностиФайловая системаЦентрализованная политика доступа.

Поддержка авторизации файлов на основе утверждений и аудита для файловых систем посредством использования групповой политики и аудита доступа к глобальным объектам

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

Поддержка преобразования или фильтрации объектов политики утверждений, просматривающих отношения доверия лесов Active Directory

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

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

Фильтрация на основе типов утверждений. Фильтры, основанные на типе утверждения, а не на его значении. Тип утверждения определяется по его имени. Фильтрация на основе типов утверждений используется в доверенном лесе. Она не позволяет Windows отправлять утверждения, раскрывающие информацию доверяющему лесу.

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

А что для динамического контроля доступа представляют собой ресурсы?

Свойство ресурса представляет собой некую сущность, описывающую какую-либо конкретную характерную особенность ресурса, которым могут выступать такие объекты как, скажем, файлы или папки. По сути, это свойство играет роль при создании централизованных правил доступа, а именно служит для определения самих целевых ресурсов, а также непосредственно разрешений. В таких свойствах ресурса содержатся предполагаемые значения, которые определены для самого объекта, и хранятся они в атрибуте msDS-ClaimPossibleValues объекта. Помимо этого, между прочим, свойство ресурса также используется для классификации самого ресурса;
Свойство ссылочного ресурса, или – как также принято его называть – ссылочное свойство ресурса, в свою очередь, представляет собой, грубо говоря, свойство ресурса, использующее существующий тип утверждения в качестве своих предложенных значений. Что это означает? По сути, объекты ссылочных свойств ресурса отличаются от объектов свойств ресурса тем, что они не хранят свои значения, а используют их из DN ссылающегося объекта утверждения в атрибуте msDS-ClaimSharesPossibleValuesWith. Получается, что используя ссылочное свойство ресурса, сами свойства ресурса всегда будут допустимы для сравнения с типом утверждения в самих централизованных правилах доступа, на которые они ссылаются, тем самым уменьшая ручную поддержку согласованности данных.

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

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

Как и в случае с утверждениями, управлять свойствами ресурса и ссылочными свойствами ресурса можно как средствами «Центра администрирования Active Directory», так и, для реализации автоматизированных сценариев, воспользовавшись богатыми возможностями Windows PowerShell. Ввиду того, что этот цикл статей подразумевает плотное изучение технологии динамического контроля доступа, далее в этой статье будет рассматриваться управление свойствами ресурса при использовании обоих методов. А начинать, опять же, мы сейчас будем с центра администрирования Active Directory. Итак:

Управление объектами свойств ресурса средствами центра администрирования Active Directory

На контроллере домена откройте окно «Центра администрирования Active Directory», где в области списка выделите узел «Динамический контроль доступа», а затем выберите узел «Resource Properties» (Dynamic Access Control >Resource Properties);
В отобразившемся узле нажмите в области сведений правой кнопкой мыши и из контекстного меню выберите последовательно команды «Создать» и «Свойство ресурса» (New >Resource Property), как показано на первой иллюстрации данной пошаговой процедуры, либо на начальной странице центра администрирования Active Directory перейдите к тайлу динамического контроля доступа и в группе действий Active Directory выберите второе действие, позволяющее создавать новые свойства ресурса. Как в первом, так и во втором случае откроется диалоговое окно создания нового свойства ресурса.

Отображаемое имя (Display name). В текущем текстовом поле вы должны указать уникальное отображаемое имя для создаваемого вами свойства ресурса. Следовательно, это имя будет фигурировать в узле Resource Properties и в прочих элементах консоли центра администрирования Active Directory. Само собой, называть свои свойства ресурса вы можете в буквенно-цифровом формате. Например, назовем наше свойство ресурса «Region» и перейдем к следующему параметру;
Тип значения (Value type). Представляет собой раскрывающийся список, откуда можно выбрать логические типы данных, которые уже операционная система будет использовать для описания данных, и которые, собственно, будут храниться в свойствах ресурсов. При создании свойства ресурса можно выбрать любое из восьми доступных типов значения, а именно:
- Date time. Позволяет создавать свойства ресурса, основанные на логическом типе значения, представляющем собой дату и время. Тут стоит отметить лишь то, что при использовании такого типа значения вы не сможете использовать такое свойство ресурса непосредственно для авторизации (об этой опции подробнее вы узнаете буквально через несколько абзацев). В качестве предустановленных свойств ресурса с этим типом значения выступает свойство «Retention Start Date», которое определяет дату начала периода удержания. В принципе, это не самый распространенный тип значения свойства ресурса;
- Multi-Valued Choice. Объекты свойств ресурса, которые основаны на текущем логическом типе значения могут содержать по несколько предложенных значений, позволяющих выбрать из сгенерированного списка один или же несколько допустимых значений. В том случае, если для конкретного объекта в редакторе условных выражений дополнительных параметров безопасности вам нужно будет выбрать несколько таких значений, их следует указывать при помощи оператора равно. Во всех остальных случаях достаточно указывать лишь одно такое значение. В качестве примера можно привести предустановленное свойство ресурса Projects, при помощи которого вы можете выбирать проекты, над которыми работают ваши пользователи;
- Multi-Valued Text. В свою очередь, объекты свойств ресурса текущего логического типа значений могут включать в себя по несколько текстовых записей. Предустановленных объектов свойства ресурса для данного типа не существует;
- Number. Текущие логически типы значений для объектов свойств ресурсов всего-навсего позволяют вам создавать такие объекты, которые могут включать в себя лишь одно число. Довольно примитивный тип значений, поэтому он не сильно востребован и по умолчанию не создаются объекты свойств ресурсов, использующие этот тип;
- Ordered List. Те объекты свойств ресурса, которые основаны на этом логическом типе значений, предоставляют единичный выбор предлагаемых значений, которые можно сравнивать с другими объектами свойств ресурса этого же типа. Примером тому служит предустановленный объект свойства ресурса Confidentiality, отвечающий за уровень конфиденциальности ресурса и последующего взаимодействия с принципалами безопасности;
- Single-Valued Choice. Очередной логический тип значения, на основании которого могут создаваться объекты свойств ресурса, позволяющий также создавать несколько предлагаемых значений для того, чтобы в будущем можно было выбрать из соответствующего списка только лишь одно такое значение. В качестве примера можно привести предустановленный объект свойства ресурса Department, который включает в себя перечень потенциальных подразделений, к которым может иметь отношение целевой ресурс;
- Text. Логический тип значения, позволяющий создавать для объекта свойств ресурса единственную запись с текстом. Существенно проще предыдущего типа, поэтому, как и в случае с типом Number, используется очень редко, и среди предустановленных объектов свойств ресурсов объект с таким типом обнаружить невозможно;
- Yes/No. Последний по счету, но не по значимости логический тип значения, позволяющий создавать объекты свойств ресурса со значениями, представляющими собой булевы true или false. В качестве примера можно привести объект свойств ресурса «Personal Use», отвечающий за то, является ли целевой объект рабочим или же личным документом (положительный ответ означает личное использование последнего).
  В качестве примера, так как у нас в первом примере будет указываться единственный регион, пользователи которого смогут воспользоваться ресурсом, выбирается тип значения Single-Valued Choice;
Создание ссылочного свойства ресурса

Сам процесс создания ссылочного свойства ресурса несколько отличается от создания обычного объекта свойства ресурса. Прежде всего, именования таких объектов изначально основываются на наименовании предложенных вами созданных ранее типов утверждений. У таких объектов может быть лишь одно их двух существующих типов значений. Почему именно так? Так как ссылочные свойства ресурса напрямую зависят от выбранных вами в соответствующем управляющем элементе типов утверждений, тип значения зачастую представляет собой обычную строку (как видно на следующей иллюстрации), и, как следствие, в качестве типа значения такого объекта по умолчанию определяется Single-Valued Choice, представляющее собой, как было указано ранее, однозначный выбор. В качестве альтернативы этому типу значению, вы можете еще выбрать тип Multi-Valued Choice.
Теперь по поводу этих типов утверждений, которые я несколько раз упомянул в предыдущем абзаце. Выбрать в качестве предложенных значений существующие типы утверждений вы можете непосредственно при помощи управляющего элемента «Выберите тип утверждения для общего доступа к его предложенным значениям» (Select a claim type to share its suggested values). Этот элемент содержит список типов утверждений, которые изначально были настроены с предлагаемыми значениями. Выбрав тип утверждения, его различающееся имя записывается в атрибут msDS-ClaimSharePossibleValuesWith объекта ссылочного свойства ресурса. И ввиду того, что такой атрибут является ссылочным, он обновляется, используя связанный атрибут msDS-ClaimSharePossibleValuesWithBL типа утверждения, согласно различающемуся имени объекта ссылочного свойства ресурса, включающего такую ссылку.
Обо всех остальных опциях, то есть «Описание», «Присвоить идентификатору семантически идентичное свойство ресурса из доверяющего леса, чтобы упростить использование утверждений в лесах, связанных отношениями доверия», «Используется для авторизации» и «Защита от случайного удаления», я писал в предыдущем разделе данной статьи, и они ничем не отличаются от одноименных параметров обычного объекта свойства ресурса.

Рис. 4. Процесс создания ссылочного свойства ресурса

Помимо этого, сразу можно обнаружить то, что все предустановленные объекты свойства ресурса отключены. У каждого такого объекта есть два состояния: отключено и включено. Естественно, отрабатывать будут только лишь те объекты, которые были заблаговременно включены, а те объекты, которые у вас облагают статусом «Отключено» никогда не будут отображаться в диалоговом окне дополнительных параметров безопасности. Следовательно, для того, чтобы их включить, вы можете либо из контекстного меню, либо в области «Задачи» выбрать опцию «Включить» (Enable).

Требования к программному обеспечению

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

Каждый домен, поддерживаючий динамический контроль доступа, должен иметь достаточно контроллеров домена, работающих с поддерживаемой версией Windows Server, чтобы поддерживать проверку подлинности на всех устройствах с поддерживаемой версией Windows или Windows Server.

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

Для доменов, поддерживаюющих утверждения пользователей, каждый контроллер домена, запускающий поддерживаемые версии сервера Windows, должен быть настроен с соответствующими настройками для поддержки утверждений и сложной проверки подлинности, а также для обеспечения бронетехники Kerberos. Настройка параметров в политике административного шаблона KDC следующим образом:

Всегда предоставлять утверждения Используйте этот параметр, если все контроллеры домена запускают поддерживаемые версии Windows Server. Кроме того, установите функциональный уровень домена для Windows Server 2012 или выше.

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

Если домен пользователя и домен файлового сервера находятся в разных лесах, все контроллеры домена в корне леса файлового сервера должны устанавливаться на уровне Windows Server 2012 или более высокой функциональной.

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

Если утверждения преобразуются, когда они покидают лес, все контроллеры домена в корне леса пользователя должны быть установлены на уровне Windows Server 2012 или более высокого функционального уровня.

На файловом сервере с операционной системой сервера, поддерживаючей управление доступом Dyamic, должен быть параметр групповой политики, который указывает, нужно ли получать требования пользователей к маркерам пользователей, которые не имеют утверждений. Этот параметр по умолчанию устанавливается автоматическим, что приводит к **** включению этого параметра групповой политики, если имеется центральная политика, которая содержит утверждения пользователя или устройства для этого файлового сервера. **** Если на файловом сервере содержатся дискреционные acLs, которые **** включают утверждения пользователей, необходимо настроить эту групповую политику для того, чтобы сервер знал, что запрашивает утверждения от имени пользователей, которые не предоставляют утверждений при доступе к серверу.

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

Как и в случае с утверждениями, управлять свойствами ресурса и ссылочными свойствами ресурса можно как средствами «Центра администрирования Active Directory», так и, для реализации автоматизированных сценариев, воспользовавшись богатыми возможностями Windows PowerShell. Ввиду того, что этот цикл статей подразумевает плотное изучение технологии динамического контроля доступа, далее в этой статье будет рассматриваться управление свойствами ресурса при использовании обоих методов. А начинать, опять же, мы сейчас будем с центра администрирования Active Directory. Итак:

Управление объектами свойств ресурса средствами центра администрирования Active Directory
1. На контроллере домена откройте окно «Центра администрирования Active Directory», где в области списка выделите узел «Динамический контроль доступа», а затем выберите узел «Resource Properties» (Dynamic Access Control >Resource Properties);
2. В отобразившемся узле нажмите в области сведений правой кнопкой мыши и из контекстного меню выберите последовательно команды «Создать» и «Свойство ресурса» (New >Resource Property), как показано на первой иллюстрации данной пошаговой процедуры, либо на начальной странице центра администрирования Active Directory перейдите к тайлу динамического контроля доступа и в группе действий Active Directory выберите второе действие, позволяющее создавать новые свойства ресурса. Как в первом, так и во втором случае откроется диалоговое окно создания нового свойства ресурса.
- Отображаемое имя (Display name). В текущем текстовом поле вы должны указать уникальное отображаемое имя для создаваемого вами свойства ресурса. Следовательно, это имя будет фигурировать в узле Resource Properties и в прочих элементах консоли центра администрирования Active Directory. Само собой, называть свои свойства ресурса вы можете в буквенно-цифровом формате. Например, назовем наше свойство ресурса «Region» и перейдем к следующему параметру;
- Тип значения (Value type). Представляет собой раскрывающийся список, откуда можно выбрать логические типы данных, которые уже операционная система будет использовать для описания данных, и которые, собственно, будут храниться в свойствах ресурсов. При создании свойства ресурса можно выбрать любое из восьми доступных типов значения, а именно:
  - Date time. Позволяет создавать свойства ресурса, основанные на логическом типе значения, представляющем собой дату и время. Тут стоит отметить лишь то, что при использовании такого типа значения вы не сможете использовать такое свойство ресурса непосредственно для авторизации (об этой опции подробнее вы узнаете буквально через несколько абзацев). В качестве предустановленных свойств ресурса с этим типом значения выступает свойство «Retention Start Date», которое определяет дату начала периода удержания. В принципе, это не самый распространенный тип значения свойства ресурса;
  - Multi-Valued Choice. Объекты свойств ресурса, которые основаны на текущем логическом типе значения могут содержать по несколько предложенных значений, позволяющих выбрать из сгенерированного списка один или же несколько допустимых значений. В том случае, если для конкретного объекта в редакторе условных выражений дополнительных параметров безопасности вам нужно будет выбрать несколько таких значений, их следует указывать при помощи оператора равно. Во всех остальных случаях достаточно указывать лишь одно такое значение. В качестве примера можно привести предустановленное свойство ресурса Projects, при помощи которого вы можете выбирать проекты, над которыми работают ваши пользователи;
  - Multi-Valued Text. В свою очередь, объекты свойств ресурса текущего логического типа значений могут включать в себя по несколько текстовых записей. Предустановленных объектов свойства ресурса для данного типа не существует;
  - Number. Текущие логически типы значений для объектов свойств ресурсов всего-навсего позволяют вам создавать такие объекты, которые могут включать в себя лишь одно число. Довольно примитивный тип значений, поэтому он не сильно востребован и по умолчанию не создаются объекты свойств ресурсов, использующие этот тип;
  - Ordered List. Те объекты свойств ресурса, которые основаны на этом логическом типе значений, предоставляют единичный выбор предлагаемых значений, которые можно сравнивать с другими объектами свойств ресурса этого же типа. Примером тому служит предустановленный объект свойства ресурса Confidentiality, отвечающий за уровень конфиденциальности ресурса и последующего взаимодействия с принципалами безопасности;
  - Single-Valued Choice. Очередной логический тип значения, на основании которого могут создаваться объекты свойств ресурса, позволяющий также создавать несколько предлагаемых значений для того, чтобы в будущем можно было выбрать из соответствующего списка только лишь одно такое значение. В качестве примера можно привести предустановленный объект свойства ресурса Department, который включает в себя перечень потенциальных подразделений, к которым может иметь отношение целевой ресурс;
  - Text. Логический тип значения, позволяющий создавать для объекта свойств ресурса единственную запись с текстом. Существенно проще предыдущего типа, поэтому, как и в случае с типом Number, используется очень редко, и среди предустановленных объектов свойств ресурсов объект с таким типом обнаружить невозможно;
  - Yes/No. Последний по счету, но не по значимости логический тип значения, позволяющий создавать объекты свойств ресурса со значениями, представляющими собой булевы true или false. В качестве примера можно привести объект свойств ресурса «Personal Use», отвечающий за то, является ли целевой объект рабочим или же личным документом (положительный ответ означает личное использование последнего).
    В качестве примера, так как у нас в первом примере будет указываться единственный регион, пользователи которого смогут воспользоваться ресурсом, выбирается тип значения Single-Valued Choice;
  Создание ссылочного свойства ресурса
  
  Сам процесс создания ссылочного свойства ресурса несколько отличается от создания обычного объекта свойства ресурса. Прежде всего, именования таких объектов изначально основываются на наименовании предложенных вами созданных ранее типов утверждений. У таких объектов может быть лишь одно их двух существующих типов значений. Почему именно так? Так как ссылочные свойства ресурса напрямую зависят от выбранных вами в соответствующем управляющем элементе типов утверждений, тип значения зачастую представляет собой обычную строку (как видно на следующей иллюстрации), и, как следствие, в качестве типа значения такого объекта по умолчанию определяется Single-Valued Choice, представляющее собой, как было указано ранее, однозначный выбор. В качестве альтернативы этому типу значению, вы можете еще выбрать тип Multi-Valued Choice.
  Теперь по поводу этих типов утверждений, которые я несколько раз упомянул в предыдущем абзаце. Выбрать в качестве предложенных значений существующие типы утверждений вы можете непосредственно при помощи управляющего элемента «Выберите тип утверждения для общего доступа к его предложенным значениям» (Select a claim type to share its suggested values). Этот элемент содержит список типов утверждений, которые изначально были настроены с предлагаемыми значениями. Выбрав тип утверждения, его различающееся имя записывается в атрибут msDS-ClaimSharePossibleValuesWith объекта ссылочного свойства ресурса. И ввиду того, что такой атрибут является ссылочным, он обновляется, используя связанный атрибут msDS-ClaimSharePossibleValuesWithBL типа утверждения, согласно различающемуся имени объекта ссылочного свойства ресурса, включающего такую ссылку.
  Обо всех остальных опциях, то есть «Описание», «Присвоить идентификатору семантически идентичное свойство ресурса из доверяющего леса, чтобы упростить использование утверждений в лесах, связанных отношениями доверия», «Используется для авторизации» и «Защита от случайного удаления», я писал в предыдущем разделе данной статьи, и они ничем не отличаются от одноименных параметров обычного объекта свойства ресурса.
  
  Рис. 4. Процесс создания ссылочного свойства ресурса
  
  Помимо этого, сразу можно обнаружить то, что все предустановленные объекты свойства ресурса отключены. У каждого такого объекта есть два состояния: отключено и включено. Естественно, отрабатывать будут только лишь те объекты, которые были заблаговременно включены, а те объекты, которые у вас облагают статусом «Отключено» никогда не будут отображаться в диалоговом окне дополнительных параметров безопасности. Следовательно, для того, чтобы их включить, вы можете либо из контекстного меню, либо в области «Задачи» выбрать опцию «Включить» (Enable).
  
  Управление объектами свойств ресурса при использовании Windows PowerShell
  
  Как в случае с типами утверждений, да и практически с любыми функциональными возможностями Windows Server 2012, управлять объектами свойств ресурса вы можете не только средствами центра администрирования Active Directory, но также для написания сценариев и автоматизации ваших действий можно использовать богатейшие возможности Windows PowerShell. Для управления свойствами ресурсов используются командлеты ADResourceProperty, то есть New-ADResourceProperty для их создания, Set-ADResourceProperty для изменения существующих объектов, а также Remove-ADResourceProperty, который отвечает за удаление последних.
  Итак, сейчас попробуем создать объект свойство ресурса под названием Depart, где будут указаны различные должности (в этом примере Маркетинг, Бухгалтерия, Финансисты), которые должны фигурировать при изменении условного выражения. Значит, следует использовать такой командлет:
  
  Требования к программному обеспечению
  
  Так как утверждения и комплексная проверка подлинности для динамического контроля доступа требуют расширений проверки подлинности Kerberos, у домена, поддерживающего динамический контроль доступа, должно быть достаточно контроллеров домена, использующих поддерживаемые версии Windows, для поддержки проверки подлинности клиентов Kerberos, применяющих динамический контроль доступа. По умолчанию устройства должны применять контроллеры доменов на других сайтах. Если такие контроллеры недоступны, проверка подлинности окончится неудачей. Поэтому необходима поддержка одного из следующих условий.
  
  Во всех доменах, поддерживающих динамический контроль доступа, должно быть достаточно контроллеров доменов с поддерживаемыми версиями Windows Server для поддержки проверки подлинности всех устройств с поддерживаемыми версиями Windows или Windows Server.
  
  Для устройств с поддерживаемыми версиями Windows, которые не защищают ресурсы с помощью утверждений или составных удостоверений, следует отключить поддержку динамического контроля доступа протоколом Kerberos.
  
  В доменах, поддерживающих утверждения пользователей, все контроллеры доменов с поддерживаемыми версиями Windows должны быть настроены для поддержки утверждений, комплексной проверки подлинности и защиты Kerberos. Настройте параметры в политике административного шаблона KDC следующим образом.
  
  Всегда предоставлять утверждения. Используйте этот параметр, если на всех контроллерах доменов используются поддерживаемые версии Windows Server. Кроме того, установите режим работы домена Windows Server 2012 или выше.
  
  Поддерживается. При использовании этого параметра отслеживайте контроллеры доменов, чтобы убедиться в том, что число контроллеров домена с поддерживаемыми версиями Windows Server достаточно для числа клиентских компьютеров, которым необходим доступ к ресурсам, защищенным динамическим контролем доступа.
  
  если домен домена пользователя и файлового сервера находятся в разных лесах, все контроллеры домена в корне леса файлового сервера должны быть установлены на Windows Server 2012 или более высоком уровне работы.
  
  Если клиенты не признают динамический контроль доступа, между двумя лесами должны существовать двусторонние отношения доверия.
  
  если утверждения преобразуются при выходе из леса, все контроллеры домена в корне леса пользователя должны быть установлены на Windows Server 2012 или более высоком функциональном уровне.
  
  У файлового сервера с ОС Windows Server 2012 или Windows Server 2012 R2 должен быть параметр групповой политики, указывающий, должен ли сервер получать утверждения пользователей для токенов пользователей, у которых нет утверждений. По умолчанию этот параметр групповой политики установлен в значение Автоматически, что ведет к его включению при наличии централизованной политики, содержащей утверждения пользователей или устройств для данного файлового сервера. Если файловый сервер содержит списки управления доступом на уровне пользователей, включающие утверждения пользователей, эту групповую политику необходимо установить на Включено, чтобы сервер знал о необходимости запрашивать утверждения от имени пользователей, которые не предоставляют утверждений при доступе к серверу.
  
  Читайте также:
  - Сколько весит kings bounty
  - Сколько платят инкассаторам в некст рп
  - Сколько врат обливиона в игре обливион
  - Как выглядит бан в forza horizon 4
  - Что дает престиж в dead by daylight

Источник

We can configure user and device claim types in Active Directory which can be used as part of Dynamic Access Control (DAC) in a Windows based environment.

DAC was added in Windows Server 2012 to allow administrators to configure custom authorization to a file server by using conditional logic using user and device claim types. This is quite powerful, we can have permissions to a user change and update automatically based on changes to attributes to the user or device itself.

About Dynamic Access Control

Within a domain, DAC allows us to define access control permissions based on rules that we create that set the sensitivity of resources, the job or role of the user, and configuration of the device that will be accessing these resources. A good example of this, is that a user may be assigned different levels of permissions based on how they are accessing a network. They may be assigned a lower level of permissions when connecting from a laptop remotely, and higher permissions from their office machine.

Dynamic Access Control, as per the name, allows a user’s permissions to change dynamically without any extra administrative overhead. DAC is supported in Windows 8 and Windows Server 2012 and above.

Now let’s discuss the different claim types that we’ll be dealing with here.

User Claims: These are Active Directory attributes which are associated with a certain user.
Device Claims: More commonly known as a computer claim, these are Active Directory attributes which are associated with a certain computer object.

Keep in mind that these claims are based on the schema attributes available in AD. If what you need doesn’t exist, it is possible to extend the schema to add what you want. The names on the schema side of things aren’t always clear, I suggest using this table of mappings for user interface objects. For example we can see that ‘l’ is Locality-Name, which is used for specifying a town or city.

For instance we could say a user has a location claim of being in the location of US. We might then have a computer with a device claim listing its location as the US. We could then have a central access policy that says users in the location US are allowed access to devices in the location US. If we update the location of the user object in AD, the user will no longer have access.

Configure User and Device Claim Types

First open Active Directory Administrative Center. This can be done through Server Manager > Tools > Active Directory Administrative Center, or by simply typing ‘dsac’ into PowerShell. Select Dynamic Access Control from the menu on the left, followed by Claim Types.

From here we can select New from the menu on the right to create a new claim type. This opens the Create Claim Type window.

From here you can select which claims are to be used when defining permissions. In the select an AD attribute to base this claim type on search box, we simply enter ‘l’. As mentioned previously, this is Locality-Name. We can then specify a display name for this claim type, I’ve named this one “City”. We can then tick to select if the claim can be issued by users or computers, as this is a user claim this has been selected. The claim can optionally be filled with suggested values to use.

Finally select OK to create the claim type. We should now see it listed under the list of claim types.

We have now successfully created a user claim type based on the Locality-Name attribute. In the same way we could also configure a device claim type by instead selecting the computer check box rather than user.

Summary

As shown we can configure user and device claim types from within Active Directory Administrative Center in Windows Server 2016. This is done through Dynamic Access Control > Claim Types, followed by selecting new claim type.

Источник

Remove From My Forums

Question
Hello All:

Does anyone know, what is going on with Dynamic Access Control (DAC) in Server 2016 or beyond?

Server 2016 Preview 2 appears to have no new enhancements for DAC. Is anyone at Microsoft working on DAC? Is DAC going to be deprecated like NAP or rolled into some kind of larger DLP feature set?

Thank you for any insights or links!!!

J.
- Moved by
  
  Thursday, May 14, 2015 9:29 AM

Answers

[Microsoft — Nir Ben-Zvi]

Thanks for your question. DAC is shipping with Server 2016 with no new enhancements.

DAC includes a wide range of technologies so if there are specific enhancements that you would like to see, please be sure to let us know — you can use the «User Voice» to both add and vote on suggestions

http://windowsserver.uservoice.com/forums/295065-security-and-assurance

Regards,

Nir
- Proposed as answer by
  Meinolf Weber
  Friday, May 15, 2015 7:19 AM
- Marked as answer by
  Jessicu
  Thursday, July 16, 2015 6:44 PM

Источник

В предыдущей статье мы рассмотрели теоретические аспекты технологии 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 configurationPoliciesAdministrative TemplatesSystemKDC выбрать параметр «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, не смогут аутентифицироваться в домене.

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

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

Настройка DAC производится из оснастки Active Directory Administrative Center. Открыть ее можно из меню Tools в Server Manager, либо командой dsac. Все шаги по настройке по пунктам расписаны прямо на главной странице 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, с помощью которых производились операции с клаймами. Их можно скопировать и использовать при написании скриптов.

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

Переходим раздел 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 — свойство представляет из себя дату и время. Этот тип нельзя использовать для ограничения доступа к ресурсу;
• YesNo — свойство представляет из себя булево значение типа 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 на редактирование.

Переходим в раздел Computer ConfigurationPoliciesWindows SettingsSecurity SettingsFile SystemCentral Access Policy. Кликаем правой клавишей и выбираем «Manage Central Access Policies».

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

Аудит

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

Для включения аудита надо перейти в раздел Computer ConfigurationPoliciesWindows SettingsAdvanced Audit Policy ConfigurationAudit PoliciesObject 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. Если вы хотите знать больше, то вот здесь есть пошаговые инструкции по развертыванию, а здесь можно загрузить подробное описание технологии (на английском).

Источник

В 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.

Источник

Central access rules

Central access policies

Claims

Expressions

Proposed permissions

Additional changes

Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.

Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.

Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.

Support in Active Directory to store user and device claims, resource properties, and central access policy objects.

Support for using Group Policy to deploy central access policy objects.

Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing

Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts

Software requirements

Additional resource

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

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

Претензи

Выражения

Предложенные разрешения

Дополнительный ресурс

Дополнительные изменения

Поддержка в протоколе проверки подлинности Kerberos для надежного предоставления утверждений пользователей, утверждений устройств и групп устройств.

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

Поддержка в Active Directory для хранения утверждений пользователей и устройств, свойств ресурсов и объектов политики центрального доступа.

Поддержка использования групповой политики для развертывания объектов политики центрального доступа.

Поддержка авторизации файлов на основе утверждений и аудита для файловой системы с помощью групповой политики и аудита глобального доступа к объектам

Поддержка преобразований или фильтрации объектов политики утверждений, которые пересекают доверия леса Active Directory

А что для динамического контроля доступа представляют собой ресурсы?

Обзор динамического контроля доступа

Правила центрального доступа

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

Утверждения

Выражения

Предлагаемые разрешения

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

Управление объектами свойств ресурса при использовании Windows PowerShell

Дополнительные изменения

Поддержку протокола проверки подлинности Kerberos для надежного предоставления утверждений пользователей, утверждений устройств и групп устройств.

Поддержка использования групповой политики центра распространения ключей (KDC) для обеспечения динамического контроля доступа в домене.

Поддержка использования групповой политики центра распространения ключей (KDC) для обеспечения динамического контроля доступа в домене.

Поддержка сохранения утверждений пользователей и устройств, свойств ресурсов и объектов централизованных политик доступа в Active Directory.

Поддержка использования групповых политик для развертывания объектов централизованных политик доступа.

Поддержка преобразования или фильтрации объектов политики утверждений, просматривающих отношения доверия лесов Active Directory

А что для динамического контроля доступа представляют собой ресурсы?

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

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

Управление объектами свойств ресурса средствами центра администрирования Active Directory

Создание ссылочного свойства ресурса

Требования к программному обеспечению

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

Управление объектами свойств ресурса средствами центра администрирования Active Directory

Создание ссылочного свойства ресурса

Управление объектами свойств ресурса при использовании Windows PowerShell

Требования к программному обеспечению

About Dynamic Access Control

Configure User and Device Claim Types

Summary

Question

Answers

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

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

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

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

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

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

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

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

Аудит

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

Заключение

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

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

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

Заключение