Ошибка KCC ID 11 и дублированные SPN имена у CNF записей

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в России по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами разобрали ситуацию, при которой у вас в системе отсутствовала библиотека vcruntime140.dll и из-за нее у вас не запускалась игра или программа. В сегодняшней публикации я хочу вам показать решение ошибки с кодом ошибки 11: The KDC encountered duplicate names while processing a Kerberos authentication request. Ее вы можете встретить на своих контроллерах домена.

Описание ошибки "The duplicate name"

Ранее я вам показывал на своем тестовом стенде установку Active Directory на сервера Windows Server 2019. Инфраструктура работает и живет своей жизнью, а это означает, что вы можете в процессе ее работы сталкиваться с различным букетом ошибок, вот вам свежие примеры:

• Ошибка 1311 при репликации Active Directory
• Ошибка 1818 удаленный вызов процедуры был отменен
• Ошибка 1722 сервер RPC не доступен
• Ошибка 14550 DfsSvc и netlogon 5781
• Ошибка NETLOGON 5723

Это вполне нормально, что появляются ошибки. Факторов, из-за которых так происходит очень много:

• Проблема с сетью и связью
• Проблемные обновления
• Фаэрволы
• Антивирусы
• Сбои служб и многое другое

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

И так залез я как-то на один контроллер домена и обнаружил там в логах системы ошибки:

или

Данная ошибка у меня появлялась каждые 5-7 минут.

Причины появления ошибки с дублированием SPN

Service Principal Names (Имя участника службы (SPN)) - это уникальный идентификатор экземпляра службы. SPN-имена используются проверкой подлинности Kerberos для связи экземпляра службы с учетной записью службы. Это позволяет клиентскому приложению запрашивать, чтобы служба аутентифицировала учетную запись, даже если у клиента нет имени учетной записи.

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

Прежде чем служба проверки подлинности Kerberos сможет использовать имя участника-службы для проверки подлинности службы, имя участника-службы должно быть зарегистрировано на объекте учетной записи, который используется экземпляром службы для входа в систему. Данный SPN может быть зарегистрирован только на одном аккаунте. Для служб Win32 установщик службы указывает учетную запись для входа при установке экземпляра службы. Затем установщик создает имена участников-служб и записывает их как свойство объекта учетной записи в доменных службах Active Directory.

Если две или несколько учетных записей компьютеров имеют одно и то же зарегистрированное имя участника службы, то логично, что это ведет к некому конфликту. Для поиска дублированных SPN есть cmd утилита "setspn". Откройте командную строку от имени администратора и введите команду:

Благодаря ключу -X вы получите дубли. Если вам необходимо произвести поиск дубликатов SPN в лесу, то добавьте ключ -F.

В результате чего я увидел свои дубли:

Оказалось, что у моего контроллера домена есть некий дубль в виде какого-то CNF объекта. Еще посмотреть дубли вы можете и старой командой ldifde:

Как удалить дублированный SPN

Избавиться от ошибки 11 весьма просто в большинстве случаев, но бывают и исключения, где приходится слегка больше времени. У утилиты etspn есть ключ -D.

Либо вы можете зайти по пути, где хранится объект и открыть там редактор атрибутов, где в строке с атрибутом servicePrincipalName вы можете обнаружить все SPN и удалить нужный.

Разберем мой пример, где я должен найти объект CN=DC01\0ACNF:ba395d9d-1193-4df4-bcea-860e94f52dec по пути OU=Domain Controllers,DC=root,DC=pyatilistnik,DC=org, но могут быть ситуации, что вы не сможете его обнаружить, так как его могли удалить ранее.

Объекты CNF и RND

Когда создаются объекты в Active Directory, они получают относительное отличительное имя (RDN - Relative Distinguished Names), которое должно быть уникальным в родительском организационном подразделении (OU) или контейнере . Это обеспечивает уникальность атрибутов extevedName и canonicalName в лесу. Организационное подразделение или контейнер - это место, где новый объект будет находиться в Active Directory.

Объекты в AD однозначно идентифицируются по их отличительному имени (DN). DN формируется с использованием относительного различающегося имени (RDN, CN=имя_компьютера) плюс имена контейнеров (OU=someOUname) и домена (DC=your, DC=domain,DC=com), которые содержат объект. Если DN должен быть уникальным, то не может быть двух объектов, которые используют один и тот же RDN в одном и том же контейнере.

Если вы попытаетесь создать объект в Active Directory с RDN существующего объекта в том же подразделении, то вы получите сообщение об ошибке, например "Не удается создать новый объект-компьютер, поскольку пред-Windows 2000 имя уже используется Выберите другое имя и повторите попытку". Если вы попытаетесь создать объект с уникальным RDN, но с именем sAMAccountName, совпадающим с именем существующего объекта в домене, вы получите то же сообщение об ошибке. Но как видите на картинке вы можете попадать в ситуации, при которых такие дубли RND будут созданы.

Ситуации при которых могут быть созданы дублирующие объекты CNF

Предположим ситуацию, что у меня мой тестовый домен root.pyatilistnik.org имеет несколько контроллер домена. Предположим, что есть два сотрудника тех поддержки и они решили выполнить эту задачу, и не знали, что делают ее параллельно. Каждый завел в AD компьютер с именем W10CL-TEST01, только проблема в том, что репликация в какой-то момент делалась с ошибками между разными контроллерами и получилось так, что защиты от дублей не произошло. И на каждом контроллере домена появился такой объект. Далее связь восстанавливается и что мы получим?

Когда атрибут модифицируется или создается, это изменение помечается отметкой об изменении. Метка изменения содержит номер версии, время последней записи и исходный сервер, это как в DNS. Когда контроллеры домена получают конфликтующие обновления, они проверяют метку изменения и принимают обновление с более высоким номером версии. Если номера версий совпадают, контроллеры домена проверяют время последней записи и принимают тот, который имеет более позднюю отметку времени. Последнее, что нужно решить, какое обновление принято, если номер версии и метки времени идентичны, - это глобальный уникальный идентификатор базы данных сервера (GUID). Изменение от сервера с более высоким GUID будет принято. Когда контроллеры домена добавляются в домен, эти идентификаторы GUID назначаются, и назначение является произвольным.

Но поскольку AD поддерживает репликацию объектов каталога с несколькими хозяевами между контроллерами домена в домене, изменяющими данные в одно и то же время (в одном и том же интервале репликации) на разных контроллерах домена, все же может иметь место два объекта с одинаковым именем (RDN) в одном контейнере (RDN). Скорее всего, это происходит при репликации между различными сайтами, когда интервал репликации по умолчанию составляет 180 минут или по меньшей мере 15 минут (если не настроен из реестра).

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

DC автоматически изменит относительное различающееся имя объекта с более низким GUID на уникальное имя <Старый RDN>\0ACNF:<objectGUID>. Объект с более высоким GUID сохраняется с оригинальным именем. Вот пример:

Это событие может быть зарегистрировано в журнале системных событий с идентификатором 12292 или в журнале Directory Service с идентификатором 1226.

Уникальное имя формируется с использованием GUID объекта. Формат для нового RDN:<имя_объекта>\0ACNF: <objectguid>

• \0A - зарезервированный символ, представляющий символ завершения строки (перевод строки)
• CNF (Conflict Name) - константа, указывающая конфликт
• ObjectGUID - печатное представление значения атрибута objectGuid.

Когда вы пытаетесь переместить этот объект в AD, то вы не сможете это сделать, потому что синтаксис атрибута, указанный для службы каталогов, недопустим. Это вызвано тем зарезервированным символом, который не отображается в RDN или атрибутах имени, но может быть виден в атрибуте DN.

Указанные выше номера версий и временные метки являются значениями метаданных репликации, которые хранятся в атрибуте replPropertyMetaData объекта. Этот атрибут не реплицируется, поэтому значения различаются на каждом контроллере домена. Эти метаданные можно просмотреть с помощью утилиты командной строки repadmin.

Как видите, в моем примере у объектов разное время создания, и когда реплика появилась тот объект у которого значение CN меньше был переименован. Важным моментом является то, что один из объектов переименован, но sAMAccountName не изменяется. Результатом могут быть два объекта с одинаковым sAMAccountName в домене, по крайней мере, пока процесс, описанный в следующем разделе, не распознает дубликат. Конечно, один из объектов должен быть удален.

Как найти в CNF объекты

По мимо команды setspn вы можете найти все дублированные объекты RND через вот такую команду:

Еще можно воспользоваться LDAP запросами в ADUC. Выберите пользовательский поиск и на вкладке дополнительно введите:

В итоге получите список всех объектов CNF.

или еще можно воспользоваться конструкцией:

Что делать с CNF объектами

Хорошо, теперь мы знаем, как эти конфликты рождаются. Далее мы должны выяснить, как их решить. Вы не можете переименовать объект компьютера, используя Active Directory Users and Computers. Одним из способов является удаление объектов AD вручную, а также переименование и повторное подключение компьютеров к домену:

1. Сначала вы должны узнать или сбросить пароль локального администратора, чтобы вы могли войти в систему, если что-то пойдет не так, и вы больше не сможете войти в систему с учетными записями домена.
2. Войдите в систему как администратор, присоедините компьютер к рабочей группе, НЕ перезагружайте компьютер!
3. Удалите конфликтующие объекты AD и подождите, пока это удаление будет реплицировано на все контроллеры домена в домене.
4. Присоедините компьютер к домену и переместите новый объект AD в OU, где вы хотите, чтобы он находился, НЕ перезагружайте компьютер
5. Теперь у вас есть возможность дождаться репликации вновь созданного (и перемещенного) объекта в домене.

В итоге я просто удалил такой объект в моем тестовом окружении. Но на рабочем окружении объекта CNF давно не было, но хвосты в реплике его остались, это нужно исправлять.

Что такое lingering object liquidator

Так как у меня в AD уже нет такого объекта, то это остался мусор, который нужно удалять. lingering object liquidator - это устаревшие объекты - это объекты в AD, которые были созданы, реплицированы, удалены и затем собраны сборщиком мусора по крайней мере на контроллере домена, который инициировал удаление, но все еще существует как живые объекты на одном или нескольких контроллерах домена в том же лесу. Длительное удаление объектов традиционно требует длительных сессий очистки с использованием таких инструментов, как LDP или repadmin /removelingeringobjects

• Устаревшие объекты могут привести к долгосрочному расхождению для объектов и атрибутов, находящихся на разных контроллерах домена в лесу Active Directory.
• Наличие устаревших объектов предотвращает репликацию новых созданий, удалений и модификаций конечных контроллеров домена, настроенных для использования строгой согласованности репликации. Эти не реплицированные изменения могут применяться к объектам или атрибутам пользователей, компьютеров, групп, членства в группах или ACLS.
• Объекты, преднамеренно удаленные администраторами или приложением, продолжают существовать в виде живых объектов на контроллерах домена, которым еще не удалось получить сведения о удалении для входящих репликаций.

Устаревшие объекты могут возникать, если контроллер домена не реплицируется в течение интервала времени, превышающего время жизни захоронения (tombstone lifetime-TSL). Затем контроллер домена повторно подключается к топологии репликации. Объекты, которые удаляются из службы каталогов Active Directory, когда контроллер домена отключен, могут оставаться на контроллере домена как устаревшие объекты.

Когда объект удаляется, Active Directory реплицирует удаление как объект-надгробие (tombstone). Объект-надгробие состоит из небольшого подмножества атрибутов удаленного объекта. Путем входящей репликации этого объекта другие контроллеры домена в домене и в лесу получают информацию об удалении. Tombstone хранится в Active Directory в течение определенного периода. Этот указанный период называется TSL. В конце TSL надгробный объект окончательно удаляется.

Значение TSL по умолчанию зависит от версии операционной системы, запущенной на первом контроллере домена, который установлен в лесу. Все, что выше Windows Server 2008 имеет значение 180 дней. Короче хорошего в этом мало и нужно это исправлять, так как эта запись будет теперь болтаться в корзине AD. Для удаления таких устаревших объектов есть две утилиты:

• Repadmin /removelingeringobjects
• Lingering Object Liquidator (LoL)

Если контроллер домена отключен на период, превышающий TSL, один или несколько объектов, удаленных из Active Directory на всех других контроллерах домена, могут остаться на отключенном контроллере домена. Такие объекты называются затяжными объектами (lingering objects). Поскольку контроллер домена находится в автономном режиме в течение времени, когда надгробный объект жив, контроллер домена никогда не получает репликацию tombstone.

Когда этот контроллер домена повторно подключается к топологии репликации, он действует как исходный партнер репликации, у которого есть объект, которого нет у его конечного партнера. Проблемы с репликацией возникают при обновлении объекта на контроллере домена источника. В этом случае, когда целевой партнер пытается выполнить входящую репликацию обновления, конечный контроллер домена отвечает одним из двух способов:

• Если на контроллере домена назначения включена согласованная строгая репликация, контроллер распознает, что он не может обновить объект. Контроллер локально останавливает входящую репликацию раздела каталога с исходного контроллера домена.
• Если на контроллере домена назначения отключена согласованность строгой репликации, контроллер запрашивает полную копию обновленного объекта. В этом случае объект повторно вводится в каталог.

Если еще проще, то вот пример, у вас есть сервер глобального каталога в удаленном офисе в Доминикане, который не был доступен в сети в течение 60-дневного срока службы захоронения. Это может быть связано с техническим обслуживанием, перебоями в работе сети, сбоями оборудования и т.д., которые препятствуют репликации глобального каталога с другими контроллерами домена.

