Динамический контроль доступа: как работать с утверждениями

• О том, что такое утверждения и какая от них будет польза;
• Вы узнаете о типах утверждений;
• Об условных выражениях и об операторах;
• А также, что важнее всего, вы узнаете о том, каким образом можно управлять утверждениями средствами «Центра администрирования Active Directory» и Windows PowerShell.

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

Что такое утверждения и какая от них будет польза?

Боюсь ошибиться, но, вероятнее всего, в наше время уже не осталось такого пользователя, который хотя бы один раз не предоставлял доступ к какой-то своей общедоступной папке. Специально для этой цели, еще в далекие времена Windows NT, корпорация Microsoft ввела в операционные системы такое понятие как идентификация, которое плотно закрепилось на многие годы. Тут все очевидно: что, как я уже упоминал в одной из своих статей, доступ к файлам и ресурсам основывался непосредственно на идентификаторах безопасности. Получается, доступ к общедоступным файловым ресурсам предоставлялся, основываясь на том, удачно ли была пройдена проверка подлинности пользователя согласно его учетным данным. Конечно же, в большинстве случаев такие учетные данные представляли собой имя учетной записи и его пароль или же принадлежность пользователя к конкретной группе. Саму концепцию идентификации вы все прекрасно знаете и, полагаю, нет никакого смысла останавливаться на ней в очередной раз.
Но практика показывает, что в некоторых случаях (а таких случаев можно привести достаточно много) из-за членства в различных группах пользователям может случайно быть предоставлен доступ к таким ресурсам, доступ к которым им попросту не положен. Чтобы избавиться от таких случаев, в последней операционной системе от Microsoft было представлено новое понятие, которое называется, как вы догадались, утверждением. Рассмотрим, что же это такое.
Как сейчас поступает бОльшая часть населения, которая слышит новое или непонятное слово? Они заглядывают в Википедию. Что же там написано на этот счет? «Утверждение в лингвистике — особая форма предложения, которая в утвердительной форме выдвигает гипотезу относительно некоторого явления». Определенно это не то.
Что еще можно найти? «Логическое утверждение — это высказывание, образованное из других высказываний с помощью логических связок». Тоже не подходит. «Утверждение в программировании — это предикат, размещённый в программе и указывающий на то, что разработчик имеет в виду этот предикат в этом месте программы всегда истинным». Но все равно, похоже, что все это не то, что подразумевается в текущем контексте.
На самом деле, согласно официальной терминологии, утверждения представляют собой доверенный источник информации об учетной записи, пытающейся выполнить авторизацию, предоставляемую в атрибутах этой учетной записи, которая хранится в доменных службах Active Directory. К различным утверждениям можно отнести множество свойств, таких как идентификатор безопасности самого пользователя или его компьютера, подразделение, в котором может работать пользователь, его номер комнаты, город, в котором он живет. Причем стоит обратить внимание на то, что в одной записи может храниться несколько утверждений, что позволяет делать политики динамического контроля доступа достаточно гибкими, чтобы удовлетворить практически любые возможные потребности.
На этом этапе у вас может возникнуть вполне логичный вопрос: а что нам вообще дадут эти утверждения и какой в них смысл? При помощи утверждений можно ограничивать доступ как к файлам, так и к папкам. А что в утверждениях самое ценное, так это то, что все созданные утверждения будут публиковаться непосредственно в Active Directory. Причем, как я уже упоминал в предыдущей статье по этой технологии, для полноценного функционирования динамического контроля доступа в целом и утверждений в частности, нет каких-либо ограничений относительно функционального уровня домена или леса вашей организации.
Так как о связи Kerberos с утверждениями я подробно рассказывал в одной из статей по протоколу сетевой аутентификации Kerberos, ссылку на которую я давал в предыдущей статье данного цикла, сразу будем переходить к такой теме, как:

Типы утверждений

