Microsoft AZ-801: Безопасность Active Directory Domain Services — Руководство по подготовке

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Часть Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Службы доменов Active Directory (AD DS) лежат в основе управления удостоверениями и доступом в сетях Windows. Защита AD DS включает в себя контроль над созданием, хранением и использованием учетных данных; ограничение мест, где могут проходить аутентификацию привилегированные удостоверения; усиление протоколов аутентификации; аудит критически важных действий; и обеспечение надежного восстановления. В этом разделе рассматриваются мелкозернистые политики паролей и учетных записей, меры защиты привилегированных удостоверений, усиление и делегирование аутентификации, аудит и SACL, корзина Active Directory, подписывание LDAP и привязка канала, поведение AdminSDHolder, резервное копирование и полномочное восстановление, включая восстановление SYSVOL, а также многоуровневая модель AD.

Политики учетных данных и контроль привилегированных удостоверений

Мелкозернистые политики паролей (PSO) позволяют применять несколько политик паролей и блокировки в одном домене без создания дополнительных доменов. PSO — это объекты msDS-PasswordSettings, хранящиеся в CN=Password Settings Container,CN=System,<domain DN> (контейнер msDS-PasswordSettingsContainer). PSO применяется к пользователям и глобальным группам безопасности через атрибут msDS-PSOAppliesTo. Когда к пользователю применимо несколько PSO (напрямую или через группы), результирующей становится та PSO, у которой наименьшее значение msDS-PasswordSettingsPrecedence; при равенстве значений приоритет отдается PSO с наименьшим GUID. Действующая для пользователя PSO записывается в его атрибут msDS-ResultantPSO. Проектируйте PSO таким образом, чтобы меньшие значения приоритета соответствовали наиболее строгим политикам, которые должны иметь преимущество, и проверяйте действующие политики, считывая атрибут msDS-ResultantPSO.

Группа безопасности Protected Users усиливает защиту критически важных учетных записей, отключая устаревшие и рискованные механизмы аутентификации. Члены этой группы:

Не могут использовать NTLM, Digest или CredSSP
Не могут использовать RC4 и DES для Kerberos
Не могут быть делегированы через Kerberos (ни неограниченное, ни ограниченное делегирование)
Получают необновляемые TGT с фиксированным коротким сроком действия (по умолчанию 4 часа)
Не кэшируют учетные данные в виде открытого текста или долгосрочные секреты на рабочей станции (что предотвращает использование WDigest и сохранение учетных данных в памяти процесса LSASS) Используйте эту группу для привилегированных учетных записей, управляемых людьми, и владельцев высокорисковых служб после проверки совместимости приложений. Для применения этих мер защиты контроллеры домена должны работать под управлением Windows Server 2012 R2 или более поздней версии.

Политики аутентификации и контейнеры политик аутентификации (authentication policy silos) ограничивают, где и как учетные записи могут проходить аутентификацию. Политика аутентификации может устанавливать ограничения Kerberos для конкретной учетной записи, такие как срок действия TGT и разрешенные устройства (по SPN/FQDN хоста). Контейнер политик аутентификации группирует пользователей, компьютеры и служебные учетные записи, чтобы только разрешенные комбинации могли проходить аутентификацию с помощью Kerberos в соответствии с этой политикой. Это обеспечивает контроль по принципу «станция-администратор»: например, администраторы уровня 0 (Tier 0) могут входить в систему только на контроллерах домена и выделенных рабочих станциях с привилегированным доступом (PAW), но не на рядовых серверах или рабочих станциях. Для максимального эффекта используйте их совместно с группой Protected Users. Эти функции требуют наличия контроллеров домена на базе Windows Server 2012 R2 и механизма KDC armoring.

AdminSDHolder и SDProp защищают списки контроля доступа (ACL) привилегированных удостоверений. Члены встроенных административных групп (например, Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators и др.) считаются «защищенными». SDProp запускается ежечасно на эмуляторе PDC, копирует ACL из CN=AdminSDHolder,CN=System на защищенные объекты и отключает для них наследование ACL (устанавливая AdminCount=1). Чтобы предоставить права службе поддержки на защищенные объекты, изменяйте ACL на самом объекте AdminSDHolder, а не напрямую на отдельных защищенных объектах, иначе изменения будут отменены. Когда учетная запись удаляется из всех защищенных групп, снова включите наследование ACL и сбросьте AdminCount, чтобы к ней снова начали применяться ACL и GPO уровня OU.

