Ошибка 4015 на DNS Server

Обновлено 23.04.2024

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

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

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

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

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

Ошибка "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, это просто и быстро. Во многих случаях это помогает устранить проблему.

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

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

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

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

Далее 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

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

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

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

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

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

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

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

или:

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

Давайте изучим права на эту зону в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

замените фактическое различающееся имя, имя 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