Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

Linguagem de regras de transformação de declarações

 

Aplica-se a: Windows Server 2012

A entre as florestas declarações transformação recurso permite que a ponte de declarações de controle de acesso dinâmico limites da floresta, definindo políticas de transformação de declarações em relações de confiança entre as florestas. O componente principal de todas as diretivas é regras que são escritas em linguagem de regras de transformação de declarações. Este tópico fornece detalhes sobre essa linguagem e fornece orientação sobre a criação de regras de transformação de declarações.

Os cmdlets do Windows PowerShell para políticas de transformação em entre as florestas confia tem opções para definir diretivas simples que são necessárias em comum cenários. Esses cmdlets converter a entrada do usuário em regras e políticas na linguagem de regras de transformação de declarações e armazená-las no Active Directory no formato indicado. Para obter mais informações sobre os cmdlets para a transformação de declarações, consulte o Cmdlets do AD DS para controle de acesso dinâmico.

Dependendo da configuração de declarações e os requisitos estabelecidos para a relação de confiança entre as florestas nas suas florestas do Active Directory, as políticas de transformação de declarações talvez precise ser mais complexo do que as políticas de suporte pelos cmdlets do Windows PowerShell para Active Directory. Para criar efetivamente dessas políticas, é essencial compreender a sintaxe de linguagem de regras de transformação de declarações e a semântica. Essa declarações transformação regras linguagem ("a") no Active Directory é um subconjunto da linguagem que é usada pelo Serviços de Federação do Active Directory para semelhante finalidades e ele tem uma sintaxe e semântica muito semelhantes. No entanto, há menos operações permitidas e as restrições de sintaxe adicionais são colocadas na versão do idioma do Active Directory.

Este tópico explica rapidamente a sintaxe e semântica da linguagem de regras de transformação de declarações no Active Directory e considerações a serem feitas ao criar políticas. Ele fornece vários conjuntos de regras de exemplo para você começar e ver exemplos de sintaxe incorreta e as mensagens que eles geram, para ajudá-lo a decifrar as mensagens de erro quando você cria as regras.

Cmdlets do Windows PowerShell para Active Directory: essa é a maneira preferencial e recomendada para criar e definir políticas de transformação de declarações. Esses cmdlets fornecem opções para políticas simples e verifique se as regras que são definidas para diretivas mais complexas.

LDAP: políticas de transformação de declarações podem ser editadas no Active Directory por meio de Lightweight Directory Access Protocol (LDAP). No entanto, isso não é recomendado porque as diretivas têm vários componentes complexos e as ferramentas que você usa não podem validar a política antes de gravá-la no Active Directory. Posteriormente, isso pode exigir uma quantidade considerável de tempo para diagnosticar problemas.

Aqui está uma breve visão geral da sintaxe e semântica da linguagem:

  • O conjunto de regras de transformação de declarações consiste de zero ou mais regras. Cada regra tem duas partes active: Selecione lista de condições e ação de regra. Se o Selecione lista de condições for avaliada como TRUE, a ação de regra correspondente é executada.

  • Selecione lista de condições tem zero ou mais Selecionar condições. Todos os Selecionar condições deve ser avaliada como TRUE para o Selecione lista de condições a ser avaliada como TRUE.

  • Cada Selecionar condição tem um conjunto de zero ou mais condições de correspondência. Todos os condições de correspondência deve ser avaliada como TRUE para selecionar condição a ser avaliada como TRUE. Todas essas condições são avaliadas em relação a uma única declaração. Uma declaração que corresponde a um Selecionar condição podem ser identificados por um identificador e refere-se ao ação de regra.

  • Cada condição de correspondência Especifica a condição para corresponder a tipo ou Value ou ValueType de uma declaração usando diferentes condição operadores e literais de cadeia de caracteres.

    • Quando você especifica um condição de correspondência para um valor, você também deve especificar um condição de correspondência para um determinado ValueType e vice-versa. Essas condições devem ser próximos uns dos outros na sintaxe.

    • ValueType critérios de correspondência devem usar específico ValueType apenas literais.

  • Um ação de regra pode copiar uma declaração que é marcada com um identificador ou emitir uma declaração com base em uma declaração que é marcada com um identificador e/ou dado literais de cadeia de caracteres.

Regra de exemplo

Este exemplo mostra uma regra que pode ser usada para traduzir as declarações de tipo entre duas florestas, desde que eles usam as mesmas declarações ValueTypes e têm as mesmo interpretações declarações valores para esse tipo. A regra tem uma condição correspondente e uma instrução de problema que usa literais de cadeia de caracteres e uma referência de declarações correspondente.

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.

É importante compreender a operação de tempo de execução de transformações de declarações para criar as regras com eficiência. A operação de tempo de execução usa três conjuntos de declarações:

  1. Conjunto de declarações de entrada: O conjunto de declarações que são fornecidos para a operação de transformação de declarações de entrada.

  2. Trabalho conjunto de declarações: intermediário de declarações que são ler e gravadas durante a transformação de declarações.

  3. Conjunto de declarações de saída: saída da operação de transformação de declarações.

Aqui está uma visão geral sobre a operação de transformação de declarações de tempo de execução:

  1. Declarações de entrada para transformação de declarações são usadas para inicializar o conjunto de declarações de trabalho.

    1. Durante o processamento de cada regra, o conjunto de declarações de trabalho é usado para as declarações de entrada.

    2. A lista de condições de seleção em uma regra é comparada com todos os possíveis conjuntos de declarações do conjunto de declarações de trabalho.

    3. Cada conjunto de declarações de correspondência é usado para executar a ação na regra.

    4. Execução de uma regra ação resulta em uma declaração, que é anexado à saída de declarações conjunto e o conjunto de declarações de trabalho. Portanto, a saída de uma regra é usada como entrada para regras subseqüentes no conjunto de regras.

  2. As regras no conjunto de regras são processadas em ordem sequencial, começando com a primeira regra.

  3. Quando o conjunto de regras inteiro é processado, o conjunto de declarações de saída é processado para remover declarações duplicadas e outros problemas de segurança. As reivindicações resultantes são a saída do processo de transformação de declarações.

É possível escrever transformações complexas de declarações com base no comportamento de tempo de execução anterior.

Exemplo: Operação de tempo de execução

Este exemplo mostra a operação de tempo de execução 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”)}


Veja a seguir sintaxe especial para regras:

  1. Regra conjunto vazio = = nenhuma declaração de saída

  2. Esvaziar selecione lista de condições = = correspondências de cada declaração lista Selecionar condição

    Exemplo: Lista de condições de seleção vazia

    A regra a seguir corresponde a cada declaração no conjunto de trabalho.

    => Issue (Type = “UserType”, Value = “External”, ValueType = “string”)
    
  3. Esvaziar lista Select de correspondência = = todas as correspondências de declaração lista Selecionar condição

    Exemplo: Condições de correspondência vazia

    A regra a seguir corresponde a cada declaração no conjunto de trabalho. Essa é a regra de all-básico"Permitir" se ele for usado sozinho.

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

Declarações que inserir uma floresta

As declarações apresentadas por entidades que são recebidas para uma floresta precisam ser inspecionadas cuidadosamente para garantir que estamos permitir ou execute somente as declarações corretas. Declarações inadequadas podem comprometer a segurança de floresta, e isso deve ser uma consideração importante ao criar políticas de transformação de declarações que inserir uma floresta.

Active Directory possui os seguintes recursos para evitar erros de configuração de declarações que inserir uma floresta:

  • Se uma relação de confiança de floresta não tiver nenhuma política de transformação de declarações definidas para as declarações que inserir uma floresta, para fins de segurança, o Active Directory descarta todas as declarações de entidades que insere a floresta.

  • Se executar a regra definida em declarações que insere os resultados de uma floresta em declarações que não são definidas na floresta, as declarações são eliminadas das declarações de saída.

Declarações que deixar uma floresta

Declarações que deixar uma floresta apresentam uma preocupação de segurança menor para a floresta que as declarações que insere a floresta. Declarações são permitidas para deixar a floresta-é o mesmo quando não há nenhuma declaração correspondente política de transformação no lugar. Também é possível emitir declarações que não são definidas na floresta como parte da transformação de declarações que deixam a floresta. Isso é facilmente configurar relações de confiança entre as florestas com declarações. Um administrador pode determinar se as declarações que insere a floresta precisam ser transformadas e configurar a política apropriada. Por exemplo, um administrador pode definir uma política, caso haja uma necessidade para ocultar uma declaração para evitar a divulgação de informações.

Erros de sintaxe de regras de transformação de declarações

Se uma política de transformação de declarações determinado tem um conjunto de regras está sintaticamente incorreto ou se há outros problemas de sintaxe ou armazenamento, a diretiva é considerada inválida. Isso é tratado diferentemente padrão condições mencionadas anteriormente.

Active Directory não pôde determinar a intenção nesse caso e entra em um modo à prova de falhas, onde nenhuma declaração de saída é geradas nessa confiança + direção de passagem. É necessária a intervenção do administrador para corrigir o problema. Isso pode ocorrer se o LDAP é usado para editar a política de transformação de declarações. Cmdlets do Windows PowerShell para o Active Directory tem validação para evitar escrever uma política com problemas de sintaxe.

  1. Há várias palavras-chave ou caracteres especiais no idioma (conhecido como terminais). Eles são apresentados no Terminais de linguagem tabela mais adiante neste tópico. As mensagens de erro usam as marcas para os terminais de Desambigüidade.

  2. Terminais, às vezes, podem ser usados como literais de cadeia de caracteres. No entanto, esse uso pode entrar em conflito com a definição de linguagem ou ter conseqüências indesejadas. Esse tipo de uso não é recomendado.

  3. A ação de regra não pode realizar nenhuma conversão de tipos em valores de declaração e um conjunto de regras que contém tal uma ação de regra é considerado inválido. Isso causaria um erro de tempo de execução e nenhuma declaração de saída é geradas.

  4. Se uma ação de regra refere-se a um identificador que não foi usado na parte selecione lista de condição da regra, é um uso inválido. Isso causaria um erro de sintaxe.

    Exemplo: Referência de identificador incorreta
    a regra a seguir ilustra um identificador incorreto usado na ação de regra.

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

  • Permitir que 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

    exata de tipo

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

    Usando Regex

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

Regras de transformação de declarações são analisadas por um analisador personalizado para verificar se há erros de sintaxe. Esse analisador é executado pelos cmdlets do Windows PowerShell relacionados antes de armazenar regras no Active Directory. Erros ao analisar as regras, incluindo erros de sintaxe, são impressas no console. Controladores de domínio também executam o analisador antes de usar as regras de transformação de declarações, e eles registrar erros no log de eventos (Adicionar números de log de eventos).

Esta seção ilustra alguns exemplos de regras que são escritas com sintaxe incorreta e a sintaxe correspondente erros gerados pelo analisador.

  1. Exemplo:

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

    Este exemplo tem uma ponto e vírgula incorretamente usada no lugar de uma vírgula.
    Mensagem de erro:
    POLICY0002: não foi possível analisar os dados da diretiva.
    Número da linha: 1, número de coluna: 2, token de erro:;. Linha: ' c1; [] = > Issue(claim=c1);'.
    Erro do analisador: ' POLICY0030: erro de sintaxe, inesperado ';', esperado um dos seguintes: ':'.'

  2. Exemplo:

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

    Neste exemplo, a marca de identificador na instrução de emissão de cópia é indefinida.
    Mensagem de erro:
    POLICY0011: nenhuma condição na regra de declaração corresponde à marca de condição especificada no CopyIssuanceStatement: 'c2'.

  3. Exemplo:

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

    "booleano" não é um Terminal no idioma, e não é um ValueType válido. Terminais válidos estão listados na seguinte mensagem de erro.
    Mensagem de erro:
    POLICY0002: não foi possível analisar os dados da diretiva.
    Número da linha: 1, número de coluna: 39, token de erro: "booleano".
    Linha: ' c1: [tipo = = "x1", valor = = "1", valuetype = = "booleano"] = > Issue(claim=c1);'.
    Erro do analisador: ' POLICY0030: erro de sintaxe, inesperado 'STRING', esperado um dos seguintes: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'Identificador'

  4. Exemplo:

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

    O número 1 neste exemplo não é um token válido no idioma, e tal uso não é permitido em um critério de correspondência. Ele deve ser colocado entre aspas duplas para torná-lo em uma cadeia de caracteres.
    Mensagem de erro:
    POLICY0002: não foi possível analisar os dados da diretiva.
    Número da linha: 1, número de coluna: 23, token de erro: 1. Linha: ' c1: [tipo = = "x1", valor = = 1, valuetype = = "booleano"] = > Issue(claim=c1);'. Erro do analisador: ' POLICY0029: entrada inesperada.

  5. 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 diretiva.
    Número da linha: 1, número de coluna: 91, token de erro: = =. Linha: ' c1: [tipo = = "x1", valor = = "1",
    valuetype = = "boolean"] = > problema (type=c1.type, valor = "0", valuetype = = "boolean");'.
    Erro do analisador: ' POLICY0030: erro de sintaxe, inesperado '= =', esperado um dos seguintes: '='

  6. Exemplo:

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

    Este exemplo é sintaticamente e semanticamente correto. No entanto, usando "boolean" como um valor de cadeia de caracteres é vinculado a causar confusão e deve ser evitada. Como mencionado anteriormente, usando os terminais de linguagem como valores de declarações devem ser evitadas sempre que possível.

A tabela a seguir lista o conjunto completo de cadeias de caracteres de terminal e os terminais de idioma associado são usados na linguagem de regras de transformação de declarações. Essas definições de usam cadeias de caracteres UTF-16 diferenciam maiúsculas de minúsculas.

String

Terminal

"=>"

IMPLICA

";"

PONTO E VÍRGULA

":"

DOIS PONTOS

","

VÍRGULA

"."

PONTO

"["

O_SQ_BRACKET

"]"

C_SQ_BRACKET

"("

O_BRACKET

")"

C_BRACKET

"=="

EQ

"!="

NEQ

"=~"

REGEXP_MATCH

"!~"

REGEXP_NOT_MATCH

"="

ATRIBUIR

"&&"

E

"problema"

Assunto

"tipo"

Tipo

"valor"

Valor

"valuetype"

VALUE_TYPE

"reivindicação"

DECLARAÇÃO

"[_A-Za-z][_A-Za-z0-9]*"

identificador

"\"[^\"\n]*\""

String

"uint64"

UINT64_TYPE

"int64"

INT64_TYPE

"string"

STRING_TYPE

"boolean"

BOOLEAN_TYPE

A seguinte linguagem de regras de transformação de declarações é especificada no formulário ABNF. Essa definição usa os terminais são especificados na tabela anterior, além de produções ABNF definidas aqui. As regras devem ser codificadas em UTF-16, e as comparações de cadeia de caracteres devem ser tratadas como maiúsculas e 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   

Mostrar: