title | description | ms.date | author | ms.author | manager | audience | ms.topic | ms.prod | localization_priority | ms.reviewer | ms.custom | ms.technology |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Troubleshoot AD replication error -2146893022 |
This article describes how to troubleshoot a problem in which Active Directory replication fails and generates an error (-2146893022). |
04/28/2023 |
Deland-Han |
delhan |
dcscontentpm |
itpro |
troubleshooting |
windows-server |
medium |
kaushika |
sap:active-directory-replication, csstroubleshoot |
windows-server-active-directory |
Active Directory replication error -2146893022: The target principal name is incorrect
This article describes how to troubleshoot a problem in which Active Directory replication fails and generates an error (-2146893022: The target principal name is incorrect).
Applies to: Windows Server 2012 R2
Original KB number: 2090913
[!NOTE]
Home users: This article is only intended for technical support agents and IT professionals. If you’re looking for help with a problem, please ask the Microsoft Community.
Summary
This error occurs when the source domain controller doesn’t decrypt the service ticket provided by the destination (target) domain controller.
Top cause
The destination domain controller receives a service ticket from a Kerberos Key Distribution Center (KDC). And the KDC has an old version of the password for the source domain controller.
Top resolution
-
Stop the KDC service on the destination domain controller. To do it, run the following command at a command prompt:
-
Start replication on the destination domain controller from the source domain controller. Use AD Sites and Services or
Repadmin
.Using
repadmin
:Repadmin /replicate destinationDC sourceDC DN_of_Domain_NC
For example, if replication is failing on
ContosoDC2.contoso.com
, run the following command onContosoDC1.contoso.com
:Repadmin /replicate ContosoDC2.contoso.com ContosoDC1.contoso.com "DC=contoso,DC=com"
-
Start the Kerberos KDC service on the destination domain controller by running the following command:
If it doesn’t resolve the issue, see the Resolution section for an alternative solution in which you use the netdom resetpwd
command to reset the computer account password of the source domain controller. If these steps don’t resolve the problem, review the rest of this article.
Symptoms
When this problem occurs, you experience one or more of the following symptoms:
-
DCDIAG reports that the Active Directory replications test has failed and returned error -2146893022: The target principal name is incorrect.
[Replications Check,<DC Name>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The replication generated an error (-2146893022):
The target principal name is incorrect.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
<X> failures have occurred since the last success. -
Repadmin.exe reports that a replication attempt failed, and reports a status of -2146893022 (0x80090322).
Repadmin
commands that commonly indicate the -2146893022 (0x80090322) status include but aren’t limited to the following ones:-
DMIN /REPLSUMREPA
-
REPADMIN /SHOWREPL
-
REPADMIN /SHOWREPL
-
REPADMIN /SYNCALL
Sample output from
REPADMIN /SHOWREPS
andREPADMIN /SYNCALL
that indicate the target principal name is incorrect error is as follows:c:> repadmin /showreps <site name><destination DC> DC Options: IS_GC Site Options: (none) DC object GUID: <NTDS settings object object GUID> DChttp://bemis/13/Pages/2090913_en-US.aspx invocationID: <invocation ID string> ==== INBOUND NEIGHBORS ====================================== DC=<DN path for directory partition> <site name><source DC via RPC DC object GUID: <source DCs ntds settings object object guid> Last attempt @ <date> <time> failed, result -2146893022 (0x80090322): The target principal name is incorrect. <X #> consecutive failure(s). Last success @ <date> <time>. c:> repadmin /syncall /Ade Syncing all NC's held on localhost. Syncing partition: DC=<Directory DN path> CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=<server name>,CN=Servers,CN=<site name>,CN=Sites,CN=Configuration,DC=<forest root domain> (network error): -2146893022 (0x80090322):
-
-
The replicate now command in Active Directory Sites and Services returns the following error message:
The target principal name is incorrectRight-clicking on the connection object from a source DC and then selecting replicate now fails. The on-screen error message is as follows:
Dialog title text: Replicate Now
Dialog message text: The following error occurred during the attempt to contact the domain controller <source DC name>:
The target principal name is incorrect
Buttons in Dialog: OK -
NTDS Knowledge Consistency Checker (KCC), NTDS General, or Microsoft-Windows-ActiveDirectory_DomainService events that have the -2146893022 status are logged in the directory service event log.
Active Directory events that commonly cite the -2146893022 status include but aren’t limited to the following ones:
Event Source Event ID Event String NTDS Replication 1586 The Windows NT 4.0 or earlier replication checkpoint with the PDC emulator master was unsuccessful. A full synchronization of the security accounts manager (SAM) database to domain controllers running Windows NT 4.0 and earlier might take place if the PDC emulator master role is transferred to the local domain controller before the next successful checkpoint.
NTDS KCC 1925 The attempt to establish a replication link for the following writable directory partition failed. NTDS KCC 1308 The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with the following domain controller has consistently failed. Microsoft-Windows-ActiveDirectory_DomainService 1926 The attempt to establish a replication link to a read-only directory partition with the following parameters failed NTDS Inter-site Messaging 1373 The Intersite Messaging service could not receive any messages for the following service through the following transport. The query for messages failed.
Cause
The -21468930220x80090322SEC_E_WRONG_PRINCIPAL error code isn’t an Active Directory error. It may be returned by the following lower layer components for different root causes:
- RPC
- Kerberos
- SSL
- LSA
- NTLM
Kerberos errors that are mapped by Windows code to -21468930220x80090322SEC_E_WRONG_PRINCIPAL include:
- KRB_AP_ERR_MODIFIED (0x29/41 decimal/KRB_APP_ERR_MODIFIED)
- KRB_AP_ERR_BADMATCH (0x24h/36 decimal/«Ticket and authenticator don’t match»)
- KRB_AP_ERR_NOT_US (0x23h/35 decimal/«The ticket isn’t for us»)
Some specific root causes for -21468930220x80090322SEC_E_WRONG_PRINCIPAL include:
-
A bad name-to-IP mapping in DNS, WINS, HOST, or LMHOST file. It caused the destination domain controller to connect to the wrong source domain controller in a different Kerberos realm.
-
The KDC and source domain controller have different versions of the source domain controller’s computer account password. So the Kerberos target computer (source domain controller) couldn’t decrypt Kerberos authentication data sent by the Kerberos client (destination domain controller).
-
The KDC couldn’t find a domain to look for the source domain controller’s SPN.
-
Authentication data in Kerberos encrypted frames were modified by hardware (including network devices), software, or an attacker.
Resolution
-
Run
dcdiag /test:checksecurityerror
on the source DCSPNs may be missing, invalid, or duplicated due to simple replication latency, especially following promotion, or replication failures.
Duplicate SPNs may cause bad SPN to name mappings.
DCDIAG /TEST:CheckSecurityError
can check for missing or duplicate SPNs and other errors.Run this command on the console of all source domain controllers that fail outbound replication with the SEC_E_WRONG_PRINCIPAL error.
You can check SPN registration against a specific location by using the following syntax:
dcdiag /test:checksecurityerror replsource:<remote dc>
-
Verify that Kerberos encrypted network traffic reached the intended Kerberos target (name-to-IP mapping)
Consider the following scenario:
-
Inbound replicating Active Directory destination domain controllers search their local copy of the directory for the objectGUID of the source domain controllers NTDS Settings objects.
-
The domain controllers query the active DNS server for a matching DC GUIDED CNAME record. Then it’s mapped to a host A/AAAA record that contains the source domain controller’s IP address.
In this scenario, Active Directory runs a name resolution fallback. It includes queries for fully qualified computer names in DNS or single-label host names in WINS.
[!NOTE]
DNS Servers can also perform WINS lookups in fallback scenarios.
-
The following situations can all cause a destination domain controller to submit Kerberos-encrypted traffic to the wrong Kerberos target:
- Stale NTDS Settings objects
- Bad name-to-IP mappings in DNS and WINS host records
- Stale entries in HOST files
To check for this condition, either take a network trace or manually verify that name DNS/NetBIOS name queries resolve to the intended target computer.
Method 1: Network trace method (as parsed by Network Monitor 3.3.1641 by having full default parsers enabled)
The following table shows a synopsis of network traffic that occurs when destination DC1 inbound replicates the Active Directory directory from source DC2.
F# | SRC | DEST | Protocol | Frame | Comment |
---|---|---|---|---|---|
1 | DC1 | DC2 | MSRPC | MSRPC:c/o Request: unknown Call=0x5 Opnum=0x3 Context=0x1 Hint=0x90 | Dest DC RPC call to EPM on source DC over 135 |
2 | DC2 | DC1 | MSRPC | MSRPC:c/o Response: unknown Call=0x5 Context=0x1 Hint=0xF4 Cancels=0x0 | EPM response to RPC caller |
3 | DC1 | DC2 | MSRPC | MSRPC:c/o Bind: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 | RPC bind request to E351… service UUID |
4 | DC2 | DC1 | MSRPC | MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0x9E62 Xmit=0x16D0 Recv=0x16D0 | RPC Bind response |
5 | DC1 | KDC | KerberosV5 | KerberosV5:TGS Request Realm: CONTOSO.COM Sname : E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso.com |
TGS request for replication SPN of source DC. This operation will not appear on the wire of destination DC uses self as KDC. |
6 | KDC | DC1 | KerberosV5 | KerberosV5:TGS Response Cname: CONTOSO-DC1$ | TGS response to destination DC contoso-dc1. This operation will not appear on the wire of destination DC uses self as KDC. |
7 | DC1 | DC2 | MSRPC | MSRPC:c/o Alter Cont: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2 |
AP request |
8 | DC2 | DC1 | MSRPC | MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x9E62 Xmit=0x16D0 Recv=0x16D0 |
AP response. |
Drilldown on Frame 7 | Drilldown on Frame 8 | Comments |
---|---|---|
MSRPC MSRPC:c/o Alter Cont: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2 |
MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0xC3EA43 Xmit=0x16D0 Recv=0x16D0 |
DC1 connects to AD Replication Service on DC2 over the port returned by the EPM on DC2. |
Ipv4: Src = x.x.x.245, Dest = x.x.x.35, Next Protocol = TCP, Packet ID =, Total IP Length = 0 | Ipv4: Src = x.x.x.35, Dest = x.x.x.245, Next Protocol = TCP, Packet ID = 31546, Total IP Length = 278 | Verify that AD replication source DC (referred to as the Dest computer in the first column and Src computer in column 2 owns the IP address cited in the trace. It’s x.x.x.35 in this example. |
Ticket: Realm: CONTOSO.COM , Sname : E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso.com |
ErrorCode: KRB_AP_ERR_MODIFIED (41)
Realm: <verify that realm returned by the source DC matches the Kerberos realm intended by the destination DC>. |
In column 1, note the realm of the target Kerberos realm as contoso.com followed by the source domain controllers Replication SPN (Sname ) which consists of the Active Directory replication service UUID (E351…) concatenated with object GUID of the source domain controllers NTDS Settings object.
The GUIDED value 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2 to the right of the E351… replication service UUID is the Object GUID for the source domain controllers NTDS settings object. It’s currently defined in the destination domain controllers copy of Active Directory. Verify that this object GUID matches the value in the DSA Object GUID field when A
In the reply shown in column 2, focus on the Bad name-to-IP mappings could cause the destination DC to connect to a DC in an invalid target realm causing the Realm value to be invalid as shown in this case. Bad host-to-IP mappings could cause DC1 to connect to DC3 in the same domain. It would still generate KRB_AP_ERR_MODIFIED, but the realm name in frame 8 would match the realm in frame 7. |
Method 2: Name-to-IP mapping verification (without using a network trace)
From the console of the Source domain controller:
Command | Comment |
---|---|
`IPCONFIG /ALL | MORE` |
`REPADMIN /SHOWREPS | MORE` |
From the Console of the destination DC:
Command | Comment |
---|---|
`IPCONFIG /ALL | MORE` |
`REPADMIN /SHOWREPS | MORE` |
IPCONFIG /FLUSHDNS |
Clear the DNS Client cache |
Start > Run > Notepad %systemroot%system32driversetchosts |
Check for host-to-IP mappings referencing the source domain controllers single label or fully qualified DNS name. Remove if present. Save changes to HOST file.
Run |
NSLOOKUP -type=CNAME <object guid of source DCs NTDS Settings object>._msdcs.<forest root DNS name> <primary DNS Server IP>
Repeat for each additional DNS Server IP configured on the destination DC. example: |
Verify that IP returned matches the IP address of target DC listed above recorded from the console of the source DC.
Repeat for all DNS Servers IPs configured on destination DC. |
nslookup -type=A+AAAA <FQDN of source DC> <DNS Server IP> |
Check for duplicate host A records on all DNS Server IPs configured on the destination DC. |
nbtstat -A <IP address of DNS Server IP returned by nslookup> |
Should return name of the source DC. |
[!NOTE]
A replication request that’s directed to a non-domain controller (because of a bad name-to-IP mapping) or a domain controller that doesn’t currently have the E351… service UUID registered with the endpoint mapper returns error 1753: There are no more endpoints available with the endpoint mapper.
The Kerberos target can’t decrypt Kerberos authenticated data because of a password mismatch.
This issue can occur if the password for the source domain controller differs between the KDC and source domain controller’s copy of the Active Directory directory. The destination domain controller’s copy of the source domain controller computer account password may be stale if it’s not using itself as the KDC.
Replication failures can prevent domain controllers from having a current password value for domain controllers in a given domain.
Every domain controller runs the KDC service for their domain realm. For same realm transactions, a destination domain controller favors getting Kerberos tickets from itself. However, it may get a ticket from a remote domain controller. Referrals are used to get Kerberos tickets from other realms.
The NLTEST /DSGETDC:<DNS domain of target domain> /kdc
command that’s run at an elevated command prompt in close time proximity to a SEC_E_WRONG_PRINCIPAL error can be used to quickly identify which KDC a Kerberos client is targeting.
The definitive way to determine which domain controller a Kerberos client got a ticket from is to take a network trace. The lack of Kerberos traffic in a network trace may indicate:
- The Kerberos client has already acquired tickets.
- It’s getting tickets off-the-wire from itself.
- Your network trace application isn’t correctly parsing Kerberos traffic.
Kerberos tickets for the logged-on user account can be purged at an elevated command prompt by using the KLIST purge
command.
Kerberos tickets for the system account that are used by Active Directory replication can be purged without a restart by using KLIST -li 0x3e7 purge
.
Domain controllers can be made to use other domain controllers by stopping the KDC service on a local or remote domain controller.
Use REPADMIN /SHOWOBJMETA
to check for obvious version number differences in password-related attributes (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, lmPwdHistory) for the source domain controller in the source domain controller’s and destination domain controller’s copy of the Active Directory directory.
C:>repadmin /showobjmeta <source DC> <DN path of source DC computer account>
C:>repadmin /showobjmeta <KDC selected by destination DC> <DN path of source DC computer account>
The netdom resetpwd /server:<DC to direct password change to> /userd:<user name> /passwordd:<password>
command that’s run at an elevated command prompt on the console of the domain controller that requires a password reset can be used to reset domain controller machine account passwords.
Troubleshoot specific scenarios
-
Repro steps for bad host-to-IP mapping that causes the destination domain controller to pull from wrong source.
-
Promote \dc1 + \DC2 + \DC3 in the
contoso.com
domain. End-to-end replication occurs without errors. -
Stop the KDC on \DC1 and \DC2 to force off-box Kerberos traffic that can be observed in a network trace. End-to-end replication occurs without errors.
-
Create a Host file entry for \DC2 that points to the IP address of a DC in a remote forest. It’s to simulate a bad host-to-IP mapping in a host A/AAAA record, or perhaps a stale NTDS Settings object in the destination domain controller’s copy of the Active Directory directory.
-
Start Active Directory Sites and Services on the console of \DC1. Right-click \DC1’s inbound connection object from \DC2 and note the target account name is incorrect replication error.
-
-
Repro steps for a source domain controller password mismatch between KDC and the source domain controller.
-
Promote \dc1 + \DC2 + \DC3 in the
contoso.com
domain. End-to-end replication occurs without error. -
Stop the KDC on \DC1 and \DC2 to force off-box Kerberos traffic that can be observed in network trace. End-to-end replication occurs without error.
-
Disabling inbound replication on KDC \DC3 to simulate a replication failure on the KDC.
-
Reset the computer account password on \DC2 three or more times so that \DC1 and \DC2 both have the current password for \DC2.
-
Start Active Directory Sites and Services on the console of \DC1. Right-click on \DC1’s inbound connection object from \DC2 and note the target account name is incorrect replication error.
-
-
DS RPC client logging
Set NTDSDiagnostics LoggingsDS RPC Client = 3. Trigger replication. Look for Task Category Event 1962 + 1963. Note the fully qualified
cname
that’s listed in the directory service field. The destination domain controller should be able to ping this record and have the returned address map to the current IP address of the source DC. -
Kerberos workflow
The Kerberos workflow includes the following actions:
-
Client Computer calls IntializeSecurityContext function and specifies the Negotiate security support provider (SSP).
-
The client contacts the KDC with its TGT and requests a TGS Ticket for the target domain controller.
-
The KDC searches the Global Catalog for a source (either e351 or hostname) in the destination domain controller’s realm.
-
If the target domain controller is in the destination domain controller’s realm, the KDC provides the client a service ticket.
-
If the target domain controller is in a different realm, the KDC provides the client a referral ticket.
-
The client contacts a KDC in the target domain controller’s domain and requests a service ticket.
-
If the source domain controller’s SPN doesn’t exist in the realm, you receive a KDC_ERR_S_PRINCIPAL_UNKNOWN error.
-
The destination domain controller contacts the target and presents its ticket.
-
If the target domain controller owns the name in the ticket and can decrypt it, the authentication works.
-
If the target domain controller hosts the RPC server service UUID, the on-wire Kerberos KRB_AP_ERR_NOT_US or KRB_AP_ERR_MODIFIED error is remapped to the following one:
-2146893022 decimal / 0x80090322 / SEC_E_WRONG_PRINCIPAL / «The target principal name is incorrect»
-
Data collection
If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in Gather information by using TSSv2 for Active Directory replication issues.
Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.
В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:
- Error 2146893022 (главное конечное имя неверно);
- Error 1908 (не удалось найти контроллер домена);
- Error 8606 (недостаточно атрибутов для создания объекта);
- Error 8453 (доступ к репликации отвергнут).
Вы также узнаете, как анализировать метаданные репликации с помощью таких инструментов, как AD Replication Status Tool, встроенная утилита командной строки RepAdmin.exe и Windows PowerShell.
Для всестороннего рассмотрения я буду использовать лес Contoso, который показан на рисунке. В таблице 1 перечислены роли, IP-адреса и настройки DNS-клиента для компьютеров данного леса.
|
Рисунок. Архитектура леса |
Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.
|
Экран 1. Два недостающих контроллера домена |
В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.
|
Экран 2. Статус репликации контроллеров домена |
Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.
|
Экран 3. Ошибки репликации, возникающие в лесу Contoso |
Поскольку ошибки репликации все же возникают, полезно задействовать утилиту командной строки RepAdmin.exe, которая помогает получить отчет о состоянии репликации по всему лесу. Чтобы создать файл, запустите следующую команду из Cmd.exe:
Repadmin /showrel * /csv > ShowRepl.csv
Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:
- Из меню Home щелкните Format as table и выберите один из стилей.
- Удерживая нажатой клавишу Ctrl, щелкните столбцы A (Showrepl_COLUMNS) и G (Transport Type). Правой кнопкой мыши щелкните в этих столбцах и выберите Hide.
- Уменьшите ширину остальных столбцов так, чтобы был виден столбец K (Last Failure Status).
- Для столбца I (Last Failure Time) нажмите стрелку вниз и отмените выбор 0.
- Посмотрите на дату в столбце J (Last Success Time). Это последнее время успешной репликации.
- Посмотрите на ошибки в столбце K (Last Failure Status). Вы увидите те же ошибки, что и в AD Replication Status Tool.
Таким же образом вы можете запустить средство RepAdmin.exe из PowerShell. Для этого сделайте следующее:
1. Перейдите к приглашению PowerShell и введите команду
Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView
2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.
3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.
4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.
|
Экран 4. Задание фильтра |
Теперь, когда вы знаете, как проверять статус репликации и обнаруживать ошибки, давайте посмотрим, как выявлять и устранять четыре наиболее распространенные неисправности.
Исправление ошибки AD Replication Error -2146893022
Итак, начнем с устранения ошибки -2146893022, возникающей между DC2 и DC1. Из DC1 запустите команду Repadmin для проверки статуса репликации DC2:
Repadmin /showrepl dc2
На экране 5 показаны результаты, свидетельствующие о том, что репликация перестала выполняться, поскольку возникла проблема с DC2: целевое основное имя неверно. Тем не менее, описание ошибки может указать ложный путь, поэтому приготовьтесь копать глубже.
|
Экран 5. Проблема с DC2 — целевое основное имя неверно |
Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:
Repadmin /bind DC1
На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:
Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»
И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).
|
Экран 6. Сообщение о событии с Event ID 4 |
Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:
Repadmin /showobjmeta dc1 «cn=dc1,ou=domain controllers, dc=root,dc=contoso,dc=com» > dc1objmeta1.txt
Repadmin /showobjmeta dc2 «cn=dc1,ou=domain controllers, dc=root,dc=contoso,dc=com» > dc1objmeta2.txt
Далее откройте файлы dc1objmeta1.txt и dc1objmeta2.txt, которые были созданы, и посмотрите на различия версий для dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet и lmPwdHistory. В нашем случае файл dc1objmeta1.txt показывает версию 19, тогда как версия в файле dc1objmeta2.txt – 11. Таким образом, сравнивая эти два файла, мы видим, что DC2 содержит информацию о старом пароле для DC1. Операция Kerberos не удалась, потому что DC1 не смог расшифровать билет службы, представленный DC2.
KDC, запущенный на DC2, не может быть использован для Kerberos вместе с DC1, так как DC2 содержит информацию о старом пароле. Чтобы решить эту проблему, вы должны заставить DC2 использовать KDC на DC1, чтобы завершить репликацию. Для этого вам, в первую очередь, необходимо остановить службу KDC на DC2:
Net stop kdc
Теперь требуется начать репликацию корневого раздела Root:
Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»
Следующим вашим шагом будет запуск двух команд Repadmin /showobjmeta снова, чтобы убедиться в том, что версии совпадают. Если все хорошо, вы можете перезапустить службу KDC:
Net start kdc
Обнаружение и устранение ошибки AD Replication Error 1908
Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:
Nltest /dbflag:2080fff
Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:
Repadmin /replicate dc1 childdc1 dc=child,dc=root, dc=contoso,dc=com
Результат, показанный на экране 7, говорит о том, что репликация не состоялась, потому что DC домена не может быть найден.
|
Экран 7. Репликация не состоялась, потому что DC домена не может быть найден |
Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:
Nltest /dsgetdc:child /kdc
Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:
Nltest /dsgetdc:child
В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 7.
Теперь, когда вы воспроизвели все ошибки, просмотрите файл Netlogon.log, созданный в папке C:Windowsdebug. Откройте его в «Блокноте» и найдите запись, которая начинается с DSGetDcName function called. Обратите внимание, что записей с таким вызовом будет несколько. Вам нужно найти запись, имеющую те же параметры, что вы указали в команде Nltest (Dom:child и Flags:KDC). Запись, которую вы ищете, будет выглядеть так:
DSGetDcName function called: client PID=2176, Dom:child Acct:(null) Flags:KDC
Вы должны просмотреть начальную запись, равно как и последующие, в этом потоке. В таблице 2 представлен пример потока 3372. Из этой таблицы следует, что поиск DNS записи KDC SRV в дочернем домене был неудачным. Ошибка 1355 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.
Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:
Dcdiag /test:dns /dnsdelegation > Dnstest.txt
На экране 8 показан пример файла Dnstest.txt. Как вы можете заметить, это проблема DNS. Считается, что IP-адрес 192.168.10.1 – адрес для DC1.
|
Экран 8. Пример файла Dnstest.txt |
Чтобы устранить проблему DNS, сделайте следующее:
1. На DC1 откройте консоль управления DNS.
2. Разверните Forward Lookup Zones, разверните root.contoso.com и выберите child.
3. Щелкните правой кнопкой мыши (как в родительской папке) на записи Name Server и выберите пункт Properties.
4. Выберите lamedc1.child.contoso.com и нажмите кнопку Remove.
5. Выберите Add, чтобы можно было добавить дочерний домен сервера DNS в настройки делегирования.
6. В окне Server fully qualified domain name (FQDN) введите правильный сервер childdc1.child.root.contoso.com.
7. В окне IP Addresses of this NS record введите правильный IP-адрес 192.168.10.11.
8. Дважды нажмите кнопку OK.
9. Выберите Yes в диалоговом окне, где спрашивается, хотите ли вы удалить связующую запись (glue record) lamedc1.child.contoso.com [192.168.10.1]. Glue record – это запись DNS для полномочного сервера доменных имен для делегированной зоны.
10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:
Nltest /dsgetdc:child /kdc /force
11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду
Repadmin /replicate dc1 childdc1 «dc=child,dc=root, dc=contoso,dc=com»
Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.
|
Экран 9. Использование оснастки Active Directory Sites и?Services |
После этого вы увидите диалоговое окно, как показано на экране 10. Не учитывайте его, нажмите OK. Я вкратце расскажу об этой ошибке.
|
Экран 10. Ошибка при репликации |
Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.
Устранение ошибки AD Replication Error 8606
Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).
Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:
Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»
Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.
|
Экран 11. Ошибка из-за наличия устаревшего объекта |
|
Экран 12. Событие с кодом 1988 |
Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.
Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:
Repadmin /showobjmeta * «e8bd5af127d8>» > Objects.txt
Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).
Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:
Repadmin /showrepl DC1 > Showrepl.txt
В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:
DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.
Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4- b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com» /Advisory_mode
Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.
Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.
Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:
Repldiag /removelingeringobjects Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»
Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:
Repadmin /removelingeringobjects childdc2.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com» /Advisory_mode
После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.
|
Экран 13. Сообщение об удалении устаревших объектов |
Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.
Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.
Устранение ошибки AD Replication Error 8453
Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.
Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:
Repadmin /showrepl childdc2 > Repl.txt
Данная команда отправляет результаты Repl.txt. Если вы откроете этот текстовый файл, то увидите вверху следующее:
BoulderChildDC2 DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC WARNING: Not advertising as a global catalog
Если вы внимательно посмотрите на раздел Inbound Neighbors, то увидите, что раздел DC=treeroot,DC=fabrikam,DC=com отсутствует, потому что он не реплицируется. Взгляните на кнопку файла – вы увидите ошибку:
Source: BoulderTRDC1 ******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30 Last error: 8453 (0x2105): Replication access was denied Naming Context: DC=treeroot,DC=fabrikam,DC=com
Эта ошибка означает, что ChildDC2 не может добавить связь репликации (replication link) для раздела Treeroot. Как показано на экране 14, данная ошибка также записывается в журнал регистрации событий Directory Services на ChildDC2 как событие с кодом 1926.
|
Экран 14. Отсутствие связи репликации |
Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте DCDiag.exe:
Dcdiag /test:checksecurityerror
На экране 15 показан фрагмент вывода DCDiag.exe.
|
Экран 15. Фрагмент вывода DCDiag.exe |
Как видите, вы получаете ошибку 8453, потому что группа безопасности Enterprise Read-Only Domain Controllers не имеет разрешения Replicating Directory Changes.
Чтобы решить проблему, вам нужно добавить отсутствующую запись контроля доступа – missing access control entry (ACE) в раздел Treeroot. В этом вам помогут следующие шаги:
1. На TRDC1 откройте оснастку ADSI Edit.
2. Правой кнопкой мыши щелкните DC=treeroot,DC=fabrikam,DC=com и выберите Properties.
3. Выберите вкладку Security.
4. Посмотрите разрешения на этот раздел. Отметьте, что нет записей для группы безопасности Enterprise Read-Only Domain Controllers.
5. Нажмите Add.
6. В окне Enter the object names to select наберите ROOTEnterprise Read-Only Domain Controllers.
7. Нажмите кнопку Check Names, затем выберите OK, если указатель объектов (object picker) разрешает имя.
8. В диалоговом окне Permissions для Enterprise Read-Only Domain Controllers снимите флажки Allow для следующих разрешений
*Read
*Read domain password & lockout policies («Чтение политики блокировки и пароля домена»)
*Read Other domain parameters
9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.
10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду
Repadmin /kcc childdc2
|
Экран 16. Включение разрешения Replicating Directory Change |
Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.
Состояние репликации критически важно
Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.
Листинг 1. Команды для удаления устаревших объектов из Reference DC
REM Команды для удаления устаревших объектов REM из раздела Configuration. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «cn=configuration,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела ForestDNSZones. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child. root.contoso.com 0b457f73-96a4-429b-ba81- 1a3e0f51c848 «dc=forestdnszones,dc=root, dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена Root. Repadmin /removelingeringobjects dc1.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones. Repadmin /removelingeringobjects dc1.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=root,dc=contoso,dc=com»
Листинг 2. Команды для удаления устаревших объектов из остальных DC
REM Команды для удаления устаревших объектов REM из раздела Configuration. Repadmin /removelingeringobjects dc1.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела ForestDNSZones. Repadmin /removelingeringobjects dc1.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones–Root. Repadmin /removelingeringobjects dc2.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=domaindnszones,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена Child. Repadmin /removelingeringobjects dc1.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones-Child. Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена TreeRoot. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects dc1.root.contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects dc2.root.contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com»
We lost one of our DCs at the remote site. The last backup from from 51 days ago. Lost DC was not the primary holder of any of the FISMO roles. We went ahead and restored a server from the backup with the assumption we would be able to replicate all (very
few) AD changes one the DC is up and computer password is reset.
http://sumoomicrosoft.blogspot.com/2012/07/reset-domain-controller-computer-account.html
Unfortunately AD replication isn’t working after a reboot on the recovered DC.
repadmin /syncall
CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.
repadmin /syncall /AedqP
Syncing all NC’s held on REMOTEDC.
Syncing partition: DC=ForestDnsZones,DC=DOMAIN,DC=local
SyncAll reported the following errors:
Error issuing replication: -2146893022 (0x80090322):
The target principal name is incorrect.
From: CN=NTDS Settings,CN=REMOTEDC,CN=Servers,CN=REMOTECITY,CN=Sites,CN=Configura
tion,DC=DOMAIN,DC=local
To : CN=NTDS Settings,CN=HQDC,CN=Servers,CN=HQCITY,CN=Sites,CN=Conf
iguration,DC=DOMAIN,DC=local
Syncing partition: DC=DomainDnsZones,DC=DOMAIN,DC=local
SyncAll reported the following errors:
Error issuing replication: -2146893022 (0x80090322):
The target principal name is incorrect.
From: CN=NTDS Settings,CN=REMOTEDC,CN=Servers,CN=REMOTECITY,CN=Sites,CN=Configura
tion,DC=DOMAIN,DC=local
To : CN=NTDS Settings,CN=HQDC,CN=Servers,CN=HQCITY,CN=Sites,CN=Conf
iguration,DC=DOMAIN,DC=local
Syncing partition: CN=Schema,CN=Configuration,DC=DOMAIN,DC=local
SyncAll reported the following errors:
Error issuing replication: -2146893022 (0x80090322):
The target principal name is incorrect.
From: CN=NTDS Settings,CN=REMOTEDC,CN=Servers,CN=REMOTECITY,CN=Sites,CN=Configura
tion,DC=DOMAIN,DC=local
To : CN=NTDS Settings,CN=HQDC,CN=Servers,CN=HQCITY,CN=Sites,CN=Conf
iguration,DC=DOMAIN,DC=local
Syncing partition: CN=Configuration,DC=DOMAIN,DC=local
SyncAll reported the following errors:
Error issuing replication: -2146893022 (0x80090322):
The target principal name is incorrect.
From: CN=NTDS Settings,CN=REMOTEDC,CN=Servers,CN=REMOTECITY,CN=Sites,CN=Configura
tion,DC=DOMAIN,DC=local
To : CN=NTDS Settings,CN=HQDC,CN=Servers,CN=HQCITY,CN=Sites,CN=Conf
iguration,DC=DOMAIN,DC=local
Syncing partition: DC=DOMAIN,DC=local
SyncAll reported the following errors:
Error issuing replication: -2146893022 (0x80090322):
The target principal name is incorrect.
From: CN=NTDS Settings,CN=REMOTEDC,CN=Servers,CN=REMOTECITY,CN=Sites,CN=Configura
tion,DC=DOMAIN,DC=local
To : CN=NTDS Settings,CN=HQDC,CN=Servers,CN=HQCITY,CN=Sites,CN=Conf
iguration,DC=DOMAIN,DC=local
https://social.technet.microsoft.com/Forums/windowsserver/en-US/1e501602-6189-41de-8e17-473d305ba61f/error-0x80090322-in-the-replication-check?forum=winserverDS
Обновлено 15.11.2020
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали методы оплаты телефона Билайн, я привел вам варианты использования самых известных банков, мы сэкономили время, самый ценный ресурс в мире. Двигаемся дальше и сегодня разберем серьезную ошибку, которая может вам доставить уйму проблем при ее диагностике и в работе пользователей. Речь пойдет, о проблемах репликации между контроллерами домена, где на сбойном контроллере вы будите получать тьму ошибок, одной из которых будет «The target principal name is incorrect. SyncAll exited with fatal Win32 error: 8440 (0x20f8)«. Давайте восстанавливать правильную работу нашего AD.
Описание проблемы репликации между контроллерами
И так стали поступать заявки в систему технической поддержки, о том, что пользователь при попытке доступа по RDP получает ошибку:
Неверное имя пользователя или пароль. Попробуйте снова (The user name or password is incorrect. Try again)
Хотя пользователь уверял, что все верно вводил. Давайте разбираться в чем дело.
Диагностика Active Directory
Первым делом, я конечно же проверил не заблокирован ли пользователь, с ним было все прекрасно и он спокойно мог авторизовываться на других серверах компании. Параллельно другие сотрудники, из соседнего сайта Active Directory, получали такую же ошибку, поэтому я стал проверять репликации между контроллерами, таких ошибок я уже видел уйму:
- Ошибка 1311 при репликации Active Directory
- Ошибка 1694 в Active Directory
- Ошибка KCC ID 11 и дублированные SPN имена у CNF записей
- Ошибка 1722 сервер RPC не доступен
Напоминаю, что существует два инструмента, которые вам помогут произвести проверку репликации в лесу Active Directory, это repadmin и dcdiag, я не беру графические Active Directory Replication Status Tool. Моя AD состоит из 4 доменов, один корневой и три дочерних. Проблема была в одном из дочерних. Он состоял из четырех контроллеров домена, 3 из которых были в одном сайте, а оставшийся в другом. Первым делом я выполнил команду на контроллере из первого сайта:
Ошибок он мне не показал, но меня привлекло, то что среди списка входящей и исходящей репликации, отсутствовал контроллер домена из другого сайта, тут я понял что проблема кроется явно уже в связи с ним. Контроллера DC6, просто не было
Естественно я начал подключаться к нему, прикол в том, что при попытке войти из под учетной записи пользователя корневого домена, я получил ту же ошибку «Неверное имя пользователя или пароль. Попробуйте снова (The user name or password is incorrect. Try again)», а вот под админом дочернего домена, все же пустило. Там я так же запустил в командной строке проверку репликации.
Тут уже сразу начались новые ошибки, с которыми я ранее не встречался:
Ошибка 1326: experienced the following operational errors trying to retrieve replication information
Получается так, что с частью контроллеров домена, данный DC6 общался, а вот часть не видел.
Посмотрев как происходит реплика между сайтами, я понял, что входящая реплика идет от одного нового контроллера, а исходящая идет уже на другой. Открыв оснастку ADUC на DC6 я увидел, что нового контроллера домена DC2 просто нет в списке контейнера D0main Controllers, но зато присутствовал старый умерший контроллер.
Далее я естественно заглянул и в оснастку DNS, где мне нужно было удостовериться, в наличии или отсутствии сервисных записей нового контроллера и старого. Я оказался прав, присутствовали записи старого контроллера. Записи SOA, так же сильно отличались.
В логах Windows, через просмотр событий или Windows Admin Center, можно было наблюдать такие ошибки:
Ошибка ID 4: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc4main$. The target name used was E3514235-00000-0000-AB04-00C04FC4534D2/f0e3a106-7b73-4ce0-a6f2-09c673454356/домен. 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 (root.pyatilistnik.org) is different from the client domain (root.pyatilistnik.org), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
Или ошибка ID 1645: Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
Destination directory server:
d06896a3-be4b-4b8a-b75f-e3453457526a0f._msdcs.pyatilistnik.org
SPN:
E3514235-4B06-11D1-AB04-00C04FC2DCD2/d06896a3-be4b-4b8a-b3453453526a0f/pyatilistnik.org
User Action
Verify that the names of the destination directory server and domain are correct. Also, verify that the SPN is registered on the KDC domain controller. If the destination directory server has been recently promoted, it will be necessary for the local directory server’s account data to replicate to the KDC before this directory server can be authenticated.
Устранение проблем
Первое на , что я наткнулся в качестве решений, это простая перезагрузка и правда, зачастую с Windows системами это один из действенных методов.
После перезагрузки я первым делом попытался выполнить принудительную синхронизацию, через команду:
В результате у меня она не прошла и я получил ошибку:
CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=DC6,CN=Servers,CN=root, CN=Sites,CN=Configuration,DC=pyatilistnik,DC=org (network error): -2146893022 (0x80090322):
The target principal name is incorrect.
SyncAll exited with fatal Win32 error: 8440 (0x20f8):
The naming context specified for this replication operation is invalid.
Так же показывались старые ошибки. Еще я попробовал команду, которая должна показать все ошибки при диагностике Active Directory:
В результате ошибок было еще больше 🙂
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000785
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link for the following writable directory partition failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000785
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link for the following writable directory partition failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000785
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link for the following writable directory partition failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000786
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000786
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000786
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link to a read-only directory partition with the following parameters failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000785
Time Generated: 11/13/2020 12:19:37
Event String: The attempt to establish a replication link for the following writable directory partition failed.
An error event occurred. EventID: 0xC000066D
Time Generated: 11/13/2020 12:19:37
Event String:
Active Directory Domain Services did not perform an authenticated remote procedure call (RPC) to another directory server because the desired service principal name (SPN) for the destination directory server is not registered on the Key Distribution Center (KDC) domain controller that resolves the SPN.
A warning event occurred. EventID: 0x80000785
Я попытался вручную запустить входящую реплику через оснастку Active Directory Сайты и службы, но так же получил порцию новых ошибок.
The following error occurred during the attempt to synchronize naming context pyatilictnik.org from Domain Controller DC2 to Domain Controller DC6. The naming context is in the progress of being removed or is not replicated from the specified server.
Новые ошибки уже начали выводить меня на приблизительное решение данной проблемы. Ошибка «-2146893022 (0x80090322):The target principal name is incorrect. SyncAll exited with fatal Win32 error: 8440 (0x20f8)», говорит на, о том, что между мастером PDC и текущим контроллером домена не работает безопасный канал. Там мы производили его сброс через утилиту Netdom. Самое интересное, что команда проверяющая безопасный канал показывала, что с ним все в порядке.
Test-ComputerSecureChannel –verbose
Безопасный канал между локальным компьютером и доменом находится в хорошем состоянии, но ошибкам репликации на это безразницы.
На сбойном контроллере домена нужно выполнить:
- В командной строке или оболочке PowerShell вам необходимо остановить службу Key Distribution Center (Центр распространения ключей Kerberos) (KDC) на СБОЙНОМ контроллере домена.
Далее вам необходимо выставить у нее тип запуска «Отключено», для этого выполните команду:
sc config KDC start= disabled
После чего перезагрузите контроллер домена
- На сбойном контроллере выполните команду, для того чтобы очистить билеты (Purge Tickets)
Далее на любом из контроллеров домена, который не является держателем роли FSMO DPC, вам нужно произвести сброс безопасного канала, я делаю эту команду на сбойном контроллере домена. Так же об этом советует Microsoft:
После перезагрузки компьютера используйте служебную программу Netdom для сброса безопасных каналов между этими контроллерами домена и держателем роли хозяина операций эмулятора PDC. Для этого выполните следующую команду с контроллеров домена, отличных от владельца роли хозяина операций эмулятора PDC:
Netdom RESETPWD / сервер: server_name / userd: domain_name администратор / PasswordD: administrator_password
Где server_name — это имя сервера, который является владельцем роли хозяина операций эмулятора PDC.
У меня это получилось вот так:
netdom /resetpwd /server:dc01 /userd:root.pyatilistnik.orgsem /passwordd:Мой пароль
В результате вы должны получить «Пароль учетной записи локального компьютера успешно сброшен».
После сброса безопасного канала перезапустите контроллеры домена, я перезапустил сбойный и сервер с PDC ролью. Даже если вы попытаетесь сбросить безопасный канал с помощью утилиты Netdom, и команда не завершится успешно, продолжите процесс перезапуска. Если работает только владелец роли хозяина операций эмулятора PDC, KDC заставляет другие контроллеры домена повторно синхронизироваться с этим компьютером, вместо того, чтобы выдавать себе новый билет Kerberos.
После перезагрузки на сбойном контроллере и на PDC выполните команду:
После чего можно запускать службу Key Distribution Center (Центр распространения ключей Kerberos) (KDC). Для этого выполните:
sc config KDC start= auto
net start KDC
Дополнительные методы диагностики
- Если у вас контроллеры домена располагаются по разным сайтам, то обязательно проверьте все ли порты Active Directory вы открыли на своем оборудовании, самый главный порт 135, его можно проверить с обоих сторон, через утилиту Telnet.
- Если ничего не помогает, то я вам советую выключить сбойный контроллер и удалить его, почистить метаданные в AD и создать новый контроллер домена, для ускорения реплики при создании, сделайте файл IFM.
Дополнительные ссылки
- https://console.kim.sg/how-to-revive-dead-dns-server-on-the-last-standing-domain-controller-after-seizing-all-other-dcs/
- https://support.microsoft.com/en-sg/help/288167/error-message-target-principal-name-is-incorrect-when-manually-replica
- https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/identity/replication-error-2146893022
На этом у меня все, мы с вами восстановили работу контроллеров домена и репликации, и больше не будет проблем с паролями. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Диагностика сервера каталогов
Выполнение начальной настройки:
Выполняется попытка поиска основного сервера…
Основной сервер = MSK-DC16
* Определен лес AD.
Сбор начальных данных завершен.
Выполнение обязательных начальных проверок
Сервер проверки: SITEMSK-DC16
Запуск проверки: Connectivity
……………………. MSK-DC16 — пройдена проверка Connectivity
Выполнение основных проверок
Сервер проверки: MaslovkaMSK-DC16
Запуск проверки: Advertising
……………………. MSK-DC16 — пройдена проверка Advertising
Запуск проверки: FrsEvent
……………………. MSK-DC16 — пройдена проверка FrsEvent
Запуск проверки: DFSREvent
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
репликации SYSVOL могут стать причиной проблем групповой политики.
……………………. MSK-DC16 — пройдена проверка DFSREvent
Запуск проверки: SysVolCheck
……………………. MSK-DC16 — пройдена проверка SysVolCheck
Запуск проверки: KccEvent
……………………. MSK-DC16 — пройдена проверка KccEvent
Запуск проверки: KnowsOfRoleHolders
……………………. MSK-DC16 — пройдена проверка
KnowsOfRoleHolders
Запуск проверки: MachineAccount
……………………. MSK-DC16 — пройдена проверка MachineAccount
Запуск проверки: NCSecDesc
……………………. MSK-DC16 — пройдена проверка NCSecDesc
Запуск проверки: NetLogons
[MSK-DC16] В учетных данных пользователя отсутствует разрешение на
выполнение данной операции.
Учетная запись, используемая для этой проверки, должна иметь права на
вход в сеть
для домена данного компьютера.
……………………. MSK-DC16 — не пройдена проверка NetLogons
Запуск проверки: ObjectsReplicated
……………………. MSK-DC16 — пройдена проверка
ObjectsReplicated
Запуск проверки: Replications
[Проверка репликации,MSK-DC16] Сбой функции
DsReplicaGetInfo(PENDING_OPS, NULL), ошибка 0x2105
«Доступ к репликации отвергнут.»
……………………. MSK-DC16 — не пройдена проверка Replications
Запуск проверки: RidManager
……………………. MSK-DC16 — пройдена проверка RidManager
Запуск проверки: Services
Не удалось открыть службу NTDS в MSK-DC16, ошибка 0x5
«Отказано в доступе.»
……………………. MSK-DC16 — не пройдена проверка Services
Запуск проверки: SystemLog
……………………. MSK-DC16 — пройдена проверка SystemLog
Запуск проверки: VerifyReferences
……………………. MSK-DC16 — пройдена проверка
VerifyReferences
Выполнение проверок разделов на: ForestDnsZones
Запуск проверки: CheckSDRefDom
……………………. ForestDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
……………………. ForestDnsZones — пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: DomainDnsZones
Запуск проверки: CheckSDRefDom
……………………. DomainDnsZones — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
……………………. DomainDnsZones — пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: Schema
Запуск проверки: CheckSDRefDom
……………………. Schema — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
……………………. Schema — пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: Configuration
Запуск проверки: CheckSDRefDom
……………………. Configuration — пройдена проверка
CheckSDRefDom
Запуск проверки: CrossRefValidation
……………………. Configuration — пройдена проверка
CrossRefValidation
Выполнение проверок разделов на: DOMEN
Запуск проверки: CheckSDRefDom
……………………. DOMEN — пройдена проверка CheckSDRefDom
Запуск проверки: CrossRefValidation
……………………. DOMEN — пройдена проверка CrossRefValidation
Выполнение проверок предприятия на: DOMEN.local
Запуск проверки: LocatorCheck
……………………. DOMEN.local — пройдена проверка LocatorCheck
Запуск проверки: Intersite
……………………. DOMEN.local — пройдена проверка Intersite
Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.
В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:
- Error 2146893022 (главное конечное имя неверно);
- Error 1908 (не удалось найти контроллер домена);
- Error 8606 (недостаточно атрибутов для создания объекта);
- Error 8453 (доступ к репликации отвергнут).
Вы также узнаете, как анализировать метаданные репликации с помощью таких инструментов, как AD Replication Status Tool, встроенная утилита командной строки RepAdmin.exe и Windows PowerShell.
Для всестороннего рассмотрения я буду использовать лес Contoso, который показан на рисунке. В таблице 1 перечислены роли, IP-адреса и настройки DNS-клиента для компьютеров данного леса.
|
Рисунок. Архитектура леса |
Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.
|
Экран 1. Два недостающих контроллера домена |
В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.
|
Экран 2. Статус репликации контроллеров домена |
Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.
|
Экран 3. Ошибки репликации, возникающие в лесу Contoso |
Поскольку ошибки репликации все же возникают, полезно задействовать утилиту командной строки RepAdmin.exe, которая помогает получить отчет о состоянии репликации по всему лесу. Чтобы создать файл, запустите следующую команду из Cmd.exe:
Repadmin /showrel * /csv > ShowRepl.csv
Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:
- Из меню Home щелкните Format as table и выберите один из стилей.
- Удерживая нажатой клавишу Ctrl, щелкните столбцы A (Showrepl_COLUMNS) и G (Transport Type). Правой кнопкой мыши щелкните в этих столбцах и выберите Hide.
- Уменьшите ширину остальных столбцов так, чтобы был виден столбец K (Last Failure Status).
- Для столбца I (Last Failure Time) нажмите стрелку вниз и отмените выбор 0.
- Посмотрите на дату в столбце J (Last Success Time). Это последнее время успешной репликации.
- Посмотрите на ошибки в столбце K (Last Failure Status). Вы увидите те же ошибки, что и в AD Replication Status Tool.
Таким же образом вы можете запустить средство RepAdmin.exe из PowerShell. Для этого сделайте следующее:
1. Перейдите к приглашению PowerShell и введите команду
Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView
2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.
3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.
4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.
|
Экран 4. Задание фильтра |
Теперь, когда вы знаете, как проверять статус репликации и обнаруживать ошибки, давайте посмотрим, как выявлять и устранять четыре наиболее распространенные неисправности.
Исправление ошибки AD Replication Error -2146893022
Итак, начнем с устранения ошибки -2146893022, возникающей между DC2 и DC1. Из DC1 запустите команду Repadmin для проверки статуса репликации DC2:
Repadmin /showrepl dc2
На экране 5 показаны результаты, свидетельствующие о том, что репликация перестала выполняться, поскольку возникла проблема с DC2: целевое основное имя неверно. Тем не менее, описание ошибки может указать ложный путь, поэтому приготовьтесь копать глубже.
|
Экран 5. Проблема с DC2 — целевое основное имя неверно |
Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:
Repadmin /bind DC1
На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:
Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»
И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).
|
Экран 6. Сообщение о событии с Event ID 4 |
Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:
Repadmin /showobjmeta dc1 «cn=dc1,ou=domain controllers, dc=root,dc=contoso,dc=com» > dc1objmeta1.txt
Repadmin /showobjmeta dc2 «cn=dc1,ou=domain controllers, dc=root,dc=contoso,dc=com» > dc1objmeta2.txt
Далее откройте файлы dc1objmeta1.txt и dc1objmeta2.txt, которые были созданы, и посмотрите на различия версий для dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet и lmPwdHistory. В нашем случае файл dc1objmeta1.txt показывает версию 19, тогда как версия в файле dc1objmeta2.txt – 11. Таким образом, сравнивая эти два файла, мы видим, что DC2 содержит информацию о старом пароле для DC1. Операция Kerberos не удалась, потому что DC1 не смог расшифровать билет службы, представленный DC2.
KDC, запущенный на DC2, не может быть использован для Kerberos вместе с DC1, так как DC2 содержит информацию о старом пароле. Чтобы решить эту проблему, вы должны заставить DC2 использовать KDC на DC1, чтобы завершить репликацию. Для этого вам, в первую очередь, необходимо остановить службу KDC на DC2:
Net stop kdc
Теперь требуется начать репликацию корневого раздела Root:
Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»
Следующим вашим шагом будет запуск двух команд Repadmin /showobjmeta снова, чтобы убедиться в том, что версии совпадают. Если все хорошо, вы можете перезапустить службу KDC:
Net start kdc
Обнаружение и устранение ошибки AD Replication Error 1908
Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:
Nltest /dbflag:2080fff
Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:
Repadmin /replicate dc1 childdc1 dc=child,dc=root, dc=contoso,dc=com
Результат, показанный на экране 7, говорит о том, что репликация не состоялась, потому что DC домена не может быть найден.
|
Экран 7. Репликация не состоялась, потому что DC домена не может быть найден |
Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:
Nltest /dsgetdc:child /kdc
Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:
Nltest /dsgetdc:child
В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 7.
Теперь, когда вы воспроизвели все ошибки, просмотрите файл Netlogon.log, созданный в папке C:Windowsdebug. Откройте его в «Блокноте» и найдите запись, которая начинается с DSGetDcName function called. Обратите внимание, что записей с таким вызовом будет несколько. Вам нужно найти запись, имеющую те же параметры, что вы указали в команде Nltest (Dom:child и Flags:KDC). Запись, которую вы ищете, будет выглядеть так:
DSGetDcName function called: client PID=2176, Dom:child Acct:(null) Flags:KDC
Вы должны просмотреть начальную запись, равно как и последующие, в этом потоке. В таблице 2 представлен пример потока 3372. Из этой таблицы следует, что поиск DNS записи KDC SRV в дочернем домене был неудачным. Ошибка 1355 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.
Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:
Dcdiag /test:dns /dnsdelegation > Dnstest.txt
На экране 8 показан пример файла Dnstest.txt. Как вы можете заметить, это проблема DNS. Считается, что IP-адрес 192.168.10.1 – адрес для DC1.
|
Экран 8. Пример файла Dnstest.txt |
Чтобы устранить проблему DNS, сделайте следующее:
1. На DC1 откройте консоль управления DNS.
2. Разверните Forward Lookup Zones, разверните root.contoso.com и выберите child.
3. Щелкните правой кнопкой мыши (как в родительской папке) на записи Name Server и выберите пункт Properties.
4. Выберите lamedc1.child.contoso.com и нажмите кнопку Remove.
5. Выберите Add, чтобы можно было добавить дочерний домен сервера DNS в настройки делегирования.
6. В окне Server fully qualified domain name (FQDN) введите правильный сервер childdc1.child.root.contoso.com.
7. В окне IP Addresses of this NS record введите правильный IP-адрес 192.168.10.11.
8. Дважды нажмите кнопку OK.
9. Выберите Yes в диалоговом окне, где спрашивается, хотите ли вы удалить связующую запись (glue record) lamedc1.child.contoso.com [192.168.10.1]. Glue record – это запись DNS для полномочного сервера доменных имен для делегированной зоны.
10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:
Nltest /dsgetdc:child /kdc /force
11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду
Repadmin /replicate dc1 childdc1 «dc=child,dc=root, dc=contoso,dc=com»
Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.
|
Экран 9. Использование оснастки Active Directory Sites и?Services |
После этого вы увидите диалоговое окно, как показано на экране 10. Не учитывайте его, нажмите OK. Я вкратце расскажу об этой ошибке.
|
Экран 10. Ошибка при репликации |
Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.
Устранение ошибки AD Replication Error 8606
Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).
Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:
Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»
Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.
|
Экран 11. Ошибка из-за наличия устаревшего объекта |
|
Экран 12. Событие с кодом 1988 |
Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.
Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:
Repadmin /showobjmeta * «e8bd5af127d8>» > Objects.txt
Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).
Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:
Repadmin /showrepl DC1 > Showrepl.txt
В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:
DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.
Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4- b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com» /Advisory_mode
Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.
Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.
Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:
Repldiag /removelingeringobjects Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»
Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:
Repadmin /removelingeringobjects childdc2.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com» /Advisory_mode
После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.
|
Экран 13. Сообщение об удалении устаревших объектов |
Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.
Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.
Устранение ошибки AD Replication Error 8453
Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.
Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:
Repadmin /showrepl childdc2 > Repl.txt
Данная команда отправляет результаты Repl.txt. Если вы откроете этот текстовый файл, то увидите вверху следующее:
BoulderChildDC2 DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC WARNING: Not advertising as a global catalog
Если вы внимательно посмотрите на раздел Inbound Neighbors, то увидите, что раздел DC=treeroot,DC=fabrikam,DC=com отсутствует, потому что он не реплицируется. Взгляните на кнопку файла – вы увидите ошибку:
Source: BoulderTRDC1 ******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30 Last error: 8453 (0x2105): Replication access was denied Naming Context: DC=treeroot,DC=fabrikam,DC=com
Эта ошибка означает, что ChildDC2 не может добавить связь репликации (replication link) для раздела Treeroot. Как показано на экране 14, данная ошибка также записывается в журнал регистрации событий Directory Services на ChildDC2 как событие с кодом 1926.
|
Экран 14. Отсутствие связи репликации |
Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте DCDiag.exe:
Dcdiag /test:checksecurityerror
На экране 15 показан фрагмент вывода DCDiag.exe.
|
Экран 15. Фрагмент вывода DCDiag.exe |
Как видите, вы получаете ошибку 8453, потому что группа безопасности Enterprise Read-Only Domain Controllers не имеет разрешения Replicating Directory Changes.
Чтобы решить проблему, вам нужно добавить отсутствующую запись контроля доступа – missing access control entry (ACE) в раздел Treeroot. В этом вам помогут следующие шаги:
1. На TRDC1 откройте оснастку ADSI Edit.
2. Правой кнопкой мыши щелкните DC=treeroot,DC=fabrikam,DC=com и выберите Properties.
3. Выберите вкладку Security.
4. Посмотрите разрешения на этот раздел. Отметьте, что нет записей для группы безопасности Enterprise Read-Only Domain Controllers.
5. Нажмите Add.
6. В окне Enter the object names to select наберите ROOTEnterprise Read-Only Domain Controllers.
7. Нажмите кнопку Check Names, затем выберите OK, если указатель объектов (object picker) разрешает имя.
8. В диалоговом окне Permissions для Enterprise Read-Only Domain Controllers снимите флажки Allow для следующих разрешений
*Read
*Read domain password & lockout policies («Чтение политики блокировки и пароля домена»)
*Read Other domain parameters
9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.
10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду
Repadmin /kcc childdc2
|
Экран 16. Включение разрешения Replicating Directory Change |
Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.
Состояние репликации критически важно
Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.
Листинг 1. Команды для удаления устаревших объектов из Reference DC
REM Команды для удаления устаревших объектов REM из раздела Configuration. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «cn=configuration,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела ForestDNSZones. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc1.child. root.contoso.com 0b457f73-96a4-429b-ba81- 1a3e0f51c848 «dc=forestdnszones,dc=root, dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена Root. Repadmin /removelingeringobjects dc1.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones. Repadmin /removelingeringobjects dc1.root. contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6 «dc=root,dc=contoso,dc=com»
Листинг 2. Команды для удаления устаревших объектов из остальных DC
REM Команды для удаления устаревших объектов REM из раздела Configuration. Repadmin /removelingeringobjects dc1.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «cn=configuration,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «cn=configuration,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела ForestDNSZones. Repadmin /removelingeringobjects dc1.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=forestdnszones,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=forestdnszones,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones–Root. Repadmin /removelingeringobjects dc2.child.root. contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e «dc=domaindnszones,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена Child. Repadmin /removelingeringobjects dc1.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects dc2.root.contoso. com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=child,dc=root,dc=contoso,dc=com» Repadmin /removelingeringobjects trdc1.treeroot. fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=child,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела DomainDNSZones-Child. Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604 «dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com» REM Команды для удаления устаревших объектов REM из раздела домена TreeRoot. Repadmin /removelingeringobjects childdc1.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects childdc2.child.root. contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects dc1.root.contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com» Repadmin /removelingeringobjects dc2.root.contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848 «dc=treeroot,dc=fabrikam,dc=com»
Постановка задачи
В этой статье мы рассмотрим как добавить контроллер домена Active Directory в существующий лес, а затем сделать его главным в нашем домене, т.е. перенести на него роли хозяина операций. Про перенос отдельных ролей и компонентов можно прочесть в официальной документации.
Предположим:
- MYDOMAIN.LOCAL – наш домен под управлением Active Directory в Windows 2012 Server
- DC1 – единственный контроллер домена
- DC2 – новый добавляемый сервер, который будет вторым контроллером домена и впоследствии хозяином операций
Добавление контроллера домена
После установки на Windows 2012 Server роли “Доменные службы Active Directory” и повышения уровня сервера до контроллера домена (см офиц инструкцию) необходимо перед дальнейшими действиями дать несколько часов на синхронизацию между контроллерами доменов.
Затем следует проверить насколько гладко новый котроллер вошёл в домен.
C:Windowssystem32>nltest /dclist:mydomain.local Получить список контроллеров домена в домене “mydomain.local” из “dc1.mydomain.local”. dc1.mydomain.local [PDC] [DS] Сайт: Default-First-Site-Name DC2.mydomain.local [DS] Сайт: Default-First-Site-Name Команда выполнена успешно.
Можно альтернативно запросить туже информацию непосредственно из каталога Active Directory:
C:Windowssystem32>dsquery server “CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=local” “CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=local”
Посмотрим краткий отчёт о проведённых между контроллерами репликациях, есть ли что-нибудь в очереди, можно также посмотреть более подробный отчёт:
repadmin /replsummary repadmin /queue repadmin /showrepl
Если репликации не были успешными, то можно запустить репликацию принудительно, но при этом командный интерпритатор cmd должне быть запущен с административными правами:
repadmin /syncall
Командой dcdiag можно более подробно диагностировать состояние контроллера домена, а также отдельно запустить более подробные тесты для проверки разных служб (офиц. описание)
Перенос роли хозяина операций
Прежде чем начать перенос ролей, желательно добиться отсутствия ошибок в dcdiag!
Алгоритм переноса ролей FSMO (Flexible Single-Master Operations) такой же как и при захвате. В первом случае используется работающий главный контроллер домена (PDC), и переносимые роли на нём отключаются, если же он потерян, то роли захватываются новым контроллером принудительно.
Посмотрим список контроллеров домена mydomain.local:
nltest /dclist:mydomain.local
Выясняем, кто из контроллеров является хозяином операций:
C:Userspnm>netdom query FSMO Хозяин схемы dc1.mydomain.local Хозяин именования доменов dc1.mydomain.local PDC dc1.mydomain.local Диспетчер пула RID dc1.mydomain.local Хозяин инфраструктуры dc1.mydomain.local Команда выполнена успешно.
Перенос ролей можно сделать двумя способами:
1. через оснастку “Active Directory – Домены и доверие”, открыв её из Диспетчера серверов – Средства.
2. консольной утилитой управления доменом ntdsutil (офиц. документация). Если роли передаются, то используем команду transfer, если же захватываются, то seize. Ниже приведён алгоритм захвата ролей новым контроллером dc2:
C:Userspnm>ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server dc2 Привязка к dc2 … Подключен к dc2 с помощью учетных данных локального пользователя. server connections: quit fsmo maintenance: seize infrastructure master fsmo maintenance: seize naming master fsmo maintenance: seize PDC fsmo maintenance: seize RID master fsmo maintenance: seize schema master quit quit
Находясь в разделе fsmo maintenance можно узнать список всех ролей, послав команду ?.
В случае успешного захвата мы должны увидеть следующее
C:Userspnm>netdom query FSMO Хозяин схемы dc2.mydomain.local Хозяин именования доменов dc2.mydomain.local PDC dc2.mydomain.local Диспетчер пула RID dc2.mydomain.local Хозяин инфраструктуры dc2.mydomain.local Команда выполнена успешно.
Работа над ошибками
Некоторые примеры диагностики проблем с контроллерами домена рассмотрены в примерах команды dcdiag
DNS не удаётся разрешить IP-адрес
dcdiag выдаёт ошибку DNS:
Выполнение обязательных начальных проверок Сервер проверки: Default-First-Site-NameDC2 Запуск проверки: Connectivity Узел a20970bf-3f73-400a-85ac-69c8f7b34301._msdcs.mydomain.local не удается разрешить в IP-адрес. Проверьте DNS-сервер, DHCP, имя сервера и т. д. Получена ошибка при проверке подключения LDAP и RPC. Проверьте параметры брандмауэра. ……………………. DC2 – не пройдена проверка Connectivity Выполнение основных проверок Сервер проверки: Default-First-Site-NameDC2 Пропуск всех проверок, так как сервер DC2 не отвечает на запросы службы каталогов.
РЕШЕНИЕ:
Нужно проверить существует ли обратная DNS зона и синхронизирована ли она между контроллерами.
- Детальная проверка службы DNS (может занять пару минут):
dcdiag /test:dns
- Рекомендации по настройке службы DNS на контроллере домена
- DNScmd – консольная утилита для управления DNS сервером (офиц. описание)
Ошибка репликации 8453
repadmin /showrepl выдаёт ошибку:
Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105): Доступ к репликации отвергнут.
РЕШЕНИЕ:
Запустить репликацию вручную и командной строки с административными правами
repadmin /syncall
На контроллере нет сетевых ресурсов NetLogon и SysVol
Эта ошибка означает, что репликация данных с главного контроллера домена (хозяина операций) на проблемный не была произведена до конца.
Доступность сетевых ресурсов можно проверить командой:
net share
Исправность ресурсов SysVol и NetLogon можно проверить командой:
dcdiag /test:netlogons
Официальную инструкцию по пересозданию ресурсов NetLogon и SysVol на английском можно прочесть в статье Restoring and Rebuilding SYSVOL. Ниже приведён краткий алгоритм этого процесса.