The target principal name is incorrect ошибка

При попытке ручной репликации данных между контроллерами домена Active Directory в остатке Active Directory Sites and Services (dssite.msc) появилась ошибка:

The following error occurred during the attempt to synchronize naming context from Domain Controller X to Domain Controller Y.
The target principal name is incorrect.
This operation will not continue.

При проверке репликации с помощью repadmin, у одного из DC появляется ошибка:

(2148074274) The target principal name is incorrect.

В журнале событий DC есть такие ошибки:

Source: Security-Kerberos
Event ID: 4

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server DC2. The target name used was cifs/DC2.winitpro.ru. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (winitpro.ru) is different from the client domain (winiptro.ru), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Event ID 3210:

Failed to authenticate with \DC, a Windows NT domain controller for domain WINITPRO.

Event ID 5722:

The session setup from the computer 1 failed to authenticate. The name of the account referenced in the security database is 2. The following error occurred:

В первую очередь проверьте:

1. Доступность проблемного контроллера домена с помощью простого ICMP ping
2. Проверьте, что на нем доступен порт TCP 445 и опубликованы сетевые папки SysVol и NetLogon;

Если все ОК, значит проблема в том, между контроллерами домена нарушен безопасный канал передачи данных. Проверьте его с помощью PowerShell команды:

Test-ComputerSecureChannel -Verbose

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

Чтобы исправить проблему, нужно сбросить этот пароль. Сначала нужно найти текущий контроллер домена с FSMO ролью PDC.

netdom query fsmo |find "PDC"

В нашем примере PDC находится на MSK-DC02. Мы будем исопользовать это имя в команде
netdom resetpwd
далее.

Остановите службу Kerberos Key Distribution Center (KDC) на контроллере домена, на котором появляется ошибка “The target principal name is incorrect” и измените тип запуска на Disabled. Можно изменить настройки службы из консоли services.msc или с помощью PowerShell:

Get-Service kdc -ComputerName msk-dc03 | Set-Service –startuptype disabled –passthru

Перезагрузите этот контроллер домена.

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

netdom resetpwd /server:msk-dc02 /userd:winitproadministrator /passwordd:*

Укажите пароль администратора домена.

Перезагрузите проблемный DC и запустите службу KDC. Попробуйте запустить репликацию и проверить ошибки.

repadmin /syncall
repadmin /replsum
repadmin /showrepl

Если репликация успешно выполнена, в журнале Directory Service Event Viewerа должно появится событие Event ID 1394:

All Problems preventing updates to the Active Directory Domain Services database have been cleared. New Updates to the Active Directory Domain Services database are succeeding. The Net Logon service has restarted

Проверьте состояние вашего домена и контроллеров домена Active Directory согласно этого гайда.

Обновлено 03.05.2022

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз я вам показал .как вы можете легко взаимодействовать с файлами папками с помощью утилиты robocopy, я показал как делать резервные копии и многое другое. В сегодняшней статье я покажу, как устраняется ошибка в репликации контроллеров домена Active Directory, ошибка звучит вот так (2148074274) The target principal name is incorrect. Давайте смотреть в чем дело.

🛑Описание ошибки 2148074274

Проверяя на одном из контроллеров домена репликацию через утилиту repadmin, я обнаружил, что от одного из участников стала появляться ошибка:

Оказалось, что перестал корректно работать безопасный режим между этим неисправным контроллером домена и основным контроллером домена. Как советует Microsoft, его нужно сбросить.

🛠Как исправить ошибку The target principal name is incorrect

Идем на неисправный контроллер домена и отключаем службу центра распространения ключей Kerberos (Kerberos Key Distribution Center service — KDC). Вызовите окно «Выполнить» и введите в нем:

Найдите там службу «Центр распространения ключей Kerberos (Kerberos Key Distribution Center service — KDC)«, зайдите в ее свойства, остановите ее и выставите тип запуска «Вручную«. После этого перезагрузите сервер.

После загрузки в командной строке выполните:

Первой командой мы выясняем, кто у нас сервер PDC, далее мы будим к нему обращаться в команде по сбросу безопасного канала в параметре /server. В /userd указываем учетную запись имеющую права администратора в данном домене.

После сброса безопасного канала перезапустите контроллер домена. Даже если вы попытайтесь сбросить защищенный канал с помощью утилиты Netdom, и команда не будет успешно завершена, приступите к процессу перезапуска. После завершения перезапуска компьютеров запустите оснастку «Services», перезапустите службу KDC и повторите попытку репликации, не забудьте ей выставить тип запуска «Автоматический«.

Далее проверьте репликацию между контроллерами.

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

https://docs.microsoft.com/ru-RU/troubleshoot/windows-server/identity/target-principal-name-is-incorrect-when-replicating-data

