делегировать право ввода в домен

Делегирование административных полномочий в Active Directory

В этой статье мы рассмотрим особенности делегирования административных полномочий в домене Active Directory. Делегирование позволяет предоставить право на выполнение некоторых задач управления в AD обычным пользователям домена, не включая их в привилегированные доменные группы, такие как Domain Admins, Account Operators и т.д.. Например, с помощью делегирования вы можете предоставить определённой группе пользователей (допустим, Helpdesk) право на добавление пользователей в группы, заведение новых пользователей в AD и сброс пароля.

Особенности делегирования прав в AD

Для делегации полномочий в AD используется мастер Delegation of Control Wizard в графической оснастке Active Directory Users and Computers (DSA.msc).

Административные права в AD можно делегировать на довольно детальном уровне. Одной группе можно предоставить право на сброс пароля в OU, другой – на создание и удаление аккаунтов, третье на сброс пароля. Можно настроить наследование разрешений на вложенные OU. Вы можете делегировать полномочия на уровне:

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

Делегирование полномочий на сброс паролей и разблокировку учетных записей

Представим, наша задача – предоставить группе HelpDesk право на сброс пароля и разблокировку аккаунтов пользователей в домене. Итак, создадим новую группу в AD с помощью PowerShell:

Добавьте в группу нужных пользователей:

Запустите консоль Active Directory Users and Computers (ADUC), щелкните ПКМ по OU с пользователями (в нашем примере это ‘OU=Users,OU=Moscow,DC=corp,dc=winitpro,DC=ru’) и выберите пункт меню Delegate Control.

Выберите группу, которой вы хотите предоставить административные полномочия.

Выберите из списка один из преднастроенных наборов привилегий (Delegate the following common tasks):

Либо создайте собственное задание делегирования (Create a custom task to delegate). Я выберу второй вариант.

Выберите тип объектов AD, на которые нужно предоставить права. Т.к. нам нужно предоставить права на учетные записи пользователей, выберите пункт User Object. Если вы хотите предоставить право на создание и удаление пользователей в этом OU, выберите опции Create/Delete selected objects in this folder. В нашем примере мы не предоставляем таких полномочий.

В списке разрешений нужно выбрать те привилегий, которые вы хотите делегировать. В нашем примере мы выберем право на разблокировку (Read lockoutTime и Write lockoutTime) и сброс пароля (Reset password).

Нажмите Next и на последнем экране подтвердите назначение выбранных полномочий.

Теперь под учетной записью пользователя из группы HelpDesk попробуйте из PowerShell сбросить пароль пользователя из OU Users, например из PowerShell:

Пароль должен сброситься успешно (если он соответствует доменной политике паролей).

Теперь попробуйте создать пользователя в данной OU с помомью командлета New-ADUser:

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

Для контроля пользователям, которым вы делегированными привилегии, вы можете использовать журналы контроллеров домена. Например, вы можете отследить кто сбросил пароль пользователя в домене, узнать кто создал учетную запись пользователя в AD или отследить изменения в определённых группах AD.

Делегация полномочий на присоединение компьютеров в домен AD

По умолчанию любой пользователь домена может присоединить в домен 10 компьютеров. При добавлении в домен 11-го компьютера появляется сообщение об ошибке.

Вы можете изменить это ограничение на уровне всего домена, увеличив значение в атрибуте ms-DS-MachineAccountQuota (ссылка). Либо (гораздо правильнее и безопаснее), делегировав право на присоединение компьютеров к домену в определенной OU конкретной группе пользователей (helpdesk). Для этого нужно предоставить право создавать объекты типа (Computer objects). В мастере делегирования выберите Create selected objects in this folder.

А в секции Permissions выберите Create All Child Objects.

Отключаем делегирование прав в домене AD

Чтобы лишить группу делегированных ранее прав на OU, откройте свойства OU в консоли ADUC и перейдите на вкладку Security.

В списке разрешений найдите группу, который вы делегировали права и нажмите Remove. Список предоставленных полномочий можно посмотреть на вкладке Advanced. Как вы видите для группы HelpDesk разрешен сброс паролей.

Источник

Как делегировать контроль над OU в Active Directory

В крупных организациях существует несколько команд ИТ-администраторов и специалистов службы поддержки и в этом случае необходимо делегирование полномочий. Например, специалисты службы поддержки или руководители групп могут сбрасывать пароли, системные администраторы могут изменять членство в группах, а управлять OU могут только ИТ-архитекторы.

Такое разделение обязанностей действительно полезно для оптимизации операций и безопасности.

Чтобы выполнить делегирование управления, администраторы домена должны иметь разрешения или полные привилегии управления над OU. Это можно сделать несколькими способами: через Active Directory Users and Computers, командную строку, группы и пр.

Делегирование через Active Directory Users and Computers

Для того чтобы делегировать управление через Active Directory Users and Computers (dsa.msc). Выполните следующие действия:

Запустите Active Directory Users and Computers. Щелкните правой кнопкой мыши на OU, которому вы хотите делегировать управление, и выберите Delegate Control.

Появится мастер делегирования контроля, где вам нужно нажать «Next«.

В появившемся окне нужно нажать «Add. » и выбрать пользователей или группы, которым вы хотите делегировать управление, и нажать «Next«.

В окне «Tasks to Delegate» выберите задачи, которые вы хотите делегировать, вы также можете создать пользовательскую задачу с нуля.

Нажмите Next и Finish

Разрешения на делегирование можно просмотреть в свойствах OU на вкладке Security.

Делегирование через командную строку

Для делегирования прав доступа компания Microsoft разработала сервис dsacls.exe. Он хорошо подходит для назначения делегирования посредством скриптов. Он также хорошо подходит для отображения текущих прав доступа. Вы можете использовать параметр /a для отображения всех прав доступа у OU, например:

dsacls.exe «OU=Employees,DC=office,dc=local» /a

Здесь мы видим права доступа KJenkins, которые мы делегировали в нашем предыдущем примере.

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

Наиболее популярные расширенные права:

Давайте делегируем нашему пользователю KJenkins права на удаление OU Employees:

dsacls.exe «OU=Employees,DC=office,DC=local» /G OFFICE\KJenkins:SD;

Делегирование через встроенные группы

По умолчанию существуют встроенные группы, такие как Account Operators и Server Operators, которые выполняют административные задачи в Active Directory.

Вы можете включить любого пользователя в эти группы и получить дополнительные полномочия в домене без необходимости предоставления полного доступа к управлению. Но имейте в виду, что встроенная группа Account Operators предоставляет больше разрешений, чем требуется на самом деле. Они могут создавать, изменять и удалять все объекты, кроме членов группы Domain Admins, во всех OU, кроме OU Domain Controllers.

Лучшие практики по делегированию прав в OU

— Постройте матрицу управления делегированием, чтобы документировать все права доступа к AD

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

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

— Попробуйте протестировать настройки делегирования на предмет нежелательных эффектов.

Источник

Делегирование разрешений в Active Directory

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

Все о списках управления доступом

Список управления доступом (ACL) сопоставляется со всеми объектами каталога и управляет средствами защиты каждого из них. Список управления доступом, известный также как дескриптор безопасности, хранится в формате двоичных данных в атрибуте nTSecurityDescriptor соответствующего объекта. Начиная с версии Windows Server 2003, для хранения в базе данных AD списков управления доступом в структуре AD предусмотрен внутренний механизм, обеспечивающий хранение одного экземпляра каждого списка. Этого вполне достаточно, поскольку почти все объекты каталога совместно используют общий набор списков ACL. Фактический объем данных ACL довольно велик, и при сведении числа копий к одной обеспечивается существенная экономия дискового пространства.

Списки ACL состоят из двух компонентов: разграничительный список ACL (Discretionary ACL, DACL) и системный список ACL (System ACL, SACL). Компонент SACL используется в случаях, когда для соответствующего объекта проводится аудит безопасности (скажем, когда объект модифицируется). Оба компонента включают в себя ряд записей управления доступом access control entries (ACE), которые представляют фактические разрешения доступа в данном ACL. В дальнейшем при упоминании термина ACL мы будем иметь в виду компонент DACL.

Чтобы просмотреть компонент ACL с использованием оснастки ADUC, нужно прежде всего активировать в консоли режим просмотра Advanced Features; для этого следует выбрать пункт View, а затем Advanced Features. Теперь правой кнопкой мыши щелкните на одном из объектов, откройте вкладку Properties и перейдите на вкладку Security, показанную на экране 1. Вы увидите, что пользовательский интерфейс оснастки и интерфейс, используемый при управлении системными разрешениями, в общих чертах одинаковые, просто в первом случае назначаются одни разрешения доступа, а во втором — другие. Более подробно структура ACL описана во врезке «Внутри абстракций ACL».

Подобно разрешениям в файловой системе, разрешения в каталоге AD наследуются объектами-потомками, если пользователь не дает каталогу инструкцию отменить такое наследование. Благодаря этому обстоятельству процедура предоставления администратору разрешений на выполнение той или иной операции (скажем, изменения пароля) во всех объектах заданной организационной единицы organizational unit (OU) или в иерархии OU выполняется очень легко. Если бы такой функции не было, нам приходилось бы предоставлять разрешения каждому пользователю в индивидуальном порядке.

Для применения унаследованных разрешений к дочерним объектам в AD используется внутренний фоновый процесс, именуемый распространителем дескрипторов безопасности Security Descriptor Propagator (SDProp). В очень больших сетях унаследованные разрешения обычно применяются с некоторой задержкой. Кстати, если в AD вам попадался атрибут dSCorePropagationData и вы задавались вопросом, для чего он нужен, имейте в виду, что данный атрибут используется с целью хранения информации о состоянии процесса SDProp.

Что делегировать

На высоком уровне имеется ограниченный набор операций, разрешения на выполнение которых могут быть делегированы, причем их можно применять как для всех классов объектов, так и для отдельного класса, например для класса users. Если вы незнакомы с основными принципами функционирования схемы AD, рекомендую прочитать статью «Расширяем схему Active Directory» (опубликованную в Windows IT Pro/RE № 1 за 2011 год), поскольку ниже мы будем использовать некоторые термины из этой статьи. Метод делегирования разрешений доступа можно применять для предоставления разрешений пользователям или группам. С функциональной точки зрения нет ничего дурного в том, чтобы делегировать разрешения непосредственно пользователям, однако в любом случае будет правильнее делегировать разрешения группе, а затем уже включать в эту группу тех или иных пользователей. В этом случае вы сможете управлять разрешениями пользователей, вводя или выводя их из состава соответствующих групп. Решать подобную задачу гораздо проще, чем управлять разрешениями.

Самое типичное полномочие из тех, что вам предстоит предоставлять, это, пожалуй, разрешение на запись в том или ином атрибуте либо в наборе атрибутов. Если, к примеру, вы намереваетесь предоставить кому-то разрешение отменять блокировку учетных записей пользователей, вы предоставите этому лицу разрешение записи (Write Property) в атрибуте lockoutTime.

Некоторые операции, сводящиеся на первый взгляд к предоставлению разрешения Write Property на один-два атрибута, фактически предполагают делегирование одного или нескольких расширенных разрешений. Два расширенных разрешения, с которыми вам придется сталкиваться чаще всего, — это разрешения Reset Password и Change Password. В случае поступления через стандартные интерфейсы прикладного программирования запроса на выполнение той или иной операции, AD и другие приложения могут выяснять, имеются ли разрешения на пользование расширенными разрешениями, причем приложения могут даже определять в каталоге специализированные расширенные разрешения. Если в вашей сети развернута система Microsoft Exchange Server, вы обнаружите, что в ней предусмотрен целый ряд расширенных разрешений, таких как Send-As и Receive-As.

Если присмотреться к компоненту ACL в учетной записи пользователя (подобному на экране 1), можно увидеть, что участнику безопасности SELF делегировано расширенное разрешение Change Password. Кроме того, вы заметите, что этому участнику делегировано разрешение вводить ряд дополнительных записей, таких как Personal Information. Personal Information — пример объекта Property Set, коллекции атрибутов, сведенных вместе. Этот объект позволяет предоставлять разрешения не на уровне индивидуальных атрибутов, а на уровне всего их набора. AD допускает включение каждого атрибута в один набор Property Set. Достоинство этого набора состоит в том, что администратору нет нужды создавать индивидуальные записи управления доступом с целью предоставления разрешений на чтение или запись в большое количество атрибутов; он может выполнить одну-единственную процедуру делегирования для всего набора Property Set, и необходимые разрешения будут предоставлены всем входящим в этот набор атрибутам.

Экран 1. Редактор ACL оснастки Active Directory Users and Computers

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

Если вас интересует, какие атрибуты включаются в набор Property Set, вы можете получить ответ на этот вопрос с помощью инструмента, поставляемого со службой Active Directory Lightweight Directory Service (AD LDS). На системе, где установлены средства удаленного администрирования сервера Remote Server Administration Tools (RSAT) системы Windows Server 2008 или более новой версии и активированы средства доменных служб Active Directory (AD DS), а также служб Active Directory облегченного доступа к каталогам (AD LDS), перейдите в каталог C:\Windows\ADAM и запустите программу ADSchemaAnalyzer.exe. После этого откройте меню File, выберите пункт Load Target Schema, укажите один из контроллеров домена (DC) в своем лесу и введите действительные учетные данные пользователя. Анализатор схемы Active Directory загрузит схему AD и отобразит ее в графическом представлении, так что вы сможете уяснить отношения между классами, атрибутами и наборами свойств (экран 2). Атрибуты каждого набора свойств перечислены в контейнере Dependents.

