Dynamic Access Control: Reshaping Resource Management

As every Windows system administrator knows, starting with the Windows Server 2008 server operating system, such a crucial, complex role that allows you to effectively manage identity and access in organizations, like Active Directory Domain Services, has been divided into as many as five roles. More specifically, it is clear to everyone that the main task of the Active Directory Domain Services role is the execution of authentication and access operations. That is, here you have tasks related to authentication and authorization, and there are also opportunities to create and manage security principals, sites, services, and trust relationships. The same role can be safely attributed to the centralized setting of workplaces, implemented by means of the functionality of group policy, and much more. In addition, in order to take advantage of all the rich features of directory services, you can also work with other server roles.
SPOILER : This article is purely theoretical material, and this article does not imply any step-by-step procedures.
Consider such roles. As I said above, there are four of them, namely:

• Active Directory Certificate Services, namely Active Directory Certification Services, AD CS . Midsize and large organizations can also host AD CS Certificate Services in the PKI PKI in order to create a certification authority for issuing digital certificates that bind a user, device, or service identification object to the corresponding private key. In other words, AD CS provides an efficient, secure way to self-issue certificates and, as a result, to manage them;
• Active Directory Rights Management Services - Active Directory Rights Management Services , that is, AD RMS . The capabilities of this server role, which, by the way, are neglected by many, provide information protection technology, with which you can implement patterns of robust usage policies that define allowed and unauthorized use on and off the network, as well as inside and outside the firewall perimeter;
• Active Directory Federation Services , which in English sounds like Active Directory Federation Services , or simply AD FS . Using these services, an organization can in some way extend the identity and access infrastructure across multiple platforms, including not only Windows environments, and also provide trusted partners with IDA protection outside the security perimeter. In a federation environment, organizations are given the opportunity to support and control their own identification objects;
• Lightweight Directory Services , that is, Active Directory Lightweight Directory Services , or simply AD LDS . This role is, roughly speaking, an LDAP directory that stores only application data that requires access to the directory store, but which information should not be replicated to all domain controllers.

And if we add the read-only capabilities of domain controllers, virtualization of domain controllers, as well as new features such as activating operating systems through Active Directory and the history of Windows PowerShell cmdlets, we can conclude that the capabilities of Active Directory are almost endless. . However, if you look at how access to information is provided, then we can say that everything is completely sad. After all, NTFS-based rights do not allow you to control access to documents according to some strict file classification, do not allow granular auditing according to any specific policies, do not provide the possibility of generating “access requests” and still have a certain number of restrictions.
But now, with the release of such a server operating system from Microsoft as Windows Server 2012, all these file access restrictions through access control lists, that is, ACLs, can be forgotten, since a technology called Dynamic Access Control ), which allows you to control access to information based on specific attributes or certain criteria. Starting from this article, I will tell you about this wonderful technology, you will learn about how you can use it, about various scenarios, about what statements are (also in some cases referred to as applications or clauses, because in English it sounds as a claim ), what are the properties of the resource. You will also learn about centralized access policies and rules, how exactly you can publish and apply such centralized access policies, learn about auditing, classify various files and folders, troubleshoot dynamic access control issues, and about many other things.
Naturally, looking at all these points about which I just wrote, it is immediately clear that one article on this technology can’t be bypassed, and therefore, figuratively speaking, I will try to fully disclose this technology for 6-10 articles, having considered most possible scenarios, subtleties of this technology, as well as examples based on the use of Active Directory Administrative Center and Windows PowerShell tools, which is also important.
What exactly do you learn from this, first, article on such technology as dynamic access control ? And from this article you will learn more about the following points:

• About what this technology is intended for;
• About how this technology is better than providing access based on ACLs;
• Learn about the benefits and limitations of current technology;
• And also I will talk about several scenarios in which it would be expedient to use dynamic access control and centralized access policies.

Well, let's get started.

The purpose and differences of dynamic access control from ACLs

As I have already noted in the large introductory part of the first article devoted to this technology, dynamic access control allows you to take a fresh look at the mechanism for providing general access to corporate resources located primarily on domain controllers and file servers running the Windows Server 2012 operating system. So why can we look at granting access in a new way, and why wasn’t the access control lists so pleasing?
First of all, let us remember how access to resources was provided before the release of this, still mysterious, technology.

As previously assigned access permissions?

Speaking in general terms, access control permissions are assigned to shared objects and Active Directory objects to determine how different users can use each object. As everyone knows, not only the administrator, but also a regular PC user, a shared object or shared resource is an object that is intended to be used by one or several users over the network. Naturally, such objects can be files, printers, folders and services. In Active Directory, access control was performed at the object level by setting objects for different levels of access or permissions, such as “Full access”, “Write”, “Read” or “No access”. Access control permissions for both shared objects and Active Directory objects are stored in their security descriptors.
The security descriptor contains two access control lists (ACLs) used to assign and control security information for each object. Of course, this is a selective access control table (DACL) and a system access control table (SACL).

• Discretionary access control list (DACL) polling tables . As it is known from official sources, the DACL identifies users and groups that are explicitly allowed or denied access to the object. For an understandable reason, if a particular user or groups into which he belongs are not explicitly listed in the DACL, this user will be denied access to the object. By default, the DACL is controlled by the owner of the object or by the user who created the object, and contains Access control entries ( ACE ) that determine the user's access to the object;
• System Access Control Tables (System access control list, SACL). In turn, the SACL indicates the users and groups for which an audit of successful and unsuccessful attempts to access the object is required. An audit is used to monitor events relating to the security of a system or network, as well as to detect deficiencies in the security system and to determine the extent and location of any damage. By default, as with the DACL, the SACL is controlled by the owner of the object or the user who created it. The SACL contains access control entries that determine whether successful or unsuccessful attempts by a user to access an object using this permission, such as Full Access or Read, are recorded.

By default, DACL and SACL are associated with each Active Directory object, which reduces the likelihood of malicious attacks by network users and random errors of domain users. However, if an attacker finds out the name and password of any account that has Active Directory administration rights, this forest will be vulnerable to attack.
Also, do not forget that by default Active Directory objects inherit ACE from the security descriptor of the parent container object. Inheritance allows you to apply access control information specific to an Active Directory container object to the security descriptors of any subordinate object, including other containers and their objects. This eliminates the need to apply permissions to each new child object. If necessary, you can change the inherited permissions. However, it is recommended not to change the default permissions and inheritance parameters of Active Directory objects.
Although the authorization process looks to the user as a single event, it consists of two parts:
The user provides access parameters, usually a username and password, which are then checked in the AD DS database. If the username and password coincide with the information stored in the database, the user becomes authorized, and the domain controller for him is issued a ticket to get a ticket. At this stage, the user does not have access to network resources.
The secondary background process passes the ticket to the domain controller for review and requests access to the local machine. The domain controller issues a service ticket to the user, which can then interact with the local computer. At this stage of the process, the user is authorized in AD DS and registered on the local machine.
When the user subsequently attempts to establish a connection with another computer on the network, the secondary process is restarted, and the ticket for receiving the ticket is submitted to the nearest domain controller for review. When a domain controller returns a service ticket, the user gets access to a computer on the network that generates an authorization event on that computer.
A computer connected to a domain is also authorized in AD DS at startup — a fact that is often overlooked. You do not see the transaction when the computer uses its account name and password for authorization in Active Directory Domain Services. After authentication, the computer becomes a member of a group of authorized users. Although the process of authorizing a computer does not have a visual confirmation in the graphical user interface, it is worth remembering that there are event logs that record this activity. In addition, if auditing is activated, more events available for viewing will be added to the Event Viewer security log.

And what better dynamic access control?

Actually, based on what constitutes access based on access control lists, it can be concluded that when using this method, permissions are granted solely on the basis of the membership of the target object in a particular group. You cannot restrict or, on the contrary, allow access for a specific user device based on some third-party characteristics, and also, of course, you can immediately forget about any non-standard scenarios.
Dynamic access control , in turn, removes these restrictions and allows you to create more granular rules, based on which you can grant access according to various criteria. In other words, first of all, you should pay attention to the fact that this technology provides the ability to control access to files and data through the creation of centralized security policies, allowing the most detailed way to determine who has the right to use this or that information. In other words, you can create policies that best reflect your business strategy and fully comply with any regulatory requirements. Moreover, you can identify such information when using file classification, both in manual and automatic mode. Only these two possibilities can almost instantly put access control on blades when using ACLs.
However, this is not all. The most common types of data that can be accessed are office documents, that is, files that can be managed using Microsoft Office products. Previously, to set specific users or groups unique permissions with document encryption, Active Directory Rights Management Services (AD RMS) was used for each such document. This technology has proven itself well and now, with the advent of dynamic access control, you are given the opportunity to apply RMS protection using automatic encryption based on specific criteria.
Nowadays, one of the most valuable assets of many companies is nothing more than information itself, which should not go beyond the organization. The improper use of such information may adversely affect the future of the entire company. Thanks to the centralized audit policies of this technology, you can create reports for further auditing access to files or, if absolutely necessary, forensic analysis. In other words, you will not need to resort to the use of any third-party applications and software products.
What else can be distinguished besides this? And you can emphasize that you can use the current technology without making changes to the Active Directory scheme without deploying additional roles or some specific software, and, in general, as they say, "right out of the box." Moreover, specifically for the implementation of the use of dynamic access control, a new authorization and audit mechanism was developed for Windows operating systems, as well as for Kerberos authentication capabilities, some innovations were implemented, which I already wrote about in the third part of the article on Kerberos, which was called “ Network authentication protocol Kerberos or why claims are needed . "

Does he have any restrictions?

Unfortunately, as one would expect, this technology also has a number of limitations. First of all, Active Directory Domain Services must be deployed in the organization. That is, if you want to use dynamic access control for computers that are part of a workgroup, nothing will come of it. Secondly, dynamic access control is not just a separate feature. This technology is a file server solution built on the basis of the Windows Server 2012 infrastructure, including support for direct Kerberos approvals, Active Directory support specifically for storing resource properties, as well as user and computer statements, Active Directory support specifically for storing centralized access policies, implementation distributing such centralized access policies through Group Policy functionality, and much more.
Therefore, according to all these requirements, we can draw the following conclusion: at least one domain controller running Windows Server 2012 operating system should be deployed in your organization, and if there are several domains in your forest, then each Such a domain should have at least one domain controller deployed under Windows Server 2012. This is done specifically to allow claims to be used between domains for which trust relationships are established. Moreover, as I said before, in Windows Server 2012, the KDC service has been significantly improved specifically to work with assertions within the Kerberos ticket.
The operating system on the file server, of course, must be Windows Sever 2012. When a user connects to a shared folder, the file server checks the access to the resource using the credentials of the incoming connection. This means that the file server determines access to a shared resource. It also means that the various components on the file server must support assertions, such as LSA and the Kerberos application server. It turns out that the file server on which the data will be located, to which users will have access, should be able to read the device authorization and authorization data from the Kerberos ticket, translate these security identifiers (SID) and ticket approvals into the authentication token and compare the authorization data in the token with the conditions included in the security descriptor. That is, older versions of the OS, as a result, will not work.
Well, in the event that you have specified approvals for devices, only clients running Windows 8 or Windows Server 2012 operating systems can be used as clients. In other words, this restriction can be called a weighty reason for migrating clients to the eight.

Key scenarios for using dynamic access control

Now, regarding more lively moments - the scenarios themselves, in which it is advisable to use dynamic access control. By and large, many scenarios can be modeled, but seven main ones can be distinguished, namely:

• Centralized deployment of authorization policies . First of all, one of the main tasks of this technology is to create centralized access policies for company files, allowing users or their devices to access files on the basis of specific conditions, as well as, obviously, managing such policies. They are created solely on the basis of the needs of each particular company, which makes this technology particularly valuable. How this scenario is implemented:
  
  1. First of all, you need to assess the direction of your business and determine how such policies will work. That is, to begin with, you must determine why you generally need centralized access policies, in other words, you localize the resources for which such policies should be applied in the future. After that, a list of all policies that you will apply in your environment is created. If you talk not so blurry, then you conditionally divide your file resources into departments, into specific categories, and in the case of a large number of branches you think about how it will be more profitable to restrict access depending on the physical location, and so on;
  2. Then comes the implementation of access policy expressions in the Windows Server structural components in a form that is understandable to the server. What does this whole set of words mean? And it means that the second step in the implementation of this scenario is the transformation of the access policy required for you into the correct expression. Such policies, by and large, are very easily converted from the usual, understandable to everyone, form into the language required to provide authorization to the principals of security. That is, such access policies have rules of applicability , access conditions , and exceptions . All of us will discuss this in great detail in one of the following articles of this short cycle;
  3. After that, task number three is to define user groups, properties of resources, and also required assertions. That is, now you need to analyze what specific resources and for which security principals the statements created for each centralized access policy will apply;
  4. And, obviously, the last item for you will be the definition of servers to which such centralized access policies will apply. For example, you can distribute such policies both to all file servers at once, and to servers, according to their original purpose.
• Implementing statements between forests . The Windows Server 2012 operating system was designed so that it can use so-called statement dictionaries in every forest, all of which will be defined directly at the level of Active Directory Domain Services. Baseline scenarios represent a situation where a client needs to obtain an access claim that will somehow bypass the trust boundary.
  It is obvious that statements refer to objects with which they are associated, and their own types of statements are defined for each Active Directory forest. Cross-forest claims transformations allow them to be recognized and applied in trusted and trusted forests. To make it a little clearer:
  A trusting forest can be used to transform assertions to avoid attacks associated with elevated privileges, by filtering incoming assertions according to specific values. They also issue statements for principals across trust boundaries in the event that trusted forests do not support or do not issue certain statements.
  In turn, trusted forests can use assertion conversion to prevent certain types of assertions, as well as to prevent assertions with certain parameters from penetrating into the trusting forest.
  By the way, it is very important to understand that the creation of assertion conversion policies involves two components, namely, assertion conversion policy objects, as well as conversion links. These moments, like the scenario in particular, will be discussed in more detail in the relevant article on this technology.
• Improved support for users who have been denied access . In principle, the regular situation: user N comes to work and receives a task related to some specific information located on the file server, but access to which is not provided to such a user. What happens next: the same user N tries to go to the shared folder, but when he tries to open one he gets the only answer that says: “Access is denied”. After that, the user contacts the support service and, as practice shows, in an understandable form only for this user, he will try to explain to which documentation he needs access, why he is needed, where such documentation is located, and so on.
  What is the advantage of using dynamic access control? , , , .
  . , , . . Microsoft? , , :
  
  1. , . , , , . , - . , ;
  2. , , , ;
  3. , ;
  4. , . , , ;
  5. , . - .
• . , – , , , , . , - , , . , , ( DFS-R), , . , , - , .
  Windows Server 2012 , , , , . , , , . , , . :
  
  1. , . ? , , ;
  2. , , - , . , , , , , , , . .
• Microsoft Office . AD RMS… . , , . . Active Directory. , Windows Server 2012, , Microsoft Office, , , . :
  
  1. , , . , , . - , . , . , . , , , , , ;
  2. , . , , , , AD RMS. , . -, , , . , , . ;
  3. , , , , - .
• . , : ? , « , , ». , . , , . , -, - , . , , , , , Microsoft. , , , - . , , :
  
  1. , , , , . , ;
  2. , , . , , .
• . , , . ? , , . : ? , , , , , .
  ? -, . : , , . -, , . , , , , , , , , , . , , - , - , , , .
  , , , , .

?

I myself know perfectly well that at times a purely theoretical part can be very dull, especially if a lot of material is immediately served. However, any practice without a theoretical basis is the wrong approach to studying the material. In the following articles of this cycle, as I have already noted earlier, you will learn about what are assertions, how they are created, and which pitfalls can be encountered during this process; You will learn about the properties of the resource. I will dwell on the various nuances in creating centralized access policies and rules, and, of course, I will be told how to publish and apply such centralized access policies. All scenarios that were briefly mentioned in several paragraphs above will be considered.You will learn something about auditing, and we'll look at the classification of various files and folders. Moreover, I will definitely devote a separate article to the issues of troubleshooting possible problems associated with dynamic access control.
In general, I hope that this article was not too tiring for you and you have not lost the desire to learn more about the use of this technology. In turn, the following articles, naturally, will not have an abundant amount of theoretical material, and they will mainly consider scenarios, various procedures and step-by-step examples of using this technology.