Como resolver problemas de replicación de Active Directory

Artikel
04/22/2010

Por: Juan Carlos Albert y Martin Kirtchayan

Que ocurre cuando tenemos un ambiente en el cual, nos encontramos con que la replicación está fallando, revisamos la replicación, ya sea a través de repadmin, replmon, visor de sucesos, etc. y nos encontramos con diferentes tipos de errores y advertencias, todos relacionados a fallas en la replicación de la base de datos de Active Directory, o bien, aparecen como consecuencia de fallas en la replicación. Bien, en base a la cantidad de errores, (también podríamos tomar como parámetro la envergadura del ambiente, con algunos pocos controladores de dominio distribuidos en algunos sites, como cientos de controladores de dominios, distribuidos en decenas de sites) el proceso para encontrar la causa o causas por la cual se están generando el o los problemas pueden ser demasiado complicado.

¿Por dónde empezar?

Pues bien, supongamos que tenemos varios sites, y nuestro problema de replicación está afectando todo el ambiente, nuestra topología lógica es en estrella, básicamente todos los sites replican contra uno central.
La clave aquí es simplificar el ambiente en el cual se encuentra el problema, si bien el mismo afecta a todo el ambiente, centrémonos solamente en dos sitios, tomemos al sitio central, y algún partner de replicación. En nuestro caso tomaremos al sitio central, en el cual radica un controlador de dominio que maneja todos los roles FSMO, como también tomaremos a su partner de replicación (un sitio remoto), sitio que cuenta con un solo controlador de dominio. Pongamos los siguientes nombres, como ejemplo:

Nombre del dominio: ejemplo.lab
Nombre del sitio central: Central
Controlador de dominio en el sitio central: DC01 (con todos los roles FSMO)
Nombre del sitio remoto: Sucursal
Controlador de dominio en el sitio remoto: DC10
Subred utilizada 192.168.0.0/24

(Lo sé.. no me puse muy creativo con los nombres ?)

Una vez que tenemos definidos nuestros sitios, comenzaremos a aplicar el siguiente plan de acción, de manera secuencial, para ir resolviendo los diferentes problemas que se nos presentan, hasta poder lograr que el ambiente pueda converger y por ende poder llevar a cabo la replicación de las particiones de Active Directory de manera exitosa.

Este plan va a estar compuesto por los siguientes pasos:

Topología
Resolución de nombres
Interfaz RPC
Seguridad

1. Topología

Aquí la herramienta de diagnóstico básica es repadmin.exe.
En el servidor de la sucursal, ejecutar:

c:\>repadmin.exe showreps

En el reporte podemos ver cuáles son los partners de replicación definidos para el server de la Sucursal
Como la replicación es inbound (el server inicia la replicación y se trae los cambios del partner) nos interesa sobre todo la sección del reporte que se llama INBOUND NEIGHBORS

En el caso de Sucursal, el reporte muestra:

==== INBOUND NEIGHBORS ======================================

DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
200 consecutive failure(s).
Last success @ (never).

CN=Configuration,DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:05.

CN=Schema,CN=Configuration, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result -2146893022 (0x80090322):
Can't retrieve message string -2146893022 (0x80090322), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:07.

DC=DomainDnsZones, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result 1256 (0x4e8):
Can't retrieve message string 1256 (0x4e8), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:08.

DC=ForestDnsZones, DC=ejemplo,DC=lab
Central\DC01 via RPC
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx
Last attempt @ 2010-03-03 01:21:50 failed, result 1256 (0x4e8):
Can't retrieve message string 1256 (0x4e8), error 1815.
99 consecutive failure(s).
Last success @ 2009-11-25 06:23:09.

Este reporte nos muestra el partner para cada uno de los contenedores del AD, y por los general (a menos que tengamos alguna configuración particularmente macabra) el partner de replicación maneja todos los contenedores.
En nuestro caso, tenemos el partner que es: Central\DC01.

