Security kerberos ошибка 4

 Success! It appears the error in my last message was (obviously) the place to look for a solution. A quick Google search brought me to this page Opens a new window in which a similar problem is described. The accepted answers for this problem list a few sites that may hold the answer. In the end, it was this one Opens a new window that brought me to a solution.

In the event that the linked pages disappear, I will provide a quick rundown of what happened and what steps I took to resolve the issue. All of the unnecessary and ultimately worthless «fixes» I attempted will not be mentioned in this review.

As stated, the issue began when a user arrived in IT complaining about a missing home folder drive. In trying to investigate the issue while a help desk tech visited the affected machine, I discovered that I could not access \\domain.com which is the beginning of the home folder location (\\domain.com\folder\folder\home). After several failed attempts to fix the issue, I discovered the error mentioned in my previous post. As mentioned, the second linked page in this reply brought me to a website where a similar problem was being discussed. The owner of that blog mentioned using a third-party tool called ADFind to query his AD environment for the SPN in the error. When that search yielded no results, he tried the «catch-all» SPN by adjusting the command to read (in my case):

adfind -f "servicePrincipalName=HOST/domain.com" -gcb

For me, this returned a value for a recently-added Federation Services service account. I had been attempting to build an ADFS server to prepare my environment for our soon-to-be move to O365. Since the first attempt at configuring the ADFS server failed, the ADFS service account could be deleted without issue. Deleting this AD account made the \\domain.com location immediately available.

Thank you to both of the respondents to this thread.

При попытке ручной репликации данных между контроллерами домена 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:winitpro\administrator /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 согласно этого гайда.

I have two new Domain Controllers on new Forest. Servers have DFS and IIS services installed. Everything seemed to go Ok for a While. After updating servers I got new errors. Now once in hour aditional Domain controller IIS2 is making these errors to event log:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the
server iis2$. The target name used was
E3514235-4B06-11D1-AB04-00C04FC2DCD2/d170f7fc-6f05-4ea5-9dee-a657e3de019b/example.com@example.com.
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 (example.com) is different from the
client domain (example.com), check if there are identically named
server accounts in these two domains, or use the fully-qualified name
to identify the server.

What does this really mean? What should I do to fix this problem? How to start…

Those server are new ones, I even tryed to reinstall servers with same roles. Every time same kind of kerberos erros occurs. Previous time it was somemethin to di with Ldap, and now this…

Some Background:

OS:Win Server 2012 R2 on both machines

These error messages started occurring after and attempted an installation of a new backup domain controller. There were replications issues between the PDC and the newly installed DC from the beginning (likely due to incorrect configuration during the install).
I ended up performing a forced demotion of the backup DC (DC2), and metadata cleanup on both machines. Again, I installed and promoted the new backup machine to a DC to no avail. Currently all master roles belong to DC1. AD changes made on DC1 are replicated
to DC2, i.e., PW changes. The issue seems to be with DC2 establishing a secure channel with DC1, not the other way around. 

Event ID 4:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server servermain$. The target name used was E3514235-4B06-11D1-AB04-00C04FC2DCD2/68c402df-a3a0-4a41-8454-0210e86148e8/gps.com@gps.com. 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 (GPS.COM) is different from the client domain (GPS.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

In this case I diabled the KDC service on DC2 as well cleared out its kerberos tickets. I then performed a PW reset on DC1 using the netdom utility for the administrator account, which went through. Restarted KDC service, power cycled DC2, and the problem was
not corrected. 

Some Notes:

— Within AD sites and services (on DC1), I try replicating from DC2 and get the message, «The following occured…The target principal name is incorrect.» The same happens when I try to replicate DC2 to DC1. 

— There also appears to be some DNS issues. After checking sites and services, DC1 has NTDS and DNS setting listed underneath it, DC2 only has NTDS setting, not sure if this is standard behavior or not. 

— Just to clarify, end-user machines are able to resolve DNS fine, but on DC1 when trying to resolve either a local FQDN or even an outside FQDN, like google.com, I get this error:

google.com

C:UsersAdministrator>nslookup google.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  ::1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Resolve the name of DC2

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:UsersAdministrator>nslookup GPSDC2
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
Server:  UnKnown
Address:  ::1

DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Running these same lookups from end-user host machines on the domain or on DC2 work.

And then there’s error 1925, which I’m guessing is related to the kerberos authentication issue:

     
The attempt to establish a replication link for the following writable directory partition failed. 

Directory partition: 
DC=gps,DC=com 
Source directory service: 
CN=NTDS Settings,CN=GPSDC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gps,DC=com 
Source directory service address: 
68c402df-a3a0-4a41-8454-0210e86148e8._msdcs.gps.com 
Intersite transport (if any): 

This directory service will be unable to replicate with the source directory service until this problem is corrected. 

User Action 
Verify if the source directory service is accessible or network connectivity is available. 

Additional Data 
Error value: 
2148074274 The target principal name is incorrect.

At this point I’ve read most support articles related to these error codes and haven’t found anything that quite addresses the issues I’m experienceing, or at least the solutions tried didn’t work. I welcome any suggestions advice, and will post any log info
that you think will be helpful in solving this issue. Thank you for your time in looking over my notes.

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server

The article helps you to resolve the issue that the kerberos client received a KRB_AP_ERR_MODIFIED error from the server.

Applies to: В Windows Server 2003
Original KB number: В 558115

Symptoms

During access to NLB virtual IP/NLB Virtual Name, the user may prompt to a username and password, and the following error may add to the local system event log:

«The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/myserver.domain.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domain.com), and the client realm. Please contact your system administrator.»

Cause

During access to the IIS 6 web site that support Windows Integrated Authentication, the following issues may occur:

1. Mismatch DNS name resolution. The issue is common in an NLB environment that uses multiple IPs or network adapters.
2. The user doesn’t have a Local NTFS access permission.
3. The Web Site is using Application Pool with a poor permission setting.

Resolution

To resolve the error issue, consider to implement the following tests:

Verify that the IIS has been set up with correct NTFS settings.

Integrated Windows Authentication (IIS 6.0)

Verify that each cluster node has been set up with correct DNS settings.

Verify that the node has been set up with correct Application Pool settings:

Configuring Application Pool Identity with IIS 6.0 (IIS 6.0)

Verify that internet explorer has been set up with a correct security setting.

More information

Authentication and Access Control Diagnostics 1.0 (x86)

Internet Information Services Diagnostic Tools

Community Solutions Content Disclaimer

Microsoft corporation and/or its respective suppliers make no representations about the suitability, reliability, or accuracy of the information and related graphics contained herein. All such information and related graphics are provided «as is» without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information and related graphics, including all implied warranties and conditions of merchantability, fitness for a particular purpose, workmanlike effort, title and non-infringement. You specifically agree that in no event shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental, special, consequential damages or any damages whatsoever including, without limitation, damages for loss of use, data or profits, arising out of or in any way connected with the use of or inability to use the information and related graphics contained herein, whether based on contract, tort, negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has been advised of the possibility of damages.

Источник

Клиент kerberos получил KRB_AP_ERR_MODIFIED ошибку с сервера.

Эта статья поможет устранить проблему, из-за которую клиент Kerberos KRB_AP_ERR_MODIFIED ошибку с сервера.

Применяется к: Windows Server 2003
Исходный номер базы знаний: 558115

Симптомы

Во время доступа к виртуальному IP-адресу или виртуальному имени сетевой подсистемы балансировки сетевой нагрузки пользователь может ввести имя пользователя и пароль, а в журнал событий локальной системы может быть добавлена следующую ошибку:

Идентификатор события: 4
Источник: Kerberos
Тип: Ошибка

«Клиент kerberos получил KRB_AP_ERR_MODIFIED с узла сервера/myserver.domain.com. Это означает, что пароль, используемый для шифрования билета службы Kerberos, отличается от пароля на целевом сервере. Как правило, это связано с одинаковыми именованными учетными записями компьютеров в целевой области (domain.com) и клиентской области. Обратитесь к системному администратору».

Причина

Во время доступа к веб-сайту IIS 6, который поддерживает встроенную проверку подлинности Windows, могут возникнуть следующие проблемы:

1. Несоответствие разрешения DNS-имен. Эта проблема распространена в среде балансировки сетевой подсистемы балансировки нагрузки, использующей несколько IP-адресов или сетевых адаптеров.
2. У пользователя нет разрешения на локальный доступ NTFS.
3. Веб-сайт использует пул приложений с неудовлетворительной настройкой разрешений.

Решение

Чтобы устранить ошибку, рассмотрите возможность реализации следующих тестов:

Убедитесь, что службы IIS настроены с правильными параметрами NTFS.

Встроенная проверка подлинности Windows (IIS 6.0)

Убедитесь, что для каждого узла кластера настроены правильные параметры DNS.

Убедитесь, что узел настроен с правильными параметрами пула приложений:

Настройка удостоверения пула приложений с помощью IIS 6.0 (IIS 6.0)

Убедитесь, что в Internet Explorer настроен правильный параметр безопасности.

Дополнительные сведения

Проверка подлинности и контроль доступа диагностики 1.0 (x86)

Средства диагностики служб Internet Information Services

Отказ от ответственности за содержимое общедоступных решений

Корпорация Майкрософт и/или ее поставщики не делают никаких заявлений относительно пригодности, надежности или точности сведений и соответствующих изображений, приведенных в настоящем документе. Все эти сведения и соответствующие изображения предоставлены «как есть» без каких-либо гарантий. Корпорация Майкрософт и/или ее поставщики настоящим отказываются от каких-либо гарантийных обязательств и условий в отношении этих сведений и соответствующих изображений, включая все подразумеваемые гарантии и условия товарной пригодности, применимости для конкретных целей, качества исполнения, прав собственности и отсутствия нарушений прав интеллектуальной собственности. В частности, вы подтверждаете свое согласие с тем, что корпорация Майкрософт и/или ее поставщики ни при каких обстоятельствах не несут ответственности за прямой или косвенный ущерб, штрафные санкции, случайные, фактические, косвенные или иные убытки, включая, в частности, убытки от утраты эксплуатационных качеств, от потери данных или прибылей в связи с использованием или невозможностью использовать эти сведения и соответствующие изображения, содержащиеся в настоящем документе, возникшие вследствие соглашения, гражданского правонарушения, халатности, объективной ответственности или иным образом, даже если корпорация Майкрософт или ее поставщики заранее были извещены о возможности такого ущерба.

Источник

Kerberos – KRB_AP_ERR_MODIFIED is not always an SPN problem

TLDR: This can also be caused by a mismatch in security policy “Network Security: Configure encryption types allowed for Kerberos“.

Consider the following scenario:

• You have a web site set up to use Kerberos authentication. It doesn’t matter what kind of site, but we’ll say it’s a SharePoint site, since that’s the theme around here.
• The site is at https://teams.contoso.com and its application pool is running as service account CONTOSOSP_WEB_APP_SVC.
• Kernel Mode authentication is not enabled in IIS Manager.

• Note: It’s possible that some users could have this “access denied” behavior, while others have no trouble accessing the site.

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SP_WEB_APP_SVC. The target name used was HTTP/teams.contoso.com. 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 (CONTOSO.COM) is different from the client domain (CONTOSO.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Most commonly, the “KRB_AP_ERR_MODIFIED” error means that you have a Service Principal Name (SPN) issue, specifically, the SPN has been added to the wrong account. You should check those things first.

In our scenario above, we know that the application pool is running as a domain account and Kernel Mode authentication is disabled, which is the typical configuration for a SharePoint web app. In that case, we need an HTTP SPN set for the site host name, and set on the account running the application pool.

We can use SETSPN -l (that’s a lower case L) to see which SPNs have been set on our service account:

Command: setspn -l CONTOSOSP_WEB_APP_SVC

Registered ServicePrincipalNames for CN=SP_WEB_APP_SVC,OU=Service Accounts,DC=contoso,DC=com:

You an also do it the opposite way, where you search for a given SPN to see which account it’s set on. For that you use SETSPN -q

Command: setspn -q HTTP/teams.contoso.com

And you can use SETSPN -x to check if there are any duplicate SPNs, meaning the same SPN set on more than one account. That situation will also cause Kerberos to fail, so if it finds any duplicates, you should probably take care of those.

That all looks good, now what?

Lets say you look through all of this, and it all checks out:

• The application pool is running as the account you expect (CONTOSOSP_WEB_APP_SVC)
• Kernel Mode Authentication is disabled.
• The SPN is in the correct format (HTTP/teams.contoso.com)
• The SPN is set on the application pool account, and only that account.

Now that we’ve gone through the most common reasons for “KRB_AP_ERR_MODIFIED”, we’ll get to a lesser-known problem, which is what spawned this blog post.

All “KRB_AP_ERR_MODIFIED” means is that the encryption key used to encrypt the Kerberos ticket is not the same as the key that the server is trying to use to decrypt it. This can happen if the encryption algorithm is different between client and server, which can be controlled by a Windows security policy called “Network Security: Configure encryption types allowed for Kerberos“. If this setting is configured differently between the client machine and the web server, the result can be a mismatch in encryption types, a failure to decrypt the Kerberos ticket, and the “KRB_AP_ERR_MODIFIED” error, resulting in Access Denied.

You can check this by looking at the Local Security Policy on both client and server.

SecPol.msc > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos

Example:

Lets say that on the problem client machine, the policy is undefined, which would allow the user to get a Kerberos ticket encrypted with the “RC4_HMAC_MD5” algorithm.

However, on the web server side, the “Configure encryption types allowed for Kerberos” policy is defined, and is set to only allow these three:

– Future encryption types

Because the encryption type used by the client machine is not included in the “allowed” list on the server, the server is unable to decrypt the Kerberos ticket, and authentication fails with “KRB_AP_ERR_MODIFIED”.

Resolution:

Use Group Policy to define the same settings for “Network Security: Configure encryption types allowed for Kerberos” and make sure it’s applied consistently to both servers and client machines.

Other Tips:

If you’re wondering which encryption type was used to encrypt a Kerberos ticket, you can run the command “klist” on the client. It will display all of the Kerberos tickets currently assigned to the user. You’re looking for the one that matches the SPN you’re using for the site.

Command: klist

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-9

Ticket Flags 0x40a10000 -> forwardable renewable…

Источник

Kerberos error krb ap err modified

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

since one night i receive the following error message on all member Server in a branch office for a special subent.
Other Member server i a different subnet are not getting these errors. Before those member servers (new setup)
worked fine for about 2-3 Month:

Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 09.10.2013 02:47:27
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: server
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc01$.
The target name used was cifs/dc01.local. 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. Please ensure that the target SPN
is registered on, and only registered on, the account used by the server. This error can also happen when the target
ervice is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC)
has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password.
If the server name is not fully qualified, and the target domain (domain.local) is different from the client domain (domain.local),
check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

These servers have no routing to the local Domain Controllers, instead they contact the DCs at the main office. So the
KRB_AP_ERR_MODIFIED error is coming from both DCs at the main office, not specific to one pc.

Effects that i have:
— no logon with RDP possible (wrong username or password)
— Service which Relay on Kerberos Auth have Problems

So when i reboot the server in most cases its working again for some time. I also find out, when deleting the cached
Kerberos Tickets with kerbtray its working.

Any ideas what could cause the problem. As mentioned, it happend for all member servers in this subnet starting in the
same night. As always, nothing was changed 😉

Источник

При попытке ручной репликации данных между контроллерами домена 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 согласно этого гайда.