Linguaggio delle regole di trasformazione delle attestazioni

• Si applica a:

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

La funzionalità di trasformazione delle attestazioni tra foreste consente di collegare le attestazioni per il controllo dinamico degli accessi attraverso i limiti della foresta impostando i criteri di trasformazione delle attestazioni in trust tra foreste. Il componente principale di tutti i criteri sono le regole scritte nel linguaggio delle regole di trasformazione delle attestazioni. In questo argomento vengono fornite informazioni dettagliate su tale linguaggio e vengono fornite indicazioni sulla creazione di regole di trasformazione delle attestazioni.

I cmdlet di Windows PowerShell per i criteri di trasformazione nei trust tra foreste sono dotati di opzioni per impostare dei criteri semplici che sono necessari in scenari comuni. Questi cmdlet convertono l'input dell'utente in criteri e regole nel linguaggio delle regole di trasformazione delle attestazioni, dopodiché li archiviano all’interno di Active Directory nel formato specificato. Per altre informazioni sui cmdlet per la trasformazione delle attestazioni, vedere Cmdlet di Active Directory Domain Services per il controllo dinamico degli accessi.

A seconda della configurazione delle attestazioni e dei requisiti applicati al trust tra foreste nelle foreste di Active Directory, i criteri di trasformazione delle attestazioni potrebbero essere più complessi rispetto ai criteri supportati dai cmdlet di Windows PowerShell per Active Directory. Per creare in modo efficace tali criteri, è essenziale comprendere la sintassi e la semantica del linguaggio delle regole di trasformazione delle attestazioni. Questo linguaggio delle regole di trasformazione delle attestazioni ("il linguaggio") in Active Directory è un subset del linguaggio usato da Active Directory Federation Services per scopi simili e presenta una sintassi e una semantica estremamente simili. Tuttavia, nella versione del linguaggio di Active Directory è consentito un minor numero di operazioni e vengono applicate restrizioni di sintassi aggiuntive.

Questo argomento illustra brevemente la sintassi e la semantica del linguaggio delle regole di trasformazione delle attestazioni in Active Directory e gli aspetti da tenere in considerazione durante la creazione dei criteri. Fornisce diversi set di regole di esempio per iniziare ed esempi di sintassi non corretta e i messaggi da essa generati, così da facilitare la decifrazione dei messaggi di errore quando si creano le regole.

Strumenti per la creazione di criteri di trasformazione delle attestazioni

Cmdlet di Windows PowerShell per Active Directory: questo è il modo preferito e consigliato per creare e impostare criteri di trasformazione delle attestazioni. Questi cmdlet forniscono opzioni per criteri semplici e verificare le regole impostate per criteri più complessi.

LDAP: i criteri di trasformazione delle attestazioni possono essere modificati in Active Directory tramite Lightweight Directory Access Protocol (LDAP). Tuttavia, tale opzione non è consigliata perché i criteri hanno diversi componenti complessi e gli strumenti usati potrebbero non convalidare il criterio prima di scriverlo in Active Directory. Ciò può richiedere successivamente una notevole quantità di tempo per diagnosticare i problemi.

Linguaggio delle regole di trasformazione delle attestazioni di Active Directory

Panoramica della sintassi

Ecco una breve panoramica della sintassi e della semantica del linguaggio:

• Il set di regole di trasformazione delle attestazioni è costituito da zero o più regole. Ogni regola ha due parti attive: Elenco condizioni di selezione e Azione regola. Se l’Elenco condizioni di selezione restituisce TRUE, viene eseguita l'azione della regola corrispondente.

• Elenco condizioni di selezione ha zero o più Condizioni di selezione. Tutte le Condizioni di selezione devono restituire TRUE affinché l'Elenco condizioni di selezione restituisca TRUE.

• Ogni Condizione di selezione ha un set di zero o più Condizioni corrispondenti. Tutte le Condizioni corrispondenti devono restituire TRUE affinché la Condizione di selezione restituisca TRUE. Tutte queste condizioni vengono valutate rispetto a una singola attestazione. Un'attestazione che corrisponde a una Condizione di selezione può essere contrassegnata da un identificatore e citata nell'Azione regola.

• Ogni Condizione corrispondente specifica la condizione in base a tipo o valore o ValueType di un'attestazione utilizzando Operatori condizione e Valori di stringa letterali diversi.

  • Quando si specifica una Condizione corrispondente per un valore, è necessario specificare anche una condizione corrispondente per un ValueTypespecifico e viceversa. Nella sintassi, tali condizioni devono trovarsi le une accanto alle altre.

  • Le condizioni corrispondenti ValueType devono usare solo valori letterali ValueTypespecifici.

• Un'azione regola può copiare un'attestazione contrassegnata con un identificatore o rilasciare un'attestazione in base a un'attestazione contrassegnata con un identificatore e/o i valori letterali stringa specificati.

Regola di esempio

In questo esempio viene illustrata una regola che può essere usata per convertire il tipo di attestazioni tra due foreste, purché queste usino le stesse attestazioni ValueType e abbiano le stesse interpretazioni dei valori delle attestazioni per questo tipo. La regola ha una condizione corrispondente e un'istruzione Issue che usa valori letterali di stringa e un riferimento alle attestazioni corrispondenti.

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.

Operazione di runtime

È importante comprendere l'operazione di runtime delle trasformazioni delle attestazioni per creare le regole in modo efficace. L'operazione di runtime usa tre set di attestazioni:

1. Set di attestazioni di input: set di attestazioni di input che viene assegnato all'operazione di trasformazione delle attestazioni.

2. Set di attestazioni operative: attestazioni intermedie lette e scritte durante la trasformazione delle attestazioni.

3. Set di attestazioni di output: output dell'operazione di trasformazione delle attestazioni.

Ecco una breve panoramica dell'operazione di trasformazione delle attestazioni di runtime:

1. Le attestazioni di input per la trasformazione delle attestazioni vengono usate per inizializzare il set di attestazioni operative.

   1. Durante l'elaborazione di ogni regola, il set di attestazioni operative viene usato per le attestazioni di input.

   2. L'elenco di condizioni di selezione in una regola viene confrontato con tutti i possibili set di attestazioni del set di attestazioni operative.

   3. Ogni set di attestazioni corrispondenti viene usato per eseguire l'azione in tale regola.

   4. L'esecuzione di un'azione regola comporta un'attestazione, che viene aggiunta al set di attestazioni di output e al set di attestazioni operative. Di conseguenza, l'output di una regola viene usato come input per le regole successive all’interno del set di regole.

2. Le regole contenute nel set di regole vengono elaborate in ordine sequenziale a partire dalla prima regola.

3. Quando viene elaborato l'intero set di regole, il set di attestazioni di output viene elaborato per rimuovere attestazioni duplicate e per altre problematiche legate alla sicurezza. Le attestazioni risultanti sono l'output del processo di trasformazione delle attestazioni.

È possibile scrivere trasformazioni di attestazioni complesse in base al comportamento di runtime precedente.

Esempio: Operazione di runtime

In questo esempio viene illustrata l'operazione di runtime di una trasformazione delle attestazioni che utilizza due regole.

     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")}

Semantica delle regole speciali

Di seguito è riportata una sintassi speciale che vincola le regole:

1. Set di regole vuoto == Nessuna attestazione di output

2. Elenco condizioni di selezione vuoto == Ciascuna attestazione corrisponde all'elenco condizione di selezione

   Esempio: Elenco di condizioni di selezione vuoto

   La regola seguente corrisponde a ogni attestazione presente nel set operativo.

   => Issue (Type = "UserType", Value = "External", ValueType = "string")
   

3. Elenco condizioni corrispondenti vuoto == Ciascuna attestazione corrisponde all'elenco condizione di selezione

   Esempio: condizioni corrispondenti vuote

   La regola seguente corrisponde a ogni attestazione presente nel set operativo. Questa è la regola di base "Allow-all" se viene usata da sola.

   C1:[] => Issule (claim = C1);
   

Considerazioni sulla sicurezza

Attestazioni che immettono una foresta

Le attestazioni presentate dalle entità in ingresso a una foresta devono essere esaminate accuratamente per far sì che se ne consenta l’accesso oppure si rilascino solo le attestazioni corrette. Le attestazioni non corrette possono compromettere la sicurezza della foresta e questo rischio va valutato con attenzione quando si creano criteri di trasformazione per le attestazioni che accedono a una foresta.

Active Directory include le funzionalità seguenti tese a evitare errori di configurazione delle attestazioni che accedono a una foresta:

• Se un trust tra foreste non dispone di criteri di trasformazione delle attestazioni impostati per le attestazioni che accedono a una foresta, Active Directory elimina tutte le attestazioni principali che accedono alla foresta a scopo di sicurezza.

• Se l'esecuzione del set di regole sulle attestazioni che entrano in una foresta comporta attestazioni non definite nella foresta, le attestazioni non definite vengono eliminate dalle attestazioni di output.

Attestazioni che abbandonano una foresta

Le attestazioni che abbandonano una foresta rappresentano un problema di sicurezza minore per la foresta rispetto a quelle che vi accedono. Le attestazioni possono lasciare la foresta invariate anche quando non sono presenti criteri di trasformazione delle attestazioni corrispondenti. Inoltre, è possibile rilasciare attestazioni che non sono definite nella foresta come parte della trasformazione delle attestazioni che lasciano la foresta. Si tratta di configurare facilmente trust tra foreste con delle attestazioni. Un amministratore può stabilire se le attestazioni che entrano nella foresta devono essere trasformate e configurare i criteri appropriati. Ad esempio, un amministratore potrebbe impostare un criterio nel caso sussista la necessità di nascondere un'attestazione per impedire la divulgazione di informazioni.

Errori di sintassi nelle regole di trasformazione delle attestazioni

Se un determinato criterio di trasformazione delle attestazioni ha un set di regole sintatticamente errato o se sono presenti altri problemi di sintassi o archiviazione, il criterio viene considerato non valido. Tale comportamento viene trattato in modo diverso rispetto alle condizioni predefinite indicate in precedenza.

In questo caso, Active Directory non è in grado di stabilire la finalità e passa a una modalità di sicurezza, nella quale non vengono generate attestazioni di output in tale trust+direzione di diniego. È necessario l'intervento dell'amministratore per correggere il problema. Questo problema può verificarsi se si usa LDAP per modificare i criteri di trasformazione delle attestazioni. I cmdlet di Windows PowerShell per Active Directory dispongono di una validazione atta a impedire la scrittura di criteri con problemi di sintassi.

Altre considerazioni sul linguaggio

1. All’interno di questo linguaggio sono presenti diverse parole chiave o caratteri speciali (altresì detti “terminali”). Tali elementi vengono indicati nella Tabella dei terminali linguistici riportata più avanti. Per questi terminali, messaggi di errore utilizzano i tag per la disambiguazione.

2. I terminali possono talvolta essere usati come valori letterali stringa. Tuttavia, tale utilizzo può essere in conflitto con la definizione del linguaggio o avere conseguenze impreviste. Questo tipo di utilizzo non è consigliato.

3. L'azione regola non può eseguire conversioni di tipi in valori attestazioni e un set di regole che contiene tale azione regola è considerato non valido. Ciò provocherebbe un errore di runtime e non vengono generate attestazioni di output.

4. Se un'azione regola fa riferimento a un identificatore non utilizzato nella parte Elenco condizioni di selezione della regola, si tratta di un utilizzo non valido. In questo modo si verificherebbe un errore di sintassi.

   Esempio: Riferimento identificatore non corretto La regola seguente illustra un identificatore non corretto utilizzato nell'azione della regola.

   C1:[] => Issue (claim = C2);
   

Esempio di trasformazione delle attestazioni

• Consenti tutte le attestazioni di un determinato tipo

  Tipo esatto

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

  Uso di Regex

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

• Non consentire un determinato tipo di attestazione Tipo esatto

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

  Uso di Regex

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

Esempi di errori del parser regole

Le regole di trasformazione delle attestazioni vengono analizzate da un parser (o decodificatore) personalizzato per verificare la presenza di errori di sintassi. Questo parser viene eseguito dai cmdlet di Windows PowerShell correlati prima di archiviare le regole in Active Directory. Eventuali errori nell'analisi delle regole, inclusi gli errori di sintassi, vengono stampati nella console. Inoltre,i controller di dominio eseguono il parser prima di usare le regole per la trasformazione delle attestazioni e registrano gli errori nel registro eventi (aggiungere i numeri del registro eventi).

In questa sezione vengono illustrati alcuni esempi di regole scritte con sintassi non corretta e gli errori di sintassi corrispondenti generati dal parser.

1. Esempio:

   c1;[]=>Issue(claim=c1);
   

   In questo esempio viene utilizzato un punto e virgola in modo non corretto al posto dei due punti. Messaggio di errore:POLICY0002: Impossibile analizzare i dati dei criteri.Numero di riga: 1, Numero di colonna: 2, Token di errore: ;. Riga: 'c1; []=>Issue(claim=c1);'.Errore parser: 'POLICY0030: errore di sintassi, imprevisto ';', a fronte di uno dei seguenti: ':' .'

2. Esempio:

   c1:[]=>Issue(claim=c2);
   

   In questo esempio il tag Identificatore nell'istruzione di rilascio della copia non è definito. Messaggio di errore: POLICY0011: nessuna condizione nella regola attestazione corrisponde al tag di condizione specificato in CopyIssuanceStatement: 'c2'.

3. Esempio:

   c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
   

   "bool" non è un terminale nella lingua e non è un ValueType valido. I terminali validi sono elencati nel seguente messaggio di errore. Messaggio di errore:POLICY0002: Impossibile analizzare i dati dei criteri. Numero di riga: 1, Numero di colonna: 39, Token di errore: "bool". Riga: 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Errore del parser: 'POLICY0030: errore di sintassi, 'STRING' imprevisto, a fronte di uno dei seguenti: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'

4. Esempio:

   c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
   

   Il numero 1 in questo esempio non è un token valido nella lingua e tale utilizzo non è consentito in una condizione di corrispondenza. Deve essere racchiuso tra virgolette doppie per renderlo una stringa. Messaggio di errore:POLICY0002: Impossibile analizzare i dati dei criteri.Numero di riga: 1, Numero di colonna: 23, Token di errore: 1. Riga: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Errore del parser: 'POLICY0029: input imprevisto.

5. Esempio:

   c1:[type == "x1", value == "1", valuetype == "boolean"] =>
   
        Issue(type = c1.type, value="0", valuetype == "boolean");
   

   In questo esempio, viene utilizzato un doppio segno di uguale (==) anziché uno singolo (=). Messaggio di errore:POLICY0002: Impossibile analizzare i dati dei criteri.Numero di riga: 1, Numero di colonna: 91, Token di errore: ==. Riga: 'c1:[type=="x1", value=="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Errore del parser: 'POLICY0030: errore di sintassi, imprevisto '==', a fronte di uno dei seguenti: '='

6. Esempio:

   c1:[type=="x1", value=="boolean", valuetype=="string"] =>
   
         Issue(type=c1.type, value=c1.value, valuetype = "string");
   

   Questo esempio è sintatticamente e semanticamente corretto. Tuttavia, l'uso di "boolean" come valore stringa è destinato a causare confusione ed è consigliabile evitarlo. Come accennato in precedenza, è consigliabile evitare l'uso di terminali linguistici come valori delle attestazioni, laddove possibile.

Terminali linguistici

La tabella seguente elenca il set completo di stringhe terminali e i terminali linguistici associati usati nel linguaggio delle regole di trasformazione delle attestazioni. Tali definizioni utilizzano stringhe UTF-16 senza distinzione tra maiuscole e minuscole.

Stringa	Terminale
"=>"	IMPLY
";"	SEMICOLON
":"	COLON
","	COMMA
"."	DOT
"["	O_SQ_BRACKET
"]"	C_SQ_BRACKET
"("	O_BRACKET
")"	C_BRACKET
"=="	EQ
"!="	NEQ
"=~"	REGEXP_MATCH
"!~"	REGEXP_NOT_MATCH
"="	ASSIGN
"&&"	E
"issue"	PROBLEMA
"type"	TYPE
"value"	VALORE
"valuetype"	VALUE_TYPE
"claim"	CLAIM
"[_A-Za-z][_A-Za-z0-9]*"	IDENTIFIER
"\"[^\"\n]*\""	STRING
"uint64"	UINT64_TYPE
"int64"	INT64_TYPE
"string"	STRING_TYPE
"boolean"	BOOLEAN_TYPE

Sintassi del linguaggio

Il linguaggio delle regole di trasformazione delle attestazioni seguente viene specificato nel formato ABNF. Questa definizione usa i terminali specificati nella tabella precedente oltre alle produzioni ABNF definite qui. Le regole devono essere codificate in UTF-16 e i confronti tra stringhe devono essere considerati senza distinzione tra maiuscole e minuscole.

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