Ошибка 4015 на DNS Server

DNS server logo

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik. Ранее мы с вами рассматривали что из себя представляет DNS сервер, какие функции он несет, какие у него бывают зоны и так далее. В сегодняшней статье я с вами займусь траблшутингом и мы рассмотрим ошибку ID 4015 "0: 0000051B: DSID-030F25BA, problem 1005 (CONSTRAINT_ATT_TYPE" на DNS сервере установленном на контроллере домена. Ошибка оказалась интересной и не такой тривиальной как во многих случаях, чем ценнее данный опыт. Если у вас будут другие варианты решения или разновидности этой ошибки, то просьба описать их в комментариях. я буду вам очень признателен.

Описание ошибки ID 4015

Несколько дней назад в чат мониторинга прилетело уведомление об ошибке:

09:04:43,2024.04.08 : Важно : dc08.root.pyatilistnik.org: DC08 : 4015 DNS Event

Обычно в таких случаях помогало перезапустить службу DNS на контроллере домена, но через 10 минут ошибка вновь появлялась. Первым делом я проверил доступность порта 53 отвечающего за DNS, он отвечал. Оставалось идти в логи Windows, журнал DNS Server. Журнал был просто забит ошибками:

ID 4015: The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is "0000051B: AtrErr: DSID-030F25BA, #1:
0: 0000051B: DSID-030F25BA, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 20119 (nTSecurityDescriptor)". The event data contains the error.

ID 4015 The DNS server has encountered a critical error from the Active Directory

Через какое-то время они проходили, но потом появлялись вновь.

Более подробно изучив повторяющиеся события, я обратил внимание, что все они шли от учетных записей компьютера которые являются DHCP серверами.

Ошибка "CONSTRAINT_ATT_TYPE" (код ошибки 0000051B) указывает на то, что возникла проблема с типом атрибута при выполнении операции LDAP. В данном случае атрибут, вызывающий ошибку, это "nTSecurityDescriptor" (Att 20119).

Эта ошибка обычно возникает, когда LDAP-запрос или операция пытается изменить или использовать атрибут с недопустимым типом данных или недопустимыми ограничениями. В данном случае, похоже, что атрибут "nTSecurityDescriptor" имеет ограничения на тип данных или правила использования, которые не были соблюдены.

Для устранения этой ошибки вам может потребоваться проверить правила и ограничения для атрибута "nTSecurityDescriptor" в вашем LDAP-каталоге и убедиться, что операции LDAP соблюдают эти правила. Также стоит убедиться, что запросы LDAP корректно формулируются и не пытаются изменять или использовать атрибут "nTSecurityDescriptor" недопустимым образом.

Так же вы можете увидеть в ошибке nTSecurityDescriptor. nTSecurityDescriptor (Security Descriptor) - это структура данных в операционной системе Windows, которая содержит информацию о безопасности объекта, такого как файл, папка, реестр и другие ресурсы. Security Descriptor определяет права доступа к объекту, а также список пользователей или групп, которым разрешен или запрещен доступ к этому объекту. nTSecurityDescriptor включает в себя следующие основные элементы:

  1. Owner (владелец) - пользователь или группа, которые владеют объектом и могут управлять его разрешениями.
  2. Group (группа) - группа пользователей, которым предоставлен доступ к объекту.
  3. Discretionary Access Control List (DACL) - список разрешений, определяющий, какие действия могут выполнять пользователи или группы над объектом.
  4. System Access Control List (SACL) - список разрешений для аудита, который определяет, какие события должны быть аудитированы при доступе к объекту.

Методы устранения ошибки ID 4015

1️⃣Самое простое, что вы можете сделать, это попробовать перезапустить службу DNS, это просто и быстро. Во многих случаях это помогает устранить проблему.

Перезапуск DNS службы

Существует несколько разновидностей, я столкнулся с кодом ошибки 0000051B, но об остальных я расскажу чуть ниже. В моем случае компания Micfosoft предлагает включить более расширенный аудит, через ключ реестра "15 Field Engineering".

Ключ 5 Field Engineering отвечает за настройки диагностики и отладки службы NTDS (NT Directory Service). В этом ключе можно настроить различные параметры, связанные с диагностикой и отладкой службы NTDS, такие как уровень журналирования, отображение отладочной информации и т. д. Эти настройки могут быть использованы для обнаружения и устранения проблем в работе службы NTDS.

Перейдите на контроллер домена или DNS сервер, где вы наблюдаете ошибки и запустите редактор реестра Windows. Перейдите по пути:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\NTDS\Diagnostics\

Там будет ключ реестра "15 Field Engineering", измените его значение на "5"

ключ реестра 15 Field Engineering

Как только вы это сделаете, вам настоятельно рекомендую увеличить размер журнала логов "Directory Service", хотя бы до 300-500 мб

Свойства журнала Directory Service

Далее Microsoft рекомендует создать 3 дополнительных ключа реестра, чтобы определить самые дорогие, тяжелые и неэффективные поисковые запросы LDAP/LDAPS:

  • Expensive Search Results Threshold - Ключ реестра Search Results Threshold отвечает за определение порогового значения для дорогих (expensive) поисковых запросов в службе Active Directory Domain Services (NTDS). Этот параметр используется для определения того, когда запрос считается дорогим и может быть прерван для предотвращения перегрузки сервера. Значения, которые может принимать параметр Expensive Search Results Threshold, обычно указываются в миллисекундах и определяют время, которое запрос должен занимать для выполнения до того, как он будет считаться дорогим. Например, значение 5000 миллисекунд (5 секунд) означает, что запрос, который занимает более 5 секунд, будет считаться дорогим. Правильная настройка этого параметра может помочь избежать перегрузки сервера Active Directory и обеспечить более эффективную работу службы.

Выставляем для данного ключа значение "1". Тип REG_DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \NTDS\Parameters\Expensive Search Results Threshold

  • Inefficient Search Results Threshold - Ключ реестра Search Results Threshold отвечает за определение порогового значения для неэффективных (inefficient) результатов поиска в службе Active Directory Domain Services (NTDS). Этот параметр используется для определения того, когда результаты поиска считаются неэффективными из-за большого количества возвращаемых данных. Значения, которые может принимать параметр Inefficient Search Results Threshold, обычно указываются в байтах или в количестве объектов, и определяют максимальное количество данных, которое может быть возвращено результатами поиска до того, как они будут считаться неэффективными. Например, значение 100000 байт означает, что результаты поиска, возвращающие более 100 килобайт данных, будут считаться неэффективными.

Выставляем для данного ключа значение "1". Тип REG_DWORD

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \NTDS\Parameters\Inefficient Search Results Threshold

  • Search Time Threshold (msecs) - Ключ реестра Time Threshold (msecs) отвечает за определение порогового значения времени выполнения поисковых запросов в службе Active Directory Domain Services (NTDS). Этот параметр используется для определения максимального времени, в течение которого поиск должен быть выполнен, прежде чем он будет считаться неэффективным или долгим. Значения, которые может принимать параметр Search Time Threshold (msecs), обычно указываются в миллисекундах и определяют максимальное время, которое может затратиться на выполнение поискового запроса. Например, значение 5000 миллисекунд означает, что поиск, который занимает более 5 секунд, будет считаться неэффективным. Установка слишком низкого значения может привести к недопустимо быстрому считыванию данных, а установка слишком высокого значения может привести к долгим задержкам при выполнении поисковых запросов. Обычно рекомендуется устанавливать разумное значение для Search Time Threshold (msecs) в зависимости от требований к производительности и нагрузке на сервер Active Directory.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \NTDS\Parameters\Search Time Threshold (msecs)

Выставляем для данного ключа значение "1". Тип REG_DWORD

Теперь когда вы активировали расширенный сбор событий необходимо ждать появления новых событий ID 4015 в журнале "DNS Server". Как только оно появилось, я рекомендую его остановить, выставим у ключа "15 Field Engineering" значение "0", это нужно для того чтобы начать работать с текущими событиями и не забивать логи новыми.

  • Далее вам нужно найти событие ID 4015 и запомнить его точное время
  • Перейти в журнал Directory Service и найти там событие ID 1644 с таким же временем, изучить его
  • Найти после события ID 1644 событие ID 1535