El servidor es el que se encuentra en la central, que es consistente con nuestro modelo de replicación en estrella.
Si en algún otro sitio remoto (otra “sucursal”) vemos que los inbound partner no es el servidor de Central, entonces tendríamos que revisar la definición de ese site y sus enlaces en el “AD Sites and Services” y forzar la regeneración de la topología.
En este caso podemos ver que la replicación inbound ha fallado desde el 25 de nov. del 2009 en ambos servidores.

Last success @ 2009-11-25 06:23:09.

La causa de la falla viene después:

failed, result 1256 (0x4e8):

El error 1256 se traduce como:
Error Code 1256
System error code 1256 means "The remote system is not available. For information about network troubleshooting see Windows Help." This error code may also display as "ERROR_HOST_DOWN" or as the value 0x4E8. System Error Codes: Code 1200 to Code 1299

2. Resolución de nombres

Tenemos que verificar que el servidor de la Sucursal puede resolver correctamente el nombre y el GUID del partner de replicación.
Para ello podemos ejecutar, en el server de la Sucursal, el comando Nslookup
Del reporte de repadmin podemos ver los GUIDs de los servidores:
Central\DC01
DC object GUID: de11d929-55f9-4dc6-b702-xxxxxxxxxxx

En este caso, las pruebas serian:

c:\>Nslookup dc01.ejemplo.lab
c:\>Nslookup de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

El resultado del primer query debe ser la IP actual del server, el resultado del segundo query debe ser el alias y la IP del server:

C:\> Nslookup de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab
Server: DNSServer.ejemplo.lab
Address: 192.168.0.1
Name: dc01.ejemplo.lab
Address: 192.168.0.1
Aliases: de11d929-55f9-4dc6-b702-xxxxxxxxxxx._msdcs.ejemplo.lab

Si alguna de estas pruebas retorna la dirección incorrecta, entonces tenemos que verificar la configuración del DNS primario en el server remoto y corregir el problema.
Posiblemente sea una buena práctica configurar el DNS primario del servidor remoto a dc01 mientras ponemos a funcionar la replicación.

Tengamos en cuenta que si cambias la configuración del DNS en el servidor remoto, lo recomendable es reiniciar el server o, al menos, ejecutar los comandos:

c:\>Ipconfig /registerdns
c:\>Net stop netlogon
c:\>Net start netlogon

De esta forma estamos asegurando que el server se está registrando en el DNS.

3. Puertos RPC

Cuando estemos seguros que la resolución esta OK, podemos pasar a probar los puertos RPC, la mejor herramienta para esto es RPCdump.exe

En el server remoto, ejecuta el comando

c:\>rpcdump /s <partner_dc> /v /i > endpoints.txt

luego

c:\>notepad endpoints.txt

En este caso, el comando seria:

c:\>rpcdump /s dc01.ejemplo.local /v /i > endpoints.txt

En el archivo endpoints.txt, buscamos el UUID e3514235-4b06-11d1-ab04-00c04fc2dcd2

El resultado debe ser igual a:

ProtSeq:ncacn_ip_tcp
Endpoint:1025
NetOpt:
Annotation:MS NT Directory DRS Interface
IsListening:YES
StringBinding:ncacn_ip_tcp:xx.xx.xx.xx[1025]
UUID:e3514235-4b06-11d1-ab04-00c04fc2dcd2
ComTimeOutValue:RPC_C_BINDING_DEFAULT_TIMEOUT
VersMajor 4 VersMinor 0

Si el valor de IsListening es YES, entonces los puertos 135 y 1025 están escuchando.
Si el valor de IsListening es NO, tienes un problema de puertos cerrados, bien sea por un FW intermedio, o por el FW de alguno de los dos servidores.
Si el archivo no tiene ningún endpoint reportado, entonces el puerto que probablemente está bloqueado es el 135.

4. Seguridad