Экран 2. Атрибуты набора свойств, отображаемые анализатором схемы Active Directory

Еще одна типичная задача, разрешения на выполнение которой вы, вероятно, захотите делегировать, — задача формирования определенного набора объектов, скажем, чтобы сотрудники службы поддержки могли создавать объекты user. Делегировать такие разрешения в высшей степени просто; однако важно при этом тщательно проанализировать некоторые скрытые последствия для системы безопасности в связи с предоставлением пользователям разрешения создавать объекты. В момент создания объекта создавшему его пользователю в одном из полей ACL присваивается статус владельца данного объекта. Владелец объекта имеет над ним полный контроль и может обойти ограничения, содержащиеся в детализированных разрешениях, полученных этим владельцем на доступ к объекту. Вот наглядный пример того, как делегирование разрешения на создание объектов создает для администратора неожиданные проблемы. Допустим, вы делегировали пользователю разрешение на создание организационных единиц (OU) и сверх того — разрешение на создание учетных записей пользователей внутри этих OU. Поскольку упомянутый пользователь имеет полный контроль над созданными им OU, он может создавать внутри них объекты любых типов, скажем компьютеры или группы. После того как ваш домен будет переведен в режим работы Windows Server 2008 Domain Functional Level (DFL) 3 или более современный, вы сможете решить эту проблему с помощью средств Owner Access Rights.

Итак, мы бегло познакомились с различными терминами и компонентами, с которыми вам придется иметь дело при делегировании разрешений доступа. Теперь давайте перейдем к практической стороне дела и выполним несколько типичных задач.

Разрешения Password Reset и Account Unlock

Одна из задач, разрешения на выполнение которых часто делегируются (как правило, сотрудникам службы поддержки либо службы поддержки), — это переустановка паролей пользователей в случаях, когда последние их забывают, и снятие блокировки учетных записей этих пользователей. Здесь нужно осуществить несколько процедур делегирования: делегировать разрешение на использование расширенного разрешения Reset Password, а также разрешение Write Property для атрибутов pwdLastSet и lockoutTime.

В атрибуте pwdLastSet хранится метка времени, указывающая на момент, когда пароль пользователя устанавливался в последний раз; она нужна для того, чтобы служба AD могла отменить пароль по истечении срока его действия. В атрибуте lockoutTime хранятся сведения о том, в какое время учетная запись пользователя была отключена. Когда вы выставляете флажок с указанием пользователю сменить пароль при следующей процедуре регистрации в системе, вы фактически устанавливаете значение pwdLastSet равным 0. Подобным же образом, когда вы устанавливаете флажок разблокирования учетной записи в оснастке ADUC, вы фактически устанавливаете значение параметра lockoutTime равным 0.

Далее на протяжении всей статьи мы будем выполнять операции делегирования, о которых пойдет речь, с использованием редактора ACL в оснастке ADUC. Часть задач, выполняемых средствами этого редактора, можно решать и с помощью мастера Delegate Control Wizard оснастки ADUC. Но если действовать без дополнительных ухищрений только с помощью редактора ACL, мы получим гораздо более полное представление о вносимых изменениях. Если вы следуете предлагаемым мной инструкциям, используя версию ADUC, которая была выпущена до появления системы Windows Server 2008 R2, отдельные надписи на экранах и ряд этапов процесса будут несколько отличаться от описываемых мной. При работе со старыми версиями AD вы можете смело использовать более новые версии ADUC и других средств удаленного администрирования сервера.

В рамках данной статьи мы будем исходить из того, что вам предстоит делегировать членам группы Service Desk Users разрешения на переустановку паролей всех пользователей, входящих в организационную единицу People OU. Для решения этой задачи выполните следующие действия.

Вы увидите три дополнительные записи управления доступом, представленные на экране 3. Редактор ACL оснастки ADUC позволяет с легкостью предоставлять несколько разрешений одновременно — даже в ситуациях, когда для делегирования таких разрешений необходимо использовать несколько записей управления доступом. Если бы вы выполняли описанные выше действия с помощью программы редактирования с минимумом необходимых функций, такой как LDP, вам пришлось бы создавать три индивидуальные записи управления доступом: одну для осуществления операции Reset Password, другую для операции Write Property pwdLastSet и третью — для операции Write Property lockoutTime.

Экран 3. Заполнение списка ACL после предоставления разрешений Password Reset и Unlock Account

Добавление компьютеров в домен