На этом у меня все. Мы с вами устранили ошибку репликации (2148074274) The target principal name is incorrect. С вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

The SSPI context error definitely indicates authentication is being attempted using Kerberos.

Since Kerberos authentication SQL Server’s Windows Authentication relies on Active Directory, which requires a trusted relationship between your computer and your network domain controller, you should start by validating that relationship.

You can quickly check that relationship, thru the following Powershell command Test-ComputerSecureChannel.

Test-ComputerSecureChannel -Verbose

If it returns False, you must repair your computer Active Directory secure channel, since without it no domain credencials validation is possible outside your computer.

You can repair your Computer Secure Channel, thru the following Powershell command:

Test-ComputerSecureChannel -Repair -Verbose

If the above doesn’t work (because your domain credentials don’t work because the machine isn’t trusted) you can use NETDOM RESET instead from an elevated cmd.exe (not PowerShell) prompt:

NETDOM RESET %COMPUTERNAME% /UserO:domainAdminUserName /Password0:* /SecurePasswordPrompt

_{(Yes, the command-line arguments really do have an O (Capital-«Oh», not zero 0). The /Password0:* /SecurePasswordPrompt option will use a credential popup instead of having you put your password directly in the command-line, which you must never do).}

Check the security event logs, if you are using kerberos you should see logon attempts with authentication package: Kerberos.

The NTLM authentication may be failing and so a kerberos authentication attempt is being made. You might also see an NTLM logon attempt failure in your security event log?

You can turn on kerberos event logging in dev to try to debug why the kerberos is failing, although it is very verbose.

Microsoft’s Kerberos Configuration Manager for SQL Server may help you quickly diagnose and fix this issue.

Here is a good story to read: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/

The History

I had a client today that reported the CEO’s computer enabled to login against Active Directory; it had the message ‘Trust Relationship was lost’. In this kind of issues, the solution is just to
take out the computer from the domain and re-join it. After removing the server from the AD, I was unable to join it again, because of error: «Logon failure: the target account name is incorrect.» After checking the replication in the domain controllers, I
figure out this: 

The CHENSDC2 and CHENSDC had 54 days without talking to each other. IPV6 was disabled on the servers And checking replication of Active Directory:

The Repadmin gives an error «The Target Principal Name is incorrect,» so replication from «CHENSDC2» to «CHENSDC» works, but from «CHENSDC» to «CHENSDC2», doesn’t. I tried several solutions to do
this job but none of those worked, so I’ll try to be as clean as I can be in the solution.

The Solution

To fix this issue, you just need to go to do the following:

A. Determine the Primary Domain Controller (PDC) by doing this steps:

1. Windows key + R (at the same time)
2. Write cmd and then press Enter. Console windows will open.
3. Netdom query fsmo

The output will be something like this, and determine the server that has the PDC role:

So our PDC is called CHENSDC2 in this example, and the problematic domain controller will be CHENSDC

B. Stop Kerberos Key Distribution Center (KDC) service in CHENSDC (problematic server):

1. Open the console (cmd) as the previous step, if you don’t have it
2. Use the command Net stop KDC

Pre step Download WS2003 Resource kit in the link:
https://www.microsoft.com/en-us/download/details.aspx?id=17657″ then install it. I did it in windows server 2008 R2 with nothing but a warning about versions, just ignore it and install the software.

C. Purge Kerberos keys in the CHENDC (problematic server)

1. Navigate to: C:Program Files (x86)Windows Resource KitsTools and run «kerbtray.exe»

   

   You will get a Green bar Next to the time, like this

   

2. Now just right click the green bar and select «Purge tickets.»

   

   After this, the server will be aware of the synchronization KDC from the PDC.

4. Reset the Computer’s Password in the Primary Domain Controller (PDC)

1. In the PDC computer, we got this computer in step A. Open the console (cmd) as the previous step, if you don’t have it
2. netdom resetpwd /server:serverName /userd:DomainNameAdministrator /passwordd:AdminPassword

5. Start the service in the CHENSDC (problematic server)

1. Finally, in the PDC computer, we got this computer in step A. Open the console (cmd) as the previous step, if you don’t have it
2. Then run the command: net start kdc

6. Start IPV6 on both servers

1. IPv6 is used by servers to communicate to each other, so enabled it and run «ipconfig /registerdns» so they can talk to each other, especially in the consoles for Active directory

Sidenote: This is basically to improve communication between domain controllers especially for the consoles of AD (AD sites and services, AD Users and Computers, etc.)

7. Check replication again

1. run repadmin /replsum
2. repadmin /showrepl
3. repadmin /showreps

And make sure that all is working good again.