Dynamic access control: how to work with claims

  • Tutorial
In the previous article of this series, I introduced you to the course a bit and told what dynamic access control is, how it differs from providing access based on ACLs, its advantages, and also, in a nutshell, about the most common scenarios, when it’s advisable to apply this functionality. The article was a bit cumbersome, filled exclusively with theoretical material, and indeed difficult to understand, since it did not contain descriptions of any step-by-step procedures.
Beginning with this article, I will try to correct myself and tell you about how to begin acquaintance with this technology. And to begin, as can be seen from the title of the article, it should be done with nothing more than statements (they, as I already wrote in the previous article, are also called applications, klima and other words that can be replaced by claim ), which can be safely attributed to one of the main components of dynamic access control. Now I’ll try to give as little theoretical material as possible and move on to the step-by-step procedure almost immediately. So, what can you learn from this relatively small article?
And in this article I will tell you:
  • About what statements are and what will be of their benefit;
  • You will learn about the types of statements;
  • About conditional expressions and operators;
  • And, most importantly, you’ll learn how to manage claims with Active Directory Central Administration and Windows PowerShell.

Well, in order not to drastically delay the introductory part of this article, we move on to the first section, which is called:

What are statements and what will be their use?

I'm afraid to make a mistake, but most likely, in our time there is no longer a user who at least once did not provide access to some of his public folder. Especially for this purpose, back in the distant days of Windows NT, Microsoft introduced the concept of authentication into operating systems, which has been firmly entrenched for many years. Everything is obvious here: that, 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 authentication was successfully passed according to his credentials. Of course, in most cases, such credentials were the name of the account and its password, or the user's membership in a specific group.
But practice shows that in some cases (and there are quite a few such cases), due to membership in various groups, users may accidentally be granted access to resources that they simply are not allowed to access. To get rid of such cases, a new concept was introduced in the latest operating system from Microsoft, which is called, you guessed it, a statement . Consider what it is.
What is the majority of the population now that hears a new or incomprehensible word? They look at Wikipedia. What is written there on this subject? “An affirmation in linguistics is a special form of sentence, which in the affirmative form puts forward a hypothesis regarding a certain phenomenon.” This is definitely not the case.
What else can you find? “A logical statement is a statement formed from other statements using logical connectives.” Also does not fit. “A statement in programming is a predicate placed in a program and indicates that the developer means this predicate is always true at this point in the program.” But still, it seems that all this is not what is implied in the current context.
In fact, according to official terminology, statementsrepresent a trusted source of information about the account trying to perform authorization provided in the attributes of this account, which is stored in Active Directory Domain Services. Various assertions include many properties, such as the security identifier of the user or his computer, the unit in which the user can work, his room number, the city in which he lives. Moreover, it is worth paying 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 very logical question: what will these statements give us and what is the point in them? Using claims, you can restrict access to both files and folders. And what’s most valuable about claims is that all created claims will be published directly to Active Directory. Moreover, as I mentioned in a previous article on this technology, for the full functioning of dynamic access control in general and statements in particular, there are no restrictions on the functional level of the domain or forest of your organization.
Since I spoke in detail about the relationship of Kerberos with claims in one of the articles on the Kerberos network authentication protocol, a link to which I gave in the previous article of this series, we will immediately proceed to such a topic as:

Claim Types

According to the official definition, the type of claim in Windows Server 2012 is the verification statement about the object with which it is associated. As you probably already guessed, the approval type is based on the Active Directory attribute and is used to determine permissions when developing centralized access rules. In Windows Server 2012, you can use any of the following three types of claims:
  • User statements . This type of claim is associated with attribute values ​​that relate to user accounts. Naturally, domain controllers running Windows Server 2012 allow you to use the maximum number of user account attributes that are available in Active Directory for this type of claim;
  • Device approvals . In turn, this type of claims is responsible for the information provided in claims, which relates to devices that are represented as computer accounts in Active Directory Domain Services. Naturally, this type of statement also allows you to use most of the available attributes for this type of security principal;
  • Conversion statements . The final type of claim is a claim issued by a domain controller using an approval transformation policy. As noted in the first article in this series, domain controllers running Windows Server 2012 allow you to convert claims originating from a trusted forest or those entering into a trusting forest. This type of claim will be discussed in a future article on this technology.