Lo primero que hay que hacer es verificar los grupos que tienen derecho a contactar el servidor por la red (User Rights: Access this computer from the network)
La mejor manera de ver estos derechos es ejecutando

C:\>Rsop.msc

Expandimos: Computer Configuration->Windows Settings->Security Settings->Local Policies->User Right Assignment

Doble click en el derecho llamado “Access this computer from the network” y verifica que, como mínimo, los siguientes grupos tienen este derecho:

Everyone
Authenticated Users
Enterprise Domain Controllers

Si este derecho no está otorgado a estos grupos, tendríamos que verificar las políticas aplicadas al dominio (Default Domain Policy) o a los controladores de dominio (Default Domain Controller Policy).

Verifiquemos que los relojes este sincronizados entre el servidor de la agencia y el PDC del dominio.
Si los relojes no están sincronizados y sabes cuál es el PDC, puedes usar el comando:

C:\>net time \\pdc /set /y

Si no recordamos el nombre del PDC, tenemos que averiguarlo ? y podemos hacerlo con la herramienta “netdom”, entre otras, como sigue:

C:\>netdom query fsmo

Posterior a ellos, deberíamos verificar que el servicio KDC está funcionando

En la consola de “Active Directory Users and Computers” buscamos el objeto del controlador de domino de la sucursal y verificamos, en la pestaña General, que el check de “Trust this computer for delegation” está marcada.

Usando adsiedit.msc expandimos el contenedor “Domain”, expandimos el objeto del dominio “DC=ejemplo, dc=lab”, expandimos la “OU=Domain Controllers”, y hacemos un click derecho en el objeto del controlador de dominio “CN=dc10”, por ejemplo.
Seleccionar Properties y buscar userAccountControl. EL valor de este atributo debe ser 532480. Hacemos esta misma prueba tanto en la maquina remota como en la maquina del sitio central. La idea aquí es verificar que el valor de este atributo del objeto dc10 sea 532480 en las dos copias del AD.

En el servidor de la agencia, instala el tool klist.exe y ejecuta los siguientes comandos:

C:\>net stop kdc
C:\>at system_time /interactive cmd.exe

(donde system_time debe ser la hora local más uno o dos minutos)

Cuando abramos el command prompt (Esta ventana NO se va a abrir si estas conectado vía TS al servidor. Este paso tienes que hacerlo directo en la consola del server. A menos que agreguemos el switch “/console” cuando ejecutas el comando mstsc), ejecuta los comandos

c:\>klist purge
c:\>ipconfig /flushdns
c:\>nbtstat -R

Los siguientes pasos son para el reset del secure channel entre los DCs. Este paso es el que probablemente arregle el problema entre DC01 y DC10. Esto debemos hacerlo en el servidor que está fallando en traerse la replicación, en este caso, en los servidores de la sucursal. El servicio del KDC debe seguir detenido.

Ejecuta el comando

c:\>netdom resetpwd /server:PDCe /userd:ejemplo\Administrator /password:*

En este comando, el server PDCe es el partner de replicación (que tiene el KDC funcionando, y que no necesariamente es el KDC del dominio)

En este caso, el procedimiento lo vas a realizar en dc10 y el comando es:

c:\>netdom resetpwd /server:dc01 /userd:ejemplo\Administrator /password:*

Una vez resincronizado el password y desde el server de la sucursal, accedemos al servidor central con su FQDN para conseguir nuevos tickets Kerberos, por ejemplo:

c:\>net use \\dc01.ejemplo.lab\IPC$

inicia el servicio del KDC

c:\>net start kdc

Los pasos siguientes solo deben hacerse en el servidor DC01
Abrir AD Sites and Services, seleccionar el servidor dc01, y luego NTDS Settings.
Eliminar las conexiones inbound del controlador de dominio con problemas (DC10) y luego ejecuta

c:\>repadmin /kcc

Para forzar la replicación con el servidor de la central, ejecutamos el comando:

c:\>repadmin /syncall /d /e dc10 “DC=ejemplo,DC=lab”

Verificar los SPN registrados. Podemos utilizar el siguiente artículo: KB 308111
En el servidor de la sucursal, ejecutamos el comando:

ldifde –s nombre-server-de-central -f spndump.txt -p base -l servicePrincipalName -d “cn=dc01,ou=Domain Controllers,dc=ejemplo,dc=lab”

para exportar de la base de datos local los SPNs que están registrados del servidor central.
Si en el archivo spndump.txt falta alguno de los 4 SPN del tipo host/*
HOST/dc01
HOST/dc01.ejemplo.lab
HOST/dc01.ejemplo.lab/ejemplo.lab
HOST/dc01.ejemplo.lab/EJEMPLO

Ejecuta el comando:

C:\>setspn –a SPN-faltante nombre-server-de-sucursal, por ejemplo:

C:\>setspn –a HOST/dc01.ejemplo.lab dc10

Verificar que la fragmentación de la red no está dañando la autenticación de Kerberos. Podemos utilizar el siguiente artículo: KB 244474
Desde el server de la sucursal, verifica que el comando:

Ping dc01.ejemplo.lab –f –l 1472.

Si el resultado del comando es el mensaje “Packet needs to be fragmented but DF set.” Entonces es posible que exista un problema de fragmentación del trafico UDP en la red. Este problema puede causar las fallas de Kerberos.
La opción aquí es configurar Kerberos para utilizar solo TCP, como se explica en el artículo de la KB 244474.

Nota: De forma predeterminada, Windows Server 2008 y Windows Vista intentará TCP primero para Kerberos.

Una vez aplicado el plan de acción, intentamos una replicación entre los dos sites designados, obteniendo el siguiente resultado:

DC=ejemplo,DC=lab, Replication failed!
CN=Configuration,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:21:59.
CN=Schema,CN=Configuration,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:22:00
DC=DomainDnsZones,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:22:00
DC=ForestDnsZones,DC=ejemplo,DC=lab, replicada con éxito @ 2010-03-12 05:22:01.

En resumen, todas las particiones menos la partición de dominio replicaron esta mañana a las 5:20.

Lingering Objects

La partición de dominio falló en su intento de replicación ya que existen lingering objects. Este, así como también problemas de objetos en estado de tombstone, son problemas que de seguro encontraremos a lo largo del proceso de troubleshooting de la replicación de Active Directory. Dichos problemas iremos solucionándolos a medida que avanzamos sobre el plan aquí enunciado. Continuando con el problema de lingering objects, lo validamos y solucionamos de la siguiente manera:

Cuando investigamos el log de Directory Services, encontramos errores de lingering objects que están bloqueando la replicación de la partición de dominio.

El evento es el 1988:

“Active Directory Replication encountered the existence of objects in the following partition that have been deleted from the local domain controllers (DCs) Active Directory database. Not all direct or transitive replication partners replicated in the deletion before the tombstone lifetime number of days passed. Objects that have been deleted and garbage collected from an Active Directory partition but still exist in the writable partitions of other DCs in the same domain, or read-only partitions of global catalog servers in other domains in the forest are known as 'lingering objects'.

This event is being logged because the source DC contains a lingering object which does not exist on the local DCs Active Directory database. This replication attempt has been blocked.

The best solution to this problem is to identify and remove all lingering objects in the forest. Source DC (Transport-specific network address): de11d929-55f9-4dc6-b702-b63e380f6d91._msdcs.ejemplo.lab Object: CN=CD075003-Xerox WorkCentre PE16ADEL:f2343d56-3bc3-44fb-8b3c-52ea1ecc038d,CN=Deleted Objects,DC=ejemplo,DC=lab Object GUID: f2343d56-3bc3-44fb-8b3c-52ea1ecc038d

User Action: Remove Lingering Objects: The action plan to recover from this error can be found at https://support.microsoft.com/id=314282

If both the source and destination DCs are Windows Server 2003 DCs, then install the support tools included on the installation CD. To see which objects would be deleted without actually performing the deletion run 'repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC> /ADVISORY_MODE'. The event logs on the source DC will enumerate all lingering objects. To remove lingering objects from a source domain controller run 'repadmin /removelingeringobjects <Source DC> <Destination DC DSA GUID> <NC>'. If either source or destination DC is a Windows 2000 Server DC, then more information on how to remove lingering objects on the source DC can be found at https://support.microsoft.com/?id=314282 or from your Microsoft support personnel. If you need Active Directory replication to function immediately at all costs and don't have time to remove lingering objects, enable loose replication consistency by unsetting the following registry key: Registry Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict Replication Consistency. Replication errors between DCs sharing a common partition can prevent user and computer accounts, trust relationships, their passwords, security groups, security group memberships and other Active Directory configuration data to vary between DCs, affecting the ability to log on, find objects of interest and perform other critical operations. These inconsistencies are resolved once replication errors are resolved. DCs that fail to inbound replicate deleted objects within tombstone lifetime number of days will remain inconsistent until lingering objects are manually removed by an administrator from each local DC. Lingering objects may be prevented by ensuring that all domain controllers in the forest are running Active Directory, are connected by a spanning tree connection topology and perform inbound replication before Tombstone Live number of days pass.”

Este error indica que el objeto CD075003-Xerox WorkCentre fue borrado en el servidor de la Sucursal, pero todavía existe en el AD del dc01.

Lo que tenemos que hacer es lo siguiente:

En el servidor dc01 ejecuta el comando:

C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-4dd35916b89c DC=ejemplo,DC=lab /ADVISORY_MODE

Este comando va a generar la lista de lingering objects (desde el punto de vista de dc10) que existen en dc01

Si todo está bien, y conseguimos el objeto, entonces ejecutamos:

C:\repadmin /removelingeringobjects dc01.ejemplo.lab 19d40098-6fba-44ae-a8a8-4dd35916b89c DC=ejemplo,DC=lab

Una vez realizado la remoción del objeto en estado de lingering, la replicación de todas las particiones de Active Directory se realizaron de manera satisfactoria.

Una vez que tenemos la replicación funcionando entre los dos sites, el central y la sucursal, deberíamos ir tomando las siguientes sucursales, e ir aplicando este plan de acción, repito que es posible que nos encontremos con problemas adicionales, como ser algún servidor que se encuentre en estado de tombstone (adjuntamos un artículo sobre cómo tratar este inconveniente) o algún problema de conectividad, en tales casos deberemos proceder a resolverlos y continuar con nuestro plan de acción.

Referencias

Esperamos que esta guía les sea de utilidad.

Saludos y hasta pronto!

Comments

Anonymous
March 17, 2016
A los Srs Juan Carlos Albert y Martin Kirtchayan les agradezco su tiempo y dedicación en la elaboración de esta explicación, Excelente información y muy bien explicada.
Anonymous
September 07, 2016
Les agradezco su instructivo esta fantástico.
Anonymous
June 05, 2017
The comment has been removed
- Anonymous
  July 21, 2017
  Hola Francisco, entiendo que el problema lo tenes a nivel de capa de red, desde una ubicacion remota a serverdc1 especificamente. necesitaria un poco mas de detalle para entender un poco major el context, pero entiendo te puede ayudar lo siguiente:Si el ping se lo haces por nombre, proba hacerlo por IP, si tambien falla, el problema lo tenes a nivel de capa de red. en dicho caso podes tomar una captura de red tanto en el origen, como en el destino, mientras reproducis el problema. y apartir de alli comenzar a ir mas profundo.Si el ping solo falla a nivel de nombre, es posible que tengas unproblema a nivel de resolucion de nombres. en ese caso podes usar nslookup para validar la resolucion, como tambien verificar a que DNS server estas contactando cuando pasa el problema.espero te sea de utilidad.

Freigeben über