Еще одна типичная задача — делегирование группе пользователей разрешений по включению компьютеров в домен. Служба AD позволяет любому прошедшему процедуру аутентификации пользователю в любое время без предварительной подготовки добавлять в домен до десяти систем. Разработчики AD реализовали это ограничение с помощью функции, известной как «квоты на объекты». Она дает администратору возможность определять число объектов определенного типа, которые пользователь может иметь в каталоге в любой момент времени. AD определяет, сколько объектов входит в квоту того или иного пользователя, на основании сведений о принадлежности, которые хранятся в списке ACL наряду с компонентами DACL и SACL.

Вы можете предоставить другому лицу (возможно, младшему администратору) разрешение добавлять в домен неограниченное число компьютеров. Задача решается двумя способами. Первый способ — воспользоваться унаследованным от прежних систем разрешением NT Security Privilege (SeMachineAccount­Privilege); обладающий им пользователь может добавлять компьютеры в домен. Это разрешение предоставляется на контроллерах доменов через групповую политику и включается в маркер безопасности пользователя, когда тот регистрируется в системе. Если вы просто хотите дать пользователям возможность добавлять системы в контейнер Computers, эта задача, по-видимому, легче всего решается посредством предоставления рассматриваемого разрешения с помощью групповой политики. Чтобы предоставить это разрешение пользователям группы Service Desk Users через групповую политику, выполните следующие действия.

Если вместо этого вы хотите определить, к каким организационным единицам может быть присоединен тот или иной компьютер, вам придется воспользоваться собственными списками ACL каталога Active Directory, подобными тем, что упоминались в предыдущей пошаговой инструкции. В данном примере мы делегируем группе Service Desk Users разрешения по присоединению компьютеров к организационной единице Desktops, а кроме того, предоставляем членам этой группы возможность менять пароли учетных записей машин на тот случай, если у них возникнет необходимость вновь ввести ту или иную систему в состав домена. С целью выполнения этих задач мы делегируем группе Service Desk Users разрешение создавать объекты computer в организационной единице Desktops, а затем предоставим членам этой группы разрешение Reset Password, а также разрешение Write to pwdLastSet применительно к объектам computer.

Атрибуты и разрешения, доступные в редакторе ADUC ACL Editor, загружаются не из каталога, а из файла dssec.dat на локальной системе. Один из атрибутов, который вам придется модифицировать в процессе выполнения указанной задачи, по умолчанию не указывается в файле dssec.dat. Чтобы редактировать файл dssec.dat, выполните следующие действия на компьютере, где выполняется оснастка ADUC.

Для предоставления указанных разрешений выполните следующие действия.

Теперь нужно выяснить, каков результат процедуры делегирования разрешений. Попытайтесь присоединить тестовый компьютер к домену с использованием учетной записи пользователя, входящего в группу Service Desk Users. Задачу включения компьютера в состав домена с указанием, в какую организационную единицу он будет при этом входить, можно решить двумя способами. Первый метод состоит в том, чтобы заранее создать учетную запись компьютера с помощью оснастки ADUC. Запустите оснастку и щелкните правой кнопкой мыши внутри организационной единицы Desktops, затем нажмите кнопку New и выберите элемент Computer. Укажите имя компьютера и предоставьте членам группы Service Desk Users разрешения на присоединение системы к домену, как показано на экране 5.

Экран 5. Диалоговое окно New Computer

Второй метод предусматривает добавление системы к домену с помощью средства командной строки netdom; имя надлежащей организационной единицы указывается при этом в качестве составной части команды. Чтобы включить систему TEST-PC02 в состав организационной единицы Desktops, расположенной в корневом каталоге домена contoso.com, введите следующую команду:

Вы получите приглашение ввести пароль для учетной записи John.Doe. Если вы хотите использовать смарт-карту, добавьте переключатель /Secure-PasswordPrompt.

Сначала упражнения

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

Внутри абстракций ACL

Удалять абстракции из списка ACL можно с помощью редактора безопасности в программе LDP. Данный интерфейс не отличается особым удобством и весьма непрост в использовании, но он дает возможность получать более основательные результаты. Если вы хотите испытать его на практике, выполните следующие действия.

Более подробные сведения будут отображаться на экране дескриптора безопасности, если дважды щелкнуть на соответствующей записи (экран А). Отметим, что в версиях LDP, выпускавшихся до выхода системы Windows Server 2008, текст выводится из списков ACL в формате «только для чтения».

Экран A. Редактор дескрипторов безопасности LDP

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP, ведет блог www.briandesmond.com

Поделитесь материалом с коллегами и друзьями

Источник