Согласно официальному определению, типом утверждения в Windows Server 2012 называется проверочное утверждение об объекте, с которым оно связано. Как вы уже, вероятнее всего, догадались, тип утверждения основывается на атрибуте Active Directory и служит для определения разрешений при разработке централизованных правил доступа. В операционной системе Windows Server 2012 вы можете использовать любой из следующих трех типов утверждений:

• Пользовательские утверждения. Этот тип утверждений связан со значениями атрибутов, которые относятся к учетным записям пользователей. Естественно, контроллеры домена, работающие под управлением операционной системы Windows Server 2012, позволяют вам использовать для этого типа утверждений максимальное количество атрибутов пользовательских учетных записей, которые доступны в Active Directory;
• Утверждения устройств. В свою очередь, этот тип утверждений отвечает за предоставляемую в утверждениях информацию, которая относится к устройствам, представляемым в доменных службах Active Directory в качестве учетных записей компьютеров. Естественно, этот тип утверждений также позволяет вам использовать большинство доступных атрибутов для этого типа принципалов безопасности;
• Утверждения преобразования. Последний тип утверждений представляет собой утверждение, выданное контроллером домена при использовании политики преобразования утверждения. Как было отмечено еще в первой статье этого цикла, контроллеры домена под управлением Windows Server 2012 позволяют вам преобразовывать исходящие из доверенного леса или входящие в доверяющий лес утверждения. Этот тип утверждений еще будет рассматриваться в одной из последующих статей, посвященных данной технологии.

Условные выражения и операторы

Потихоньку будем переходить к более интересной части. Если говорить точнее, то сейчас мы с вами рассмотрим условные выражения, которые относятся к подсистеме безопасности ОС, появившиеся в операционной системе Windows Server 2012 специально для того, чтобы можно было реализовать поддержку авторизации на основании утверждений.
Что собой представляют эти условные выражения, которые относятся к утверждениям? По сути, эти условные выражения представляют собою булевы или логические выражения, которые, как правило, включают в себя два операнда, разделенных специальным оператором. В качестве результата условных выражений всегда могут выступать лишь два значения, а если точнее, то это могут быть значения TRUE и FALSE. Здесь также стоит обратить внимание на то, что выражения ACE оцениваются как в случае с авторизацией, так и во время аудита доступа, поэтому как в первом, так и во втором случае можно использовать одни и те же выражения.
А что вообще происходит с этими выражениями? Я уже раньше писал о том, что подсистема LSA считывает требуемую информацию из PAC и создает токены доступа. После этого, на основании предоставленной пользователем информации, выполняется проверка доступа и, на основании разрешений, назначенных в маркере безопасности определяется, будет ли разрешен либо запрещен доступ к ресурсу конечному пользователю. Это все и так понятно. Однако, с появлением утверждений в информации о проверке подлинности Kerberos, помимо SIDа принципала безопасности, также появилась возможность включать и дополнительную информацию, которую можно найти в этих условных выражениях.
Сами утверждения представляют собой совокупность из таких сущностей, как тип утверждения и имя утверждения, причем обязательно они должны разделяться точкой (это вы увидите ниже). Первая часть, что очевидно, используется непосредственно для определения типа утверждения, который, как мы с вами выяснили в предыдущем разделе, может выступать в качестве User или Device. Перед упоминанием типа утверждения следует указывать символ @, за которым уже будет следовать сам тип. Часть с именем утверждения — это просто-напросто имя, которое вы можете задать такому утверждению при его создании.
Левая и правая части выражения утверждения должны сравниваться специальным оператором, причем в качестве правого операнда может быть буквенное значение, которое может представлять собой фрагмент значения левого операнда.
Всего можно выделить 13 операторов, которые, вероятнее всего, вам уже должны быть известны по работе с другими программными продуктами. Не буду подробно рассказывать о каждом таком операторе, а просто приведу их значения. Это оператор равно (==), не равно (!=), больше (>), меньше (<), больше или равно (>=), меньше или равно (<=), не (!), и (&&), или (||), содержит (Contains), то есть при использовании такого оператора левый операнд должен содержать фрагмент правого операнда; любое из (Any_Of), назначение которого в чем-то схоже с предыдущим оператором за исключением того, что в качестве значения может выступать лишь фрагмент значения правого операнда; член группы (MemberOf) – практически то же, что и содержит, только в качестве операнда выступает SID, а также оператор любой член группы (MemberOF_Any), что также можно сравнить с оператором любое из.
Теперь попробуем рассмотреть пример условных выражений, которые могут использоваться с утверждениями при реализации сценариев динамического контроля доступа. Например, возьмем следующее выражение:

 User.Department==”Маркетинг” && (User.Title==”Финансист” || User.Title==”Маркетинг”) 

Это выражение можно условно поделить на три части, причем каждая такая часть использует утверждения, да еще и вторая и третья части, которые находятся в скобках, будут обрабатываться одновременно. Теперь немного подробнее и по частям.
Исходя из приоритетов условных выражений, первыми должны выполняться выражения, которые расположены в скобках. Здесь в скобках можно найти два оператора: == и ||. Опять же, если смотреть по приоритетам, то первым всегда должен обрабатываться оператор ==. Следовательно, выражение обрабатывается слева направо.
Здесь в качестве типа утверждения пользователя выступает User.Title, которое отвечает за должность вашего сотрудника. Значит, мы проверяем, является ли должностью пользователя должность «Финансист». Предположим, что наш пользователь маркетолог, что означает, что в первом выражении значением будет FALSE, то есть ложь. Однако у нас между двумя выражениями установлен оператор ||, означающий логическое «ИЛИ». Это означает, что если второе выражение у нас будет истинным, то будет проверяться еще самое левое условное выражение.
В нашем случае, так как пользователь маркетолог, второе условное выражение в скобках примет значение TRUE, и это значит, что можно проверять условия дальше. На этом этапе у нас выходит следующее выражение:

 User.Department==”Маркетинг” && (FALSE || TRUE) 

Это означает, что можно выражение сократить еще сильнее, до:

 User.Department==”Маркетинг” && TRUE 

После этого проверяется самое левое условное выражение. Здесь, полагаю, все понятно. Проверяется, является ли отделом нашего пользователя «Маркетинг». Так как наш пользователь маркетолог, предположим, что его отдел, – это именно отдел маркетинга, и значит, выражение истинно. У нас получается следующее:

 TRUE && TRUE 

Так как оператор && представляет собой логическое «И», это означает, что оба условия должны быть истинными. В нашем случае так и есть. Следовательно, условие истинно и доступ будет предоставлен. Если бы здесь где-то фигурировало FALSE, то при операторе && оно бы превалировало, и в конечном счете мы бы получили результат FALSE.
Другими словами, у нас получается выражение, которое изображено на следующей иллюстрации:

Рис. 1. Пример условного выражение в диалоговом окне элементов разрешения для папки
ВОПРОС для внимательного читателя: что собой представляет следующее условное выражение, и как будет выполняться проверка, если учесть, что мы имеем дело все с тем же пользователем, о котором речь шла выше:

 (User.Title==”Бухгалтер” || User.Title==”Финансист”) || User.Department!=”Служба поддержки” 

А что собой представляют сами объекты утверждений?

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

