Возможности делегирования, предусмотренные в службе каталогов Active Directory, весьма значительны; они решают ряд проблем защиты и упрощают задачи управления. Грамотное делегирование прав в службе Active
Directory® позволяет регламентировать применение в среде определенных ролей, уменьшить вероятность и нейтрализовать последствия административных ошибок, реализовать в существующей инфраструктуре принцип наименьших привилегий. В то же время, многие организации, опирающиеся в своей работе на службы Active Directory, до сих пор не воспользовались потенциалом функции делегирования. Отчасти это объясняется кажущейся сложностью разработки модели делегирования в корпоративной среде службы Active Directory. Действительно, сформировать модель делегирования, отвечающую индивидуальным потребностям предприятия, сложнее всего, но с другой стороны, существует множество простых моделей, которые можно реализовать в большинстве ИТ-сред лишь с незначительными изменениями.
Естественно, каждая среда имеет свои особенности, но все крупные предприятия во многих отношениях схожи и призваны решать одни и те же задачи в сфере ИТ. К примеру многие компании структурированы по региональному принципу, сформировались на основе отдельных инженерных или эксплуатационных рабочих групп, имеют в своем составе автономные подразделения. Кроме того, для большинства крупных организаций актуальны проблемы несанкционированного расширения полномочий, злонамеренного применения учетных записей служб и формирования «доверительных отношений».
Понятие «доверие» весьма интересно само по себе; именно им часто обосновывается необходимость создания нескольких лесов службы Active Directory. Доверительные отношения обычно формируются исходя из способности одного подразделения или региона воздействовать на доступность систем в другом подразделении или регионе. Нередко уровень компетенции специалистов в различных структурных единицах компаний бывает различным; не исключена нехватка знаний о конкретных системах, необходимых для обеспечения работы ИТ-инфраструктуры в том или ином регионе или подразделении. По этой причине подразделения не горят желанием передавать административные права «центру».
В то же время, при любой реализации службы Active Directory администраторам вменяется в обязанность установить правила обращения приложений к инфраструктуре этой службы. К сожалению, широкое распространение, в том числе среди составителей руководств по установке приложений, получил метод, согласно которому учетная запись службы вводится в состав группы «Администраторы домена». Дело в том, что учетные записи служб по существу являются универсальными. Предоставление таким учетным записям прав администратора домена создает существенную угрозу безопасности ИТ-среды. Учетные записи служб очень удобны для безответственных администраторов и злоумышленников, занимающих эту важную должность, равно как и для инициаторов атак, стремящихся воспользоваться слабыми местами системы безопасности того или иного приложения.
Эти препятствия, на первый взгляд непреодолимые, в реальности оказываются исходной предпосылкой реализации модели делегирования службы Active Directory. Разработка модели делегирования — это итеративный процесс проектирования, в рамках которого рекомендуется выполнить следующие поэтапные действия.
Регламентировать административные роли в ИТ-среде организации.
Разработать модель подразделений и групп безопасности.
Создать для ИТ-администраторов вспомогательные учетные записи.
Делегировать права.
Рассмотрим эти этапы в деталях.
Определение ролей
Для определения ролей нужно четко представлять себе структуру администрирования служб и данных. Эти понятия лежат в основе любой модели делегирования полномочий в службе Active Directory.
По существу, администрирование служб — это управление важнейшими компонентами инфраструктуры службы каталогов, такими как серверы Exchange и контроллеры домена. В свою очередь, администрирование данных — это управление объектами, в том числе почтовыми ящиками и учетными записями пользователей, которые существуют в рамках служб. В рамках службы Active Directory администраторы служб отвечают за предоставление и доступность служб каталогов, а администраторы данных управляют учетными записями пользователей и служб, группами и другими ресурсами домена.
Служба каталогов Active Directory позволяет детализировать делегируемые полномочия при помощи понятия «Подразделения» (Organizational Units – OU). Подразделения во многих случаях можно настроить так, чтобы уровень предоставляемых ими полномочий соответствовал уровню, предусмотренному для администраторов в рамках существующих моделей службы каталогов или доменов. В то же время, важно понимать, что некоторые функции не подлежат делегированию и требуют управления одной единственной, исключительно надежной группой специалистов или объектом.
Не менее серьезную роль играет анализ задач. Необходимо знать, какие задачи службы Active Directory выполняются администраторами и как эти задачи можно привязать к ролям. К примеру, создание узла службы Active Directory как задача относится к администрированию служб, в то время как изменение настроек членства в группе безопасности обычно приписывается к администрированию данных. Каждую задачу требуется проанализировать на предмет регулярности, значимости и сложности. Это — важнейшие аспекты определения задачи; исходя из них принимается решение о том, нужно ли делегировать то или иное право. Задачи, которые выполняются постоянно, создают незначительные риски и просты в осуществлении, лучше всего подходят для делегирования. Задачи, которые выполняются нерегулярно, оказывают значительное воздействие в масштабе всей организации и требуют высокого уровня компетенции, напротив, не стоит делегировать. Для выполнения таких задач лучше подходит методика «расширения» (escalation), предполагающая временное продвижение учетной записи до уровня необходимой роли или переназначение задачи.
Так как крупные организации имеют много общего, можно с уверенностью говорить о том, что реализация стандартной модели делегирования возможна. Исходя из задач этой статьи, на рассмотрение представляется набор ролей, который, с одной стороны, реализует управляющие функции, а с другой, учитывает организационную структуру и имеет своей целью частичное решение проблем, связанных с доверительными отношениями (в том числе с доступностью общекорпоративных ресурсов, каковыми являются, например, контроллеры доменов). Эта модель — не просто пример. Она может послужить основой для формирования аналогичной модели в любой организации. С другой стороны, воспроизводить её без изменений не стоит.
Некоторые роли определяются службой Active Directory автоматически, но для формирования модели делегирования их недостаточно — ряд ролей придется создать заново. Вот пример набора ролей, который можно успешно реализовать во многих крупных средах службы Active Directory: «Администраторы предприятия», «Администраторы домена», «Администраторы 4 класса» (для администрирования служб), «Администраторы 3 класса», «Региональные администраторы», «Администраторы 2 класса» и «Администраторы 1 класса» (для администрирования данных). Список ролей и соответствующих обязанностей приводится на рис. 1.
Рис. 1 Определение ролей и обязанностей
Администраторы служб Описание
Администраторы данных Описание
Администраторы служб
Рассмотрим роли, относящиеся к администрированию служб, подробнее. Администраторы служб управляют важнейшими компонентами инфраструктуры; все администраторы, приписанные к этой категории, получают высокий уровень привилегий. В отношении этих ролей рекомендуется проводить стратегию наименьших привилегий, согласно которой каждому пользователю выделяется минимальный набор разрешений, необходимый для выполнения поставленных перед ним задач.
Администраторы предприятия и домена Служба Active Directory определяет две группы уполномоченных администраторов с контекстом безопасности, который позволяет выполнять в каталоге критические функции. Эти группы (администраторы предприятия и администраторы домена) осуществляют высокоуровневое администрирование служб. В целях снижения рисков, создаваемых группами со столь высоким уровнем привилегий, настоятельно рекомендуется ограничить членство в них. В группе администраторов предприятия вообще не должно быть постоянных членов; что же касается администраторов домена, то здесь достаточно небольшого, поддающегося учету числа надежных специалистов, работающих в штате организации.
Для выполнения административных задач корпоративного уровня, таких как авторизация DHCP-сервера или создание узла службы Active Directory, участники группы администраторов домена в корневом домене леса службы Active Directory могут расширить привилегии путем наполнения группы администраторов предприятия. Такие привилегии должны предоставляться только на короткое время. Цель подобной политики — избежать постоянного членства в группе администраторов предприятия. Не стоит и говорить, что все члены группы администраторов домена в каждом конкретном лесу службы Active Directory должны быть в равной степени надежны.
При разработке модели делегирования большинство организаций совершает одну и ту же ошибку — они отключают или сокращают функциональность встроенных ролей. Внесение изменений в стандартные роли может привести к самым неожиданным результатам; кроме того, нет никакой гарантии, что при установке пакета обновления или модернизации продукта такие настройки сохранятся. Наконец, подобного рода изменения приводят к утрате совместимости с внешней средой за пределами организации. Лучше всего оставить в силе набор встроенных групп и ролей, но ограничить членство в них. Для этого, возможно, придется создать новые роли для администраторов, которые ранее входили в группы наподобие администраторов домена.
Администраторы 4 класса В группу администраторов 4 класса должны быть включены администраторы, специализирующиеся на поддержке всех корпоративных служб. Так как это нестандартная роль, права доступа к службе каталогов и к системе можно настроить согласно конкретным требованиям организации. Несмотря на то, что члены этой группы являются администраторами служб, они могут время от времени выполнять задачи управления данными в масштабе леса. В силу неоднородности классов систем и сфер ответственности роли 4 класса в рамках каталога подразделяются на несколько подгрупп. К примеру, группы класса 4 следует создать для раздельного управления системами различных видов (в частности, серверами Exchange). Эта группа, кроме того, служит отправной точкой расширения полномочий администраторов данных.
Одна из причин, по которым пользователи часто стремятся попасть в состав участников группы администраторов домена, заключается в том, что она предоставляет административные полномочия доступа ко всем системам в данном домене. Чтобы организовать работу администраторов служб в режиме наименьших привилегий, нужно включить их в группу администраторов 4 класса и разрешить в её настройках доступ к серверам предприятия; в этом случае необходимость включения таких администраторов в группу администраторов домена отпадает. Во избежание расширения привилегий администраторам 4 класса не стоит предоставлять членство в группе BUILTIN\Administrators в контроллерах домена; дело в том, что она предусматривает ряд фундаментальных прав в отношении службы каталогов, которые нельзя разделить. К примеру, каждый член группы BUILTIN\Administrators в том или ином домене имеет право управления членством в группе администраторов домена; иными словами, у него есть возможность расширять привилегии безо всяких ограничений.
С учетом изложенного правила, запрещающего нарушение функциональности стандартных разрешений, такой риск можно сократить за счет включения администраторов 4 класса во встроенные группы домена «Операторы сервера» и «Администраторы DNS» в качестве вложенных групп. Такое решение, с одной стороны, создает механизм локального управления контроллерами домена, а с другой, ограничивает возможности администраторов 4 класса расширять привилегии. В большинстве систем (за исключением «Контроллеров домена», «Серверов сертификатов» и т.д.) группу администраторов 4 класса имеет смысл включать в состав локальной группы «Администраторы». Членство во вложенных локальных группах можно автоматизировать при помощи функций «Группы с ограниченным доступом» групповой политики.
Администраторы данных
Теперь рассмотрим роли, относящиеся к администрированию данных. В них должны предусматриваться совокупные права; иначе говоря, администратор 2 класса должен обладать всеми правами администратора 1 класса и определенным набором дополнительных прав, и так на каждом последующем уровне. По этой причине рассмотрим группы в порядке от наименьших к наибольшим привилегиям.
Администраторы 1 класса Участники группы администраторов 1 класса осуществляют общее управление ранее созданными объектами каталога. Эта группа предусмотрена для наименее компетентных администраторов, а также для лиц, выполняющих отдельные задачи (например сброс паролей). В рамках определенного подразделения этой группе нужно предоставить права изменения свойств учебных записей пользователей, сброса паролей таких учетных записей, разблокирования учетных записей, включения и отключения учетных записей пользователей, добавления и сброса учетных записей рабочих станций, а также изменения настроек членства в объектах неадминистративных групп.
Администраторы 2 класса Задача этой группы – выборочное управление и создание объектов с расчетом на то, чтобы ими смогли управлять администраторы 1 класса (к примеру, группы безопасности могут в данном случае создаваться только в подразделении «Группы»). Администраторы 2 класса вправе добавлять и изменять учетные записи администраторов 1 класса; добавлять, изменять и удалять учетные записи в рамках подразделения; удалять объекты рабочих станций; добавлять, изменять и удалять объекты «Сервер», «Контакт» и «Общая папка».
Региональные администраторы Участникам этой группы предоставляются исключительные права управления региональной структурой подразделений. В то же время, они не могут управлять другими региональными структурами подразделений, существующими в каталоге. Учетные записи, относящиеся к группе «Региональные администраторы», считаются особо привилегированными; по этой причине они хранятся в отдельной иерархии подразделений и управляют ся администраторами служб из группы администраторов 4 класса. Группа «Региональные администраторы» имеет неограниченные права на создание большинства объектов в рамках локальной структуры подразделений (исключение: право создания новых подразделений за этой группой не закреплено); в связи с этим возникает риск создания объектов, которыми администраторы более низких классов не могут управлять.
Администраторы 3 класса Во многих организациях есть централизованная или ведущая служба поддержки. Наличие этой роли увеличивает численность администраторов данных; по сути, создается отдельная, вышестоящая по отношению ко всем региональным администраторам группа администраторов данных. Эта группа не имеет прав, специально делегированных ей в рамках каталога; в данном случае права аккумулируются посредством вложенного членства в каждой из групп «Региональные администраторы». В результате на высшем уровне формируется точка расширения прав всех администраторов данных; кроме того, создается центр регистрации задач, предназначенных для передачи группам администрирования служб.
Формирование модели подразделений и групп безопасности
Справившись с определением ролей в рамках организации, переходите к формированию модели подразделений и групп безопасности. Подразделение в службе Active Directory имеет смысл создать по двум причинам. Во-первых, оно позволяет организовать делегирование прав, а во-вторых, служит точкой связывания с объектами групповой политики. Подразделения регламентируют область управления (scope-of-management – SOM) в рамках каталога; такие области, в свою очередь, помогают на разных уровнях сузить действие прав до отдельных объектов. В связи с этим определяющим фактором реализации структуры подразделений должна стать принятая схема делегирования полномочий.
Соответственно, подразделение верхнего уровня (или набор таких подразделений) нужно создать непосредственно в рамках домена; в таком случае к нему (к ним) будут отнесены все объекты. Такое подразделение служит конкретной цели — оно определяет для администраторов 4 класса область управления наивысшего уровня. Благодаря подразделению верхнего уровня процесс явного распределения прав в отношении службы каталогов можно начать на уровне подразделений (в противном случае пришлось бы обращаться к уровню домена). Делегирование от подразделения верхнего уровня, минуя уровень домена, сокращает риск расширения привилегий пользователями путем операций со встроенными группами домена, о которых упоминалось ранее.
В составе подразделений верхнего уровня необходимо создать отдельные иерархии дочерних подразделений, представляющие все регионы или организационные единицы с обособленными группами управления данными. В целях управления объектами каталога в каждом региональном дочернем подразделении должна быть стандартная, не предусматривающая возможности расширения иерархия подразделений. Для текущего управления крайне важна согласованность, так как значительная часть процесса делегирования прав автоматизирована. Поскольку в каждом регионе может требоваться особая иерархия подразделений, согласовать их довольно трудно. В то же время, администраторы ИТ-отделов должны гнуть свою линию, и даже если в каком-то регионе приходится выполнить расширение структуры дочернего подразделения, оно должно быть воспроизведено во всех других регионах. Наверное, поначалу это будет казаться сложным, но суть в том, что если организации удастся сформировать универсальную схему систематизации объектов, со временем нештатные ситуации перестанут её беспокоить.
Наконец, создайте дочерние административные группы и учетные записи, благодаря которым администраторы не смогут расширять свои полномочия. В каждой иерархии дочернего подразделения нужно создать группы «Администраторы 1 класса», «Администраторы 2 класса» и «Региональные администраторы». Благодаря размещению таких учетных записей в отдельных подразделениях область управления ограничивается этими подразделениями или более низким уровнем. Так, если все учетные записи администраторов 1 класса и соответствующая группа безопасности размещены в подразделении, относительно которого у них нет прав, администраторы не смогут присваивать чужие административные учетные записи и расширять привилегии других администраторов до своего уровня. К примеру, каждый член группы «Администраторы домена» может присоединить к этой группе любую учетную запись пользователя, созданную в данном домене. Если же действует модель подразделений, о которой говорится, такой риск сводится к минимуму. Пример структуры подразделений с соответствующими группами безопасности представлен на рис. 2.
Рис. 2 Структура подразделений и соответствующие группы безопасности
Создание вспомогательных учетных записей
Модель делегирования сможет стать успешной только при условии соблюдения принципа наименьших привилегий. На практике это означает, что каждый участник политики безопасности должен выполнять только те задачи, которые требуются для исполнения его роли, и ничего более. К сожалению, при администрировании каталога и выполнении повседневных задач, таких как просмотр веб-страниц и чтение электронной почты, многие специалисты обращаются к одному и тому же участнику политики безопасности. Наличие автономных учетных записей сокращает риск случайного повреждения администратором того или иного класса службы каталогов или проведения атаки, направленной на администратора каталога, через стандартные приложения.
Чтобы решить эту проблему, не принуждая администратора выходить и вновь входить в систему, имеет смысл обратиться к службе вторичного входа в систему (компонент Runas.exe). Она позволяет пользователям расширять полномочия, указывая при выполнении сценариев и исполняемых файлов на серверах и рабочих станциях дополнительный набор учетных данных.
Несмотря на то, что принцип настройки учетных записей с наименьшими привилегиями довольно прост, в некоторых организациях он приживается с трудом — старые привычки ИТ-специалистов не так уж легко побороть. Чтобы предотвратить применение привилегированных учетных записей для решения повседневных задач, можно составить административную политику организационного уровня и с её помощью запретить почтовый доступ к таким учетным записям в приложении Exchange Server. Этот сравнительно простой метод серьезно уменьшает вероятность употребления подобных учетных записей в повседневной работе, не связанной с администрированием.
Делегирование прав
На последнем этапе осуществляется собственно делегирование прав в службе Active Directory. Эта задача сводится к операциям с записями управления доступом (access control entries – ACE) и списками управления доступом (access control lists – ACL) к данным, хранящимся в структуре каталога. Списки ACL, относящиеся к контейнерам службы Active Directory, определяют объекты, которые могут создаваться в службе каталогов, и регламентируют способ управления этими объектами. Делегирование прав связано с базовыми операциями с объектами, в том числе с возможностью просмотра объектов, создания дочерних объектов определенного класса, чтения атрибутов и параметров безопасности объектов определенного класса. Помимо основных операций, в службе Active Directory определяются расширенные права, благодаря которым становятся доступными такие операции, как «Отправить как» и «Управление топологией репликации».
Ранее было обсуждено создание групп безопасности, соответствующих предусмотренным в организации ролям. При этом с каждой ролью ассоциируется группа безопасности, созданная в структуре дочерних подразделений. Для реализации такой модели делегирования группам необходимо назначить разрешения применительно к объектам каталога. На этом этапе не имеет смысла изобретать колесо и создавать среду с высокой индивидуализацией. По возможности старайтесь обходиться встроенными группами и правами. Предположим, что той или иной роли требуется предоставить средства управления DNS-записями в масштабах отдельного леса. Не пытайтесь делегировать права в отношении контейнеров и контекстов именования, связанных с встроенной в службу Active Directory службой DNS; лучше обратитесь к существующей в домене группе BUILTIN\DNS Admins. Кроме того, права пользователя и другие разрешения можно расширить с помощью групповой политики; в таком случае формируются дополнительные права, необходимые для управления определенным классом систем посредством определенной роли.
При распределении полномочий путем делегирования нужно ограничить или полностью исключить применение в каталоге запрещающих элементов ACE. Дело в том, что они могут создать трудности при устранении неполадок. Предоставить права настраиваемым группам, представляющим роли, лучше при помощи явных разрешающих элементов ACE. Не забывайте о том, что любая роль, определенная пользователем (например администраторов 4 класса), не имеет никаких прав, кроме тех, что были заданы в ней явным образом.
Существенную роль в системе безопасности службы Active Directory играет наследование; механизм наследования регламентирует действие тех или иных списков ACL на дочерние объекты в данном контейнере (обычном или вложенном). Разграничивая сферу наследования, будьте предельно конкретны — применяйте наследуемые элементы ACE как можно ближе к целевым объектам. Наследуемые запреты разрешений (deny permissions), установленные в отношении родительского объекта, имеют приоритет относительно аналогичных запретов, установленных на уровне прародительского объекта; это одна из тех причин, по которым запрещающие элементы ACE не рекомендуется применять в практике делегирования. Более того, наследуемое разрешение не может перекрыть явно заданный в отношении объекта элемент ACE. По этой причине рекомендуется ограничить или полностью исключить для администраторов, принадлежащих к различным классам, возможность изменения списка управления доступом на уровне пользователей (путем отзыва права записи в списке разграничительного контроля доступа — DACL), действующего в отношении объектов каталога (следует учитывать, что создателю объекта это право присваивается неявно). Как правило, если администратор имеет возможность изменить действующий в отношении объекта список DACL, он это сделает. Так уберегите же модель делегирования, на формирование которой ушло столько сил, от необоснованного выбора и возможных административных ошибок.
Существует ряд инструментов, которые потребуются для надежной реализации модели делегирования в службе Active Directory. В большинстве крупных организаций делегирование полномочий в каталоге посредством встроенного Мастера делегирования сопряжено с риском административных ошибок. Делегирование должно быть автоматизированным; в связи с этим модель делегирования должна быть комплексно документирована, предусматривать возможность поддержки и способ восстановления на случай утраты или случайного изменения настроек.
Основной инструмент, необходимый для реализации делегирования — программа DSACLS.EXE. Это утилита с интерфейсом командной строки, применяемая для управления списками ACL службы каталогов, действующими в отношении объектов. Кроме того, она позволяет указывать применительно к родительским объектам флаги наследования списка DACL. (Виды флагов наследования: «Данный объект и дочерние объекты», «Только дочерние объекты», «Распространить наследуемые разрешения на один уровень».) В случае неверной установки флага наследования команды DSACLS завершаются с ошибками, поэтому при работе с рассматриваемой утилитой очень важно не пренебрегать тестированием. Вот пример синтаксиса команды DSACLS, предназначенной для делегирования права создавать объекты компьютеров в целевом подразделении demo:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
Типы объектов в утилите DSACLS нужно указывать с соблюдением регистра. Скажем, попытка делегирования разрешений относительно класса объектов "cn=Computer" с помощью параметра "cn=computer" не приведет к желаемому результату (см. рис. 3).
Рис. 3 Ошибка, вызванная чувствительностью к регистру
Для создания некоторых объектов требуется определенный набор прав. Имеются в виду обязательные и необязательные атрибуты объектов. Лучше всего этот принцип объясняет сравнение с гамбургером. В каждом полноценном гамбургере должны быть кусок мяса и булка. Это — обязательные атрибуты класса объектов типа «Гамбургер». Соленья, кетчуп, салат и прочие компоненты относятся к категории необязательных атрибутов. Чтобы создать на основе гамбургера класс объектов «Чизбургер», нужно добавить в список обязательных атрибутов сыр.
Аналогичным образом устроены объекты пользователей. Теперь предположим, что для создания на основе этой модели объектов пользователей применяется следующий синтаксис команды DSACLS:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
В ходе создания объектов таким способом администратор столкнется с несколькими ошибками. Нужно предоставить привилегии, необходимые для установки обязательных атрибутов объекта пользователя, в том числе указать пароль. Это сделано в следующем примере добавочного синтаксиса команды DSACLS.
В первую очередь, предоставим право записи обязательных атрибутов; для этого нужно присвоить всем атрибутам класса пользователя разрешения Generic Read/Generic Write (базовая запись/чтение):
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Далее предоставим расширенное право изменения пароля:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Наконец, присвоим атрибуту «Последний пароль задан» права «Чтение свойства» и «Запись свойства»:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
После делегирования прав определенные роли смогут управлять только теми классами объектов, которые указаны в списке DACL контейнера. В контексте предыдущего примера объекта компьютера отметим, что контекстное меню в консоли «Active Directory – пользователи и компьютеры» ограничивает список новых объектов, которые может создать пользователь, получивший подобные права путем делегирования (см. сокращенный список на рис. 4).
Рис. 4 Сокращенный список новых объектов
Для комплексного развертывания прав команды DSACLS можно автоматизировать. Ниже приведены некоторые команды DSACLS, позволяющие делегировать права управления стандартными атрибутами адресов по отношению к объектам пользователей в отдельно взятом контейнере.
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Подобные примеры в большинстве моделей делегирования встречаются нередко; их можно реализовать в совокупности с ранее указанными ролями.
Еще один инструмент, применяемый для реализации делегирования, называется DSREVOKE.EXE. Он позволяет администраторам находить и удалять права, делегированные отдельным участникам политики безопасности в отношении объектов каталога. Не умаляя достоинств этой утилиты, следует подчеркнуть, что она работает с конкретными участниками политики безопасности и не оценивает вложенную структуру членства в группах безопасности.
Помимо упомянутых утилит с интерфейсом командной строки, настоятельно рекомендуется обращаться к разделам «Назначение прав пользователя» и «Группы с ограниченным доступом» групповой политики. Как уже говорилось, раздел «Назначение прав пользователя» позволяет ИТ-администраторам продлевать или отзывать низкоуровневые права (например право удаленного доступа и перезагрузки системы) у различных групп пользователей в конкретных системах. Раздел «Группы с ограниченным доступом» позволяет настраивать и вводить в действие членство в локальных группах и группах доменов в масштабах того или иного леса. Сочетание всех этих инструментов предоставляет неограниченные возможности автоматизации и реализации модели делегирования в службе Active Directory.
Заключение
Формирование модели делегирования в службе Active Directory может, на первый взгляд, показаться сложной задачей, но на самом деле существуют очень простые модели, применимые в большинстве ИТ-инфраструктур. Один из важнейших этапов развертывания эффективной модели делегирования полномочий сводится к четкому определению ролей. Набор ролей должен быть компактным и поддающимся учету. Здесь важно найти компромиссное решение: если ролей слишком много, некоторые из них останутся без употребления, а если их слишком мало, разделение ролей будет затруднено.
Не забывайте о том, что при определении задач их нужно систематизировать по признакам регулярности, значимости и сложности. Справившись с определением ролей, создайте в целях автоматизации процесса тестирования набор вариантов использования, регламентирующих возможности и ограничения каждой роли. Тщательно подготовленные варианты использования помогут объяснить распределение ролей заинтересованным лицам в организации и сократить риск неожиданных последствий из-за ошибок автоматизации.
Наконец, при разработке модели делегирования лучше всего исходить из практических соображений. Не забывайте: простота упрощает поддержку, а устойчивая модель делегирования исключает многие проблемы, связанные с контролем административных прав в среде службы Active Directory.
|
