Убрал пользователя из Domain Admins, а helpdesk всё ещё не может сбросить ему пароль

Ситуация, из-за которой я однажды потерял полдня, а теперь узнаю её по одной строке в заявке: «делегировали helpdesk сброс паролей на OU — работает у всех, кроме Петрова». Петров — бывший системный администратор, которого месяц назад вывели из Domain Admins и перевели в отдел закупок. Учётная запись лежит в той же OU, что и остальные сотрудники, права на OU выданы, но сброс пароля заканчивается сообщением «Отказано в доступе». Разбираю, что остаётся в каталоге после привилегированного членства, как поставить точный диагноз, безопасно вернуть наследование и не устроить массовой чисткой новую проблему.

Симптом, который уводит диагностику в сторону

Инженер первой линии открывает оснастку «Active Directory — пользователи и компьютеры», выбирает «Сброс пароля» для одного сотрудника и получает отказ. На соседней учётной записи из той же OU операция проходит. Под административной учётной записью пароль проблемного пользователя тоже меняется. Такая картина говорит не о неисправном контроллере домена, а о различии в дескрипторах безопасности двух объектов.

Первая реакция обычно такая: делегирование потерялось, поэтому его надо выдать на OU ещё раз. Права назначают повторно, ждут репликации между контроллерами и получают тот же отказ. Это ожидаемо: новая наследуемая ACE остаётся на родительской OU, а пользовательский объект с защищённой DACL её не принимает. Перемещение пользователя в другую OU также ничего не исправляет, потому что запрет наследования хранится в nTSecurityDescriptor самого объекта.

Более опасная реакция — временно включить сотрудников helpdesk в Account Operators. По умолчанию эта встроенная группа может создавать и администрировать большинство пользовательских и групповых учётных записей домена, хотя не может управлять встроенным Administrator, административными учётными записями и рядом защищённых групп. Для обычной первой линии это всё равно несоразмерно широкие полномочия. Я встречал такие «временные» назначения спустя несколько лет после исходной заявки.

Важно не превращать косвенный признак в готовый диагноз. Значение adminCount=1 часто указывает, что объект находится или раньше находился под защитой AdminSDHolder, но само по себе не является разрешением и не доказывает, что текущий отказ вызван именно им. Проверить надо две вещи: фактическую DACL объекта и состояние наследования. Непосредственная причина проблемы — защищённая от наследования DACL, в которой нет нужной ACE для helpdesk.

• Операция не проходит только на отдельных учётных записях, хотя они находятся в одной OU с исправными объектами.
• Перемещение пользователя в другую OU не помогает, если защита DACL от наследования осталась включённой.
• Администратор выполняет операцию успешно, а делегированная группа — нет: сравнивать нужно ACL объектов и наследуемые ACE.
• `adminCount` полезен для поиска кандидатов, но окончательный ответ даёт `AreAccessRulesProtected` и просмотр DACL.

Как связаны AdminSDHolder, SDProp и adminCount

В контейнере System каждого домена автоматически создаётся объект CN=AdminSDHolder,CN=System с собственным дескриптором безопасности. Его ACL служит шаблоном для защищённых учётных записей и групп. По умолчанию процесс SDProp запускается каждые 60 минут на контроллере, которому принадлежит роль PDC Emulator данного домена, сравнивает дескрипторы защищённых объектов с шаблоном и при необходимости восстанавливает требуемые разрешения.

Официальный актуальный перечень включает Account Operators, встроенную учётную запись Administrator, Administrators, Backup Operators, Domain Admins, Domain Controllers, Enterprise Admins, Enterprise Key Admins, Key Admins, krbtgt, Print Operators, Read-only Domain Controllers, Replicator, Schema Admins и Server Operators. В этом перечне смешаны группы и две специальные пользовательские учётные записи. Важная оговорка Microsoft: для Domain Controllers и Read-only Domain Controllers защищены сами групповые объекты, но не их члены. Поэтому обычное наличие adminCount=1 на компьютерной учётной записи контроллера нельзя объявлять штатным, не разобрав её историю.

Защита распространяется на пользовательские учётные записи с прямым или транзитивным членством в перечисленных группах. При обходе цепочки учитываются не только security-группы, но и вложенные distribution-группы. Пользователь внутри группы рассылки не получает SID защищённой группы в токен доступа, однако его объект всё равно может попасть под AdminSDHolder. Microsoft объясняет это тем, что distribution-группу впоследствии можно преобразовать в security-группу.

