Lenguaje de reglas de transformación de notificaciones

Artículo
02/13/2024
Se aplica a:

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

La característica de transformación de notificaciones entre bosques le permite establecer notificaciones de Access Control dinámicas a través de los límites del bosque estableciendo directivas de transformación de notificaciones en relaciones de confianza entre bosques. El componente principal de todas las directivas son las reglas que se escriben en lenguaje de reglas de transformación de notificaciones. En este tema se proporcionan detalles sobre este lenguaje y se proporcionan instrucciones sobre la creación de reglas de transformación de notificaciones.

Los cmdlets de Windows PowerShell para las directivas de transformación en las confianzas entre bosques tienen opciones para establecer directivas sencillas que son necesarias en escenarios comunes. Estos cmdlets traducen la entrada del usuario en directivas y reglas en el lenguaje de reglas de transformación de notificaciones y, a continuación, los almacenan en Active Directory en el formato prescrito. Para obtener más información sobre los cmdlets para la transformación de notificaciones, consulte los cmdlets de AD DS para Dynamic Access Control.

En función de la configuración de notificaciones y de los requisitos establecidos en la confianza entre bosques en los bosques de Active Directory, es posible que las directivas de transformación de notificaciones tengan que ser más complejas que las directivas admitidas por los cmdlets de Windows PowerShell para Active Directory. Para crear eficazmente estas directivas, es esencial comprender la sintaxis y la semántica del lenguaje de las reglas de transformación de notificaciones. Este lenguaje de reglas de transformación de notificaciones («el lenguaje») de Active Directory es un subconjunto del lenguaje que usa Servicios de federación de Active Directory con fines similares y tiene una sintaxis y semántica muy similares. Sin embargo, hay menos operaciones permitidas y se colocan restricciones de sintaxis adicionales en la versión de Active Directory del lenguaje.

En este tema se explican brevemente la sintaxis y la semántica del lenguaje de reglas de transformación de notificaciones en Active Directory y las consideraciones que se deben tener en cuenta al crear directivas. Proporciona varios conjuntos de reglas de ejemplo para empezar y ejemplos de sintaxis incorrecta y los mensajes que generan, para ayudarle a descifrar los mensajes de error al crear las reglas.

Herramientas para crear directivas de transformación de notificaciones

Cmdlets de Windows PowerShell para Active Directory: esta es la manera preferida y recomendada de crear y establecer directivas de transformación de notificaciones. Estos cmdlets proporcionan modificadores para directivas sencillas y comprueban las reglas establecidas para directivas más complejas.

LDAP: las directivas de transformación de notificaciones se pueden editar en Active Directory mediante el Protocolo ligero de acceso a directorios (LDAP). Sin embargo, esto no se recomienda porque las directivas tienen varios componentes complejos y es posible que las herramientas que use no validen la directiva antes de escribirla en Active Directory. Esto puede requerir posteriormente una cantidad considerable de tiempo para diagnosticar problemas.

Lenguaje de reglas de transformación de notificaciones de Active Directory

Información general sobre la sintaxis

Esta es una breve introducción a la sintaxis y la semántica del lenguaje:

El conjunto de reglas de transformación de notificaciones consta de cero o más reglas. Cada regla tiene dos partes activas: Seleccionar lista de condiciones y Acción de regla. Si Seleccionar lista de condiciones se evalúa como TRUE, se ejecuta la acción de regla correspondiente.
Seleccionar lista de condiciones tiene cero o más Seleccionar condiciones. Todas las Seleccionar condiciones deben evaluarse como TRUE para que la Seleccionar lista de condiciones se evalúe como TRUE.
Cada Seleccionar condiciones tiene un conjunto de cero o más Condiciones de coincidencia. Todas las Condiciones de coincidencia deben evaluarse como TRUE para que la Seleccionar lista de condiciones se evalúe como TRUE. Todas estas condiciones se evalúan en una sola notificación. Una notificación que coincide con una Seleccionar condiciones se puede etiquetar mediante un Identificador y hacer referencia a en la Acción de regla.
Cada Condición coincidente especifica la condición para que coincida con el Tipo o Valor o ValueType de una notificación mediante diferentes Operadores de condición y Literales de cadena.
- Al especificar una Condición coincidente para un Valor, también debe especificar una Condición coincidente para un ValueType específico y viceversa. Estas condiciones deben estar una al lado de la otra en la sintaxis.
- Las condiciones de coincidencia de ValueType solo deben usar literales ValueType específicos.
Una Acción de regla puede copiar una notificación etiquetada con un Identificador o emitir una notificación basada en una notificación etiquetada con un identificador o literales de cadena especificados.

Regla de ejemplo

En este ejemplo se muestra una regla que se puede usar para traducir el tipo de notificaciones entre dos bosques, siempre que usen las mismas notificaciones ValueTypes y tengan las mismas interpretaciones para los valores de notificaciones de este tipo. La regla tiene una condición de coincidencia y una instrucción Issue que usa literales de cadena y una referencia de notificaciones de coincidencia.

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.

Operación en tiempo de ejecución

Es importante comprender el funcionamiento en tiempo de ejecución de las transformaciones de notificaciones para crear las reglas de forma eficaz. La operación en tiempo de ejecución usa tres conjuntos de notificaciones:

Conjunto de notificaciones de entrada: conjunto de notificaciones de entrada que se proporcionan a la operación de transformación de notificaciones.
Conjunto de notificaciones de trabajo: notificaciones intermedias que se leen y escriben durante la transformación de las notificaciones.
Conjunto de notificaciones de salida: salida de la operación de transformación de notificaciones.

Esta es una breve introducción a la operación de transformación de notificaciones en tiempo de ejecución:

Las notificaciones de entrada para la transformación de notificaciones se usan para inicializar el conjunto de notificaciones de trabajo.
1. Al procesar cada regla, el conjunto de notificaciones de trabajo se usa para las notificaciones de entrada.
2. La lista de condiciones de selección de una regla coincide con todos los conjuntos posibles de notificaciones del conjunto de notificaciones de trabajo.
3. Cada conjunto de notificaciones de coincidencia se usa para ejecutar la acción en esa regla.
4. La ejecución de una acción de regla da como resultado una notificación, que se anexa al conjunto de notificaciones de salida y al conjunto de notificaciones de trabajo. Por lo tanto, la salida de una regla se usa como entrada para las reglas posteriores del conjunto de reglas.
Las reglas del conjunto de reglas se procesan en orden secuencial a partir de la primera regla.
Cuando se procesa todo el conjunto de reglas, el conjunto de notificaciones de salida se procesa para quitar notificaciones duplicadas y para otros problemas de seguridad. Las notificaciones resultantes son la salida del proceso de transformación de notificaciones.

Es posible escribir transformaciones de notificaciones complejas basadas en el comportamiento anterior en tiempo de ejecución.

Ejemplo: Operación en tiempo de ejecución

En este ejemplo se muestra la operación en tiempo de ejecución de una transformación de notificaciones que usa dos reglas.


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

Semántica de reglas especiales

A continuación se muestra reglas especiales de sintaxis:

Conjunto de reglas vacío == Sin notificaciones de salida
Lista de condiciones de selección vacía == Cada notificación coincide con la lista de seleccionar condiciones

Ejemplo: Lista de condiciones de selección vacía

La siguiente regla coincide con todas las notificaciones del conjunto de trabajo.
```
=> Issue (Type = "UserType", Value = "External", ValueType = "string")
```
Lista de coincidencia de selección vacía == Cada notificación coincide con la lista de seleccionar condiciones

Ejemplo: Condiciones de coincidencia vacías

La siguiente regla coincide con todas las notificaciones del conjunto de trabajo. Esta es la regla básica «Permitir todo» si se usa sola.
```
C1:[] => Issule (claim = C1);
```

Consideraciones sobre la seguridad

Notificaciones que entran en un bosque

Las notificaciones presentadas por entidades de seguridad que están entrantes a un bosque deben inspeccionarse exhaustivamente para asegurarse de que se permiten o emiten solo las notificaciones correctas. Las notificaciones incorrectas pueden poner en peligro la seguridad del bosque y esto debe ser una consideración importante al crear directivas de transformación para notificaciones que entran en un bosque.

Active Directory tiene las siguientes características para evitar la configuración incorrecta de las notificaciones que entran en un bosque:

Si una confianza de bosque no tiene ninguna directiva de transformación de notificaciones establecida para las notificaciones que entran en un bosque, con fines de seguridad, Active Directory quita todas las notificaciones principales que entran en el bosque.
Si ejecuta el conjunto de reglas en notificaciones que entra en un bosque da como resultado notificaciones que no están definidas en el bosque, las notificaciones no definidas se quitan de las notificaciones de salida.

Notificaciones que dejan un bosque

Las notificaciones que dejan un bosque presentan una preocupación de seguridad menor para el bosque que las notificaciones que entran en el bosque. Las notificaciones pueden dejar el bosque tal cual incluso cuando no hay ninguna directiva de transformación de notificaciones correspondiente en su lugar. También es posible emitir notificaciones que no están definidas en el bosque como parte de la transformación de notificaciones que dejan el bosque. Se trata de configurar fácilmente confianzas entre bosques con notificaciones. Un administrador puede determinar si las notificaciones que entran en el bosque deben transformarse y configurar la directiva adecuada. Por ejemplo, un administrador podría establecer una directiva si es necesario ocultar una notificación para evitar la divulgación de información.

Errores de sintaxis en las reglas de transformación de notificaciones

Si una directiva de transformación de notificaciones determinada tiene un conjunto de reglas que es sintácticamente incorrecto o si hay otras sintaxis o problemas de almacenamiento, la directiva se considera no válida. Esto se trata de forma diferente a las condiciones predeterminadas mencionadas anteriormente.

Active Directory no puede determinar la intención en este caso y entra en un modo seguro para errores, donde no se generan notificaciones de salida en esa dirección de confianza y dirección del recorrido. La intervención del administrador es necesaria para corregir el problema. Esto podría ocurrir si LDAP se usa para editar la directiva de transformación de notificaciones. Los cmdlets de Windows PowerShell para Active Directory tienen validación para evitar la escritura de una directiva con problemas de sintaxis.

Otras consideraciones del lenguaje

Hay varias palabras clave o caracteres especiales en este lenguaje (denominados terminales). Estos se presentan en la tabla Terminales de lenguaje más adelante en este tema. Los mensajes de error usan las etiquetas de estos terminales para la desambiguación.
A veces, los terminales se pueden usar como literales de cadena. Sin embargo, este uso puede entrar en conflicto con la definición del lenguaje o tener consecuencias imprevistas. Este tipo de uso no se recomienda.
La acción de regla no puede realizar conversiones de tipos en valores de notificación y un conjunto de reglas que contenga dicha acción de regla se considera no válida. Esto provocaría un error en tiempo de ejecución y no se generan notificaciones de salida.
Si una acción de regla hace referencia a un identificador que no se usó en la parte Seleccionar lista de condiciones de la regla, es un uso no válido. Estro provocaría un error de sintaxis.

Ejemplo: Referencia de identificador incorrecta En la siguiente regla se muestra un identificador incorrecto usado en la acción de regla.
```
C1:[] => Issue (claim = C2);
```

Reglas de transformación de ejemplo

Permitir todas las notificaciones de un tipo determinado

Tipo exacto

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

Uso de Regex

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

No permitir un tipo de notificación determinado Tipo exacto

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

Uso de Regex

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

Ejemplos de errores del analizador de reglas

Las reglas de transformación de notificaciones se analizan mediante un analizador personalizado para comprobar si hay errores de sintaxis. Este analizador se ejecuta mediante cmdlets de Windows PowerShell relacionados antes de almacenar reglas en Active Directory. Los errores en el análisis de las reglas, incluidos los errores de sintaxis, se imprimen en la consola. Los controladores de dominio también ejecutan el analizador antes de usar las reglas para transformar las notificaciones y registran errores en el registro de eventos (agregue números de registro de eventos).

En esta sección se muestran algunos ejemplos de reglas escritas con sintaxis incorrecta y los errores de sintaxis correspondientes generados por el analizador.

Ejemplo:
```
c1;[]=>Issue(claim=c1);
```
En este ejemplo se usa un punto y coma incorrectamente en lugar de dos puntos. Mensaje de error:POLICY0002: No se pudieron analizar los datos de la directiva.Número de línea: 1, Número de columna: 2, Token de error: ;. Línea: 'c1; []=>Issue(claim=c1);'.Error del analizador: 'POLICY0030: error de sintaxis, inesperado ';', esperando uno de lo siguiente: ':' .'
Ejemplo:
```
c1:[]=>Issue(claim=c2);
```
En este ejemplo, la etiqueta Identificador de la instrucción de emisión de copia no está definida. Mensaje de error: POLICY0011: No hay condiciones en la regla de notificación que coincidan con la etiqueta de condición especificada en copyIssuanceStatement: 'c2'.
Ejemplo:
```
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
```
"bool" no es un terminal en el lenguaje y no es un valueType válido. Los terminales válidos aparecen en el siguiente mensaje de error. Mensaje de error:POLICY0002: No se pudieron analizar los datos de la directiva. Número de línea: 1, Número de columna: 39, Token de error: "bool". Line: 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Error del analizador: 'POLICY0030: error de sintaxis, 'STRING' inesperado, esperando uno de los siguientes: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'
Ejemplo:
```
c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
```
El número 1 de este ejemplo no es un token válido en el idioma y este uso no se permite en una condición coincidente. Debe incluirse entre comillas dobles para convertirlo en una cadena. Mensaje de error:POLICY0002: No se pudieron analizar los datos de la directiva.Número de línea: 1, Número de columna: 23, Token de error: 1. Línea: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Error del analizador: 'POLICY0029: Entrada inesperada.
Ejemplo:
```
c1:[type == "x1", value == "1", valuetype == "boolean"] =>

     Issue(type = c1.type, value="0", valuetype == "boolean");
```
En este ejemplo se usa un signo igual doble (==) en lugar de un único signo igual (=). Mensaje de error:POLICY0002: No se pudieron analizar los datos de la directiva.Número de línea: 1, Número de columna: 91, Token de error: ==. Línea: 'c1:[type=="x1", value="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Error del analizador: 'POLICY0030: error de sintaxis, inesperado '==', esperando uno de los siguientes: '='
Ejemplo:
```
c1:[type=="x1", value=="boolean", valuetype=="string"] =>

      Issue(type=c1.type, value=c1.value, valuetype = "string");
```
Este ejemplo es sintáctica y semánticamente correcto. Sin embargo, el uso de "boolean" como valor de cadena está enlazado para causar confusión y debe evitarse. Como se mencionó anteriormente, el uso de terminales de lenguaje como valores de notificaciones debe evitarse siempre que sea posible.

Terminales de lenguaje

En la tabla siguiente se muestra el conjunto completo de cadenas de terminal y los terminales de lenguaje asociados que se usan en el lenguaje de reglas de transformación de notificaciones. Estas definiciones usan cadenas UTF-16 que no distinguen mayúsculas de minúsculas.

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
"&&"	Y
"issue"	PROBLEMA
"type"	TYPE
"value"	VALOR
"valuetype"	VALUE_TYPE
"claim"	CLAIM
"[_A-Za-z][_A-Za-z0-9]*"	IDENTIFIER
"\"[^\"\n]*\""	STRING
"uint64"	UINT64_TYPE
"int64"	INT64_TYPE
"cadena"	STRING_TYPE
"boolean"	BOOLEAN_TYPE

Sintaxis del lenguaje

El siguiente lenguaje de reglas de transformación de notificaciones se especifica en formato ABNF. Esta definición usa los terminales que se especifican en la tabla anterior además de las producciones de ABNF definidas aquí. Las reglas se deben codificar en UTF-16 y las comparaciones de cadenas deben tratarse como no distingue mayúsculas de minúsculas.

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

Compartir a través de