Допустим, у вас есть лес из нескольких доменов, и 100 пользователей были удалены из домена в России, в то время как DC в Доминикане был отключен от сети. Наконец, Доминиканский глобальный каталог возвращается в оперативный режим и начинает репликацию, но, поскольку он не реплицировал удаление тех 100 пользовательских объектов, которые теперь были удалены из Active Directory, он считает, что эти объекты должны быть реплицированы его партнерам. Так что теперь партнеры копируют объекты, и эти 100 учетных записей снова оживают - вроде как. Поскольку глобальный каталог Доминиканы содержит копию домена России, он реплицирует копии этих объектов.

Различные события будут либо указывать на наличие устаревших объектов Active Directory, либо предупреждать о том, что они могут существовать. В просмотре событии службы каталогов может быть зарегистрировано несколько событий.

• Код события 1864 - Это событие будет указывать на наличие затяжных объектов. Обратите внимание, что он содержит подсчет количества DC, которые не реплицировались за день, неделю, месяц, два месяца или время жизни захоронения. Последняя запись важна. К сожалению, событие не сообщит нам имя контроллера домена, который не реплицировался за время существования захоронения.
• Событие 2042 - событие указывает на то, что включена строгая репликация, исходный контроллер домена не реплицировался в в период tombstone и пытается реплицировать, поэтому репликация отключена из источника. Событие предоставляет GUID источника в формате записи DNS CName:982a942e-40e4-4e3c-8609-bae0cfd2affb._msdcs.pyatilistnik.org. Понятное имя контроллера домена можно легко найти, просмотрев записи псевдонимов в зоне _msdcs в оснастке DNS.
• Событие 1388 - Другой контроллер домена (DC) попытался реплицировать этот объект, которого нет в локальной базе данных Active Directory. Возможно, объект был удален и уже был собран сборщиком мусора на этом контроллере домена. Эта система назначения получила обновление для объекта, который должен был присутствовать локально, но не присутствовал.
• Событие 1988 - При репликации доменных служб Active Directory в следующем разделе обнаружены объекты, которые были удалены из базы данных доменных служб Active Directory контроллеров домена (DC). Это событие регистрируется, потому что исходный контроллер домена содержит устаревший объект, которого нет в локальной базе данных Active Directory контроллеров домена.

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

Сначала я покажу встроенную утилиту repadmin. Первым делом вам нужно посмотреть наличие таких объектов, для этого используется ключ /advisory_mode. Конструкция будет выглядеть вот так:

• <lingering_DC_name> - Полное доменное имя или GUID (Отличительное имя) контроллера домена, на котором есть устаревшие объекты, которых нет на других участниках репликации.
• <reference_DC_GUID> - GUID контроллера домена, который содержит актуальную копию базы Active Directory, чаще всего это главный контроллер домена.
• <dir_partition> - отличительное имя раздела каталога, в котором находятся устаревшие объекты. Проще всего указать корень домена.
• /advisory_mode - это необязательный параметр, который выполняет поиск устаревших записей в режиме чтения, БЕЗ УДАЛЕНИЯ. Всегда старайтесь выполнить команду с параметром /advisory_mode, а уже потом без него.

Пример команды:

Чтобы узнать GUID нужного контроллер введите команду:

Параметр /advisory_mode будет регистрировать на контроллере домена у которого есть объекты (Lingering Objects) события с кодом ID 1942. Данное событие укажет количество найденных и оставшихся объектов.

Когда вы обнаружили, что объекты "Lingering Objects" присутствуют, то вам необходимо из команды убрать параметр /advisory_mode. В результате чего устаревшие объекты с данного контроллера домена будут удалены. На контроллере будут события с кодом:

• ID 1937 - указывает, что процесс удаления начался
• ID 1945 - будет описан каждый удаляемый объект
• ID 1939 - указывает, что процесс удаления завершен

Далее вам необходимо то же самое выполнить на других контроллерах домена, где есть устаревшие объекты. Проверяем репликацию.

Разрешить/запретить репликацию с серверами, которых давно не было в сети

Если вы хотите запретить репликацию с контроллерами домена которых давно не было в сети, то для этого есть 2 ключа в реестре. Их необходимо выставить на каждом из контроллеров домена, чтобы между ними проходила репликация. После успешной синхронизации/репликации и (желательно неоднократной) проверки того, что все работает. Откройте редактор реестра Windows и перейдите в раздел:

• Strict Replication Consistency - Отключение строгой согласованности репликации, выставите для отключения значение "0"
• Allow Replication With Divergent and Corrupt Partner - Включает репликацию с испорченными партнерами, если его нет, то создайте его, и выставите значение "1".

После запуска будет разрешена синхронизация между контроллерами домена. Чтобы проверить, что контроллеры синхронизираются, необходимо на одном из них открыть: "Active Directory Sites and Services" - Sites - Default-First-Site-Name - Servers и по очереди открываем КАЖДЫЙ контроллер домена, у него - NTDS Settings, после чего кликаем правой кнопкой по имени контроллера домена (внутри NTDS Settings) и выбираем "Реплицировать конфигурацию на выбранный контроллер домена". Все должно синхронизироваться.

Не забываем потом сменить значения "Strict Replication Consistency" на "1" и "Allow Replication With Divergent and Corrupt Partner" на "0".

Как удалить устаревшие объекты через Lingering Object Liquidator (LoL)

Microsoft имеет отдельную утилиту, которая призвана удалять устаревшие объекты, называется она "Lingering Object Liquidator (LoL)". Скачиваем утилиту по адресу:

Системные требования:

1. 1. У вас должен быть установлен NET 4.5.2 или выше, на том компьютере или сервере, где вы планируете запуск утилиты. Напоминаю вам инструкцию, как узнать текущую версию NetFramework.
   2. У учетной записи от имени которой вы будите запускать утилиту, должны быть права администратора домена, если доменов несколько то лучше воспользоваться правами администратора предприятия.
   3. Система из которой вы будите производить работы, должна иметь доступ на уровне сети и портов ко всем необходимым контроллерам домена. Конкретные порты включают DNS, Kerberos, RPC, LDAP и эфемерный диапазон портов, используемый целевым DC.
   4. Необходимо включить правило брандмауэра для службы "Удаленный вызов процедур (RPC)" на каждом контроллере домена, который будет сканироваться инструментом. В противном случае Lingering Object Liquidator выводит сообщение об ошибке "Исключение: сервер RPC недоступен".
   5. Удаление устаревших объектов в средах AD Lightweight Directory Services (AD LDS/ADAM) не поддерживается.
   6. Удаление устаревших объектов с помощью этого инструмента не поддерживается на контроллерах домена под управлением Windows Server 2003 R2 или более ранних версий (инструмент использует функцию подписки на журнал событий, которая не была добавлена ​​до Windows Server 2008).

Запустите инструмент от имени администратора домена (если вы хотите просканировать весь лес), если вы не запускаете инструмент с повышенными правами, возникает ошибка 8453. В LoL вам нужно выполнить три действия:

• В Naming Context - Выберите в какой части вам необходимо искать устаревшие объекты
• Reference DC - контроллер домена на котором нет объектов для удаления
• Target DC - контроллер домена с которого будет удален устаревший объект

После заполнения данных вам нужно нажать на кнопку "Detect Lingering Objects"

Примечание. Журнал событий службы каталогов может полностью заполниться, если среда содержит большое количество устаревших объектов, а журнал событий служб каталогов использует максимальный размер журнала по умолчанию. Инструмент использует тот же метод обнаружения устаревших объектов, что и repadmin и repldiag, регистрируя одно событие для каждого найденного объекта.

Инструмент использует метод консультативного режима, предоставляемый DRSReplicaVerifyObjects, который используется как repadmin /removelingeringobjects /Advisory_Mode, так и repldiag /removelingeringobjects /advisorymode. В дополнение к обычным событиям, связанным с консультативным режимом, зарегистрированным на каждом контроллере домена, он отображает каждый из устаревших объектов в основной панели содержимого. Если нужно уже удалить объекты. то нажмите соответствующую кнопку "Remove Selected Lingering Objects".

На этом у меня все, мы научились удалять устаревшие SPN, устранять ошибку ID 11 и удалять CNF и RND объекты. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

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

• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731241(v=ws.10)?redirectedfrom=MSDN
• https://social.technet.microsoft.com/wiki/contents/articles/1375.event-id-1311-microsoft-windows-activedirectory-domainservice.aspx
• https://social.technet.microsoft.com/wiki/contents/articles/15435.active-directory-duplicate-object-name-resolution.aspx
• https://blogs.technet.microsoft.com/askds/2014/09/15/remove-lingering-objects-that-cause-ad-replication-error-8606-and-friends/
• https://docs.microsoft.com/ru-ru/archive/blogs/askds/remove-lingering-objects-that-cause-ad-replication-error-8606-and-friends
• https://www.windowstechno.com/how-to-remove-lingering-objects/