Применяйте многоуровневую модель AD, чтобы минимизировать риск компрометации учетных данных. Уровень 0 (Tier 0) содержит контроллеры домена, системы управления удостоверениями (PKI, федерация, PAM) и учетные записи администраторов, которые ими управляют. Уровень 1 (Tier 1) содержит серверные рабочие нагрузки и их администраторов. Уровень 2 (Tier 2) содержит рабочие станции и их администраторов. Запретите вход в систему между уровнями, используйте PAW для администрирования уровней 0 и 1 и изолируйте учетные данные с помощью таких функций, как Protected Users, контейнеры политик аутентификации, Remote Credential Guard, Just-Enough Administration (JEA) и Windows LAPS для ротации паролей локальных администраторов.

Усиление защиты аутентификации и делегирование

Подписывание LDAP и привязка канала защищают от атак ретрансляции и «человек посередине» (man-in-the-middle). Настройте контроллеры домена так, чтобы они требовали подписывание, через групповую политику: Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности\«Контроллер домена: требования к подписи сервера LDAP» = Требовать подпись. По возможности требуйте подписывание на стороне клиента: «Сетевая безопасность: требования к подписи клиента LDAP» = Требовать подпись. Для LDAPS включите привязку канала на контроллерах домена, установив для параметра LDAPEnforceChannelBinding в разделе HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters значение 1 (Включено, рекомендуется) или 2 (Всегда). Проведите инвентаризацию устаревших устройств и приложений; включение подписывания или привязки канала может нарушить работу анонимных/простых привязок или старых стеков LDAP. Отслеживайте журнал событий Directory Service: 2886 (подписывание не требуется), 2887 (сводка по неподписанным простым привязкам), 2888 (подписывание все еще отключено), 2889 (IP-адреса клиентов, выполняющих неподписанные простые привязки, при включенном диагностическом логировании). Внедряйте изменения поэтапно, сначала в режиме «Предупреждение» (привязка канала=1), а затем переходите к принудительному режиму «Всегда» (2).

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

Неограниченное делегирование («Доверять этому компьютеру в делегировании для любой службы (только Kerberos)») позволяет службе получать перенаправляемый TGT и олицетворять пользователей для доступа к любой службе. Это сопряжено с высоким риском; избегайте этого варианта в пользу ограниченных моделей.
Ограниченное делегирование (KCD) («Доверять этому компьютеру в делегировании только для указанных служб») ограничивает службы, которым можно делегировать полномочия (список целевых SPN). При использовании опции «Использовать любой протокол проверки подлинности» служба может выполнить переход протокола (S4U2Self), а затем использовать S4U2Proxy для доступа к указанным внутренним службам (backend).
Ограниченное делегирование на основе ресурсов (RBCD) переносит управление на сам ресурс путем установки атрибута msDS-AllowedToActOnBehalfOfOtherIdentity для целевой учетной записи службы. Владелец ресурса определяет, какие внешние участники (front-end principals) могут делегировать ему полномочия, что упрощает междоменные сценарии и минимизирует поверхность атаки. Для современных архитектур предпочтительно использовать RBCD; проводите аудит и периодически проверяйте SPN и настройки делегирования.

Аудит и отказоустойчивость

Аудит AD DS должен быть целенаправленным и конкретным. Используйте «Расширенную настройку политики аудита», чтобы включать подкатегории вместо устаревших категорий, и установите политику «Аудит: принудительно переопределять параметры категории политики аудита параметрами подкатегории политики аудита» для обеспечения согласованности. Рекомендуемые подкатегории включают «Управление учетными записями», «Вход/выход из системы» (Вход в систему, Выход из системы, Специальный вход в систему), «Вход в учетную запись» (Служба проверки подлинности Kerberos/Операции со служебными билетами) и «Изменение/доступ к службе каталогов». Ключевые идентификаторы событий:

4720 (Создана учетная запись пользователя) из категории «Управление учетными записями»
4740 (Учетная запись пользователя была заблокирована) из категории «Управление учетными записями»
4625 (Неудачная попытка входа в учетную запись) из категории «Вход/выход из системы»
4648 (Была предпринята попытка входа с использованием явных учетных данных) из категории «Вход/выход из системы» Дополните аудит событиями из категории «Изменение службы каталогов», чтобы фиксировать, кто/что/старые/новые значения для критически важных атрибутов (события 5136/5137/5139). Для аудита конкретных изменений (например, членства в группах, SPN, ACL) настройте SACL для целевых объектов или OU (включите «Дополнительные компоненты» в ADUC, откройте свойства объекта: Безопасность > Дополнительно > Аудит). Добавьте записи для аудита операций «Запись всех свойств» или конкретных свойств (member, servicePrincipalName), а также «Изменение разрешений/владельца» по мере необходимости. Убедитесь, что журналы поступают в централизованную систему SIEM и что для журналов безопасности контроллеров домена настроен достаточный срок хранения.

Корзина AD DS защищает от случайных удалений, сохраняя все атрибуты и обратные ссылки для удаленных объектов. Включите ее один раз для всего леса (действие необратимо) через ADAC или PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forest>). После включения удаленный объект остается в состоянии «удаленного объекта» в течение времени, заданного в msDS-DeletedObjectLifetime (если не установлено, используется значение tombstoneLifetime), и в этот период его можно полностью восстановить со всеми атрибутами. По истечении этого времени он становится «переработанным объектом» (recycled object) и больше не может быть восстановлен с атрибутами, а позже удаляется сборщиком мусора. В современных лесах значение tombstoneLifetime по умолчанию обычно составляет 180 дней; в старых лесах оно может быть 60 дней. Восстанавливайте объекты с помощью ADAC, LDP или PowerShell (Restore-ADObject) и отдавайте предпочтение авторитетному восстановлению членства в группах через корзину, а не ручному добавлению, чтобы избежать расползания привилегий.

Резервное копирование и авторитетное восстановление — это последняя линия защиты. Регулярно создавайте резервные копии состояния системы (System State) каждого контроллера домена с помощью Windows Server Backup или wbadmin (wbadmin start systemstatebackup). Для отката изменений на уровне объектов, которые уже не находятся в корзине, выполните неавторитетное восстановление состояния системы, а затем с помощью ntdsutil пометьте конкретные объекты или OU как авторитетные (это увеличит номер их версии, чтобы репликация применила их повторно). Понимайте разницу: неавторитетное восстановление возвращает контроллер домена в рабочее состояние, а затем применяет к нему текущие данные репликации; авторитетное восстановление помечает объект так, чтобы его восстановленная версия перезаписала более новые реплики. Для SYSVOL, использующего репликацию DFS (DFSR), выполните неавторитетное или авторитетное восстановление:

Неавторитетное: остановите службу DFSR, установите для подписки SYSVOL затронутого участника неавторитетный режим (msDFSR-Options=0), запустите DFSR, чтобы он повторно синхронизировался с вышестоящим партнером.
Авторитетное: на выбранном «хорошем» контроллере домена установите для подписки SYSVOL авторитетный режим (msDFSR-Options=1), запустите DFSR, а затем принудительно заставьте партнеров выполнить повторную синхронизацию (DFSRDIAG PollAD). Проверьте работоспособность с помощью dfsrdiag backlog и журналов событий. Для устаревшей службы FRS (не поддерживается) выполните миграцию на DFSR и избегайте процедур с использованием BurFlags.

Собираем все вместе: операции, приоритеты усиления безопасности и многоуровневый доступ

В первую очередь уделите внимание уровню 0 (Tier 0): принудительно включите подписывание LDAP/привязку к каналу, устраните неограниченное делегирование, перейдите на KCD/RBCD, поместите привилегированные удостоверения в группу Protected Users и примените политики/изоляторы аутентификации, чтобы ограничить конечные точки для входа, а также потребуйте использования станций привилегированного доступа (PAW) для администраторов уровней 0/1. Создайте объекты параметров паролей (PSO) для привилегированных учетных записей со строгой блокировкой и ротацией. Включите расширенный аудит с помощью SACL для контейнеров уровня 0. Обеспечьте ежедневное резервное копирование состояния системы (System State) контроллеров домена и наличие задокументированных сценариев (runbooks) для авторитетного восстановления и восстановления SYSVOL. На уровнях 1 и 2 заблокируйте вход администраторов на более низкие уровни, устраните повторное использование паролей локальных администраторов с помощью Windows LAPS и отслеживайте всплески событий 4625/4740 и неправомерное использование события 4648 для выявления попыток бокового перемещения.

Практический сценарий

Компании Adobe необходимо быстро защитить локальный лес AD DS после приобретения дочерней компании, чьи бизнес-приложения зависят от устаревших протоколов. Цели: снизить успешность атак перебора паролей (password spraying), остановить ретрансляцию учетных данных на контроллеры домена (DC), ограничить привилегированные входы только станциями PAW, модернизировать делегирование для веб-уровня и обеспечить быстрое восстановление после случайных удалений.

