Поделиться через

Язык правил преобразования утверждений

  • Статья

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Функция преобразования утверждений между лесами позволяет мостить утверждения для динамических контроль доступа через границы леса, задав политики преобразования утверждений в отношениях доверия между лесами. Основным компонентом всех политик является правила, написанные на языке правил преобразования утверждений. В этом разделе приведены сведения об этом языке и рекомендации по созданию правил преобразования утверждений.

Командлеты Windows PowerShell для политик преобразования в отношениях доверия между лесами могут задавать простые политики, необходимые в распространенных сценариях. Эти командлеты преобразовывают входные данные пользователя в политики и правила в языке правил преобразования утверждений, а затем хранят их в Active Directory в указанном формате. Дополнительные сведения о командлетах для преобразования утверждений см. в командлетах AD DS для dynamic контроль доступа.

В зависимости от конфигурации утверждений и требований, предъявляемых к доверию между лесами в лесах Active Directory, политики преобразования утверждений могут быть более сложными, чем политики, поддерживаемые командлетами Windows PowerShell для Active Directory. Чтобы эффективно создавать такие политики, важно понимать синтаксис и семантику правил преобразования утверждений. Этот язык правил преобразования утверждений ("язык") в Active Directory представляет собой подмножество языка, используемого службы федерации Active Directory (AD FS) для аналогичных целей, и имеет очень похожий синтаксис и семантику. Однако есть меньше операций, и дополнительные ограничения синтаксиса помещаются в версию Active Directory языка.

В этом разделе кратко описывается синтаксис и семантика языка правил преобразования утверждений в Active Directory и рекомендации, которые следует учитывать при создании политик. Он предоставляет несколько наборов примеров правил для начала работы, а также примеры неправильного синтаксиса и сообщений, которые они создают, чтобы помочь расшифровать сообщения об ошибках при создании правил.

Средства разработки политик преобразования утверждений

Командлеты Windows PowerShell для Active Directory. Это предпочтительный и рекомендуемый способ создавать и задавать политики преобразования утверждений. Эти командлеты предоставляют переключатели для простых политик и проверяют правила, заданные для более сложных политик.

LDAP: политики преобразования утверждений можно изменять в Active Directory с помощью протокола LDAP. Однако это не рекомендуется, так как политики имеют несколько сложных компонентов, а используемые средства могут не проверять политику перед записью в Active Directory. Впоследствии для диагностики проблем может потребоваться значительное время.

Язык правил преобразования утверждений Active Directory

Общие сведения о синтаксисе

Ниже приведен краткий обзор синтаксиса и семантики языка:

  • Набор правил преобразования утверждений состоит из нуля или более правил. Каждое правило состоит из двух активных частей: выбор списка условий и действия правила. Если список условий select оценивается как TRUE, выполняется соответствующее действие правила.

  • Выбор списка условий имеет ноль или больше условий выбора. Все условия выбора должны оцениваться как TRUE для списка условий выбора, чтобы оценить значение TRUE.

  • Каждое условие выбора имеет набор нулевых или более условий сопоставления. Все условия сопоставления должны иметь значение TRUE, чтобы выбрать условие, чтобы вычислить значение TRUE. Все эти условия оцениваются по одному утверждению. Утверждение, соответствующее условию выбора, можно пометить идентификатором и ссылаться на действие правила.

  • Каждое условие сопоставления указывает условие, соответствующее типу или значениюили значению утверждения с помощью различных операторов условий и строковых литералов.

    • При указании условия сопоставления для значения необходимо также указать условие сопоставления для определенного типа ValueType и наоборот. Эти условия должны находиться рядом друг с другом в синтаксисе.

    • Условия сопоставления ValueType должны использовать только определенные литералы ValueType.

  • Действие правила может скопировать одно утверждение, помеченное идентификатором или выдачой одного утверждения на основе утверждения, помеченного идентификатором и /или заданными строковыми литералами.

Пример правила

В этом примере показано правило, которое можно использовать для перевода типа утверждений между двумя лесами, при условии, что они используют одинаковые значения valueTypes и имеют одинаковые интерпретации для значений утверждений для этого типа. Правило имеет одно условие сопоставления и оператор Issue, использующий строковые литералы и ссылку на соответствующие утверждения.

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.

Операция выполнения

Важно понимать операцию выполнения преобразований утверждений, чтобы эффективно создавать правила. Операция выполнения использует три набора утверждений:

  1. Набор входных утверждений: входной набор утверждений, предоставленный операции преобразования утверждений.

  2. Набор рабочих утверждений: промежуточные утверждения, которые считываются и записываются во время преобразования утверждений.

  3. Набор выходных утверждений: выходные данные операции преобразования утверждений.

