Geekly Articles each Day
📜 ⬆️ ⬇️

Dynamic access control: how to work with assertions

In the previous article in this series, I briefed you a little bit and explained what dynamic access control is, how it differs from providing access based on ACLs, its advantages, and also - in two words - o the most frequent scenarios, when it is appropriate to apply this functionality. The article was a bit cumbersome, filled with purely theoretical material, and, indeed, difficult to read, since it contained no descriptions of any step-by-step procedures.
Starting with this article, I will try to improve and tell you about how to begin acquaintance with this technology. And, as can be seen from the title of the article itself, it should be nothing more than a statement (they, as I already wrote in the previous article, are also called applications, claims and other words that can be replaced with a claim ), which can be safely attributed to one of the main components of dynamic access control. Now I will try to give as little as possible theoretical material and almost immediately go to the step by step procedure. So, what can you learn from this relatively small article?
And in this article I will tell you:

Well, in order not to drag out the introductory part of this article, let's move on to the first section, which is called:

What are statements and what will be their benefits?


I'm afraid to make a mistake, but, most likely, in our time there is no longer a user who has not at least once provided access to some of his public folder. Especially for this purpose, even in the distant past of Windows NT, Microsoft introduced such a notion as identification into operating systems that has been firmly established for many years. Everything is obvious here: as I mentioned in one of my articles, access to files and resources was based directly on security identifiers. It turns out that access to public file resources was provided based on whether the user’s authentication was successfully completed according to his credentials. Of course, in most cases, such credentials represented the account name and password, or the user's belonging to a specific group. You all perfectly know the concept of identification and, I think, there is no point in dwelling on it once again.
But practice shows that in some cases (there are quite a lot of such cases), due to membership in various groups, users may accidentally be given access to such resources, access to which they simply are not allowed. To get rid of such cases, in the latest operating system from Microsoft was introduced a new concept, which is called, you guessed it, assertion . Consider what it is.
What is the majority of the population who hear a new or incomprehensible word now? They drop in on Wikipedia. What does it say about this? “Approval in linguistics is a special form of sentence, which in an affirmative form puts forward a hypothesis about a certain phenomenon.” Definitely not it.
What else can you find? “A logical statement is a statement formed from other statements with the help of logical connectives.” Also not suitable. "A statement in programming is a predicate placed in a program and indicating that the developer means this predicate in this place of the program is always true." But still, it seems that all this is not what is meant in the current context.
In fact, according to official terminology, claims are a trusted source of account information attempting to perform the authorization provided in the attributes of this account, which is stored in Active Directory Domain Services. Various statements include many properties, such as the security identifier of the user himself or his computer, the unit in which the user can work, his room number, and the city in which he lives. And you should pay attention to the fact that several statements can be stored in one record, which allows you to make dynamic access control policies flexible enough to satisfy almost any possible need.
At this stage, you may have a completely logical question: what do these statements give us and what is the point? With statements, you can restrict access to both files and folders. And the most valuable thing in statements is that all created statements will be published directly in Active Directory. And, as I mentioned in the previous article on this technology, for the full functioning of dynamic access control in general and assertions in particular, there are no restrictions regarding the functional level of the domain or forest of your organization.
Since I talked in detail about the connection of Kerberos with statements in one of the articles on the Kerberos network authentication protocol, the link to which I gave in the previous article of this series, we will immediately proceed to a topic such as:

Types of Claims


According to the official definition, the type of assertion in Windows Server 2012 is the verification statement about the object with which it is associated. As you have probably already guessed, the type of claim is based on the Active Directory attribute and serves to determine permissions when developing centralized access rules. In the Windows Server 2012 operating system, you can use any of the following three types of statements:

Conditional Expressions and Operators


Slowly we will move on to the more interesting part. More specifically, we will now consider conditional expressions that relate to the OS security subsystem, which appeared in the Windows Server 2012 operating system specifically so that you can implement assertion-based authorization support.
What are these conditional expressions that relate to assertions? In essence, these conditional expressions are Boolean or logical expressions, which, as a rule, include two operands separated by a special operator. As a result of conditional expressions, there can always be only two values, and more precisely, these can be TRUE and FALSE. Here you should also pay attention to the fact that ACE expressions are evaluated both in the case of authorization and during an access audit, therefore, the same expressions can be used in both the first and second cases.
And what happens with these expressions? I already wrote earlier that the LSA subsystem reads the required information from the PAC and creates access tokens. After that, based on the information provided by the user, an access check is performed and, based on the permissions assigned in the security token, it is determined whether the end user is allowed or denied access to the resource. This is all clear. However, with the advent of claims in the Kerberos authentication information, in addition to the security principal’s SID, it also became possible to include additional information that can be found in these conditional expressions.
The statements themselves are a collection of such entities as the type of statement and the name of the statement, and they must be separated by a period (you will see this below). The first part, obviously, is used directly to determine the type of assertion, which, as we clarified in the previous section, can act as a User or Device . Before mentioning an assertion type, the @ symbol must be specified, followed by the type itself. The part with the name of an assertion is simply a name that you can give to such an assertion when it is created.
The left and right parts of an assertion expression must be compared by a special operator, and the right operand may be a literal value, which may be a fragment of the value of the left operand.
In total, 13 operators can be identified, which, most likely, you should already be known for working with other software products. I will not talk in detail about each such operator, but simply give their values. This operator is equal ( == ), not equal ( ! = ), Greater than ( > ), less than ( < ), greater than or equal to ( > = ), less than or equal to ( <= ), not ( ! ), And ( && ) , or ( || ), contains ( Contains ), that is, when using such an operator, the left operand must contain a fragment of the right operand; any of ( Any_Of ), the purpose of which is somewhat similar to the previous statement, except that only a fragment of the value of the right-hand operand can act as a value; a member of a group ( MemberOf ) is practically the same as it contains , only SID acts as an operand, as well as the operator of any member of the group ( MemberOF_Any ), which can also be compared with the operator of any of .
Now let's try to consider an example of conditional expressions that can be used with assertions when implementing dynamic access control scripts. For example, take the following expression:
 
  @ User.Department == ”Marketing” && (@ User.Title == ”Financier” || @ User.Title == ”Marketing”)

This expression can be divided into three parts, and each such part uses assertions, and the second and third parts, which are in brackets, will be processed simultaneously. Now a little more detail and in parts.
Based on the priorities of conditional expressions, the first should be executed expressions that are located in brackets. Here in brackets you can find two operators: == and ||. Again, if you look at priorities, the == operator should always be processed first. Therefore, the expression is processed from left to right.
Here, the type of user approval is User .Title, which is responsible for the position of your employee. So, we check whether the post of "Financier" is a user. Suppose that our user is a marketer, which means that in the first expression the value is FALSE, that is, false. However, between two expressions, we have the operator ||, which means a logical "OR". This means that if the second expression is true, then the leftmost conditional expression will be checked.
In our case, since the user is a marketer, the second conditional expression in parentheses will be TRUE, and this means that conditions can be checked further. At this stage, we get the following expression:
 
  @ User.Department == ”Marketing” && (FALSE || TRUE)

This means that the expression can be reduced even more, to:
 
  @ User.Department == ”Marketing” && TRUE

After that, the leftmost conditional expression is checked. Here, I think everything is clear. It is checked whether the department of our user is “Marketing” . Since our user is a marketer, let's assume that his department is the marketing department, which means that the expression is true. We get the following:
 
  TRUE && TRUE

Since the && operator is a logical AND, this means that both conditions must be true. In our case it is. Therefore, the condition is true and access will be granted. If FALSE figured here somewhere, then with the && operator it would prevail, and ultimately we would get the result FALSE.
In other words, we get an expression that is shown in the following illustration:


Fig. 1. An example of a conditional expression in the folder permission dialog box
QUESTION for the attentive reader: what is the following conditional expression, and how the check will be performed, if we consider that we are dealing with the same user, which was discussed above:
 
  (@ User.Title == ”Accountant” || @ User.Title == ”Financier”) ||  @ User.Department! = ”Support Service”

And what are the objects of the statements themselves?


As you know, in the Active Directory schema you can find a description of all the objects you can work with in Active Directory Domain Services. And the objects of dynamic access control technology are by no means an exception. So far at this stage, I see no reason to describe all objects that have a particular relationship to the current technology, but simply note that there are 9 such objects (there are almost three times more attributes), but in the case with the statements considered at this stage , you can select only two objects, namely:

The objects of the msDS-ClaimType class are depicted in the following illustration:


Fig. 2. Objects of the msDS-ClaimType Class

Claims Management


Due to the fact that in the latest server operating system from Microsoft, developers tried to devote directly to tools such as the Active Directory Administrative Center , as well as the Windows PowerShell command shell, you can manage your claim types using the first and second tools. facilities. Since it would be unfair to consider only one tool, in the following sections I will show how to work with statements using these two tools of administration. And we begin, naturally, with

Claims Management by Active Directory Central Administration Tools


In principle, the already purely theoretical part has dragged on for a long time, so without unnecessary preludes, I will probably get to the bottom. So, to create a claim that will be used for subsequent centralized access policies using Active Directory Central Administration tools, you will need to perform the following steps:
  1. On the domain controller, open the Active Directory Administration Center window, where in the list area, highlight the Dynamic Access Control node, and then select the Claim Types node ( Dynamic Access Control > Claim Types );
  2. In the displayed node, right-click in the details pane and from the context menu, select New and Claim Type ( New > Claim Type ), as shown in the following illustration, or go to the dynamic tile on the home page of the Active Directory Administrative Center access control and in the Active Directory action group, select the first action, called creating an assertion type. Both in the first and in the second case, the dialog box for creating a new type of statement will open.
    ')

    Fig. 3. Opening the dialog box to create a new type of approval
  3. When the “Create Approval Type” dialog box appears in front of you, in the Source Attribute section, you can decide on the source attribute and additional configuration items on the basis of which your approval type will be created. As you can see in the following illustration, the first thing that can catch your eye as soon as you open the current dialog box is the large Source Attribute list, which contains many different attributes, from which you can select the desired source attribute for your created approval. Such a list is formed from a number of classes of objects, which include the classes User , Computer , inetOrgPerson , ManagerServiceAccount , GroupManagerServiceAccount , as well as auxiliary classes of objects. When choosing attributes, be sure to note that only attributes with string values, including Unicode, Boolean values, integers, including large integers, as well as OID and SID strings appear in the current list. Also, of course, this list will not display attributes that are not replicated, blocked attributes, and attributes that are not available on read-only domain controllers (that is, RODCs). For example, in this case, the department attribute is selected, but note that before you select an attribute, prematurely plan the structure of your statements for subsequent centralized access policies.


    Fig. 4. Section "Attribute source" created type of approval
  4. In addition, this section of the approval type creation dialog box also provides other parameters, namely:
    • Display Name . Represents a text field containing a unique display name that is assigned to the type of claim you created. Such a name will figure to perform subsequent operations, so it will be best if you use readable and understandable names in the future as such a name. Naturally, alphanumeric values ​​are available for the type of statement that is being created;
    • Description ( Description ). Represents a comment field for the type of claim you create. The number of characters in this field is limited - 1024 characters. Therefore, when adding your comments and goals for using the type of statement being created, you should be concise;
    • This type of statement can be issued for the following classes ( Claims of this type can be issued for the following classes ). A control element that allows you to choose whether an assertion will apply only to certain types of security principals (for example, only to users or only computers), or by checking both boxes, you can allow the current type of approval for both types of accounts to be used;
    • Assign a semantically identical type of statements from a trusting forest to an identifier in order to simplify the use of statements in a forest associated with a trust relationship ( Set ID to a semantically correct claim ). Represents a checkbox to define a method for creating an assertion type identifier. If you do not set this flag, the Active Directory Administrative Center will assign this identifier automatically. What does he look like? This identifier begins with the lowercase letters ad , followed by a colon, two slashes, the letters ext, and another slash ( ad: // ext / ). This is the standard beginning of the identifier. After that, the administration center adds the name of the attribute you selected and after the colon is added in random order a value in hexadecimal format, which to some extent can remind you of a regular GUID. That is, ultimately, the identifier in this example looks like this:
      ad: // ext / department: 88d0094e632018a6
      In turn, if you create an assertion type for forests that are linked by a trust relationship, then by default, metadata for each type of assertion will be unique for each forest, and as a result, domain controllers in the trusting forest will not be able to process assertions from the trusted forest. For this reason, you need to make sure that the identifier of the type of statement being created will be semantically identical between trusted and trusted forests. Therefore, this flag should be set only in the above case. Of course, if you specify an identifier manually, then it must correspond to the naming context, which was mentioned a little earlier. Be sure to remember how each identifier should begin, after ext / there should be no more than 32 characters, which should not contain special characters and end with a slash. These are mandatory conditions. And, of course, remember that such identifiers must be unique;
    • Protection from accidental deletion ( Protect from accidental deletion ). The checkbox, which, as in the case of operations you already know in Active Directory, protects the type of assertion being created from inadvertent deletion. Despite the fact that by default, only administrators can create, change and delete assertion types by default, in some cases this option may come in handy.
  5. The section called “ Suggested Values ” ( Suggested Values ) is responsible for predetermining selectable values ​​that you can choose using the approval type in a conditional expression. As you can see in the following illustration, here you can focus on the choice of the following values:


    Fig. 5. Section "Proposed Values" of the type of statement being created
    • No suggested values ( No values ​​are suggested ). Parameter that is set by default when creating any type of statement. It assumes that you will not override the values ​​for the types of statements, and such values ​​will be typed manually when creating the conditional expressions themselves;
    • The following values ​​are suggested ( The following values ​​are suggested ). In this case, you can create one or several values ​​that will be available for selection from the corresponding list during the subsequent creation of a conditional expression. Therefore, to work with such values, you can use the Add , Edit and Delete buttons ( Add , Edit and Remove ), which can be found in the current section of the properties dialog box of the type of approval being created. How exactly are such values ​​created?
      When you click the "Add" button , you will see the "Add proposed value" dialog box where you can find three text fields: " Value ", which is the recommended value in the corresponding text field of the conditional expression, "Display Name" ( Display Name ) - the name that will be responsible for the current value and will appear when choosing such a value, as well as “ Description ” ( Description ), which is responsible for an arbitrary description for such a value.
      :


      Fig. 6.
  6. . Is done.

, , : . , . , « » ( Disable ).

Windows PowerShell


PowerShell , , . , Microsoft , , .
, , , Active Directory Windows PowerShell. PowerShell, , , , . , , , Active Directory.
, ( ), , . :
, New-ADClaimType . 21 , . , . :
 
New-ADClaimType –AppliesToClasses:@('user') –Description:”  division” -DisplayName:”division” –IssingkeValued:$true –Server:”DC.biopharmaceutic.local” –ProtectedFromAccedentialDeletion:$true –SourceAttribute:”CN=Division,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local”

. , –AppliesToClasses : @, . , . , . , –ID , , -ID:ad://ext/division:88d00962e3d07cd1 .
, . , marketing specialist , accountant and financier :
 
New-ADClaimType -AppliesToClasses:@('user') -Description:" " -DisplayName:"title" -IsSingleValued:$true -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true -SourceAttribute:"CN=Title,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local" -SuggestedValues:@((New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("", "", "   ")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("", "", "   ")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("", "", "   ")))

, . , . –SuggestedValues , , . , . , @ , New-Object , Microsoft Active Directory Management ADSuggestedValueEntry , . . - .
, . , , . Set-ADClaimType , , - Enabled . , :
 
Set-ADClaimType -Identity "CN=ad://ext/division:88d00968ab6e025f,CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Enabled:$false

, – Identity distinguishedName . , , .
Windows PowerShell :


Fig. 7. ,
, , Active Directory , . :


Fig. 8. Active Directory

So what is next?


, . , , , , , « Active Directory » Windows PowerShell.
, , , , . , .

Source: https://habr.com/ru/post/177575/

More articles:


All Articles