База данных диспетчера учетных записей на сервере не содержит записи

Обновлено 28.03.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз я вас научил делать резервные копии с помощью утилиты Robocopy, это было очень полезно. В сегодняшней заметке я покажу, как решается проблема с вылетевшим из домена компьютером, который при логине выводит ошибку "База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера". Думаю, что многие с ней сталкивались, но не все ее решали и понимали откуда эта проблема берется.

Описание проблемы

Давайте я подробнее опишу рабочее окружение. И так есть лес Active Directory, в котором есть родительский домен, дочерний и транзитивный отдельный домен в рамках леса. Поступила задача мигрировать и доверительного домена объект компьютера в дочерний домен. Для этого была использована утилита ADMT 3.2. Сама миграция учетной записи компьютера прошла штатно. Далее я сменил принадлежность к домену Active Directory нового компьютера, у меня ввод был успешен, но было предупреждение, что якобы есть проблемы на уровне DNS-сервера. После перезагрузки и попытке на него залогиниться появилась вот такая ошибка:

В английской версии, это выглядит вот так:

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

И так давайте рассуждать, тут есть два сценария, когда вы можете увидеть эту ошибку:

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

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

В ситуации, когда компьютер по тем или иным причинам не мог связаться с контроллером домена, он не мог вовремя обновить свой пароль, в этом случае, когда он появится в локальной сети, он попытается аутентифицироваться со старым паролем в следствии чего будет успешно послан DC на все четыре стороны и получит ту самую ошибку "База данных диспетчера учетных записей на сервере не содержит записи"

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

• Утилита Netdom
• Nltest
• Командлет Reset-ComputerMachinePassword

Если эти манипуляции не помогают, то у вас сто процентов конфликт имен на уровне леса. Первым делом я вам советую открыть логи на контроллере домена. Там вы со сто процентной уверенностью обнаружите ошибку с кодом ID 2974. Как видите в моем случае ошибка указывает на servicePrincipalName HOST/имя компьютера, именно из-за него конфликт.

В моем случае сообщение об ошибке "База данных диспетчера учетных записей на сервере не содержит записи", появлялось потому, что после миграции у меня на старом месте осталась прошлая учетная запись компьютера и в новом месте она же присутствовала, что приводило к дублированию. У новой учетной записи компьютера, была обнаружена такая вещью, у нее не проставлялся атрибут AD servicePrincipalName. Чтобы в этом удостовериться откройте редактор атрибутов Active Directory подключитесь к контексту именования по умолчанию и найдите свой объект компьютера. Перейдите в его свойства.

Тут вы видите, что атрибут servicePrincipalName пустой, и если вы попытаетесь его заполнить, то получите ошибку, пока не уберете дубль.

Думаю что все умеют искать компьютеры в Active directory, но то же самое можно сделать и другими методами.

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

Можно так же и через командную строку, через утилиту dsquery * -filter servicePrincipalName=* -attr Name.

После того, как вы обнаружили ваш дублирующий компьютер в базе данных AD, то удаляем его. После этого, чтобы без перезагрузок и вывода и повторного ввода в домен, нового компьютера сделайте вот что. Находясь в свойствах учетной записи компьютера через ADSIEdit, зайдите внутрь свойства атрибута servicePrincipalName. Там вам нужно в ручном режиме создать записи:

• HOST/dns имя компьютера
• HOST/полное FQDN имя
• RestrictedKrbHost/dns имя компьютера
• RestrictedKrbHost/полное FQDN имя
• TERMSRV/dns имя компьютера
• TERMSRV/полное FQDN имя

После этих внесений, в идеале перезагрузить этот компьютер, но работать будет и без этого. Еще одно дополнение, если вы хотите увеличить период смены пароля у учетных записей компьютеров, то это можно сделать с помощью групповой политики, отредактировав текущую или создав новую. Я вам предлагаю вам отредактировать политику Default Domain Controllers Policy. Перейдите по пути:

По умолчанию стоит значение 30, можете легко поменять, я например, установлю 90 дней.

Отключение режима проверки уникальности имени участника-пользователя и имя участника-службы

Бывают случаи, что по ряду причин нет возможности удалить дублирующий объект. Для таких сценариев компания Microsoft выпустила обновление для Windows Server 2012 R2 и выше, которое позволяет на контроллерах домена, управлять поведением обнаружения дубликатов.

С помощью этого обновления корпорация Майкрософт предоставляет переключатель уровня леса выключить или включить проверку на уникальность посредством атрибута dSHeuristics.

Ниже приведены поддерживаемые dSHeuristics значения.

• dSHeuristic = 1: AD DS позволяет добавлять имена участников-пользователя (UPN)
• dSHeuristic = 2: AD DS позволяет добавлять имена участников повторяющихся службы (SPN)
• dSHeuristic = 3: AD DS позволяет добавление повторяющихся имен SPN и UPN
• dSHeuristic = любое другое значение: службы AD DS применяет проверка уникальности имен SPN и UPN

Ошибка the trust relationship between this workstation and the primary domain failed

Разновидностью ошибки "База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения" может выступать вот такое уведомление:

Тут то же сервер не может связаться с контроллером домена, если вы зайдете на него консольно, то в журнале событий вы можете обнаружить критическую ошибку:

Как видно Windows просто не смогла открыть файл netlogon.ftl, за который отвечает служба NETLOGON, которая так же участвует в авторизации пользователя в систему. /В системе мониторинга, я так же нашел провал по свободному дисковому пространству.

Что такое netlogon.ftl ?

И так Windows хранит список входа в разделе реестра DomainCache. В реестре, это путь:

Windows заполняет ключ реестра DomainCache из файла с именем C:\WINDOWS\system32\config\netlogon.ftl

Раздел реестра DomainCache обновляется из netlogon.ftl в процессе загрузки компьютера и всякий раз, когда устанавливается подключение к удаленному рабочему столу. Сам же файл netlogon.ftl заполняется из Active Directory службой netlogon. В AD есть раздел defaultNamingContext в контейнере System. Он заполняется из типов объектов TrustedDomain. Посмотреть, что будет заполнено из базы Active Directory можно командой:

Так, что если локальная система не сможет прочитать содержимое файла netlogon.ftl, то ошибка с доверительными отношениями вам обеспечена. Вот так вот просто решается ошибка с отсутствием в базе данных Active Directory учетной записи компьютера для регистрации. С вами был Иван Семин, автор и создатель компьютерного портала Pyatilistnik.org.