• msDS-ClaimTypePropertyBase. Данный класс Active Directory представляет собой объект абстрактного класса, который зачастую используется для предопределения общих атрибутов для объектов классов msDS-ClaimType, а также msDS-ResourceProperty, о котором вы узнаете из следующей статьи. С этим объектом связаны три атрибута: Enabled (здесь все понятно без каких-либо разъяснений), msDS-ClaimPossibleValues (представляет собой строковое юникодное значение, определяющее предполагаемое значение в пользовательском интерфейсе. Обычно хранится это значение в XML-файле) и msDS-ClaimsSharesPossibleValuesWith (принимает различающееся имя объекта msDS-ClaimType и используется в качестве атрибута, предопределяющего значения msDS-ClaimPossibleValues для объекта msDS-ResourceProperty);
• msDS-ClaimType. А вот данный класс Active Directory выступает структурным классом для объектов, используемых для представления утверждений, применяемых принципалами безопасности организации. Данный объект уже включает в себя большее количество атрибутов, к которым можно отнести: msDS-ClaimAttributeSource (включает в себя различающееся имя схемы определения атрибута, которое используется в качестве источника утверждения), msDS-ClaimIsSingleValued (представляет собой булево значение, определяющее, содержит ли утверждение или тип утверждения только одно значение), msDS-ClaimIsValueSpaceRestricted (опять же, включает булево значение, определяющее, может ли текущий объект класса принимать значения, отличающиеся от значения, определенного в атрибуте msDS-ClaimPossibleValues), msDS-ClaimSource (такой атрибут отвечает за не являющийся атрибутом источник для объекта msDS-ClaimType, в качестве примера которого можно привести, скажем, сертификат), msDS-ClaimSourceType (атрибут, отвечающий за источник типа утверждения), msDS-ClaimTypeAppliesToClass (атрибут, определяющий схему класса объекта принципала безопасности, которому выдается утверждение), msDS-ClaimValueType (атрибут, связывающий уникальные значения в виде длинного целого числа).

Объекты класса msDS-ClaimType изображены на следующей иллюстрации:

Рис. 2. Объекты класса msDS-ClaimType

Управление утверждениями

Ввиду того, что в последней серверной операционной системе от Microsoft особое внимание разработчики старались уделить непосредственно таким инструментам, как «Центр администрирования Active Directory», а также командной оболочке Windows PowerShell, управлять своими типами утверждений вы сможете как при помощи первого, так и средствами второго средства. Так как было бы несправедливо рассматривать только лишь одно средство, в следующих разделах я покажу, каким образом можно работать с утверждениями, используя эти оба средства администрирования. А начнем мы, естественно, с

Управления утверждениями средствами центра администрирования Active Directory

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

1. На контроллере домена откройте окно «Центра администрирования Active Directory», где в области списка выделите узел «Динамический контроль доступа», а затем выберите узел «Claim Types» (Dynamic Access Control > Claim Types);
2. В отобразившемся узле нажмите в области сведений правой кнопкой мыши и из контекстного меню выберите последовательно команды «Создать» и «Тип утверждений» (New > Claim Type), как показано на следующей иллюстрации, либо на начальной странице центра администрирования Active Directory перейдите к тайлу динамического контроля доступа и в группе действий Active Directory выберите первое действие, именуемое созданием типа утверждения. Как в первом, так и во втором случае, откроется диалоговое окно создания нового типа утверждения.

   
   Рис. 3. Открытие диалогового окна создания нового типа утверждения

3. Когда перед вами появится диалоговое окно «Создать Тип утверждения», вы в разделе «Атрибут источника» (Source Attribute) можете определиться с атрибутом источника и дополнительными элементами конфигурации, на основании которых и будет создаваться ваш тип утверждения. Как видно на следующей иллюстрации, первое, что может броситься в глаза, как только вы откроете текущее диалоговое окно, это большой список «Атрибут источника» (Source Attribute), содержащий множество различных атрибутов, из которого вы можете выбрать требуемый атрибут источника для своего создаваемого утверждения. Такой список формируется из целого ряда классов объектов, к которым относятся классы User, Computer, inetOrgPerson, ManagerServiceAccount, GroupManagerServiceAccount, а также вспомогательные классы объектов. При выборе атрибутов обязательно учтите то, что в текущем списке фигурируют только лишь атрибуты, обладающиестроковыми значениями, включая юникод, булевыми значениями, целыми числами, включая большие целые числа, а также строками OID и SID. Также, естественно, в этом списке не будут отображаться атрибуты, которые не реплицируются, заблокированные атрибуты и такие атрибуты, которые не доступны на контроллерах домена только для чтения (то есть RODC). Например, в данном случае выбирается атрибут department, но учтите, что перед тем как выбирать тот или иной атрибут, преждевременно спланируйте структуру своих утверждений для последующих централизованных политик доступа.

   
   Рис. 4. Раздел «Атрибут источника» создаваемого типа утверждения

4. Помимо этого, данный раздел диалогового окна создания типа утверждения предоставляет также и прочие параметры, а именно:
   
   • Отображаемое имя (Display Name). Представляет собой текстовое поле, содержащее уникальное отображаемое имя, которое присваивается созданному вами типу утверждения. Такое имя будет фигурировать для выполнения последующих операций, поэтому будет лучше всего, если вы в качестве такого имени будете использовать читаемые и понятные в будущем имена. Естественно, для создаваемого имени типа утверждения доступны буквенные и цифровые значения;
   • Описание (Description). Представляет собой поле для комментариев к создаваемому вами типу утверждения. Количество знаков в этом поле лимитировано – 1024 знака. Поэтому при добавлении своих комментариев и целей использования создаваемого типа утверждения следует быть лаконичными;
   • Утверждение такого типа можно выдавать для следующих классов (Claims of this type can be issued for the following classes). Управляющий элемент, позволяющий выбирать, будет ли утверждение относиться только к определенным типам принципалов безопасности (например, только к пользователям или только к компьютерам), либо, установив оба флажка, можно разрешить использовать текущий тип утверждения для обоих типов учетных записей;
   • Присвоить идентификатору семантически идентичный тип утверждений из доверяющего леса, чтобы упростить использование утверждений в лесах, связанных отношениями доверия (Set ID to a semantically identical claim type in a trusted forest). Представляет собой флажок, предназначенный для определения метода создания идентификатора типа утверждения. Если не устанавливать этот флаг, то центр администрирования Active Directory назначит такой идентификатор автоматически. Как он выглядит? Такой идентификатор начинается со строчных букв ad, за которыми следует двоеточие, два косые черты, буквы ext и еще одна косая черта (ad://ext/). Это стандартное начало идентификатора. После этого центр администрирования добавляет имя выбранного вами атрибута и после двоеточия добавляется в случайном порядке значение в шестнадцатеричном формате, которой в какой-то степени могут вам напомнить обычный GUID. То есть, в конечном счете, идентификатор в данном примере выглядит так:
     ad://ext/department:88d0094e632018a6
     В свою очередь, если вы создаете тип утверждения для лесов, связанных отношениями доверия, то по умолчанию метаданные для каждого типа утверждений будут создаваться уникальными для каждого леса, и, как следствие, контроллеры домена доверяющего леса не смогут обработать утверждения из доверенного леса. По этой причине вам необходимо убедиться в том, что идентификатор создаваемого типа утверждения будет семантически идентичен между доверенным и доверяющими лесами. Следовательно, данный флажок нужно устанавливать только лишь в указанном выше случае. Само собой, если вы указываете идентификатор вручную, то он обязан соответствовать контексту именования, о котором говорилось немного ранее. Обязательно помните о том, как должен начинаться каждый идентификатор, после ext/ должно быть указано не более 32 символов, которые не должны содержать специальных символов и заканчиваться косой чертой. Это обязательные условия. Ну и, само собой, помните, что такие идентификаторы должны быть уникальными;
   • Защита от случайного удаления (Protect from accidental deletion). Флажок, который, как и в случае с уже известными вам операциями в Active Directory, защищает создаваемый тип утверждения от непреднамеренного удаления. Несмотря на то, что по умолчанию создавать, изменять и удалять типы утверждений по умолчанию могут только администраторы, в некоторых случаях эта опция может прийтись как нельзя кстати.
5. Секция под названием «Предложенные значения» (Suggested Values) отвечает за предопределение выбираемых значений, которые вы можете выбирать при использовании типа утверждения в условном выражении. Как видно на следующей иллюстрации, здесь вы можете остановиться на выборе следующих значений:

   
   Рис. 5. Раздел «Предложенные значения» создаваемого типа утверждения

   • Нет предложенных значений (No values are suggested). Параметр, который установлен по умолчанию при создании любого типа утверждения. Предполагает, что вы не будете переопределять значения для типов утверждений, а такие значения будут набиваться вручную при создании самих условных выражений;
   • Предлагаются следующие значения (The following values are suggested). В этом случае вы можете создать одно или же несколько значений, которые будут доступны для выбора из соответствующего списка при последующем создании условного выражения. Следовательно, для работы с такими значениями вы можете использовать кнопки «Добавить», «Изменить» и «Удалить» (Add, Edit и Remove), которые можно найти в текущем разделе диалогового окна свойств создаваемого типа утверждения. Как именно создаются такие значения?
     При нажатии кнопки «Добавить» вы увидите диалоговое окно «Добавить предложенное значение», где можно найти три текстовых поля: «Значение» (Value), представляющее собой рекомендуемое значение в соответствующем текстовом поле условного выражения, «Отображаемое имя» (Display Name) – имя, которое будет отвечать за текущее значение и фигурировать при выборе такого значения, а также «Описание» (Description), отвечающее за произвольное описание для такого значения.
     Данное диалоговое окно можно увидеть на следующей иллюстрации:

     
     Рис. 6. Диалоговое окно добавления предложенного значения

6. По завершению добавления последнего предложенного значения можно сохранять получившейся тип утверждения. Готово.

Более того, при работе с утверждениями помните, что у них может быть два состояния: включено и отключено. Отключенные утверждения так и остаются настроенными со своими уникальными идентификаторами, однако вы их просто не сможете в будущем использовать. Для того чтобы отключить тип утверждения, достаточно всего лишь выделить такой объект и из контекстного меню выбрать опцию «Отключить» (Disable).

Управление утверждениями средствами Windows PowerShell

Без PowerShell сейчас, как говорится, никуда. А если еще и учесть то, что в последней на это время серверной операционной системе от Microsoft были разработаны командлеты практически для любого действия, то очевидно то, что и в случае с технологией динамического контроля доступа вы можете воспользоваться богатейшими функциональными возможностями этой современной командной оболочки.
Стоит сразу обратить внимание на то, что для работы как с типами утверждений, так и с технологией динамического контроля доступа в частности, вам понадобится использовать модуль Active Directory для Windows PowerShell. Используя богатые возможность PowerShell, вы можете создавать, изменять, удалять, включать и отключать типы утверждений. То есть, грубо говоря, можете выполнять все те же операции, которые доступны средствами графического интерфейса в центре администрирования Active Directory.
Так как данная статья вышла увесистой, рассмотрим лишь создание двух типов утверждений (с предопределенными значениями и без таковых), а также отключение типа утверждения, для которого не были определены значения. Значит:
Чтобы создать новый тип утверждения, используется командлет New-ADClaimType. Вместе с этим командлетом вы можете использовать до 21 параметра, назначение которых очевидны из самого их наименования. Поэтому я подробно не буду останавливаться на каждом параметре, а сразу предлагаю рассмотреть пример создания нового типа утверждения. Используем следующий командлет:

 New-ADClaimType –AppliesToClasses:@(‘user’) –Description:”Определение атрибута division” -DisplayName:”division” –IssingkeValued:$true –Server:”DC.biopharmaceutic.local” –ProtectedFromAccedentialDeletion:$true –SourceAttribute:”CN=Division,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local” 

Здесь обязательно обратите внимание на несколько моментов. Прежде всего, синтаксис параметра –AppliesToClasses следующий: вы указываете символ @, а затем в скобках и в кавычках указываете сам тип утверждения. Если вы хотите указать несколько типов, разделяйте их запятыми. Путь к атрибуту нужно указывать полностью, как это видно по предыдущей команде. Если вам нужно определить идентификатор, используйте параметр –ID и указывайте сам идентификатор в валидном формате, например, -ID:ad://ext/division:88d00962e3d07cd1.
Теперь посмотрим на более сложный пример, в котором попробуем вместе с типом утверждения еще и предопределить несколько значений. Попробуем создать тип утверждения для должности, где в качестве значений будут заданы маркетолог, бухгалтер и финансист:

 New-ADClaimType -AppliesToClasses:@('user') -Description:"Должность сотрудника" -DisplayName:"title" -IsSingleValued:$true -Server:"DC.biopharmaceutic.local" -ProtectedFromAccidentalDeletion:$true -SourceAttribute:"CN=Title,CN=Schema,CN=Configuration,DC=biopharmaceutic,DC=local" -SuggestedValues:@((New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Маркетолог", "Маркетолог", "Пользователь с должностью Маркетолог")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Бухгалтер", "Бухгалтер", "Пользователь с должностью Бухгалтер")), (New-Object Microsoft.ActiveDirectory.Management.ADSuggestedValueEntry("Финансист", "Финансист", "Пользователь с должностью Финансист"))) 

Как вы не могли не заметить, скрипт вышел намного массивнее. Здесь первые параметры практически идентичны, поэтому их разбирать нет смысла. А вот параметр –SuggestedValues, отвечающий за предложенные значения, может показаться весьма страшным. На самом деле, с ним все очень просто. Указывается параметр, после двоеточия следует указать символ @ и в скобках, при помощи командлета New-Object, нужно будет добавить объект Microsoft Active Directory Management ADSuggestedValueEntry с тремя значениями, определенными в скобках и разделенными запятыми. Перед добавлением каждого нового объекта следует ставить запятую и добавлять последний в дополнительных скобках. То есть все более-менее прозрачно.
И теперь третий пример, который позволит отключить созданный ранее тип утверждения без значений. Это можно реализовать, используя командлет, предназначенный для изменения типа утверждения. То есть сейчас мы будем использовать командлет Set-ADClaimType, естественно, с параметром —Enabled. Получается, следует выполнить такую команду:

 Set-ADClaimType -Identity "CN=ad://ext/division:88d00968ab6e025f,CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration,DC=biopharmaceutic,DC=local" -Enabled:$false 

Здесь нужно обратить внимание на то, что значение параметра –Identity обязательно должно совпадать со значением такого типа утверждения из атрибута distinguishedName самого объекта типа утверждения. Опять же, как видите, нет ничего сложного.
Вывод команд в окне Windows PowerShell изображен на следующей иллюстрации:

Рис. 7. Командлеты, о выполнении которых было написано раньше
Следовательно, после того как все указанные выше действия будут выполнены, в окне центра администрирования Active Directory должны отображаться три объекта типа утверждения, причем один из них должен быть отключен. Это видно на следующей иллюстрации:

Рис. 8. Окно центра администрирования Active Directory

А дальше?

В принципе, здесь материал данной статьи подходит к концу. Я вам рассказал о том, что собой представляют утверждения, какие бывают типы утверждений, что такое условные выражения, а также вы узнали о том, как можно управлять типами утверждений при помощи таких средств как «Центр администрирования Active Directory» и Windows PowerShell.
Естественно, на этом знакомство с такой технологией как динамический контроль доступа не заканчивается, так как еще будет рассмотрено очень много интересных нюансов, процедур, возможностей и сценариев. Например, в следующей статье мы с вами поговорим о свойствах ресурсов.