Conditional Expressions and Operators

Slowly we will move on to the more interesting part. To be more precise, now we will consider conditional expressions that relate to the OS security subsystem that appeared in the Windows Server 2012 operating system specifically in order to be able to implement authorization support based on claims.
What are these conditional expressions that relate to statements? In fact, these conditional expressions are Boolean or logical expressions, which, as a rule, include two operands separated by a special operator. The result of conditional expressions can always be only two values, or more precisely, these can be TRUE and FALSE. It is also worth paying attention to the fact that ACE expressions are evaluated both in the case of authorization and during an access audit, therefore, in the first and second cases, the same expressions can be used.
What happens to these expressions? I 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 access to the resource will be allowed or denied to the end user. This is all clear. However, with the advent of assertions in Kerberos authentication information, in addition to the SID security principal, it is also possible to include additional information that can be found in these conditional expressions.
Statements themselves are a collection of entities such as the type of statement and the name of the statement, and they must be separated by a period (you will see below). The first part, which is obviously used directly to determine the type of statement, which, as you and I found in the previous section, can act as a User or Device . Before mentioning the type of statement, the @ symbol should be indicated , followed by the type itself. The part with the name of the statement is simply the name that you can give to such a statement when you create it.
The left and right parts of the statement must be compared by a special operator, and the right operand can be a literal value, which can be a fragment of the value of the left operand.
In total, 13 operators can be distinguished, which, most likely, you should already be familiar with working with other software products. I will not talk in detail about each such operator, but simply give their meanings. 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 operator, except that only a fragment of the value of the right operand can act as a value; group member ( MemberOf ) - almost the same as it contains , only the SID acts as the operand, and also the operator any member of the group (MemberOF_Any ), which can also be compared with any of the operators.
Now let's try to consider an example of conditional expressions that can be used with statements when implementing dynamic access control scenarios. For example, take the following expression:
@ User.Department == ”Marketing” && (@ User.Title == ”Financier” || @ User.Title == “Marketing”)

This expression can be conditionally divided into three parts, each such part using statements, and even the second and third parts that are in brackets will be processed simultaneously. Now a little more detailed and in parts.
Based on the priorities of conditional expressions, the first to be executed are the expressions that are located in parentheses. Here in brackets you can find two operators: == and ||. Again, if you look at the priorities, then the == operator should always be processed first. Therefore, the expression is processed from left to right.
Here, the user approval type is User..Title, which is responsible for the position of your employee. This means that we check whether the position of “Financier” is the user's position. Suppose our user is a marketer, which means that in the first expression, the value will be FALSE, that is, false. However, we have the || operator between the two expressions, meaning 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 brackets will take the value TRUE, and this means that you can check the conditions further. At this stage, we have 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 suppose, everything is clear. It is checked whether our user ’s department is “Marketing” . Since our user is a marketer, suppose that his department is precisely the marketing department, and this means that the expression is true. We get the following:

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

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

And what are the objects of statements themselves?

As you know, in the Active Directory schema, you can find a description of all the objects that 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 one or another relation to the current technology, but simply note that there are 9 such objects (of course, there are almost three times as many attributes), but in the case with the statements considered at this stage , only two objects can be distinguished, namely:
  • msDS-ClaimTypePropertyBase . This Active Directory class is an abstract class object that is often used to predefine common attributes for msDS-ClaimType class objects , as well as msDS-ResourceProperty , which you will learn about in the next article. Three attributes are associated with this object: Enabled (everything is clear without any explanation), msDS-ClaimPossibleValues (a string unicode value that defines the expected value in the user interface. This value is usually stored in an XML file) and msDS-ClaimsSharesPossibleValuesWith (accepts the distinguished name of the msDS-ClaimType object and is used as an attribute that determines the value of msDS-ClaimPossibleValues ​​for the msDS-ResourceProperty object);
  • msDS-ClaimType . But this Active Directory class acts as a structural class for objects used to represent statements used by organization security principals. This object already includes a large number of attributes, which include: msDS-ClaimAttributeSource (includes the distinguished name of the attribute definition schema that is used as the approval source), msDS-ClaimIsSingleValued (represents a Boolean value that determines whether the statement contains or statement type only one value), msDS-ClaimIsValueSpaceRestricted(again, includes a Boolean value that determines whether the current class object can accept values ​​different from the value defined in the msDS-ClaimPossibleValues ​​attribute), msDS-ClaimSource (such an attribute is responsible for the non-attribute source for the msDS-ClaimType object, as an example of which can be reduced to, say, a certificate), the msDS-ClaimSourceType (attribute responsible for the source of type approval), the msDS-ClaimTypeAppliesToClass (attribute that defines an object class diagram of the principal security, which issued the statement), the msDS-ClaimValueType (attribute linking Unique e value as a long integer).

Objects class msDS-ClaimType shown in the following figure:

Fig. 2. Objects of the msDS-ClaimType class

Claim Management

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

Active Directory Central Administration Claims Management