Определите PSO и назначьте их привилегированным группам

Создайте строгий объект PSO (с низким значением приоритета) в контейнере msDS-PasswordSettingsContainer с коротким сроком действия пароля, высокой сложностью и агрессивной политикой блокировки.
Примените его через атрибут msDS-PSOAppliesTo к группам «Domain Admins», «Server Admins» и пользовательской группе «Tier0‑Privs». Почему: Детализированные (fine-grained) PSO нацелены только на учетные записи с высоким риском, не затрагивая весь домен, а приоритет гарантирует применение именно строгой политики.

Примените группу Protected Users и изоляторы аутентификации

Добавьте администраторов-людей уровня 0 в группу Protected Users.
Создайте политику аутентификации, разрешающую вход по протоколу Kerberos только с SPN хостов PAW и контроллеров домена; свяжите учетные записи и PAW в изоляторе политики аутентификации. Почему: Группа Protected Users исключает использование NTLM/RC4 и предотвращает делегирование; изоляторы обеспечивают правило «только с PAW», сокращая риски компрометации токенов и пути кражи учетных данных.

Усильте безопасность LDAP и отслеживайте сбои

Установите для параметра «Domain controller: LDAP server signing requirements» значение Require (Требовать); на начальном этапе настройте LDAPEnforceChannelBinding=1.
Проанализируйте события службы каталогов (Directory Service) 2886–2889, чтобы выявить устаревшие привязки; исправьте приложения, затем установите LDAPEnforceChannelBinding=2. Почему: Подписывание и привязка к каналу уничтожают распространенные пути ретрансляции атак на контроллеры домена, а поэтапное внедрение позволяет избежать сбоев в работе.

Переведите делегирование на RBCD для веб-уровня

Преобразуйте неограниченное делегирование для веб-серверов фронтенда в RBCD, добавив их учетные записи компьютеров в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи службы API бэкенда.
Удалите устаревшие флаги «Trust this computer for delegation to any service» (Доверять этому компьютеру в делегировании для любой службы); точно определите SPN служб. Почему: RBCD позволяет ресурсу определять, кто может делегировать ему полномочия, и ограничивает олицетворение только предполагаемыми целями, сокращая возможности для бокового перемещения.

Включите расширенный аудит и SACL

Настройте расширенную политику аудита для категорий Account Management (Управление учетными записями), Logon/Logoff (Вход/выход), Account Logon (Вход в учетную запись) и Directory Service Changes (Изменения службы каталогов).
Для подразделений (OU) уровня 0 и ключевых групп добавьте SACL для аудита операций записи (Write) в атрибуты member и servicePrincipalName, а также изменений разрешений/владельца.
Перенаправляйте журналы в SIEM; настройте оповещения об аномалиях событий 4720, 4740, 4625 и 4648. Почему: Невозможно защитить то, чего вы не видите; эти события выявляют создание учетных записей, блокировки, неудачные попытки входа и шаблоны явного использования учетных данных.

Включите корзину AD DS и завершите подготовку сценариев восстановления

Включите корзину на уровне леса и задокументируйте рабочие процессы с использованием Restore-ADObject.
Стандартизируйте ежедневное резервное копирование состояния системы (System State) контроллеров домена с помощью Windows Server Backup, протестируйте авторитетное восстановление через ntdsutil в лабораторной среде.
Задокументируйте и отработайте авторитетное и неавторитетное восстановление SYSVOL (DFSR). Почему: Быстрое и точное восстановление сдерживает деструктивные действия злоумышленников и смягчает последствия ошибок администраторов, не допуская разрастания привилегий (privilege drift).

Внедрите многоуровневую модель AD в операционную деятельность

Определите активы уровней 0/1/2; ограничьте входы администраторов по уровням с помощью групповой политики и изоляторов аутентификации.
Разверните PAW для уровней 0/1, принудительно включите Remote Credential Guard и обеспечьте ротацию паролей локальных администраторов с помощью Windows LAPS. Почему: Многоуровневая модель обеспечивает изоляцию учетных данных и останавливает эскалацию привилегий злоумышленников между уровнями, приводя повседневные операции в соответствие с границами безопасности.

← Microsoft Sentinel и мониторинг безопасности · Все домены · Azure Arc и управление гибридными серверами →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →