Langage de règles de Transformation de revendications

Article
02/13/2024
S’applique à:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

La fonctionnalité de transformation des revendications entre forêts vous permet de faire le pont entre les revendications des contrôles d’accès dynamiques entre les limites de la forêt en définissant des stratégies de transformation des revendications sur des approbations entre forêts. Le composant principal de toutes les stratégies est des règles écrites dans le langage des règles de transformation des revendications. Cette rubrique fournit des détails sur ce langage et fournit des conseils sur la création de règles de transformation de revendications.

Les applets de commande Windows PowerShell pour les stratégies de transformation sur les approbations entre forêts disposent d’options permettant de définir des stratégies simples qui sont nécessaires dans les scénarios courants. Ces applets de commande traduisent l’entrée utilisateur en stratégies et règles dans le langage des règles de transformation des revendications, puis les stockent dans Active Directory dans le format prescrit. Pour plus d’informations sur les applets de commande pour la transformation des revendications, consultez applets de commande AD DS pour les Contrôles d’accès dynamiques.

En fonction de la configuration des revendications et des exigences relatives à l’approbation entre forêts dans vos forêts Active Directory, vos stratégies de transformation des revendications peuvent être plus complexes que les stratégies prises en charge par les applets de commande Windows PowerShell pour Active Directory. Pour créer efficacement de telles stratégies, il est essentiel de comprendre la syntaxe et la sémantique du langage des règles de transformation des revendications. Ce langage de règles de transformation des revendications (« le langage ») dans Active Directory est un sous-ensemble du langage utilisé par Services ADFS à des fins similaires, et sa syntaxe et sa sémantique sont très similaires. Toutefois, il y a moins d’opérations autorisées et des restrictions de syntaxe supplémentaires sont placées dans la version Active Directory du langage.

Cette rubrique explique brièvement la syntaxe et la sémantique du langage des règles de transformation des revendications dans Active Directory et les considérations à prendre en compte lors de la création de stratégies. Il fournit plusieurs ensembles d’exemples de règles pour commencer, ainsi que des exemples de syntaxe incorrecte et des messages qu’ils génèrent, pour vous aider à déchiffrer les messages d’erreur lorsque vous créez les règles.

Outils pour la création de stratégies de transformation de revendications

Applets de commande Windows PowerShell pour Active Directory : il s’agit de la méthode recommandée pour créer et définir des stratégies de transformation des revendications. Ces applets de commande fournissent des commutateurs pour les stratégies simples et vérifient les règles définies pour les stratégies plus complexes.

LDAP : les stratégies de transformation des revendications peuvent être modifiées dans Active Directory via le protocole LDAP (Lightweight Directory Access Protocol). Toutefois, cela n’est pas recommandé, car les stratégies ont plusieurs composants complexes et les outils que vous utilisez peuvent ne pas valider la stratégie avant de l’écrire dans Active Directory. Cela peut nécessiter par la suite beaucoup de temps pour diagnostiquer les problèmes.

Langage des règles de transformation des revendications Active Directory

Vue d’ensemble de la syntaxe

Voici une brève vue d’ensemble de la syntaxe et de la sémantique du langage :

L’ensemble de règles de transformation des revendications se compose de zéro ou plus de règles. Chaque règle comporte deux parties actives : Liste Sélectionner une condition et Action de la règle. Si la Liste Sélectionner une condition est évaluée à TRUE, l’action de règle correspondante est exécutée.
Liste Sélectionner une condition a zéro ou plusieurs Conditions de sélection. Toutes les Sélectionner une condition doivent être évaluées à TRUE pour que la liste Sélectionner une condition soit évaluée à TRUE.
Chaque Sélectionner une condition a un ensemble de Conditions correspondantes égales à zéro ou plus. Toutes les Conditions correspondantes doivent avoir la valeur TRUE pour que la condition Sélectionner soit évaluée à TRUE. Toutes ces conditions sont évaluées par rapport à une seule revendication. Une revendication qui correspond à une Sélectionner une condition peut être marquée par un Identificateur et référencée dans Action de règle.
Chaque Condition correspondante spécifie la condition pour qu’elle corresponde au Type ou à la Valeur ou au Type de valeur d’une revendication à l’aide de différents Opérateurs de condition et Littéraux de chaîne.
- Lorsque vous spécifiez une Condition correspondante pour une Valeur, vous devez également spécifier une Condition correspondante pour un Type ValueType spécifique et vice versa. Ces conditions doivent être à côté les unes des autres dans la syntaxe.
- Les conditions correspondantes ValueType doivent utiliser des littéraux ValueType spécifiques uniquement.
Une Action de règle peut copier une revendication étiquetée avec un Identificateur ou émettre une revendication basée sur une revendication étiquetée avec un identificateur et/ou des littéraux de chaîne donnés.

Exemple de règle

Cet exemple montre une règle qui peut être utilisée pour traduire le type de revendications entre deux forêts, à condition qu’elles utilisent les mêmes revendications ValueTypes et aient les mêmes interprétations pour les valeurs de revendications pour ce type. La règle a une condition correspondante et une instruction Issue qui utilise des littéraux de chaîne et une référence de revendications correspondantes.

C1: [TYPE=="EmployeeType"]
                 => ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE);
[TYPE=="EmployeeType"] == Select Condition List with one Matching Condition for claims Type.
ISSUE (TYPE= "EmpType", VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE) == Rule Action that issues a claims using string literal and matching claim referred with the Identifier.

Opération de runtime

Il est important de comprendre le fonctionnement d’exécution des transformations de revendications pour créer efficacement les règles. L’opération d’exécution utilise trois ensembles de revendications :

Jeu de revendications d’entrée : jeu de revendications d’entrée donné à l’opération de transformation des revendications.
Jeu de revendications de travail : revendications intermédiaires lues et écrites pendant la transformation des revendications.
Jeu de revendications de sortie : sortie de l’opération de transformation des revendications.

Voici une brève vue d’ensemble de l’opération de transformation des revendications d’exécution :

Les revendications d’entrée pour la transformation des revendications sont utilisées pour initialiser le jeu de revendications de travail.
1. Lors du traitement de chaque règle, le jeu de revendications de travail est utilisé pour les revendications d’entrée.
2. La liste des conditions de sélection d’une règle est mise en correspondance avec tous les ensembles de revendications possibles du jeu de revendications de travail.
3. Chaque ensemble de revendications correspondantes est utilisé pour exécuter l’action dans cette règle.
4. L’exécution d’une action de règle génère une revendication, qui est ajoutée au jeu de revendications de sortie et au jeu de revendications de travail. Ainsi, la sortie d’une règle est utilisée comme entrée pour les règles suivantes dans l’ensemble de règles.
Les règles de l’ensemble de règles sont traitées dans un ordre séquentiel commençant par la première règle.
Lorsque l’ensemble de règles est traité, le jeu de revendications de sortie est traité pour supprimer les revendications dupliquées et pour d’autres problèmes de sécurité. Les revendications résultantes sont la sortie du processus de transformation des revendications.

Il est possible d’écrire des transformations de revendications complexes en fonction du comportement d’exécution précédent.

Exemple : Opération d’exécution

Cet exemple montre l’opération d’exécution d’une transformation de revendications qui utilise deux règles.


     C1:[Type=="EmpType", Value=="FullTime",ValueType=="string"] =>
                Issue(Type=="EmployeeType", Value=="FullTime",ValueType=="string");
     [Type=="EmployeeType"] =>
               Issue(Type=="AccessType", Value=="Privileged", ValueType=="string");
Input claims and Initial Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
After Processing Rule 1:
 Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"), (Value="Marketing"),(ValueType="String")}
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
Output Context:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}

After Processing Rule 2:
Evaluation Context:
  {(Type= "EmpType"),(Value="FullTime"),(ValueType="String")}
{(Type= "Organization"),(Value="Marketing"),(ValueType="String")}
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}
Output Context:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}

Final Output:
  {(Type= "EmployeeType"),(Value="FullTime"),(ValueType="String")}
  {(Type= "AccessType"),(Value="Privileged"),(ValueType="String")}

Sémantique des règles spéciales

Voici une syntaxe spéciale pour les règles :

Jeu de règles vide == Aucune revendication de sortie
Vider la Liste Sélectionner une condition == Chaque revendication correspond à la liste Sélectionner une condition

Exemple : Vider la Liste Sélectionner une condition

La règle suivante correspond à chaque revendication de l’ensemble de travail.
```
=> Issue (Type = "UserType", Value = "External", ValueType = "string")
```
Vider la Liste Sélectionner une correspondance == Chaque revendication correspond à la liste Sélectionner une condition

Exemple : vider les conditions de correspondance

La règle suivante correspond à chaque revendication de l’ensemble de travail. Il s’agit de la règle de base « Autoriser tout » si elle est utilisée seule.
```
C1:[] => Issule (claim = C1);
```

Considérations relatives à la sécurité

Revendications qui entrent dans une forêt

Les revendications présentées par les principaux entrants dans une forêt doivent être inspectées minutieusement pour nous assurer que nous n’autorisons ou émettons que les revendications correctes. Des revendications incorrectes peuvent compromettre la sécurité de la forêt, ce qui doit être une considération de premier plan lors de la création de stratégies de transformation pour les revendications qui entrent dans une forêt.

Active Directory dispose des fonctionnalités suivantes pour éviter une configuration incorrecte des revendications qui entrent dans une forêt :

Si une approbation de forêt n’a aucune stratégie de transformation des revendications définie pour les revendications qui entrent dans une forêt, à des fins de sécurité, Active Directory supprime toutes les revendications principales qui entrent dans la forêt.
Si l’exécution de l’ensemble de règles sur les revendications qui entre dans une forêt entraîne des revendications qui ne sont pas définies dans la forêt, les revendications non définies sont supprimées des revendications de sortie.

Revendications qui quittent une forêt

Les revendications qui quittent une forêt présentent un problème de sécurité moins important pour la forêt que les revendications qui y entrent. Les revendications sont autorisées à quitter la forêt telle quelle même si aucune stratégie de transformation des revendications correspondante n’est en place. Il est également possible d’émettre des revendications qui ne sont pas définies dans la forêt dans le cadre de la transformation des revendications qui quittent la forêt. Il s’agit de configurer facilement des approbations entre forêts avec des revendications. Un administrateur peut déterminer si les revendications qui entrent dans la forêt doivent être transformées et configurer la stratégie appropriée. Par exemple, un administrateur peut définir une stratégie s’il est nécessaire de masquer une revendication pour empêcher la divulgation d’informations.

Erreurs de syntaxe dans les règles de transformation des revendications

Si une stratégie de transformation de revendications donnée a un ensemble de règles qui est incorrect du point de vue de la syntaxe ou s’il existe d’autres problèmes de syntaxe ou de stockage, la stratégie est considérée comme non valide. Cela est traité différemment des conditions par défaut mentionnées précédemment.

Active Directory n’est pas en mesure de déterminer l’intention dans ce cas et passe en mode sans échec, où aucune revendication de sortie n’est générée sur cette approbation+direction de traversée. L’intervention de l’administrateur est nécessaire pour corriger le problème. Cela peut se produire si LDAP est utilisé pour modifier la stratégie de transformation des revendications. Windows PowerShell applets de commande pour Active Directory sont validées pour empêcher l’écriture d’une stratégie avec des problèmes de syntaxe.

Autres considérations linguistiques

Il existe plusieurs mots clés ou caractères qui sont spéciaux dans cette langue (appelés terminaux). Ceux-ci sont présentés dans la table Terminaux de langue plus loin dans cette rubrique. Les messages d’erreur utilisent les balises de ces terminaux pour lever l’ambiguïté.
Les terminaux peuvent parfois être utilisés comme littéraux de chaîne. Toutefois, cette utilisation peut entrer en conflit avec la définition de la langue ou avoir des conséquences inattendues. Ce type d’utilisation n’est pas recommandé.
L’action de règle ne peut effectuer aucune conversion de type sur les valeurs de revendication, et un ensemble de règles qui contient une telle action de règle est considéré comme non valide. Cela entraînerait une erreur d’exécution et aucune revendication de sortie n’est générée.
Si une action de règle fait référence à un identificateur qui n’a pas été utilisé dans la partie Sélectionner la liste des conditions de la règle, il s’agit d’une utilisation non valide. Ceci causerait une erreur de syntaxe.

Exemple : Référence de l’identificateur incorrect La règle suivante illustre un identificateur incorrect utilisé dans l’action de règle.
```
C1:[] => Issue (claim = C2);
```

Exemples de règles de transformation

Autoriser toutes les revendications d’un certain type

Type exact

C1:[type=="XYZ"] => Issue (claim = C1);

Utilisation de Regex

C1: [type =~ "XYZ*"] => Issue (claim = C1);

Interdire un certain type de revendication Type exact

C1:[type != "XYZ"] => Issue (claim=C1);

Utilisation de Regex

C1:[Type !~ "XYZ?"] => Issue (claim=C1);

Exemples d’erreurs de l’analyseur de règles

Les règles de transformation des revendications sont analysées par un analyseur personnalisé pour vérifier les erreurs de syntaxe. Cet analyseur est exécuté par des applets de commande Windows PowerShell associées avant de stocker des règles dans Active Directory. Toutes les erreurs d’analyse des règles, y compris les erreurs de syntaxe, sont imprimées sur la console. Les contrôleurs de domaine exécutent également l’analyseur avant d’utiliser les règles de transformation des revendications, et ils consignent les erreurs dans le journal des événements (ajouter des numéros de journal des événements).

Cette section illustre quelques exemples de règles écrites avec une syntaxe incorrecte et les erreurs de syntaxe correspondantes générées par l’analyseur.

Exemple :
```
c1;[]=>Issue(claim=c1);
```
Cet exemple contient un point-virgule utilisé incorrectement à la place d’un signe deux-points. Message d’erreur :POLICY0002 : Impossible d’analyser les données de stratégie.Numéro de ligne : 1, Numéro de colonne : 2, Jeton d’erreur : ;. Ligne : 'c1; []=>Issue(claim=c1);'.Erreur de l’analyseur : 'POLICY0030 : Erreur de syntaxe, inattendue ';', en attendant l’un des éléments suivants : ':' .'
Exemple :
```
c1:[]=>Issue(claim=c2);
```
Dans cet exemple, la balise Identificateur dans l’instruction d’émission de copie n’est pas définie. Message d’erreur : POLICY0011 : aucune condition de la règle de revendication ne correspond à la balise de condition spécifiée dans le CopyIssuanceStatement : 'c2'.
Exemple :
```
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
```
« bool » n’est pas un terminal dans la langue et il ne s’agit pas d’un ValueType valide. Les terminaux valides sont répertoriés dans le message d’erreur suivant. Message d’erreur :POLICY0002 : Impossible d’analyser les données de stratégie. Numéro de ligne : 1, Numéro de colonne : 39, Jeton d’erreur : « bool ». Ligne : 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Erreur de l’analyseur : 'POLICY0030: Erreur de syntaxe, inattendue 'STRING', en attendant l’un des éléments suivants : 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFICATEUR'
Exemple :
```
c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
```
Le chiffre 1 dans cet exemple n’est pas un jeton valide dans la langue, et une telle utilisation n’est pas autorisée dans une condition correspondante. Il doit être placé entre guillemets doubles pour en faire une chaîne. Message d’erreur :POLICY0002 : Impossible d’analyser les données de stratégie.Numéro de ligne : 1, Numéro de colonne : 23, Jeton d’erreur : 1. Ligne : c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Erreur de l’analyseur : ' POLICY0029 : Entrée inattendue.
Exemple :
```
c1:[type == "x1", value == "1", valuetype == "boolean"] =>

     Issue(type = c1.type, value="0", valuetype == "boolean");
```
Cet exemple a utilisé un signe égal double (==) au lieu d’un seul signe égal (=). Message d’erreur :POLICY0002 : Impossible d’analyser les données de stratégie.Numéro de ligne : 1, Numéro de colonne : 91, Jeton d’erreur : ==. Line: 'c1:[type=="x1", value=="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Erreur de l’analyseur : 'POLICY0030 : Erreur de syntaxe, inattendue '==', en attendant l’un des éléments suivants : '='
Exemple :
```
c1:[type=="x1", value=="boolean", valuetype=="string"] =>

      Issue(type=c1.type, value=c1.value, valuetype = "string");
```
Cet exemple est correct sur le plan syntaxique et sémantique. Toutefois, l’utilisation de « boolean » comme valeur de chaîne est inévitablement source de confusion et doit être évitée. Comme mentionné précédemment, l’utilisation de terminales de langue comme valeurs de revendications doit être évitée dans la mesure du possible.

Terminaux linguistiques

Le tableau suivant répertorie l’ensemble complet des chaînes de terminal et les terminaux de langue associés qui sont utilisés dans le langage des règles de transformation des revendications. Ces définitions utilisent des chaînes UTF-16 qui ne respectent pas la casse.

String	Terminal
"=>"	IMPLY
";"	SEMICOLON
":"	COLON
","	COMMA
"."	DOT
"["	O_SQ_BRACKET
"]"	C_SQ_BRACKET
"("	O_BRACKET
")"	C_BRACKET
"=="	EQ
"!="	NEQ
"=~"	REGEXP_MATCH
"!~"	REGEXP_NOT_MATCH
"="	ASSIGN
"&&"	AND
"issue"	PROBLÈME
"type"	TYPE
"value"	VALEUR
"valuetype"	VALUE_TYPE
"claim"	CLAIM
"[_A-Za-z][_A-Za-z0-9]*"	IDENTIFIER
"\"[^\"\n]*\""	STRING
"uint64"	UINT64_TYPE
"int64"	INT64_TYPE
"chaîne"	STRING_TYPE
"boolean"	BOOLEAN_TYPE

Syntaxe linguistique

Le langage de règles de transformation des revendications suivant est spécifié dans le formulaire ABNF. Cette définition utilise les terminaux spécifiés dans le tableau précédent en plus des productions ABNF définies ici. Les règles doivent être encodées en UTF-16 et les comparaisons de chaînes doivent être traitées comme ne respectant pas la casse.

Rule_set        = ;/*Empty*/
             / Rules
Rules         = Rule
             / Rule Rules
Rule          = Rule_body
Rule_body       = (Conditions IMPLY Rule_action SEMICOLON)
Conditions       = ;/*Empty*/
             / Sel_condition_list
Sel_condition_list   = Sel_condition
             / (Sel_condition_list AND Sel_condition)
Sel_condition     = Sel_condition_body
             / (IDENTIFIER COLON Sel_condition_body)
Sel_condition_body   = O_SQ_BRACKET Opt_cond_list C_SQ_BRACKET
Opt_cond_list     = /*Empty*/
             / Cond_list
Cond_list       = Cond
             / (Cond_list COMMA Cond)
Cond          = Value_cond
             / Type_cond
Type_cond       = TYPE Cond_oper Literal_expr
Value_cond       = (Val_cond COMMA Val_type_cond)
             /(Val_type_cond COMMA Val_cond)
Val_cond        = VALUE Cond_oper Literal_expr
Val_type_cond     = VALUE_TYPE Cond_oper Value_type_literal
claim_prop       = TYPE
             / VALUE
Cond_oper       = EQ
             / NEQ
             / REGEXP_MATCH
             / REGEXP_NOT_MATCH
Literal_expr      = Literal
             / Value_type_literal

Expr          = Literal
             / Value_type_expr
             / (IDENTIFIER DOT claim_prop)
Value_type_expr    = Value_type_literal
             /(IDENTIFIER DOT VALUE_TYPE)
Value_type_literal   = INT64_TYPE
             / UINT64_TYPE
             / STRING_TYPE
             / BOOLEAN_TYPE
Literal        = STRING
Rule_action      = ISSUE O_BRACKET Issue_params C_BRACKET
Issue_params      = claim_copy
             / claim_new
claim_copy       = CLAIM ASSIGN IDENTIFIER
claim_new       = claim_prop_assign_list
claim_prop_assign_list = (claim_value_assign COMMA claim_type_assign)
             /(claim_type_assign COMMA claim_value_assign)
claim_value_assign   = (claim_val_assign COMMA claim_val_type_assign)
             /(claim_val_type_assign COMMA claim_val_assign)
claim_val_assign    = VALUE ASSIGN Expr
claim_val_type_assign = VALUE_TYPE ASSIGN Value_type_expr
Claim_type_assign   = TYPE ASSIGN Expr

Partage via