Когда объект попадает под защиту, процесс устанавливает adminCount в 1, применяет защищённый дескриптор и отключает наследование разрешений. Именно последнее действие обрывает поступление ACE от родительской OU. Перенос объекта не меняет этот флаг, поэтому новая OU тоже не сможет передать ему делегированные права.

После удаления пользователя из защищённой группы SDProp больше не должен обновлять его ACL. Обратного преобразования при этом не происходит: Microsoft отдельно предупреждает, что adminCount остаётся равным 1, а наследование не включается автоматически. Получается «бывший защищённый» объект: текущего привилегированного членства уже нет, но делегирование с OU до него по-прежнему не доходит.

Реестровый параметр AdminSDProtectFrequency типа REG_DWORD действительно существует в ветке HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters на PDC Emulator. Допустимый документированный диапазон — от 60 до 7200 секунд, значение по умолчанию при отсутствии параметра — 3600 секунд. Microsoft рекомендует менять интервал только на короткое время для тестирования, поскольку более частый запуск увеличивает нагрузку на LSASS.

• AdminSDHolder — объект-шаблон ACL в контейнере System каждого домена.
• SDProp по умолчанию работает на PDC Emulator раз в 60 минут.
• `adminCount=1` — диагностическая метка, а не предоставленное разрешение.
• Делегирование фактически ломает флаг защиты DACL от наследования.
• Члены групп Domain Controllers и Read-only Domain Controllers не защищаются лишь по факту такого членства; защищены сами групповые объекты.

Диагностика без догадок: атрибут, наследование и цепочка групп

Для команд ниже нужен модуль ActiveDirectory из состава RSAT или средств управления AD DS. Я запускаю Windows PowerShell с учётной записью, которой разрешено читать каталог и ACL, и явно работаю с тем контроллером, на котором хочу получить согласованную картину. Сначала смотрю атрибут проблемного пользователя и собираю перечень всех помеченных объектов домена.

Import-Module ActiveDirectory

$pdc = (Get-ADDomain).PDCEmulator
$user = Get-ADUser -Identity 'i.petrov' -Server $pdc -Properties adminCount
$user | Select-Object Name, SamAccountName, adminCount, DistinguishedName

Get-ADObject -Server $pdc -LDAPFilter '(adminCount=1)' `
    -Properties adminCount, objectClass |
    Select-Object objectClass, Name, DistinguishedName |
    Sort-Object objectClass, Name

Запрос по adminCount — только начало. Он возвращает пользователей, группы и любые другие объекты, на которых атрибут оказался установлен. Удалять метку у всего результата нельзя. Сначала отделяю штатно защищённые группы, встроенные учётные записи, действующих привилегированных пользователей и сервисные учётные записи от объектов, защита которых осталась после старого членства.

Затем читаю ACL через провайдер Active Directory. Свойство AreAccessRulesProtected возвращает True, если DACL защищена от наследования, и False, если наследование разрешено. dsacls.exe помогает увидеть явные и унаследованные ACE в текстовом виде. Запускать эти команды удобнее на машине с установленными средствами администрирования AD DS.

$dn = $user.DistinguishedName
$acl = Get-Acl -Path "AD:\$dn"

[pscustomobject]@{
    SamAccountName          = $user.SamAccountName
    AdminCount              = $user.adminCount
    AreAccessRulesProtected = $acl.AreAccessRulesProtected
}

dsacls.exe "$dn"

Третий шаг — проверить транзитивное членство. Обычный атрибут memberOf содержит прямые обратные ссылки и не показывает полную вложенность. Правило LDAP 1.2.840.113556.1.4.1941, которое Microsoft называет LDAP_MATCHING_RULE_IN_CHAIN или LDAP_MATCHING_RULE_TRANSITIVE_EVAL, проходит цепочку DN-ссылок. Следующий запрос выводит группы текущего домена, в которые пользователь входит прямо или через вложенные группы, включая цепочки с distribution-группами.

Get-ADGroup -Server $pdc `
    -LDAPFilter "(member:1.2.840.113556.1.4.1941:=$dn)" `
    -Properties groupType, objectSid |
    Select-Object Name, DistinguishedName, groupType, objectSid |
    Sort-Object Name

В многодоменном лесу одного запроса к текущему домену недостаточно: защищённая группа может находиться в другом доменном разделе. Тогда я повторяю проверку по доменам леса или выполняю поиск через глобальный каталог, учитывая его область поиска и репликацию. Для DN с символами, имеющими специальное значение в LDAP-фильтре, значение нужно экранировать по правилам LDAP; бездумно подставлять произвольный ввод пользователя в фильтр нельзя.

Наконец, сравниваю исправную и проблемную учётные записи. Если у первой AreAccessRulesProtected=False и видны наследуемые ACE helpdesk, а у второй True и этих ACE нет, причина подтверждена. Если наследование уже включено, надо искать другую проблему: явный Deny, неверный тип делегированного права, область применения ACE, репликационную задержку или попытку операции не на том объекте.

• `Get-ADUser -Properties adminCount` показывает метку на конкретной учётной записи.
• `Get-ADObject -LDAPFilter '(adminCount=1)'` помогает оценить масштаб, но не формирует список для автоматического удаления.
• `Get-Acl` и `AreAccessRulesProtected` показывают реальное состояние наследования DACL.
• `dsacls.exe` выводит фактические ACE объекта.
• OID `1.2.840.113556.1.4.1941` проверяет транзитивную цепочку членства по DN-ссылкам.

Торговый дом «Электрокомплект», 58 РМ: разбор практики

У торгового дома «Электрокомплект», 58 РМ, работали два контроллера домена на Windows Server 2025. Уровни работы домена и леса оставались Windows Server 2016: такая конфигурация официально поддерживает контроллеры Windows Server 2025, а переход на новый функциональный уровень Windows Server 2025 мы вынесли в отдельный проект с проверкой совместимости. В структуре были отдельные OU для сотрудников, сервисных и административных учётных записей. Группа HD-PasswordReset получила на OU сотрудников право сбрасывать пароль и требовать его смену при следующем входе — без дополнительных полномочий.

Заявка выглядела буднично: helpdesk не мог сбросить пароль Петрову, хотя на соседних объектах всё работало. Полный запрос по домену сначала показал защищённые встроенные группы и множество пользовательских учётных записей. После исключения 13 штатно защищённых групп в рабочем отчёте осталось 34 объекта учётных записей, которые требовали классификации, а не немедленной правки.

Из этих 34 объектов отдельно отметили встроенные Administrator и krbtgt, а также шесть сервисных и отключённых учётных записей, судьбу которых нельзя было решать без владельцев систем. Основную выборку составили 26 пользовательских учётных записей. Пять из них были защищены законно: два штатных администратора, моя административная учётная запись и две сервисные учётные записи резервного копирования, которые действительно входили в Backup Operators. На 21 объекте защита оказалась старым следом.

Три случая объяснились сразу: это были бывшие администраторы, включая Петрова. История остальных 18 открылась после проверки членства по цепочке. Предыдущий подрядчик вложил distribution-группу «ИТ-отдел» в Account Operators, рассчитывая раздать права всему отделу одним действием. SID Account Operators пользователи через distribution-группу в токенах не получили, однако механизм AdminSDHolder всё равно отметил их объекты и отключил наследование. Позднее часть сотрудников перешла в продажи, закупки и логистику, а защищённые DACL переехали вместе с учётными записями.

На диагностику ушло 40 минут, ещё 20 минут — на проверку владельцев, подготовку списка изменений и выполнение исправлений. Distribution-группу удалили из Account Operators. Для 21 подтверждённого бывшего защищённого пользователя очистили adminCount и включили наследование. После репликации инженер первой линии успешно сбросил пароль Петрову своими обычными делегированными полномочиями.

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

• 58 рабочих мест, два контроллера Windows Server 2025 и функциональные уровни Windows Server 2016.
• 34 объекта учётных записей попали в рабочий отчёт после исключения 13 штатно защищённых групп.
• 26 обычных пользовательских учётных записей потребовали проверки: пять были защищены законно, 21 объект оказался зависшим.
• 18 пользователей получили защиту из-за distribution-группы, вложенной в Account Operators.
• Диагностика заняла 40 минут, согласование и исправление — ещё 20 минут; за девять месяцев контроль выявил два рецидива.

Как вернуть наследование одному бывшему администратору

Порядок действий важнее самой команды. Сначала подтверждаю, что пользователь больше не входит ни в одну защищённую группу прямо или через вложенность. Затем сохраняю исходный дескриптор или хотя бы вывод dsacls.exe в журнал работ, очищаю adminCount и включаю наследование. После этого проверяю ACL и прошу helpdesk выполнить именно ту операцию, ради которой было настроено делегирование.

В примере Set-ADObject -Clear adminCount удаляет значение атрибута, а не записывает туда 0. Оба состояния встречаются после разных способов исправления, но для диагностической чистоты я удаляю устаревшее значение. Метод SetAccessRuleProtection($false, $false) снимает защиту DACL от наследования. По документации .NET второй аргумент игнорируется, когда первый равен $false; я всё равно передаю его явно, чтобы назначение вызова было видно при ревью.

Import-Module ActiveDirectory

$pdc = (Get-ADDomain).PDCEmulator
$user = Get-ADUser -Identity 'i.petrov' -Server $pdc -Properties adminCount
$dn = $user.DistinguishedName

# Выполнять только после проверки прямого и транзитивного членства.
Set-ADObject -Identity $dn -Server $pdc -Clear adminCount

$acl = Get-Acl -Path "AD:\$dn"
$acl.SetAccessRuleProtection($false, $false)
Set-Acl -Path "AD:\$dn" -AclObject $acl

Get-ADUser -Identity 'i.petrov' -Server $pdc -Properties adminCount |
    Select-Object SamAccountName, adminCount

(Get-Acl -Path "AD:\$dn").AreAccessRulesProtected

Ожидаемый результат последней команды — False. После включения наследования в DACL появятся применимые ACE от родительских контейнеров. Это не означает, что все старые явные ACE исчезнут: записи, ранее скопированные или назначенные непосредственно объекту, могут остаться явными. Поэтому я сравниваю итоговую DACL с исправной учётной записью из той же OU и отдельно просматриваю записи Deny.

Сам факт наличия явных ACE, похожих на ACL AdminSDHolder, ещё не повод удалять их все. Удаление может лишить владельца или системную службу необходимого доступа, а точное происхождение записи по одному текущему списку определить не всегда возможно. Если требуется нормализовать DACL до корпоративного шаблона, делаю это отдельным изменением после экспорта исходного дескриптора и проверки владельца объекта.

После исправления жду репликацию или направляю тест на тот же PDC Emulator, где выполнялась правка. Затем повторяю проверку после очередного штатного цикла SDProp. Если adminCount снова стал равен 1, а наследование отключилось, значит пользователь всё ещё попадает в защищённую цепочку либо членство успели вернуть.

• Шаг 0. Проверить прямое и транзитивное членство, включая цепочки distribution-групп.
• Шаг 1. Зафиксировать исходную DACL и согласовать объект с его владельцем.
• Шаг 2. Очистить атрибут командой `Set-ADObject -Clear adminCount`.
• Шаг 3. Вызвать `SetAccessRuleProtection($false, $false)` и записать ACL через `Set-Acl`.
• Шаг 4. Убедиться, что `AreAccessRulesProtected` возвращает `False`, проверить DACL и выполнить реальную операцию helpdesk.
• Шаг 5. После штатного цикла SDProp убедиться, что защита не вернулась.

Массовая проверка без опасного автоисправления

Разовая починка закрывает заявку, но не показывает масштаб накопившихся исключений. Я начинаю с отчёта, который ничего не меняет. В него попадают пользователь, adminCount, флаг защиты DACL и DN. Затем для каждого кандидата проверяются транзитивные группы, владелец системы, назначение учётной записи и история временных доступов.

Import-Module ActiveDirectory

$pdc = (Get-ADDomain).PDCEmulator
$report = foreach ($user in Get-ADUser -Server $pdc `
    -LDAPFilter '(adminCount=1)' -Properties adminCount, enabled) {

    $acl = Get-Acl -Path "AD:\$($user.DistinguishedName)"

    [pscustomobject]@{
        SamAccountName          = $user.SamAccountName
        Enabled                 = $user.Enabled
        AdminCount              = $user.adminCount
        AreAccessRulesProtected = $acl.AreAccessRulesProtected
        DistinguishedName      = $user.DistinguishedName
    }
}

$report |
    Sort-Object AreAccessRulesProtected, SamAccountName |
    Export-Csv -Path '.\admincount-review.csv' -NoTypeInformation -Encoding UTF8

Я сознательно не использую Get-ADGroupMember -Recursive как единственный механизм исключений. Командлет удобен для обычных security-групп, но автоматическое решение должно учитывать цепочки через distribution-группы, специальные учётные записи, группы другого домена и локализованные имена встроенных групп. Ошибка здесь опаснее нескольких неочищенных объектов: скрипт может включить наследование действующему привилегированному администратору.

После ручной проверки формирую закрытый список одобренных sAMAccountName. В него никогда автоматически не попадают встроенный Administrator с RID 500 и krbtgt с RID 502. Это две разные учётные записи; исходная формулировка «Administrator с RID 500 и 502» была бы неверной. Компьютеры контроллеров домена я также не заношу в список исключений только по роли: если на них найден adminCount=1, причину исследую отдельно.

Само изменение выполняю только по согласованному списку. Сначала запускаю блок с $whatIfMode = $true: в таком режиме он печатает объекты и не меняет каталог. После повторной проверки переключаю значение на $false. Такой подход менее эффектен, чем полностью автоматическая чистка, зато граница ответственности видна в коде и в журнале.

Import-Module ActiveDirectory

$pdc = (Get-ADDomain).PDCEmulator
$approvedSamAccountNames = @(
    'i.petrov'
)
$whatIfMode = $true

foreach ($sam in $approvedSamAccountNames) {
    $user = Get-ADUser -Identity $sam -Server $pdc -Properties adminCount, SID

    if ($user.SID.Value -match '-(500|502)$') {
        throw "Запрещённая встроенная учётная запись: $sam"
    }

    $acl = Get-Acl -Path "AD:\$($user.DistinguishedName)"

    [pscustomobject]@{
        SamAccountName          = $sam
        AdminCount              = $user.adminCount
        AreAccessRulesProtected = $acl.AreAccessRulesProtected
        WhatIf                  = $whatIfMode
    }

    if (-not $whatIfMode) {
        Set-ADObject -Identity $user.DistinguishedName `
            -Server $pdc -Clear adminCount

        $acl.SetAccessRuleProtection($false, $false)
        Set-Acl -Path "AD:\$($user.DistinguishedName)" -AclObject $acl
    }
}

Перед массовым изменением ACL нужна актуальная резервная копия состояния системы контроллера домена, сделанная Windows Server Backup либо другим решением, которое использует поддерживаемый VSS writer для AD DS. Снимок виртуальной машины не считаю заменой резервной копии: Microsoft прямо предупреждает, что защита через VM-Generation ID и безопасный откат виртуального контроллера не заменяют System State backup.

Проверку обычно запускаю раз в неделю, а изменения состава защищённых групп отслеживаю отдельно средствами аудита. В отчёте нужны как минимум две независимые колонки — adminCount и AreAccessRulesProtected. Метка может остаться после старого членства, а состояние ACL показывает, получает ли объект наследуемые разрешения сейчас.

• Сначала сформировать CSV-отчёт без изменений каталога.
• Не считать `Get-ADGroupMember -Recursive` полной проверкой цепочек, особенно при наличии distribution-групп и нескольких доменов.
• RID 500 принадлежит встроенному Administrator, RID 502 — учётной записи `krbtgt`.
• Менять только объекты из вручную одобренного списка и сначала прогонять сценарий в режиме просмотра.
• Перед массовой правкой обеспечить поддерживаемую резервную копию System State; VM snapshot её не заменяет.
• В регулярном отчёте показывать и `adminCount`, и `AreAccessRulesProtected`.

Почему проблема возвращается и как проверить SDProp сразу

Первый сценарий рецидива прост: сотрудника снова добавили в Domain Admins, Backup Operators или другую защищённую группу «на пару часов», а заявку на отзыв доступа не закрыли. Второй сценарий — вложение рабочей группы в защищённую. Одно изменение способно пометить десятки пользовательских объектов, причём distribution-группа создаст особенно неочевидную картину: прав в токене нет, а защита объектов появляется.

Третий сценарий выглядит как возврат, хотя является незавершённой починкой. Администратор очистил adminCount, но не включил наследование, либо включил наследование, не устранив защищённое членство. В первом случае делегирование остаётся сломанным сразу. Во втором SDProp при следующем проходе закономерно восстановит защищённый дескриптор и снова отключит наследование.

Ждать 60 минут для лабораторной проверки не обязательно. Microsoft документирует ручной запуск через Ldp.exe: подключиться именно к PDC Emulator нужного домена, выполнить bind, открыть Browse → Modify, оставить поле DN пустым, указать атрибут RunProtectAdminGroupsTask, значение 1, добавить операцию в список и запустить её. Это изменение rootDSE инициирует задачу немедленно и не сбивает штатное расписание.

Я не меняю ради проверки AdminSDProtectFrequency. Хотя поддерживается диапазон от 60 до 7200 секунд, уменьшенный интервал повышает нагрузку LSASS и легко остаётся в реестре после теста. Ручной запуск точнее: он проверяет нужное изменение один раз, а затем домен возвращается к обычному часовому циклу.

После принудительного запуска повторно читаю пользователя на PDC Emulator, проверяю adminCount, AreAccessRulesProtected и ACL. Если защита вернулась, исправление нельзя «продавить» повторной очисткой. Нужно найти цепочку членства, проверить группы из других доменов, дождаться репликации удалённого членства и только после этого снова менять объект.

• Временное членство забыли отозвать.
• Рабочую или distribution-группу вложили в защищённую группу.
• Очистили метку, но не включили наследование.
• Включили наследование до устранения защищённого членства.
• Проверяли разные контроллеры до завершения репликации.

AdminSDHolder и dSHeuristics: допустимые механизмы с высокой ценой ошибки

Иногда предлагают добавить helpdesk-группу непосредственно в ACL AdminSDHolder. Технически это сработает: SDProp перенесёт подходящую ACE на защищённые пользовательские и групповые объекты домена. Но право сброса пароля тогда получат не только бывшие администраторы, а действующие защищённые пользовательские учётные записи, включая Domain Admins и krbtgt. Для обычной первой линии это не исправление делегирования, а отдельное архитектурное решение с очень высоким риском.

Microsoft действительно описывает сценарии, в которых ACL AdminSDHolder меняют для специально созданных административных учётных записей. Это не делает безопасным добавление туда повседневной helpdesk-группы. Такая правка требует выделенных управляющих учётных записей, ограничений входа, тестирования, плана восстановления и формального учёта каждой ACE.

Другой механизм — лесной атрибут dSHeuristics на объекте CN=Directory Service,CN=Windows NT,CN=Services в разделе Configuration. Его 16-й символ, dwAdminSDExMask, позволяет исключить из защиты четыре операторские группы. Биты имеют документированное значение: 1 — Account Operators, 2 — Server Operators, 4 — Print Operators, 8 — Backup Operators; комбинация записывается одной шестнадцатеричной цифрой от 0 до f.

Если строка содержит десять или больше символов, её 10-й символ обязан быть 1, иначе сервер отклонит обновление. Microsoft также требует сохранять все уже существующие символы, которые не относятся к текущему изменению. Поэтому нельзя брать готовую строку из статьи и записывать её поверх имеющегося значения: соседние позиции управляют другими функциями каталога.

Текущее значение можно безопасно прочитать следующей командой. Пустой результат означает, что атрибут не задан; это нормальное состояние по умолчанию.

Import-Module ActiveDirectory

$configurationNC = (Get-ADRootDSE).configurationNamingContext
$directoryServiceDN = "CN=Directory Service,CN=Windows NT,CN=Services,$configurationNC"

Get-ADObject -Identity $directoryServiceDN -Properties dSHeuristics |
    Select-Object DistinguishedName, dSHeuristics

В официальном материале поддержки приведён пример строки, где 16-й символ равен f, то есть из защиты исключены все четыре операторские группы. Это именно пример формата, а не рекомендуемое значение для производственного леса.

000000000100000f

Я обычно не меняю dSHeuristics ради устранения зависших adminCount. Исключение Backup Operators, например, позволяет делегированным ACE от OU снова применяться к учётным записям с весьма чувствительными возможностями резервного копирования и восстановления. Если организация всё же выбирает этот механизм, изменение надо испытать в отдельном лесу, сохранить исходную строку целиком, оформить оценку риска и проверить результат на PDC Emulator каждого домена после репликации.

Приоритет работ такой: сначала аудит фактического состава защищённых групп, затем точечное восстановление бывших защищённых объектов, после этого регулярный контроль. Изменение AdminSDHolder или dSHeuristics имеет смысл только как осознанное изменение модели управления привилегированными учётными записями, а не как быстрый ответ на заявку helpdesk.

• Не добавлять обычную helpdesk-группу в ACL AdminSDHolder.
• Помнить, что `dSHeuristics` находится в разделе Configuration и действует в масштабе леса.
• 16-й символ — шестнадцатеричная маска `1`, `2`, `4`, `8` для четырёх операторских групп.
• При длине строки от десяти символов 10-я позиция должна быть `1`; существующие позиции требуется сохранить.
• До массовых изменений ACL подготовить резервную копию и проверить восстановление.
• Каждая правка AdminSDHolder должна иметь автора, дату, обоснование и план отмены.

Частые вопросы