Linguagem de regras de transformação de declarações
O recurso de transformação de declarações entre florestas permite fazer a ponte de declarações para o Controle de Acesso Dinâmico entre os limites da floresta definindo políticas de transformação de declarações em relações de confiança entre florestas. O componente principal de todas as políticas são as regras gravadas na linguagem de regras de transformação de declarações. Este tópico fornece detalhes sobre essa linguagem e diretrizes sobre como a criação das regras de transformação de declarações.
Os cmdlets do Windows PowerShell para políticas de transformação em relações de confiança entre florestas têm opções para definir políticas simples necessárias em cenários comuns. Esses cmdlets convertem a entrada do usuário em políticas e regras na linguagem de regras de transformação de declarações e, em seguida, armazenam-nas no Active Directory no formato prescrito. Para obter mais informações sobre cmdlets para transformação de declarações, consulte Cmdlets do AD DS para Controle de Acesso Dinâmico.
A políticas de transformação de declarações podem ter que ser mais complexas do que as políticas compatíveis com os cmdlets do Windows PowerShell para o Active Directory, dependendo da configuração de declarações e dos requisitos colocados na relação de confiança entre florestas em suas florestas do Active Directory. Para de fato criar essas políticas, é essencial entender a sintaxe e a semântica da linguagem de regras de transformação de declarações. Essa linguagem de regras de transformação de declarações ("a linguagem") no Active Directory é um subconjunto da linguagem usada pelos Serviços de Federação do Active Directory (AD FS) para fins semelhantes e tem uma sintaxe e semântica muito semelhantes. No entanto, possuem menos operações permitidas e são colocadas restrições de sintaxe adicionais na versão da linguagem do Active Directory.
Este tópico explica brevemente a sintaxe e a semântica da linguagem de regras de transformação de declarações no Active Directory e as considerações a serem feitas durante a criação de políticas. Ele fornece vários conjuntos de regras de exemplo para começar, e exemplos de sintaxe incorreta e as mensagens geradas por elas, para ajudar a decifrar mensagens de erro ao criar as regras.
Ferramentas para criação das políticas de transformação de declarações
Cmdlets do Windows PowerShell para o Active Directory: essa é a forma preferencial e recomendada de criar e definir políticas de transformação de declarações. Esses cmdlets fornecem opções para políticas simples e verificam as regras definidas para políticas mais complexas.
LDAP: as políticas de transformação de declarações podem ser editadas no Active Directory por meio do LDAP (Protocolo LDAP). No entanto, isso não é recomendado porque as políticas têm vários componentes complexos e as ferramentas usadas podem não validar a política antes de gravá-la no Active Directory. Isso pode exigir uma quantidade considerável de tempo mais tarde para diagnosticar problemas.
Linguagem de regras de transformação de declarações do Active Directory
Visão geral da sintaxe
Confira uma breve visão geral da sintaxe e da semântica da linguagem:
O conjunto de regras de transformação de declarações consiste em zero ou mais regras. Cada regra tem duas partes ativas: Selecionar Lista de condições e Ação de regra. Se a parte Selecionar lista de condições for avaliada como TRUE, a ação de regra correspondente será executada.
Selecionar lista de condições tem zero ou mais Selecionar condições. Todas as Selecionar condições devem ser avaliadas como TRUE para que Selecionar lista de condições seja avaliada como TRUE.
Cada Selecionar condições tem um conjunto de zero ou mais Condições correspondentes. Todas as Condições correspondentes devem ser avaliadas como TRUE para que a Selecionar condição seja avaliada como TRUE. Todas essas condições são avaliadas em relação a uma única declaração. Uma declaração que corresponde a uma Selecionar condição pode ser marcada por um Identificador e referenciada na Ação de regra.
Cada Condição correspondente especifica a condição para corresponder ao Tipo ou Valor ou ValueType de uma declaração usando Operadores de condição diferentes e literais de cadeia de caracteres.
Ao especificar uma Condição correspondente para um Valor, você também deve especificar uma Condição correspondente para um ValueType específico e vice-versa. Essas condições devem estar próximas umas das outras na sintaxe.
As condições correspondentes de ValueType devem usar somente literais ValueType específicos.
Uma Ação de regra pode copiar uma declaração marcada com um Identificador ou emitir uma declaração com base em uma declaração marcada com um Identificador e/ou determinados Literais de cadeia de caracteres.
Regra de exemplo
Este exemplo mostra uma regra que pode ser usada para traduzir o Tipo das declarações entre duas florestas, desde que elas usem as mesmas declarações ValueTypes e tenham as mesmas interpretações para valores de declarações desse tipo. A regra tem uma condição correspondente e uma instrução Issue que usa literais de cadeia de caracteres e uma referência de declarações correspondentes.
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.
Operação de runtime
É importante entender a operação de runtime de transformações de declarações para criar as regras com eficiência. A operação de runtime usa três conjuntos de declarações:
Conjunto de declarações de entrada: o conjunto de entrada de declarações que são dadas à operação de transformação de declarações.
Conjunto de declarações de trabalho: declarações intermediárias que são lidas e gravadas durante a transformação de declarações.
Conjunto de declarações de saída: saída da operação de transformação de declarações.
Confira uma breve visão geral da operação de transformação de declarações de runtime:
As declarações de entrada para a transformação de declarações são usadas para inicializar o conjunto de declarações de trabalho.
Ao processar cada regra, o conjunto de declarações de trabalho é usado para as declarações de entrada.
A Seleção da lista de condições em uma regra corresponde a todos os conjuntos de declarações possíveis do conjunto de declarações de trabalho.
Cada conjunto de declarações correspondentes é usado para executar a ação nessa regra.
Executar uma ação de regra resulta em uma declaração e ela é acrescentada ao conjunto de declarações de saída e ao conjunto de declarações de trabalho. Assim, a saída de uma regra é usada como entrada para regras subsequentes no conjunto de regras.
As regras no conjunto de regras são processadas em ordem sequencial, começando com a primeira regra.
Quando todo o conjunto de regras é processado, o conjunto de declarações de saída é processado para remover declarações duplicadas e para outros problemas de segurança. As declarações resultantes são a saída do processo de transformação de declarações.
É possível gravar transformações de declarações complexas com base no comportamento de runtime anterior.
Exemplo: operação de runtime
Este exemplo mostra a operação de runtime de uma transformação de declarações que usa duas regras.
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 regras especiais
Confira a seguir uma sintaxe especial para regras:
Conjunto de regras vazio == Nenhuma declaração de saída
Selecionar lista de condição vazia == Cada declaração corresponde à lista de condição de seleção
Exemplo: selecionar lista de condições vazia
A regra a seguir corresponde cada declaração no conjunto de trabalho.
=> Issue (Type = "UserType", Value = "External", ValueType = "string")Selecionar lista de condições correspondentes == Cada declaração corresponde à Selecionar lista de condições
Exemplo: condições correspondentes vazias
A regra a seguir corresponde cada declaração no conjunto de trabalho. Essa é a regra "Permitir tudo" básica se ela for usada sozinha.
C1:[] => Issule (claim = C1);
Considerações de segurança
Declarações que entram em uma floresta
As declarações apresentadas por entidades de segurança que estão chegando a uma floresta precisam ser inspecionadas minuciosamente para garantir a permissão ou emissão apenas das declarações corretas. As declarações inadequadas podem comprometer a segurança da floresta, e isso deve ser uma consideração importante durante a criação das políticas de transformação para declarações que entram em uma floresta.
O Active Directory tem os seguintes recursos para evitar a configuração incorreta de declarações que entram em uma floresta:
Se uma relação de confiança de floresta não tiver nenhuma política de transformação de declarações definida para as declarações que entram em uma floresta, para fins de segurança, o Active Directory remove todas as declarações principais que entram na floresta.
Se a execução do conjunto de regras em declarações que entram em uma floresta resultar em declarações que não estão definidas na floresta, as declarações indefinidas são removidas das declarações de saída.
Declarações que saem de uma floresta
As declarações que saem de uma floresta apresentam uma preocupação de segurança menor para a floresta do que as declarações que entram na floresta. As declarações têm permissão para sair da floresta como estão mesmo quando não há nenhuma política de transformação de declarações correspondente em vigor. Também é possível emitir declarações que não estão definidas na floresta como parte da transformação das declarações que saem da floresta. Isso serve para configurar facilmente relações de confiança entre florestas com declarações. Um administrador pode determinar se as declarações que entram na floresta precisam ser transformadas e configurar a política apropriada. Por exemplo, um administrador pode definir uma política se for necessário ocultar uma declaração para impedir a divulgação de informações.
Erros de sintaxe em regras de transformação de declarações
Se uma determinada política de transformação de declarações tiver um conjunto de regras sintaticamente incorreto ou se houver outros problemas de sintaxe ou armazenamento, a política será considerada inválida. Isso é tratado de forma diferente das condições padrão mencionadas anteriormente.
Nesse caso, o Active Directory não consegue determinar a intenção e entra em um modo de segurança contra falhas, em que nenhuma declaração de saída é gerada nessa relação de confiança+direção da passagem. A intervenção do administrador é necessária para corrigir o problema. Isso pode acontecer se o LDAP for usado para editar a política de transformação de declarações. Os cmdlets para Active Directory do Windows PowerShell têm validação em vigor para impedir a gravação de uma política com problemas de sintaxe.
Outras considerações sobre linguagem
Há várias palavras-chave ou caracteres que são especiais neste idioma (conhecidos como terminais). Eles são apresentados na tabela Terminais de linguagem posteriormente neste tópico. As mensagens de erro usam as marcas desses terminais para desambiguação.
Às vezes, os terminais podem ser usados como literais de cadeia de caracteres. No entanto, esse uso pode entrar em conflito com a definição de linguagem ou gerar consequências inesperadas. Esse tipo de uso não é recomendado.
A ação de regra não pode executar conversões de tipo em valores de declaração e um conjunto de regras que contém essa ação de regra é considerado inválido. Isso causaria um erro de runtime e nenhuma declaração de saída seria produzida.
Se uma ação de regra se referir a um Identificador que não foi usado na parte Selecionar lista de condições da regra, será um uso inválido. Isso causaria um erro de sintaxe.
Exemplo: referência de identificador incorreto A regra a seguir ilustra um Identificador incorreto usado na ação de regra.
C1:[] => Issue (claim = C2);
Regras de transformação de exemplo
Permitir todas as declarações de um determinado tipo
Tipo exato
C1:[type=="XYZ"] => Issue (claim = C1);Usando Regex
C1: [type =~ "XYZ*"] => Issue (claim = C1);Não permitir um determinado tipo de declaração Tipo exato
C1:[type != "XYZ"] => Issue (claim=C1);Usando Regex
C1:[Type !~ "XYZ?"] => Issue (claim=C1);
Exemplos de erros do analisador de regras
As regras de transformação de declarações são analisadas por um analisador personalizado para verificar se há erros de sintaxe. Esse analisador é executado por cmdlets do Windows PowerShell relacionados antes de armazenar regras no Active Directory. Todos os erros na análise das regras, incluindo erros de sintaxe, são impressos no console. Os controladores de domínio também executam o analisador antes de usar as regras para transformar declarações e registram erros no log de eventos (adicionar números do log de eventos).
Esta seção ilustra alguns exemplos de regras gravadas com sintaxe incorreta e os erros de sintaxe correspondentes gerados pelo analisador.
Exemplo:
c1;[]=>Issue(claim=c1);Este exemplo tem um ponto e vírgula usado incorretamente no lugar de dois-pontos. Mensagem de erro:POLICY0002: não foi possível analisar os dados da política.Número de linha: 1, Número da coluna: 2, Token de erro: ;. Linha: 'c1; []=>Issue(claim=c1);'.Erro do analisador: 'POLICY0030: erro de sintaxe, ';' inesperado, esperando um dos seguintes: ':' .'
Exemplo:
c1:[]=>Issue(claim=c2);Neste exemplo, a marca do Identificador na instrução copy issuance está indefinida. Mensagem de erro: POLICY0011: nenhuma condição na regra de declaração corresponde à marca de condição especificada em CopyIssuanceStatement: 'c2'.
Exemplo:
c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)"bool" não é um Terminal na linguagem e não é um ValueType válido. Os terminais válidos estão listados na seguinte mensagem de erro. Mensagem de erro:POLICY0002: não foi possível analisar os dados da política. Número de linha: 1, Número da coluna: 39, Token de erro: "bool". Linha: 'c1:[type=="x1", value=="1",valuetype=="bool"]=>Issue(claim=c1);'. Erro do analisador: 'POLICY0030: erro de sintaxe, 'STRING' inesperado, esperando um dos seguintes: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'IDENTIFIER'
Exemplo:
c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);O numeral 1 neste exemplo não é um token válido na linguagem e esse uso não é permitido em uma condição correspondente. Ele deve ser colocado entre aspas duplas para torná-lo uma cadeia de caracteres. Mensagem de erro:POLICY0002: não foi possível analisar os dados da política. Número de linha: 1, Número da coluna: 23, Token de erro: 1. Linha: 'c1:[type=="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Erro do analisador: 'POLICY0029: entrada inesperada.
Exemplo:
c1:[type == "x1", value == "1", valuetype == "boolean"] => Issue(type = c1.type, value="0", valuetype == "boolean");Este exemplo usou um sinal de igual duplo (==) em vez de um único sinal de igual (=). Mensagem de erro:POLICY0002: não foi possível analisar os dados da política.Número de linha: 1, Número da coluna: 91, Token de erro: ==. Linha: 'c1:[type=="x1", value=="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype=="boolean");'.Erro do analisador: 'POLICY0030: erro de sintaxe, '==' inesperado, esperando um dos seguintes: '='
Exemplo:
c1:[type=="x1", value=="boolean", valuetype=="string"] => Issue(type=c1.type, value=c1.value, valuetype = "string");Este exemplo está sintaticamente e semanticamente correto. No entanto, o uso de "booleano" como um valor de cadeia de caracteres causa confusão e deve ser evitado. Conforme mencionado anteriormente, o uso de terminais de linguagem como valores de declarações deve ser evitado sempre que possível.
Terminais de linguagem
A tabela a seguir lista o conjunto completo de cadeias de caracteres de terminal e os terminais de linguagem associados que são usados na linguagem de regras de transformação de declarações. Essas definições usam cadeias de caracteres UTF-16 que não diferenciam maiú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 |
| "&&" | AND |
| "issue" | PROBLEMA |
| "type" | TYPE |
| "value" | VALUE |
| valuetype" | VALUE_TYPE |
| "claim" | CLAIM |
| "[_A-Za-z][_A-Za-z0-9]*" | IDENTIFICADOR |
| "\"[^\"\n]*\"" | STRING |
| "uint64" | UINT64_TYPE |
| "int64" | INT64_TYPE |
| “cadeia de caracteres” | STRING_TYPE |
| "boolean" | BOOLEAN_TYPE |
Sintaxe da linguagem
A linguagem de regras de transformação de declarações a seguir é especificada no formulário ABNF. Essa definição usa os terminais especificados na tabela anterior, além das produções do ABNF definidas aqui. As regras devem ser codificadas em UTF-16 e as comparações de cadeia de caracteres devem ser tratadas como não diferenciando maiú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