У меня было много событий по обратным зонам DC=76.192.77,DC=10.in-addr.arpa,cn=MicrosoftDNS,DC=DomainDnsZones,DC=Pyatilistnik,DC=org

id 1644 Internal event: A client issued a search operation with the following options.

Далее видно, что после него была ошибка:

Internal event: The LDAP server returned an error.

Additional Data
Error value:
0000051B: AtrErr: DSID-030F25BA, #1:
0: 0000051B: DSID-030F25BA, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 20119 (nTSecurityDescriptor)

0000051B AtrErr DSID-030F25BA

или:

Error value:
00002098: SecErr: DSID-031514A0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

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

ID 1535

Давайте изучим права на эту зону в cn=MicrosoftDNS,DC=DomainDnsZones,DC=Pyatilistnik,DC=org. DC=DomainDnsZones - это специальная раздел в Active Directory, который содержит информацию о зоне DNS для домена. Он обычно находится внутри раздела "Partitions" в Active Directory. Для доступа к DC=DomainDnsZones можно использовать утилиту ADSI Edit или другие инструменты для администрирования Active Directory.

В оснастке ADSI Edit выберите пункт "Connection Point и введите туда путь cn=MicrosoftDNS,DC=DomainDnsZones,DC=Pyatilistnik,DC=org

Подключение к MicrosoftDNS

В итоге вы подключитесь к разделу содержащему DNS зоны. В списке найдите раздел, который фигурировал в ошибке. Если это была обратная зона, то нужно удостовериться, что ее владельцем является "SYSTEM". Если это не так, то Microsoft рекомендует сменить на него.

Владелец DNS зоны

2️⃣Следующим шагом я вам советую открыть оснастку DNS, найти нужную зону которая фигурировала в ошибке. Зайдите в ее свойства и перейдите на вкладку "Name Severs" проверьте, что у вас в данном списке все DNS сервера верные и нет призраков или недоступных, как в примере ниже.

Ошибка DNS

По мимо прав на уровне зоны, проверьте кто владелец на конкретной записи, которая фигурирует в событии. Например у меня везде, в ошибках были записи PTR, где в качестве пользователя от которого шел запрос, была учетная запись DHCP сервера. В cn=MicrosoftDNS найдите свою запись DC=последний октет. Зайдите в его свойства и проверьте, что у той учетной записи, у меня это DHCP есть права на ее изменение. Если нет, то нужно добавить.

Проверка прав на DNS запись

3️⃣Если на уровне прав в ACL все хорошо, то я могу вам посоветовать проверить порядок настройки DNS серверов на контроллерах домена. Запустите ncpa.cpl в окне "Выполнить",

Вызов ncpa.cpl

В настройках IPv4 выставите, чтобы первым адресом был другой DNS сервер, а не ip-адрес текущего сервера, это должно помочь с ошибками ID 4015 по словам Microsoft, сейчас они это рекомендуют как бестпрактис, но вопрос спорный.

Настройка DNS на ipv4

Не забудьте перезапустить везде DNS службу. Если у вас как и в моем случае в ошибках фигурирует пользователь DHCP сервера, то зайдите на каждый из них и проверьте, что там в IPv4 выставлены верные адреса DNS серверов. Далее обязательно зайдите в IPv6, проверив там настройки. Я видел случаи, что там ошибочно прописывали ::1, уберите его и выставите автоматическое получение DNS (Obtain DNS Server address authomatically).

DNS ipv6

::1 был замечен и на DNS серверах, а вот где IPv6 был выключен, ошибок не было. Адрес ::1, используется по умолчанию, и при nslookup IPv6 DNS имеет приоритет в разрешении имен перед IPv4

Для удобства проверки я написал простой скрипт, который берет список список контроллеров домена их текстового файла и достает информацию по сетевым интерфейсам, о IPv6.

# Создаем пустой массив для хранения результатов
$result = @()

# Шаг 1: Список серверов
$servers = Get-Content -Path "C:\Temp\servers-dc.txt"

# Шаг 2 и 3: Запрос DNS для IPv6 на каждом сервере и добавление результатов в массив
foreach ($server in $servers) {
$dnsList = Invoke-Command -ComputerName $server -ScriptBlock {
Get-DnsClientServerAddress -AddressFamily IPv6 | Select-Object -ExpandProperty ServerAddresses
}

foreach ($dns in $dnsList) {
$row = [PSCustomObject]@{
ServerName = $server
DNS_IPv6 = $dns
}
$result += $row
}
}

# Выводим все результаты в виде одной общей таблицы
$result | Format-Table -AutoSize

Powershell вывод DNS в IPv6

Тут нужно определиться, чтобы у вас везде было одинаково. Я решил не отключать пункт IPv6 в свойствах сетевого интерфейса, так как у MS оно уже много где может быть завязано, но в качестве вашего случая вы можете протестировать.

4️⃣Если это не помогло, еще одной из рекомендаций выступает проверка зоны _msdcs.root.pyatilistnik.org. Вам необходимо проверить контейнеры dc, domains, gc, pdc на предмет в них старых записей ведущих на несуществующие контроллеры домена.

Зона msdsc

5️⃣В моем случае ошибку 4015 вызвало ежемесячное обновление безопасности KB5037425, посмотреть можно командой:

Get-WmiObject -Class Win32_QuickFixEngineering | Select-Object HotFixID, Description, InstalledOn

Powershell вывод списка обновлений

Тут у вас два варианта, либо поискать еще более новое обновление, либо же удалить текущее и дождаться исправления. Лично я просто оставил KB5037425 и жду появления обновления следующего месяца, я не считаю данную ошибку на DNS критичной, так как она не влияет на сам сервис.

Дополнительные методы

6️⃣В Windows Server есть полезный функционал, который может дать вам вектор направления куда еще можно копнуть, называется он "Best practices analyzer", который можно найти в оснастке "Диспетчер серверов".

Best Practices Analyzer (BPA) - это инструмент в Windows Server, который помогает администраторам оценить соответствие сервера рекомендуемым практикам безопасности, производительности и надежности. BPA сканирует сервер на предмет наличия настроек и конфигураций, которые могут привести к проблемам или уязвимостям.

После сканирования BPA предоставляет отчет с рекомендациями по улучшению конфигурации сервера. Это может включать изменение настроек безопасности, оптимизацию производительности или рекомендации по устранению потенциальных уязвимостей. Использование Best Practices Analyzer помогает администраторам обеспечить более надежную и безопасную работу сервера, а также улучшить его производительность.

Посмотрите список ошибок и рекомендаций, которые вы можете выполнить для улучшения работы DNS.

Best practices analyzer

7️⃣Далее я рекомендую проверить основные функции DNS, в командной строке введите следующую команду:

dcdiag /test:dns /v /s:<DCName> /DnsBasic /f:dcdiagreport.txt

замените фактическое различающееся имя, имя NetBIOS или DNS-имя контроллера домена для <DCName>. В качестве альтернативы можно протестировать все контроллеры домена в лесу, введя /e: вместо /s:. Параметр /f задает имя файла, которое в предыдущей команде dcdiagreport.txt. Если вы хотите разместить файл в расположении, отличном от текущего рабочего каталога, можно указать путь к файлу, например /f:c:reportsdcdiagreport.txt.

8️⃣Еще очень важно проверить работу репликации в Active Dirtectory с помощью утилиты repadmin, как это делать я так же подробно описывал.

Дополнительные ссылки

https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/active-directory/configure-ad-and-lds-event-logging#enable-field-engineering-diagnostic-event-logging

https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/networking/event-4015-dns-server-encounters-critical-error

https://www.mickputley.net/2015/11/dns-error-4015.htm

Оцените статью
Настройка серверов windows и linux
Добавить комментарий