Расширенные меры безопасности Active Directory

Во времена Windows 2000 меня однажды попросили подготовить модель делегирования для проекта развертывания Active Directory (AD). Для этого требовалось предоставить небольшой группе доверенных пользователей право изменять пароли учетных записей в организационной единице (OU), которая также принадлежала группе администраторов домена. В те времена задача была не особенно сложной. Но я удивился, обнаружив, что исчезли списки управления доступом (ACL), примененные к учетным записям с целью делегирования соответствующих разрешений. Поначалу я решил, что в тестовой AD есть ошибка или кто-то вернул разрешения в состояние по умолчанию. Поэтому мы переназначили списки ACL в надежде применить их, но они вновь исчезли.

Дополнительные исследования показали, что такое поведение соответствует замыслу разработчиков. Механизм безопасности, именуемый AdminSDHolder, определяет списки ACL, примененные к списку защищенных пользователей и групп, и по умолчанию запрещает наследование разрешений от родительского объекта в AD.

Процесс, именуемый SDProp (Security Descriptor Propagator — распространитель дескрипторов безопасности), запускается каждый час, чтобы применить списки ACL к объектам, защищенным с помощью AdminSDHolder. Поэтому неэффективно применять мастер из консоли управления Active Directory Users and Computers (ADUC) для делегирования прав изменения пароля учетных записей в OU, если какой-нибудь из дочерних объектов является членом группы, защищенной AdminSDHolder.

Пользователи и группы, защищенные с помощью AdminSDHolder

В Windows 2000 было всего четыре важные группы, защищенные AdminSDHolder: Administrators, Domain Admins, Enterprise Admins и Schema Admins. Со временем их число увеличилось. В Windows Server 2008 и Server 2008 R2 механизм AdminSDHolder защищает следующих пользователей и группы: Account Operators («Операторы учета»), Administrator («Администратор»), Administrators («Администраторы»), Backup Operators («Операторы архива»), Domain Admins («Администраторы домена»), Domain Controllers («Контроллеры домена»), Enterprise Admins («Администраторы предприятия»), Krbgt, Print Operators («Операторы печати»), Read-only Domain Controllers («Контроллеры домена только для чтения»), Replicator («Репликатор»), Schema Admins («Администраторы схемы») и Server Operators («Операторы сервера»).

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

Приобретая членство в защищенной группе, пользователь не наследует разрешений от соответствующего родительского объекта в AD. Кроме того, одни стандартные списки ACL удаляются, а другие назначаются.

Списки ACL учетных записей, добавленных к защищенным группам, отличаются от списков обычных учетных записей пользователей в AD. Это может отрази­ться на функциональности, в частности помешать передать сертификат пользователя в глобальный список адресов Global Address List (GAL) в Exchange из-за отсутствия разрешений SELF у учетной записи пользователя AD.

Работаем с атрибутом adminCount

Механизм AdminSDHolder определяет, следует ли защитить объект пользователя путем перечисления членства пользователя в группах, в том числе вложенных. Если пользователь отнесен к защищенной группе, ему назначаются списки ACL, установленные в объекте AdminSDHolder в AD, а атрибуту adminCount пользователя присваивается значение 1. Можно направить в AD запрос LDAP, чтобы определить, какие учетные записи пользователя или группы защищены.

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

В версии Server 2008 R2 можно выполнить запрос LDAP с использованием новых административных команд AD из Windows PowerShell. Начните с импорта модуля AD в PowerShell, чтобы иметь возможность задействовать команды AD. Приведенная ниже команда Get-ADUser перечисляет все объекты пользователя, у которых атрибуту adminCount присвоено значение 1:

import-module activedirectory 
get-aduser -ldapfilter ` 
   "(objectcategory=person) ` 
   (admincount=1)" 

Эта команда Get-ADGroup делает то же, но для групп AD:

get-adgroup -ldapfilter ` 
   "(objectcategory=group) ` 
   (admincount=1)" 

Пользователи версий, отличных от Server 2008 R2, могут применить инструмент LDAP Data Interchange Format Data Exchange (LDIFDE), где ключ -f указывает имя файла для записи результатов запроса, а -r задает фильтр LDAP:

ldifde -f ldifdeoutput.txt -r 
   "(&(objectcategory= 
   person)(objectclass=user) 
   (admincount=1))" 

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

Присвоение атрибуту adminCount нулевого значения

Когда пользователь удаляется из защищенной группы, атрибут adminCount соответствующего пользовательского объекта сохраняет значение 1. Учетная запись пребывает в странном состоянии, в котором она более не получает списки ACL из объекта AdminSDHolder.

Учетная запись также не наследует разрешения от родительского контейнера. И по-прежнему действуют любые списки ACL, ранее примененные из AdminSDHolder.

Недостаточно присвоить атрибуту adminCount значение 1, чтобы защитить группу или учетную запись с использованием AdminSDHolder, поэтому присвоение нулевого значения не является строго обязательным. Но ради единства подхода следует вернуть атрибут в нулевое значение.

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

Если необходимо сохранить учетную запись, следует просмотреть списки ACL объекта и вручную изменить атрибут adminCount, присвоив ему нулевое значение в программе ADSI Edit. Для этого выполните следующие шаги.

1. Зарегистрируйтесь на контроллере домена (DC) Server 2008 R2 как администратор домена. Найдите консоль ADUC, выполнив поиск фразы active directory в поле Search programs and files меню Start.
2. В консоли ADUC щелкните меню View и убедитесь, что выбран пункт Advanced Features.
3. В левой панели разверните иерархию AD, чтобы найти контейнер или OU с объектом пользователя, который нужно изменить.
4. Щелкните правой кнопкой мыши объект в правой панели и выберите пункт Properties из меню.
5. На вкладке Attribute Editor показан атрибут adminCount (экран 1), который можно при необходимости изменить.

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

1. Продолжая с места, где заканчивается выполнение предшествующего набора инструкций, перейдите на вкладку Security и нажмите кнопку Advanced.
2. Установите флажок Include inheritable permissions from this object's parent и нажмите кнопку OK (экран 2).
3. Нажмите кнопку OK в диалоговом окне Properties пользователя, чтобы завершить процедуру. Можно также снять флажок Include inheritable permissions и восстановить разрешения, назначенные объекту в момент создания, как определено в схеме AD. Для этого нажмите кнопку Restore defaults в диалоговом окне Advanced Security Settings. Помните, что восстановление параметров по умолчанию и восстановление списков ACL на известный момент времени — не одно и то же.

Можно изменить настройки безопасности объекта AdminSDHolder в AD, чтобы установить флаг наследования. Или же можно изменить режим безопасности, применив различные списки ACL ко всем защищенным объектам. Изменения, внесенные в списки ACL, или флаг наследования самого объекта AdminSDHolder применяются к защищаемым им объектам.

Чтобы изменить разрешения для объекта AdminSDHolder в лаборатории, выполните следующие действия.

1. Зарегистрируйтесь на контроллере домена Server 2008 R2 в качестве администратора домена и найдите консоль ADSI Edit, выполнив поиск в поле Search programs and files меню Start.
2. В консоли ADSI Edit щелкните правой кнопкой мыши ADSI Edit в левой панели и выберите из меню пункт Connect to.
3. В диалоговом окне Connection Settings оставьте без изменений настройки по умолчанию и нажмите кнопку OK.
4. В левой панели дважды щелкните Default naming context, чтобы развернуть каталог, и перейдите к CN=System.
5. В левой панели выберите CN=System, щелкните правой кнопкой мыши CN=AdminSDHolder в правой панели и выберите из меню пункт Properties.
6. В диалоговом окне CN=AdminSD Holder Properties перейдите на вкладку Security и нажмите кнопку Advanced.
7. В диалоговом окне Advanced Security Settings for AdminSD Holder установите флажок Include inheritable permissions from this object's parent и нажмите кнопку Apply.
8. Нажмите Add, а затем перейдите к группе AD, которой предстоит назначить постоянное изменение, и сбросьте разрешения пароля для защищенных объектов. В данном примере используется группа с именем On Duty Security Team.
9. После того как группа будет успешно выбрана, нажмите кнопку OK.
10. В диалоговом окне Permission Entry for AdminSD Holder (экран 3), выберите объекты Descendant User из меню Apply to.
11. В списке Permissions установите флажки Change password и Reset password, а затем нажмите кнопку OK.
12. В дополнительных настройках Advanced Security Settings для диалогового окна AdminSD Holder нажмите OK.
13. Чтобы завершить процедуру, нажмите OK в окне свойств CN=AdminSDHolder.

При следующем выполнении программного кода SDProp любые объекты пользователя, защищенные с помощью AdminSDHolder, будут иметь дополнительные записи ACL. Члены моей тестовой группы, On Duty Security Team, могут изменять и отменять пароли. Флаг наследования также устанавливается, поэтому списки ACL распространяются из родительской OU.

Принудительный запуск SDProp

По умолчанию программный код SDProp запускается каждый час на контроллерах домена, которым назначена роль PDC Emulator. Он применяет списки ACL к группам, защищенным с помощью AdminSDHolder.

Если требуется немедленно применить настройки, можно принудительно запустить программный код SDProp. Используйте следующую операцию LDAP.

1. Зарегистрируйтесь на контроллере домена Server 2008 R2 в качестве администратора домена и найдите консоль LDP, выполнив поиск в поле Search programs and files меню Start.
2. В консоли LDP выберите пункт Bind из меню Connection.
3. В диалоговом окне Bind согласитесь с настройками по умолчанию и нажмите кнопку OK.
4. Выберите команду Modify из меню Browse. В поле Edit Entry Attribute укажите RunProtectAdminGroupsTask, затем введите 1 в поле Values и нажмите клавишу Enter (экран 4). Обладателям версий Windows Server, предшествующих Server 2008 R2, следует ввести FixUpInheritance вместо RunProtectAdminGroupsTask и Yes вместо 1.
5. Нажмите кнопку Run, а затем Close. Процесс обновления занимает некоторое время в зависимости от размера базы данных AD.

Исключение операторов учета, сервера, печати и архива из AdminSDHolder

В версии Windows Server 2003 SP2 можно отменить защиту операторов учета, сервера, печати и архива из AdminSDHolder. Эти группы операторов защищены благодаря привилегиям.

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

1. Зарегистрируйтесь в контроллере домена (DC) Server 2008 R2 в качестве администратора домена и откройте консоль ADSI Edit.
2. В левой панели ADSI щелкните правой кнопкой мыши ADSI Edit и выберите из меню команду Connect to.
3. Выберите Configuration из меню Select a well known Naming Context и нажмите кнопку OK.
4. В левой панели разверните Configuration, CN=Services, CN=Windows NT. В правой панели щелкните правой кнопкой мыши CN=Directory Service и выберите из меню пункт Properties.
5. В диалоговом окне свойств CN=Directory Service выберите dsHeuristics на вкладке Attribute Editor и щелкните Edit.
6. В диалоговом окне String Attribute Editor введите 000000000100000f, чтобы исключить все четыре группы операторов, и нажмите кнопку OK.
7. Нажмите кнопку OK в диалоговом окне CN=Directory Service Properties и закройте ADSI Edit.

Каждой группе операторов соответствует двоичное значение. Двоичное значение для операторов учета — 0001, а операторов сервера — 0010. Значение для операторов печати — 0100, для операторов архива — 1000. Двоичное значение необходимо преобразовать в шестнадцатеричное и ввести в последней позиции в строке («f» на приведенном выше шаге 6).

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

Например, чтобы исключить только операторов печати и операторов архива, строка dsHeuristics должна иметь вид 000000000100000c. Складывать двоичные числа и преобразовывать их в шестнадцатеричные можно с помощью калькулятора Windows в инженерном режиме.

Как лучше?

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

Изменения, вносимые в списки ACL при использовании AdminSDHolder, могут повлиять на основную функциональность некоторых важных приложений. Среди этих приложений — Exchange, делегирование AD и любые другие функции AD и приложения, в которых используется наследование разрешений, в частности серверы BlackBerry.

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

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

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

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

Самая распространенная причина ввода учетной записи пользователя в одну из защищенных групп AD — разрешить пользователю выполнять задачи обслуживания на DC.

Если существует настоятельная необходимость в постоянном доступе к серверам, на которых размещается AD, то административные права можно отделить от доступа к AD с помощью контроллеров домена только для чтения (RODC).

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами