Ошибка 0xaac при повторном вводе компьютера в домен: почему прав helpdesk мало и кого добавлять в allowlist

Инженер поддержки переустанавливает рабочее место, вводит его в домен под старым именем — и получает «An account with the same name exists in Active Directory. Re-using the account was blocked by security policy», код 0xaac. При этом права на объект компьютера ему выданы, делегирование настроено, в ACL всё зелёное. Ниже разбираю, почему обычных разрешений здесь принципиально недостаточно, кого именно надо вписать в политику allowlist (спойлер: не того, кто вводит машину), какие ACE всё равно остаются обязательными и как я это разворачиваю у клиентов, не раздавая поддержке Domain Admins.

0xaac — это не про права доступа, это про владельца объекта

Первая ловушка в том, что ошибка выглядит как отказ в доступе, а по сути им не является. Код 0xaac (десятичное 2732) — это NERR_AccountReuseBlockedByPolicy из lmerr.h, «An account with the same name exists in Active Directory. Re-using the account was blocked by security policy». В GUI пользователь видит вообще кастрированное «Can't join this domain. Contact your IT admin for more info.» — и дальше начинается угадайка. Админ идёт в ACL объекта компьютера, видит там свою делегированную группу поддержки со всеми галками, разводит руками и в итоге либо удаляет учётку компьютера руками, либо (чаще) закидывает helpdesk в Domain Admins. Оба варианта плохие, и второй хуже.

На самом деле контроллер домена выполняет отдельную проверку, которая идёт ДО и ПОМИМО обычной проверки DACL: он смотрит, кто является владельцем (Owner в security descriptor) существующего объекта computer, и решает, можно ли этот объект переиспользовать. Обычные разрешения — Reset password, Write account restrictions, validated write — на эту проверку не влияют вообще никак. Вы можете выдать поддержке Full Control на объект и всё равно получить 0xaac, потому что владелец объекта не входит в число доверенных. Это ровно та причина, по которой типовые инструкции «делегируйте права на OU» перестали работать.

Самое надёжное подтверждение диагноза — файл C:\Windows\debug\netsetup.log на клиенте. Там видно, что LDAP-операция даже не дошла до записи атрибутов: проверка отработала на уровне политики и вернула отказ.

Что именно проверяет DC: три легальных пути и хронология изменений

Механика описана в KB5020276 (Netjoin: Domain join hardening changes). Переиспользование существующей учётной записи компьютера разрешается, если выполнено хотя бы одно из трёх условий. Первое: ввод в домен выполняет тот же пользователь, который эту учётную запись создал. Второе: учётная запись была создана членом Domain Admins, Enterprise Admins или встроенной группы Administrators. Третье: владелец переиспользуемого объекта (или группа, в которую он входит) перечислен в политике «Domain controller: Allow computer account re-use during domain join». Третий вариант появился с обновлениями от 14 марта 2023 года и требует, чтобы эти обновления стояли и на контроллерах домена, и на клиентских машинах.

Хронология важна, потому что от неё зависит, что у вас вообще есть под рукой. 11 октября 2022 — жёсткая блокировка появилась впервые (работали только «создатель» и «админ-создатель»). 14 марта 2023 — расширен список исключений и введена та самая GPO с allowlist. 12 сентября 2023 — проверка окончательно переехала на сторону контроллера домена, клиент делает аутентифицированный SAMRPC-вызов для валидации. 13 августа 2024 — из системы вырезали поддержку реестрового обходного пути NetJoinLegacyAccountReuse: Microsoft прямо пишет, что этот ключ и упоминания о нём удалены.

Отсюда практический вывод для 2026 года: если вы поднимаете домен на Windows Server 2025 или просто держите парк в актуальном состоянии, обходного пути через реестр у вас нет. Никакого. Я до сих пор регулярно вижу в чужих runbook'ах строчку про NetJoinLegacyAccountReuse=1 на клиенте — она унаследована из 2022–2023 годов и сегодня просто не делает ничего. В netsetup.log это, кстати, прекрасно видно: IsLegacyAccountReuseSetInRegistry возвращает FALSE, и следом идёт отказ политики.

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

• 11.10.2022 — блокировка переиспользования включена, обход только «тот же создатель» или создание админом.
• 14.03.2023 — добавлены Enterprise Admins / встроенные Administrators и GPO с allowlist владельцев.
• 12.09.2023 — проверка перенесена на DC, клиент валидируется через SAMRPC.
• 13.08.2024 — NetJoinLegacyAccountReuse удалён, обход через реестр больше не работает.

Кого добавлять в allowlist: владельца объекта, а не того, кто вводит машину

Здесь ошибаются почти все, кого я видел. Логика подсказывает: «падает у helpdesk — значит helpdesk и добавим в политику». Microsoft в KB5020276 пишет ровно наоборот, прямым текстом: «Do not add the user account that performs the domain join». В allowlist перечисляются доверенные создатели и владельцы учётных записей компьютеров — то есть те принципалы, которые фигурируют в поле Owner у объектов computer. Если вы туда впишете сервисную учётку, под которой инженер вводит машину, но владельцем объекта останется уволенный два года назад администратор — вы получите тот же 0xaac и потратите вечер на «политика не применяется».

Настраивается это одной GPO, привязанной к OU Domain Controllers (никуда больше её вешать не нужно — проверку делает DC). Путь: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → «Domain controller: Allow computer account re-use during domain join». Отмечаете «Define this policy setting», жмёте Edit Security и через object picker добавляете группу в Allow. Дальше gpupdate /force на контроллерах.

Проверить, что политика реально доехала, проще всего по реестру контроллера домена: политика раскладывается в HKLM\SYSTEM\CurrentControlSet\Control\SAM, значение ComputerAccountReuseAllowList в формате SDDL. Руками этот ключ править не надо — только через GPO, иначе на ближайшем применении политик всё откатится.

# на контроллере домена: что реально лежит в allowlist
$sddl = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SAM' `
         -Name ComputerAccountReuseAllowList -EA SilentlyContinue).ComputerAccountReuseAllowList
$sddl
ConvertFrom-SddlString $sddl | Select-Object -ExpandProperty DiscretionaryAcl

И второй практический момент: в политику кладут группу, а не перечень пользователей. Не «Authenticated Users», не «Everyone», не «Domain Users» — Microsoft отдельно предупреждает про большие группы, и это не формальность. Членство в этом списке фактически означает «объекты, которыми владеет этот принципал, разрешено переиспользовать при вводе в домен». Держите там одну-две сервисные учётки, которые пре-создают компьютеры, и всё.

• В allowlist — владелец/создатель объекта computer (сервисная учётка провижининга, группа админов рабочих мест).
• НЕ в allowlist — учётка, под которой инженер нажимает «Ввести в домен».
• GPO линкуется только на OU Domain Controllers.
• Контроль применения — значение ComputerAccountReuseAllowList (SDDL) в HKLM\SYSTEM\CurrentControlSet\Control\SAM.

Права на объект компьютера, которые allowlist не отменяет

Проверка владельца — дополнительная, а не заменяющая. Даже когда она пройдена, дальше идёт обычная запись в каталог: сброс пароля учётной записи компьютера, установка DnsHostName, servicePrincipalName, включение учётки через userAccountControl. Если у того, кто вводит машину, нет соответствующих ACE — вы получите уже другую ошибку, с INSUFF_ACCESS_RIGHTS в netsetup.log. Поэтому оба слоя надо настраивать вместе, иначе будете чинить по кругу.

Минимальный набор разрешений на объект компьютера для переиспользования (по документации Microsoft «Active Directory domain join permissions», редакция августа 2025): Read (read all properties + list contents), Allowed to authenticate, Change password, Reset password, Validated write to DNS host name, Validated write to service principal name, Write account restrictions. Последнее нужно именно для правки userAccountControl. Если помимо ввода в домен машину переименовывают — добавляются Write description, Write displayName и Write sAMAccountName (в интерфейсе ADUC это «Write computername (pre-Windows 2000)» и соседние).

Я предпочитаю выдавать это не на каждый объект руками, а один раз на OU с наследованием на дочерние объекты класса computer. Через мастер делегирования получается неаккуратно (он тянет лишнее), поэтому ставлю через dsacls. Кавычки в set стоят вокруг всего присваивания, чтобы при подстановке %GRP% внутрь строки прав не получить двойные кавычки — на этом спотыкаются чаще, чем на самих правах:

set "OU=OU=Workstations,DC=lapa,DC=local"
set "GRP=LAPA\HelpDesk-Join"

dsacls "%OU%" /I:S /G "%GRP%:CA;Reset Password;computer"
dsacls "%OU%" /I:S /G "%GRP%:CA;Change Password;computer"
dsacls "%OU%" /I:S /G "%GRP%:CA;Allowed to Authenticate;computer"
dsacls "%OU%" /I:S /G "%GRP%:WS;Validated write to DNS host name;computer"
dsacls "%OU%" /I:S /G "%GRP%:WS;Validated write to service principal name;computer"
dsacls "%OU%" /I:S /G "%GRP%:WP;Account Restrictions;computer"
dsacls "%OU%" /I:S /G "%GRP%:RPLC;;computer"

rem проверка результата
dsacls "%OU%" | findstr /i "HelpDesk-Join"

Обратите внимание: права на создание объектов (Create Computer Objects) в этот набор не входят и поддержке они не нужны. Пре-создаёт компьютеры отдельная сервисная учётка — она же становится владельцем, она же прописана в allowlist. Поддержка только переиспользует уже созданное. Такое разделение и есть весь смысл упражнения: helpdesk получает ровно право «переставить машину», а не право «завести в домене что угодно».

• Read all properties, List contents
• Allowed to authenticate
• Change password, Reset password
• Validated write to DNS host name
• Validated write to service principal name
• Write account restrictions (userAccountControl)
• Дополнительно при переименовании: Write description, displayName, sAMAccountName

Разбор из практики: ветеринарная клиника «Лапа и Хвост» на 17 рабочих мест

Условный клиент — ветеринарная клиника «Лапа и Хвост»: 17 рабочих мест (две стойки регистратуры, шесть кабинетов приёма, операционная, лаборатория, рентген-кабинет, склад и бухгалтерия), домен lapa.local, два виртуальных контроллера на Windows Server 2025. Поддержку ведём мы снаружи, внутри есть сотрудник, который отвечает за технику «по совместительству». Задача была штатная: замена дисков на SSD и переустановка 12 станций тройками по ночам, чтобы не останавливать приём. Имена нужно было сохранить: к ним привязаны GPO с настройками ветеринарной МИС, принтеры этикеток и доступ рентген-станции к папке со снимками на файловом сервере. Первые три машины прошли идеально. Начиная с четвёртой — 0xaac почти на каждой.

Разбирались так. На клиенте в netsetup.log — «NetpCheckIfAccountShouldBeReused: Account re-use attempt was Denied by Active Directory Policy», следом «NetpModifyComputerObjectInDs: Account exists and re-use is blocked by policy. Error: 0xaac». На контроллере домена в журнале System — предупреждения с ID 16998 от источника Directory-Services-SAM (запрос на переиспользование учётной записи компьютера отклонён), по одному на каждую неудачную попытку. Картина однозначная: политика, а не ACL. Дальше я собрал срез владельцев по всей OU рабочих мест:

Import-Module ActiveDirectory
Get-ADComputer -Filter * -SearchBase 'OU=Workstations,DC=lapa,DC=local' |
  ForEach-Object {
    [pscustomobject]@{
      Name  = $_.Name
      Owner = (Get-Acl "AD:$($_.DistinguishedName)").Owner
    }
  } | Group-Object Owner | Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Результат оказался показательным. Из 21 объекта в OU: 7 принадлежали LAPA\svc_deploy (сервисная учётка, которой прежний подрядчик заводил компьютеры при открытии клиники), 5 — учётной записи администратора, уволившегося три года назад, 4 — Domain Admins (эти вводились без проблем, потому что попадали под исключение «создан членом Domain Admins»), 3 — личной учётке ещё одного бывшего подрядчика, и 2 объекта показывали голый SID вместо имени — принципал удалён из каталога. Те самые «первые три удачных» как раз были из группы Domain Admins, отсюда и ложное ощущение, что всё работает.

Что сделали. Создали группу LAPA\Srv-ComputerOwners, положили туда одну сервисную учётку svc_deploy. Скриптом привели Owner всех объектов рабочих станций к этой группе (для смены владельца нужно право Modify Owner — делали разово под администратором домена, не отдавая это право поддержке). Подняли GPO «ITF — DC Computer Account Reuse», привязали к OU Domain Controllers, в политике «Domain controller: Allow computer account re-use during domain join» через Edit Security добавили Srv-ComputerOwners. После gpupdate /force на обоих DC проверили SDDL в ветке SAM. Параллельно выдали группе LAPA\HelpDesk-Join набор ACE на OU рабочих мест через dsacls, как выше. Сотрудника клиники, которому до этого «временно» выдали Domain Admins, из этой группы вывели.

Итог: оставшиеся девять машин прошли переустановку без единого 0xaac, ввод в домен — те же 20–30 секунд, поддержка работает под обычной делегированной учёткой. Два объекта с осиротевшими SID мы просто удалили: они соответствовали давно списанным ПК, которые стояли в кабинете груминга до ремонта. Вся правка заняла около полутора часов, из них час — аудит владельцев и согласование с главным врачом окна работ, и минут двадцать — собственно настройка.

Диагностика за десять минут: куда смотреть и в каком порядке

Порядок действий, который экономит время. Первое — netsetup.log на клиенте (C:\Windows\debug\NetSetup.LOG), смотрим хвост. Строка «Account re-use attempt was Denied by Active Directory Policy» и Error: 0xaac означает проверку владельца. Строка INSUFF_ACCESS_RIGHTS / ldap_modify_s failed: 0x32 0x5 — нехватка ACL, лечится дсаклами из предыдущего раздела. Ещё бывает 0x8b0 (NERR_UserExists) следом за 0xaac — это просто откат клиента на downlevel-путь, отдельного смысла не несёт.

Второе — журнал System на контроллере домена, источник Directory-Services-SAM. Там четыре полезных события: 16995 (информационное, «использую указанный дескриптор безопасности для валидации» — значит allowlist прочитан), 16996 (ошибка: дескриптор безопасности некорректен), 16997 (ошибка: обнаружена «осиротевшая» учётная запись компьютера), 16998 (предупреждение: запрос на переиспользование отклонён). На клиенте в журнал System параллельно пишутся события источника Netjoin: 4100 (переиспользование разрешено) и 4101 (переиспользование заблокировано).

Третье — владелец конкретного объекта. Одной строкой:

(Get-Acl "AD:$((Get-ADComputer LAPA-WS-07).DistinguishedName)").Owner

Если вместо DOMAIN\Principal вы видите S-1-5-21-…, принципал удалён — переиспользовать такой объект не получится в принципе, его надо либо переназначить, либо удалить и создать заново.

Отдельная засада, на которую стоит закладываться заранее: если в netsetup.log проверка возвращает NetStatus: 0x5 (Access denied) на этапе SAM-вызова, а не отказ политики — проблема не во владельце, а в политике «Network access: Restrict clients allowed to make remote calls to SAM». С сентября 2023 года клиент валидируется через SAMRPC, и если вы этот доступ ужимали (а в ужесточённых конфигурациях это делают часто), нужную группу придётся добавить и туда. У меня это выстреливало дважды, оба раза в доменах, где до нас работал «безопасник по чек-листу».

• C:\Windows\debug\NetSetup.LOG — хвост файла, ищем 0xaac и текст про Active Directory Policy.
• System на DC, источник Directory-Services-SAM: 16995 / 16996 / 16997 / 16998.
• System на клиенте, источник Netjoin: события 4100 (разрешено) / 4101 (заблокировано).
• Get-Acl AD:<DN> → свойство Owner для проблемного объекта.
• Реестр DC: HKLM\SYSTEM\CurrentControlSet\Control\SAM → ComputerAccountReuseAllowList.

Что я делаю по умолчанию и на чём можно сэкономить силы

Мой рабочий шаблон для клиента до 50 рабочих мест выглядит так. Одна сервисная учётка провижининга (svc_join или svc_deploy), которая создаёт все объекты computer и остаётся их владельцем. Одна группа-владелец, в которой лежит только эта учётка, и она же — единственный член allowlist в GPO на Domain Controllers. Одна группа для поддержки с делегированными ACE на OU рабочих мест: Reset/Change password, два validated write, Write account restrictions, Read. Никого из инженеров в Domain Admins. Такая конструкция переживает и увольнения, и смену подрядчика — потому что владельцем везде выступает группа, а не человек.

Если переустановки массовые и регулярные — я вообще предпочитаю обходить весь этот слой через offline domain join. Там provisioning выполняет доверенная учётка на защищённой машине, а компьютер, который вводится, вообще не обращается в каталог со своими правами:

rem на машине с RSAT, под учёткой-владельцем
djoin /provision /domain lapa.local /machine LAPA-WS-07 /reuse ^
      /savefile C:\odj\LAPA-WS-07.txt

rem на переустановленной машине, локально
djoin /requestODJ /loadfile C:\odj\LAPA-WS-07.txt /windowspath C:\Windows /localos

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

Теперь честно о спорном. Многие коллеги решают вопрос проще: перед переустановкой удаляют учётную запись компьютера и вводят машину заново под свежесозданным объектом. Это работает и это законный путь (Microsoft перечисляет его среди рекомендаций). Но вы теряете членство в группах, привязки BitLocker-ключей в AD, LAPS-пароль, историю и всё, что завязано на objectGUID/SID объекта. Для парка из десяти машин — приемлемо. Для домена, где по группам компьютеров раскиданы GPO и правила доступа, — нет. Я такой вариант использую только для реально мёртвых, годами не логинившихся объектов.

И о том, на что можно забить. Не надо перелопачивать владельцев у серверных объектов, если серверы вы не переставляете — проверка срабатывает только при вводе в домен. Не надо линковать allowlist-политику на всю доменную OU «на всякий случай»: читает её только DC. Не надо искать способ вернуть NetJoinLegacyAccountReuse — его нет с августа 2024 года, и попытки «отключить харденинг» в 2026 году сводятся к тому, чтобы не ставить обновления, а это заведомо худший размен.

• Первым делом: аудит Owner по OU компьютеров (Get-Acl AD: + Group-Object).
• Затем: единая группа-владелец и приведение Owner к ней.
• Затем: GPO с allowlist на OU Domain Controllers + проверка SDDL в реестре DC.
• Затем: делегирование ACE поддержке через dsacls на OU, без Create Computer Objects.
• Опционально: перевод массовых переустановок на djoin /provision /reuse.

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