Ниже приведен краткий обзор операции преобразования утверждений среды выполнения:

  1. Входные утверждения для преобразования утверждений используются для инициализации рабочего набора утверждений.

    1. При обработке каждого правила рабочий набор утверждений используется для входных утверждений.

    2. Список условий выбора в правиле соответствует всем возможным наборам утверждений из рабочего набора утверждений.

    3. Каждый набор соответствующих утверждений используется для выполнения действия в этом правиле.

    4. Выполнение действия правила приводит к одному утверждению, которое добавляется к набору выходных утверждений и рабочему набору утверждений. Таким образом, выходные данные из правила используются в качестве входных данных для последующих правил в наборе правил.

  2. Правила в наборе правил обрабатываются последовательно, начиная с первого правила.

  3. При обработке всего набора правил набор выходных утверждений обрабатывается для удаления повторяющихся утверждений и других проблем безопасности. Полученные утверждения являются выходными данными процесса преобразования утверждений.

Можно создавать сложные преобразования утверждений на основе предыдущего поведения среды выполнения.

Пример: операция выполнения

В этом примере показана операция выполнения преобразования утверждений, использующего два правила.


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

Специальные правила семантики

Ниже приведен специальный синтаксис для правил:

  1. Пустой набор правил == Нет выходных утверждений

  2. Пустой список условий выбора == Каждое утверждение соответствует списку условий выбора

    Пример: пустой список условий выбора

    Следующее правило соответствует каждому утверждению в рабочем наборе.

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

  3. Пустой список сопоставления выбора == Каждое утверждение соответствует списку условий выбора

    Пример: пустые условия сопоставления

    Следующее правило соответствует каждому утверждению в рабочем наборе. Это базовое правило Allow-all, если оно используется только.

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

Вопросы безопасности

Утверждения, вводимые в лес

Утверждения, представленные субъектами, входящими в лес, необходимо тщательно проверить, чтобы обеспечить разрешение или выдачу только правильных утверждений. Неправильные утверждения могут скомпрометировать безопасность леса, и это должно быть главным фактором при создании политик преобразования для утверждений, которые входят в лес.

Active Directory имеет следующие функции, чтобы предотвратить неправильное настройку утверждений, которые входят в лес:

  • Если доверие леса не имеет политики преобразования утверждений для утверждений, которые входят в лес, в целях безопасности Active Directory удаляет все основные утверждения, вводимые в лес.

  • Если выполнение набора правил для утверждений, входящих в лес, приводит к утверждениям, которые не определены в лесу, неопределенные утверждения удаляются из выходных утверждений.

Утверждения, которые покидают лес

Утверждает, что оставить лес представляет меньше проблем безопасности для леса, чем утверждения, которые входят в лес. Утверждения могут покидать лес как есть, даже если в нем нет соответствующей политики преобразования утверждений. Также можно выдавать утверждения, которые не определены в лесу в рамках преобразования утверждений, которые покидают лес. Это позволяет легко настроить отношения доверия между лесами с утверждениями. Администратор может определить, нужно ли преобразовать утверждения, которые вошли в лес, и настроить соответствующую политику. Например, администратор может задать политику, если требуется скрыть утверждение, чтобы предотвратить раскрытие информации.

Синтаксические ошибки в правилах преобразования утверждений

Если в данной политике преобразования утверждений задан набор правил, который синтаксически неверный или есть другие проблемы с синтаксисом или хранилищем, политика считается недопустимой. Это относится к условиям по умолчанию, которые упоминание раньше.

Active Directory не может определить намерение в этом случае и перейти в режим, в котором выходные утверждения не создаются в этом направлении доверия и направления обхода. для исправления проблемы требуется вмешательство Администратор istrator. Это может произойти, если ldap используется для изменения политики преобразования утверждений. Командлеты Windows PowerShell для Active Directory имеют проверку, чтобы предотвратить написание политики с проблемами синтаксиса.

Рекомендации по другим языкам

  1. Существует несколько ключевых слов или символов, которые являются специальными на этом языке (называемые терминалами). Они представлены в таблице языковых терминалов далее в этом разделе. Сообщения об ошибках используют теги для этих терминалов для диамбигации.

  2. Терминалы иногда можно использовать в качестве строковых литералов. Однако такое использование может конфликтуть с определением языка или иметь непредвиденные последствия. Этот тип использования не рекомендуется.

  3. Действие правила не может выполнять преобразования типов для значений утверждений, а набор правил, содержащий такое действие правила, считается недопустимым. Это приведет к ошибке среды выполнения, и выходные утверждения не создаются.

  4. Если действие правила ссылается на идентификатор, который не использовался в части списка условий выбора правила, это недопустимое использование. Это приведет к ошибке синтаксиса.

    Пример. Неверный справочник по идентификатору в следующем правиле иллюстрирует неправильный идентификатор, используемый в действии правила.

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

Примеры правил преобразования

  • Разрешить все утверждения определенного типа

    Точный тип

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

    Использование regex

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

  • Запретить определенный тип утверждения Exact

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

    Использование regex

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

Примеры ошибок синтаксического анализа правил

Правила преобразования утверждений анализируются пользовательским средством синтаксического анализа, чтобы проверка для синтаксической ошибки. Этот средство синтаксического анализа выполняется соответствующими командлетами Windows PowerShell перед хранением правил в Active Directory. Все ошибки при анализе правил, включая синтаксические ошибки, печатаются на консоли. Контроллеры домена также запускают средство синтаксического анализа перед использованием правил преобразования утверждений, и они регистрируют ошибки в журнале событий (добавление номеров журналов событий).

В этом разделе показаны некоторые примеры правил, написанных с неправильным синтаксисом, и соответствующие синтаксические ошибки, созданные средством синтаксического анализа.

  1. Пример:

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

    В этом примере неправильно используется точка с запятой вместо двоеточия. Сообщение об ошибке:POLICY0002: не удалось проанализировать данные политики.Номер строки: 1, номер столбца: 2, маркер ошибки: ;. Строка: 'c1; []=>Issue(claim=c1);'.Ошибка синтаксического анализа: "POLICY0030: синтаксическая ошибка, непредвиденная ";", ожидающая одно из следующих: ":".

  2. Пример:

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

    В этом примере тег идентификатора в инструкции выдачи копирования не определен. Сообщение об ошибке: POLICY0011: условия в правиле утверждений не соответствуют тегу условия, указанному в copyIssuanceStatement: "c2".

  3. Пример:

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

    "bool" не является терминалом на языке, и он не является допустимым ValueType. Допустимые терминалы перечислены в следующем сообщении об ошибке. Сообщение об ошибке:POLICY0002: не удалось проанализировать данные политики. Номер строки: 1, номер столбца: 39, маркер ошибки: "bool". Строка: 'c1:[type="x1", value="1",valuetype=="bool"]=>Issue(claim=c1);'. Ошибка синтаксического анализа: "POLICY0030: синтаксическая ошибка, непредвиденная строка", ожидающая следующего: "INT64_TYPE" "UINT64_TYPE" "STRING_TYPE" "BOOLEAN_TYPE" "ИДЕНТИФИКАТОР"

  4. Пример:

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

    Число 1 в этом примере не является допустимым маркером на языке, и такое использование не допускается в условии сопоставления. Он должен быть заключен в двойные кавычки, чтобы сделать его строкой. Сообщение об ошибке:POLICY0002: не удалось проанализировать данные политики.Номер строки: 1, номер столбца: 23, маркер ошибки: 1. Строка: 'c1:[type="x1", value==1, valuetype=="bool"]=>Issue(claim=c1);'.Ошибка синтаксического анализа: "POLICY0029: непредвиденные входные данные.

  5. Пример:

    c1:[type == "x1", value == "1", valuetype == "boolean"] =>

     Issue(type = c1.type, value="0", valuetype == "boolean");

    В этом примере используется двойной знак равенства (==) вместо единого знака равенства (=). Сообщение об ошибке:POLICY0002: не удалось проанализировать данные политики.Номер строки: 1, номер столбца: 91, маркер ошибки: ==. Строка: 'c1:[type="x1", value="1",valuetype=="boolean"]=>Issue(type=c1.type, value="0", valuetype="boolean");'Ошибка синтаксического анализа: "POLICY0030: синтаксическая ошибка, непредвиденная "==", ожидающая следующего: "="

  6. Пример:

    c1:[type=="x1", value=="boolean", valuetype=="string"] =>

      Issue(type=c1.type, value=c1.value, valuetype = "string");

    В этом примере синтаксически и семантично правильно. Однако использование boolean в качестве строкового значения привязано к путанице, и ее следует избежать. Как и ранее упоминание, использование языковых терминалов в качестве значений утверждений следует избегать по возможности.

Языковые терминалы

В следующей таблице перечислены полный набор строк терминала и связанные языковые терминалы, используемые в языке правил преобразования утверждений. Эти определения используют нечувствительные строки UTF-16.

Строка Терминал
"=>" ПОДРАЗУМЕВАЕТ
";" ЗАПЯТОЙ
":" ТОЛСТОЙ КИШКИ
"," ЗАПЯТОЙ
"." ТОЧКА
"[" O_SQ_BRACKET
"]" C_SQ_BRACKET
"(" O_BRACKET
")" C_BRACKET
"==" EQ
"!=" NEQ
"=~" REGEXP_MATCH
"!~" REGEXP_NOT_MATCH
"=" НАЗНАЧИТЬ
"&&" И
"проблема" ПРОБЛЕМА
"type" ТИП
"value" ЗНАЧЕНИЕ
"valuetype" VALUE_TYPE
"утверждение" УТВЕРЖДАЮТ
"[_A-За-z][_A-Za-z0-9]*" ИДЕНТИФИКАТОР
"\"[^\"\n]*\"" STRING
"uint64" UINT64_TYPE
"int64" INT64_TYPE
Строка STRING_TYPE
"boolean" BOOLEAN_TYPE

Синтаксис языка

Следующий язык правил преобразования утверждений указан в форме ABNF. Это определение использует терминалы, указанные в предыдущей таблице, в дополнение к рабочим средам ABNF, определенным здесь. Правила должны быть закодированы в UTF-16, а сравнения строк должны рассматриваться как нечувствительные к регистру.

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