In principle, the purely theoretical part has been dragged on for a long time, therefore, without unnecessary preludes, I will probably pass on to the point. So, to create an assertion that will be used for subsequent centralized access policies using Active Directory Central Administration, you will need to perform the following steps:
  1. On the domain controller, open the window, " the Active Directory Administration Center " where in the list, select the node " Dynamic Access Control " and then select the node " Claim the Types " ( the Dynamic the Access the Control > Claim the Types );
  2. В отобразившемся узле нажмите в области сведений правой кнопкой мыши и из контекстного меню выберите последовательно команды «Создать» и «Тип утверждений» (New > Claim Type), как показано на следующей иллюстрации, либо на начальной странице центра администрирования Active Directory перейдите к тайлу динамического контроля доступа и в группе действий Active Directory выберите первое действие, именуемое созданием типа утверждения. Как в первом, так и во втором случае, откроется диалоговое окно создания нового типа утверждения.

    Рис. 3. Открытие диалогового окна создания нового типа утверждения
  3. Когда перед вами появится диалоговое окно «Создать Тип утверждения», вы в разделе «Атрибут источника» (Source Attribute) можете определиться с атрибутом источника и дополнительными элементами конфигурации, на основании которых и будет создаваться ваш тип утверждения. Как видно на следующей иллюстрации, первое, что может броситься в глаза, как только вы откроете текущее диалоговое окно, это большой список «Атрибут источника» (Source Attribute), содержащий множество различных атрибутов, из которого вы можете выбрать требуемый атрибут источника для своего создаваемого утверждения. Такой список формируется из целого ряда классов объектов, к которым относятся классы User, Computer , inetOrgPerson , ManagerServiceAccount , GroupManagerServiceAccount , and also 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, and also OID and SID strings appear in the current list. Also, of course, attributes that are not replicated, blocked attributes, and attributes that are not available on read-only domain controllers (i.e., RODCs) will not be displayed in this list. For example, in this case, the department attribute is selected, but keep in mind that before choosing an attribute, plan your claims structure prematurely for subsequent centralized access policies.

    Fig. 4. Section "Source attribute" of the created claim type
  4. In addition, this section of the dialog box for creating a claim type also provides other parameters, namely:
    • Display name ( the Display the Name ). It is a text box containing a unique display name that is assigned to the type of claim you created. Such a name will appear for subsequent operations, so it would be best if you use names that are readable and understandable in the future as such a name. Naturally, alphabetic and numeric values ​​are available for the created name of the statement type;
    • Description ( the Description ). Represents a field for comments on the type of claim you are creating. The number of characters in this field is limited to 1024 characters. Therefore, when adding your comments and purposes of using the created type of statement, you should be concise;
    • Adoption of this type can be issued to the following classes ( Claims of this type can be issued for the following classes ). A control element that allows you to choose whether the claim applies only to certain types of security principals (for example, only to users or only computers), or by selecting both checkboxes, you can allow the current type of claim to be used for both types of accounts;
    • Assign the identifier a semantically identical type of claims in a trusted forest ( Set ID to a semantically identical claim type in a trusted forest ). It is a flag designed to determine the method for creating an approval type identifier. If this flag is not set, the Active Directory Central Administration will assign such an identifier automatically. What does he look like? This identifier begins with lowercase ad , followed by a colon, two forward slashes, ext, and another forward slash ( ad: // ext /) This is the standard beginning of the identifier. After that, the Central Administration adds the name of the attribute you selected and after the colon, a value in hexadecimal format is added randomly, which to some extent you can be reminded of by a normal 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 associated with trusts, by default metadata for each assertion type will be unique for each forest, and as a result, trusting domain controllers will not be able to process claims from the trusted forest. For this reason, you need to make sure that the identifier of the created claim type will be semantically identical between the trusted and trusted forests. Therefore, this flag should be set only in the case indicated above. Of course, if you specify the identifier manually, then it must comply with the naming context, which was mentioned a little earlier. Be sure to remember how each identifier should begin, after ext / should be indicated no more than 32 characters, which should not contain special characters and end with a slash. These are prerequisites. Well, of course, remember that such identifiers must be unique;
    • Protection against accidental deletion ( Protect from accidental deletion ). A flag that, as is the case with operations already known to you in Active Directory, protects the created claim type from being inadvertently deleted. Despite the fact that by default only administrators can create, modify, and delete claim types by default, in some cases this option may come in handy.
  5. The section titled "Proposed values» ( SUGGESTED the Values ) is responsible for the predetermination of values to choose from which you can select using the type approval conditional. As you can see in the following illustration, here you can stop at the choice of the following values:

    Fig. 5. The section "Proposed Values" of the created approval type
    • No suggested values ( No values are SUGGESTED ). The parameter that is set by default when creating any type of claim. Assumes that you will not override the values ​​for the types of statements, and such values ​​will be manually typed when creating the conditional expressions themselves;
    • The following values ( of The 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 the conditional expression. Therefore, to work with such values, you can use the “Add” , “Change” and “Delete” buttons ( Add , Edit and Remove ), which can be found in the current section of the dialog box for the properties of the created claim type. How exactly are these values ​​created?
      When you click the Add button , you will see the Add Proposed Value dialog box ., где можно найти три текстовых поля: «Значение» (Value), представляющее собой рекомендуемое значение в соответствующем текстовом поле условного выражения, «Отображаемое имя» (Display Name) – имя, которое будет отвечать за текущее значение и фигурировать при выборе такого значения, а также «Описание» (Description), отвечающее за произвольное описание для такого значения.
      Данное диалоговое окно можно увидеть на следующей иллюстрации:

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

Moreover, when working with claims, remember that they can have two states: on and off. Disabled claims remain customized with their unique identifiers, however you simply cannot use them in the future. In order to disable the type approval, just enough to highlight an object and select "from the context menu Disconnect » ( the Disable ).

Windows PowerShell claims management

Without PowerShell now, as they say, nowhere. And if we also take into account the fact that in the last at that time server operating system from Microsoft, cmdlets were developed for almost any action, then it is obvious that in the case of dynamic access control technology, you can take advantage of the rich functionality of this modern command shell.
It is worth paying attention to the fact that for working with both types of claims and with dynamic access control technology in particular, you will need to use the Active Directory module for Windows PowerShell. Using the rich PowerShell feature, you can create, modify, delete, enable, and disable claim types. That is, roughly speaking, you can perform all the same operations that are accessible by means of the graphical interface in the Active Directory admin center.
Since this article turned out to be weighty, we will consider only the creation of two types of statements (with and without predefined values), as well as disabling the type of statement for which values ​​have not been defined. Means:
To create a new claim type, use the New-ADClaimType cmdlet. Together with this cmdlet, you can use up to 21 parameters, the purpose of which is obvious from their name. Therefore, I will not dwell on each parameter in detail, but immediately propose to consider an example of creating a new type of statement. We use the following cmdlet:
New-ADClaimType –AppliesToClasses: @ ('user') –Description: ”Division attribute definition” -DisplayName: ”division” –IssingkeValued: $ true –Server: ”DC.biopharmaceutic.local” –ProtectedFromAccedentialDeletion: $ true –SourceAttribute: CN = Division, CN = Schema, CN = Configuration, DC = biopharmaceutic, DC = local ”

Here, be sure to pay attention to a few points. First of all, the syntax of the –AppliesToClasses parameter is as follows: you specify the @ symbol, and then indicate the type of statement in parentheses and quotation marks. If you want to specify multiple types, separate them with commas. The path to the attribute must be specified in full, as can be seen from the previous command. If you need to determine the identifier, use the –ID parameter and specify the identifier itself in a valid format, for example, -ID: ad: // ext / division: 88d00962e3d07cd1 .
Now let's look at a more complex example, in which, together with the type of statement, we will also try to predefine several values. Let's try to create an approval type for a post where values ​​will be setmarketer , accountant and financier :
New-ADClaimType -AppliesToClasses: @ ('user') -Description: "Employee Position" -DisplayName: "title" -IsSingleValued: $ true -Server: "DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion: $ true -SourceAttribute: " = Title, CN = Schema, CN = Configuration, DC = biopharmaceutic, DC = local "-SuggestedValues: @ ((New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry (" Marketer "," Marketer "," Marketer User " )), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry ("Financier", "Financier") (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry ("Accountant", "Accountant", "User with Accountant")), (New-Object Microsoft.ActiveDirectory.Management.AD "," User with the position of Financier ")))

