Språk för kravtransformation och regler

Gäller för: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Med funktionen för anspråkstransformering mellan skogar kan du överbrygga anspråk för dynamisk åtkomstkontroll över skogsgränser genom att ange anspråkstransformeringsprinciper för överordnade skogsförtröenden. Den primära komponenten i alla principer är regler som är skrivna i språket för anspråkstransformeringsregler. Det här avsnittet innehåller information om det här språket och innehåller vägledning om att redigera regler för anspråkstransformering.

Windows PowerShell-cmdletar för omvandlingsprinciper för förtroenden mellan skogar har alternativ för att ange enkla principer som krävs i vanliga scenarier. Dessa cmdletar översätter användarens indata till principer och regler i språket för anspråkstransformeringsregler och lagrar dem sedan i Active Directory i det föreskrivna formatet. Mer information om cmdletar för anspråkstransformering finns i AD DS-cmdletar för dynamisk åtkomstkontroll.

Beroende på anspråkskonfigurationen och kraven som ställs på förtroendet mellan skogarna i dina Active Directory-skogar kan dina anspråkstransformeringsprinciper behöva vara mer komplexa än de principer som stöds av Windows PowerShell-cmdletar för Active Directory. För att effektivt kunna skapa sådana principer är det viktigt att förstå språksyntaxen och semantiken för anspråkstransformeringsregler. Det här anspråkstransformeringsregelspråket ("språket") i Active Directory är en delmängd av språket som används av Active Directory Federation Services för liknande ändamål, och det har en mycket liknande syntax och semantik. Det är dock färre åtgärder som tillåts och ytterligare syntaxbegränsningar placeras i Active Directory-versionen av språket.

Det här avsnittet beskriver kortfattat syntaxen och semantiken för språket för anspråkstransformeringsregler i Active Directory och överväganden som ska göras vid redigering av principer. Den innehåller flera uppsättningar exempelregler för att komma igång, och exempel på felaktig syntax och meddelanden som de genererar för att hjälpa dig att dechiffrera felmeddelanden när du skapar reglerna.

Verktyg för att redigera principer för anspråkstransformering

Windows PowerShell-cmdletar för Active Directory: Det här är det bästa och rekommenderade sättet att skapa och ange principer för anspråkstransformering. Dessa cmdlets tillhandahåller switchar för enkla policys och verifierar regler som har angetts för mer komplexa policys.

LDAP: Anspråkstransformeringsprinciper kan redigeras i Active Directory via Lightweight Directory Access Protocol (LDAP). Detta rekommenderas dock inte eftersom principerna har flera komplexa komponenter, och de verktyg som du använder kanske inte verifierar principen innan du skriver den till Active Directory. Detta kan senare kräva mycket tid för att diagnostisera problem.

Språk för Active Directory-anspråkstransformeringsregler

Syntaxöversikt

Här är en kort översikt över språkets syntax och semantik:

Regeluppsättningen för anspråkstransformering består av noll eller fler regler. Varje regel har två aktiva delar: Välj villkorslista och regelåtgärd. Om listan Välj villkor utvärderas till TRUE körs motsvarande regelåtgärd.
Välj Villkorslista har noll eller fler Välj villkor. Alla Välj villkor måste utvärderas till TRUE för att listan Välj villkor ska utvärderas till TRUE.
Varje Select Condition har en uppsättning med noll eller fler matchande villkor. Alla matchande villkor måste utvärderas till TRUE för att Välj villkor ska utvärderas till TRUE. Alla dessa villkor utvärderas mot ett enda anspråk. Ett anspråk som matchar ett select-villkor kan taggas av en identifierare och refereras till i regelåtgärden.
Varje matchande villkor anger villkoret för att matcha typen eller värdet eller ValueType för ett anspråk med hjälp av olika villkorsoperatorer och strängliteraler.
- När du anger ett matchande villkor för ett värde måste du också ange ett matchande villkor för en specifik ValueType och vice versa. Dessa villkor måste finnas bredvid varandra i syntaxen.
- ValueType-matchningsvillkor måste endast använda specifika ValueType-literaler .
En regelåtgärd kan kopiera ett anspråk som är taggat med en identifierare eller utfärda ett anspråk baserat på ett anspråk som är taggat med en identifierare och/eller angivna strängliteraler.

Exempelregel

Det här exemplet visar en regel som kan användas för att översätta anspråkstypen mellan två skogar, förutsatt att de använder samma anspråk ValueTypes och har samma tolkningar för anspråksvärden för den här typen. Regeln har ett matchande villkor och en issue-instruktion som använder Strängliteraler och en matchande anspråksreferens.

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.

Körningstid operation

Det är viktigt att förstå körexekveringen av kravhantering för att effektivt kunna formulera reglerna. Körningsåtgärden använder tre uppsättningar anspråk:

Indataanspråkuppsättning: Indatauppsättningen av anspråk som ges till operationen för anspråkstransformering.
Uppsättning arbetsanspråk: Mellanliggande anspråk som läss från och skrivs till under anspråkstransformeringen.
Utdataanspråksuppsättning: Utdata från anspråkstransformationen.

Här är en kort översikt över körningstiden för claimstransformering:

Indataanspråk för anspråkstransformering används för att initiera uppsättningen arbetsanspråk.
1. När varje regel bearbetas, används arbetsanspråksuppsättningen som indata för anspråken.
2. Urvalskonditionslistan i en regel matchas mot alla möjliga uppsättningar anspråk från arbetsanspråksuppsättningen.
3. Varje uppsättning matchande anspråk används för att utföra åtgärden i den regeln.
4. Körning av en regelåtgärd resulterar i ett krav, som läggs till i uppsättningen utdataanspråk och den aktiva uppsättningen av anspråk. Därför används utdata från en regel som indata för efterföljande regler i regeluppsättningen.
Reglerna i regeluppsättningen bearbetas i sekventiell ordning från och med den första regeln.
När hela regeluppsättningen bearbetas bearbetas uppsättningen utdataanspråk för att ta bort duplicerade anspråk och för andra säkerhetsproblem. De resulterande anspråken är utdata från anspråkstransformeringsprocessen.

Det går att skriva komplexa anspråkstransformeringar baserat på det tidigare körningsbeteendet.

Exempel: Runtime-operation

Det här exemplet illustrerar körningstidoperationen av en anspråkstransformation som använder två regler.


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

Semantik för särskilda regler

Följande är en särskild syntax för regler:

Tom regeluppsättning == Inga utdataföreskrifter
Tom lista för urvalsvillkor == Varje anspråk matchar listan för urvalsvillkor

Exempel: Tom lista med välj villkor

Följande regel matchar varje påstående i arbetsuppsättningen.
```
=> Issue (Type = "UserType", Value = "External", ValueType = "string")
```
Tom Välj matchande lista == Varje anspråk matchar listan Välj villkor

Exempel: Tomma matchningsvillkor

Följande regel matchar varje påstående i arbetsuppsättningen. Det här är den grundläggande regeln "Tillåt alla" om den används ensam.
```
C1:[] => Issule (claim = C1);
```

Säkerhetsfrågor

Krav som går in i en skog

De anspråk som presenteras av huvudmän som kommer in i en skog måste inspekteras noggrant för att säkerställa att vi endast godkänner eller ger rätt anspråk. Felaktiga anspråk kan äventyra skogsäkerheten, och detta bör vara en av de viktigaste övervägandena när du skapar transformeringpolicyer för anspråk som inträder i en skog.

Active Directory har följande funktioner för att förhindra felkonfiguration av krav som kommer in i en skog:

Om ett skogsdomänförtroende inte har någon policy för anspråkstransformering inställd för anspråk som går in i skogen, tar Active Directory av säkerhetsskäl bort alla huvudanspråk som kommer in i skogen.
Om körning av regelsatsen på anspråk som går in i en skog resulterar i anspråk som inte har definierats i skogen, tas de odefinierade anspråken bort från utdata för anspråken.

Anspråk som lämnar en skog

Anspråk som lämnar en skog innebär ett mindre säkerhetsproblem för skogen än de anspråk som träder in i skogen. Anspråk tillåts lämna skogen as-is även när det inte finns någon motsvarande policy för omvandling av anspråk på plats. Det är också möjligt att utfärda anspråk som inte har definierats i skogen som en del av omvandlingen av anspråk som lämnar skogen. Det här är för att enkelt konfigurera skogsövergripande förtroenden med fordringar. En administratör kan avgöra om anspråk som kommer in i Active Directory-skogen måste transformeras och konfigurera rätt policy. En administratör kan till exempel ange en princip om det finns ett behov av att dölja ett anspråk för att förhindra avslöjande av information.

Syntaxfel i regler för anspråkstransformering

Om en viss princip för anspråkstransformering har en regeluppsättning som är syntaktiskt felaktig eller om det finns andra syntax- eller lagringsproblem anses principen vara ogiltig. Detta behandlas på ett annat sätt än de standardvillkor som nämnts tidigare.

Active Directory kan inte fastställa avsikten i det här fallet och går in i ett felsäkert läge, där inga utdataanspråk genereras på den förtroende+riktningen för bläddringar. Administratörsintervention krävs för att åtgärda problemet. Detta kan inträffa om LDAP används för att redigera anspråkstransformeringsprincipen. Windows PowerShell-cmdletar för Active Directory har validering på plats för att förhindra att en princip skrivs med syntaxproblem.

Andra språköverväganden

Det finns flera nyckelord eller tecken som är speciella på det här språket (kallas terminaler). Dessa visas i tabellen Språkterminaler senare i det här avsnittet. Felmeddelandena använder taggarna för dessa terminaler för tvetydighet.
Terminaler kan ibland användas som strängkonstanter. Sådan användning kan dock strida mot språkdefinitionen eller få oavsiktliga konsekvenser. Den här typen av användning rekommenderas inte.
Regelåtgärden kan inte utföra några typkonverteringar på anspråksvärden och en regeluppsättning som innehåller en sådan regelåtgärd anses vara ogiltig. Detta skulle orsaka ett körningsfel och inga utdataanspråk genereras.
Om en regelåtgärd refererar till en identifierare som inte användes i delen Välj villkorslista i regeln är det en ogiltig användning. Detta skulle orsaka ett syntaxfel.

Exempel: Referens för felaktig identifierare Följande regel illustrerar en felaktig identifierare som används i regelåtgärden.
```
C1:[] => Issue (claim = C2);
```

Exempeltransformeringsregler

Tillåt alla anspråk av en viss typ

Exakt typ

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

Använda Regex

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

Tillåt inte en viss anspråkstyp Exakt typ

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

Använda Regex

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

Exempel på regelparserfel

Regler för anspråkstransformering parsas av en anpassad parser för att söka efter syntaxfel. Den här parsern körs av relaterade Windows PowerShell-cmdletar innan regler lagras i Active Directory. Eventuella fel vid parsning av reglerna, inklusive syntaxfel, skrivs ut i konsolen. Domänkontrollanter kör också parsern innan de använder reglerna för att transformera anspråk, och de loggar fel i händelseloggen (lägg till händelseloggnummer).

Det här avsnittet illustrerar några exempel på regler som skrivs med felaktig syntax och motsvarande syntaxfel som genereras av parsern.

Example:
```
c1;[]=>Issue(claim=c1);
```
Det här exemplet har ett felaktigt använt semikolon i stället för ett kolon. Felmeddelande:POLICY0002: Det gick inte att parsa principdata.Radnummer: 1, Kolumnnummer: 2, Feltoken: ;. Rad: 'c1; []=>Issue(claim=c1);'.Parsningsfel: "POLICY0030: Syntaxfel, oväntat ";", förväntar sig något av följande: ':' .'
Example:
```
c1:[]=>Issue(claim=c2);
```
I det här exemplet är taggen Identifierare i instruktionen för kopieringsutfärdning odefinierad. Felmeddelande: POLICY0011: Inga villkor i anspråksregeln matchar villkorstaggen som anges i CopyIssuanceStatement: 'c2'.
Example:
```
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
```
"bool" är inte en terminal på språket och det är inte en giltig ValueType. Giltiga terminaler visas i följande felmeddelande. Felmeddelande:POLICY0002: Det gick inte att parsa principdata. Radnummer: 1, Kolumnnummer: 39, Feltoken: "bool". Rad: 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Parsningsfel: "POLICY0030: Syntaxfel, oväntat "STRING", som förväntar sig något av följande: "INT64_TYPE" "UINT64_TYPE" "STRING_TYPE" "BOOLEAN_TYPE" "IDENTIFIER"
Example:
```
c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
```
Siffran 1 i det här exemplet är inte en giltig token på språket och sådan användning tillåts inte i ett matchande villkor. Texten måste omges av dubbla citattecken för att göra den till en sträng. Felmeddelande:POLICY0002: Det gick inte att parsa principdata.Radnummer: 1, Kolumnnummer: 23, Feltoken: 1. Rad: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Parsningsfel: "POLICY0029: Oväntade indata.
Example:
```
c1:[type == "x1", value == "1", valuetype == "boolean"] =>

     Issue(type = c1.type, value="0", valuetype == "boolean");
```
I det här exemplet användes ett dubbelt likhetstecken (==) i stället för ett enda likhetstecken (=). Felmeddelande:POLICY0002: Det gick inte att parsa policysdata.Radnummer: 1, Kolumnnummer: 91, Feltoken: ==. Rad: 'c1:[type=="x1", value=="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Parserfel: 'POLICY0030: Syntaxfel, oväntat '==', förväntar sig något av följande: '='
Example:
```
c1:[type=="x1", value=="boolean", valuetype=="string"] =>

      Issue(type=c1.type, value=c1.value, valuetype = "string");
```
Det här exemplet är syntaktiskt och semantiskt korrekt. Att använda "booleskt" som ett strängvärde kommer dock att orsaka förvirring, och det bör undvikas. Som tidigare nämnts bör du undvika att använda språkterminaler som anspråksvärden där det är möjligt.

Språkterminaler

I följande tabell visas den fullständiga uppsättningen terminalsträngar och tillhörande språkterminaler som används i språket för anspråkstransformeringsregler. Dessa definitioner använder skiftlägesokänsliga UTF-16-strängar.

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"	ISSUE
"type"	TYPE
"value"	VALUE
"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

Språksyntax

Följande språk för anspråkstransformeringsregler anges i ABNF-formulär. Den här definitionen använder de terminaler som anges i föregående tabell utöver de ABNF-produktioner som definieras här. Reglerna måste kodas i UTF-16 och strängjämförelserna måste behandlas som skiftlägesokänsliga.

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

Feedback

Var den här sidan till hjälp?

Last updated on 2025-08-08