As you could not notice, the script came out much more massive. Here, the first parameters are almost identical, so it makes no sense to disassemble them. But the –SuggestedValues parameter , which is responsible for the proposed values, may seem quite scary. In fact, everything is very simple with him. The parameter is specified, after the colon, you must specify the @ symbol and in brackets, using the New-Object cmdlet , you will need to add the Microsoft Active Directory Management ADSuggestedValueEntry object with three values ​​defined in brackets and separated by commas. Before adding each new object, put a comma and add the last in additional brackets. That is, everything is more or less transparent.
And now the third example, which will disable the previously created type of statement without values. This can be implemented using a cmdlet designed to change the type of statement. That is, now we will use the Set-ADClaimType cmdlet , of course, with the - Enabled parameter . It turns out that you should run the following command:
Set-ADClaimType -Identity "CN = ad: // ext / division: 88d00968ab6e025f, CN = Claim Types, CN = Claims Configuration, CN = Services, CN = Configuration, DC = biopharmaceutic, DC = local" -Enabled: $ false

Here it is necessary to pay attention to the fact that the value of the parameter - Identity must necessarily coincide with the value of this type of statement from the distinguishedName attribute of the object of the statement type itself. Again, as you see, there is nothing complicated.
The output of commands in a Windows PowerShell window is shown in the following figure:

Fig. 7. Cmdlets, the execution of which was written earlier
Therefore, after all of the above actions have been completed, three objects of the approval type should be displayed in the Active Directory Central Administration window, and one of them should be disabled. This can be seen in the following illustration:

Fig. 8. Active Directory Central Administration window

What next?

Basically, here the material of this article comes to an end. I told you what claims are, what types of claims are, what conditional expressions are, and you also learned how to manage claims types using tools such as Active Directory Administrative Center and Windows PowerShell. Naturally, this does not end the acquaintance with technology such as dynamic access control, since a lot of interesting nuances, procedures, capabilities and scenarios will be considered. For example, in the next article we will talk about the properties of resources.

Also popular now: