Cómo solucionar el error 5 de replicación de Active Directory en Windows Server: se deniega el acceso

En este artículo se describen los síntomas, la causa y la resolución de situaciones en las que se produce un error 5 en la replicación de Active Directory: Se deniega el acceso.

Versión original del producto:   Windows Server 2012 R2
Número KB original:   3073945

Síntomas

Es posible que encuentre uno o varios de los síntomas siguientes cuando se produce un error 5 en las replicaciones de Active Directory.

Síntoma 1

La Dcdiag.exe de línea de comandos informa de que la prueba de replicación de Active Directory falla con código de estado de error (5). El informe es similar al siguiente:

Servidor de pruebas: Site_Name \ Destination_DC_Name
Prueba inicial: Replicaciones
*Replications Check
[Comprobación de replicaciones,Destination_DC_Name] Error en un intento de replicación reciente:
De Source_DC a Destination_DC
Contexto de nomenclatura: Directory_Partition_DN_Path
La replicación generó un error (5):
Acceso denegado.
El error se produjo en la fecha y hora.
El último éxito se produjo en la fecha y hora.
Se han producido errores de número desde el último éxito.

Síntoma 2

La Dcdiag.exe de línea de comandos informa de que la función DsBindWithSpnEx produce un error 5 al ejecutar el DCDIAG /test:CHECKSECURITYERROR comando.

Síntoma 3

La REPADMIN.exe de línea de comandos informa de que el último intento de replicación ha fallado con el estado 5.

Los comandos REPADMIN que citan con frecuencia el estado de cinco incluyen, entre otros, los siguientes:

  • REPADMIN /KCC
  • REPADMIN /REPLICATE
  • REPADMIN /REPLSUM
  • REPADMIN /SHOWREPL
  • REPADMIN /SHOWREPS
  • REPADMIN /SYNCALL

A continuación se muestra REPADMIN /SHOWREPL el resultado de ejemplo del comando. Este resultado muestra la replicación entrante de DC_2_Name a DC_1_Name error con el error "Acceso denegado".

Site_Name \ DC_1_Name
Opciones de DSA: IS_GC
Opciones de sitio: (ninguno)
GUID de objeto DSA: GUID
DSA invocationID: invocationID

==== INBOUND DESOY==
DC= DomainName,DC=com
Site_Name \ DC_2_Name a través de RPC
GUID de objeto DSA: GUID
Último intento @ Error de fecha y hora, resultado 5(0x5):
Acceso denegado.
<#> errores consecutivos.
Last success @ Date Time.

Síntoma 4

Los eventos NTDS KCC, NTDS General o Microsoft-Windows-ActiveDirectory_DomainService con el estado cinco se registran en el registro de Servicios de directorio en el Visor de eventos.

En la tabla siguiente se resumen los eventos de Active Directory que citan con frecuencia el estado 8524.

Id. de evento Origen Cadena de evento
1655 NTDS General Active Directory intentó comunicarse con el siguiente catálogo global y los intentos no se realizaron correctamente.
1925 NTDS KCC Error al intentar establecer un vínculo de replicación para la siguiente partición de directorio grabable.
1926 NTDS KCC Error al intentar establecer un vínculo de replicación a una partición de directorio de solo lectura con los siguientes parámetros.

Síntoma 5

Al hacer clic con el botón secundario en el objeto de conexión desde un controlador de dominio de origen en Sitios y servicios de Active Directory y, a continuación, seleccionar Replicar ahora, se produce un error en el proceso y recibe el siguiente error:

Replicar ahora

Se produjo el siguiente error durante el intento de sincronizar el contexto de nomenclatura % nombre de partición de directorio % de DC de origen del controlador de dominio con dc de destino del controlador de dominio: se deniega el acceso.

La operación no continuará.

La siguiente captura de pantalla representa una muestra del error:

Muestra del error

Solución alternativa

Use la herramienta de línea de comandos DCDIAG genérica para ejecutar varias pruebas. Use la herramienta de línea de comandos DCDIAG /TEST:CheckSecurityErrors para realizar pruebas específicas. (Estas pruebas incluyen una comprobación de registro de SPN). Ejecute las pruebas para solucionar problemas de replicación de operaciones de Active Directory con el error 5 y el error 8453. Sin embargo, tenga en cuenta que esta herramienta no se ejecuta como parte de la ejecución predeterminada de DCDIAG.

Para evitar este problema, siga estos pasos:

  1. En el símbolo del sistema, ejecute DCDIAG en el controlador de dominio de destino.
  2. Ejecute DCDAIG /TEST:CheckSecurityError .
  3. Ejecute NETDIAG.
  4. Resuelva los errores identificados por DCDIAG y NETDIAG.
  5. Reintente la operación de replicación con errores anteriores. Si las replicaciones siguen dando error, consulte la sección"Causas y soluciones".

Causas y soluciones

Las siguientes causas pueden provocar el error 5. Algunas de ellas tienen soluciones.

Causa 1: la configuración RestrictRemoteClients en el Registro tiene un valor de 2

Si la configuración de directiva de clientes RPC no autenticados está habilitada y se establece en Autenticado sin excepciones, el valor del Registro RestrictRemoteClients se establece en un valor de 0x2 en la subclave del HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC Registro.

Esta configuración de directiva permite que solo los clientes de llamada a procedimiento remoto (RPC) autenticados se conecten a los servidores RPC que se ejecutan en el equipo en el que se aplica la configuración de directiva. No permite excepciones. Si selecciona esta opción, un sistema no puede recibir llamadas anónimas remotas mediante RPC. Esta configuración nunca debe aplicarse a un controlador de dominio.

Solución

  1. Deshabilite la configuración de directiva de clientes RPC sin autenticar que restringe el valor del Registro RestrictRemoteClients a 2.

    Nota

    La configuración de directiva se encuentra en la siguiente ruta: Configuración del equipo\Plantillas administrativas\Sistema\Llamada a procedimiento remoto\Restricciones para clientes RPC no autenticados

  2. Elimina la configuración del Registro RestrictRemoteClients y, a continuación, reinicia.

Vea restricciones para clientes RPC no autenticados:la directiva de grupo que fuerza el dominio en la cara.

Causa 2: La configuración CrashOnAuditFail en el registro del controlador de dominio de destino tiene un valor de 2

Se desencadena un valor crashOnAduitFail de 2 si el sistema Auditoría: apagar inmediatamente si no se puede registrar la configuración de directiva de auditorías de seguridad en la directiva de grupo está habilitado y el registro de eventos de seguridad local se llena.

Los controladores de dominio de Active Directory son especialmente propensos a los registros de seguridad de capacidad máxima cuando la auditoría está habilitada y el tamaño del registro de eventos de seguridad está restringido por no sobrescribir eventos (borrar registro manualmente) y Sobrescribir como opciones necesarias en el Visor de eventos o sus equivalentes de directiva de grupo.

Solución

Importante

Siga atentamente los pasos de esta sección. La modificación incorrecta del Registro puede producir graves problemas. Antes de modificarlo, realice una copia de seguridad del Registro para efectuar una restauración en caso de que surjan problemas.

  1. Borre el registro de eventos de seguridad y guárdelo en una ubicación alternativa según sea necesario.
  2. Vuelva a evaluar las restricciones de tamaño en el registro de eventos de seguridad. Esto incluye la configuración basada en directivas.
  3. Elimine y, a continuación, vuelva a crear una entrada del Registro CrashOnAuditFail de la siguiente manera: subclave del Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
    Nombre del valor: CrashOnAuditFail
    Tipo de valor: REG_DWORD
    Datos de valor: 1
  4. Reinicie el controlador de dominio de destino.

Causa 3: Confianza no válida

Si se produce un error en la replicación de Active Directory entre controladores de dominio en dominios diferentes, debe comprobar el estado de las relaciones de confianza en la ruta de confianza.

Puede probar la prueba de relación de confianza de NetDiag para comprobar si hay confianzas rotas. La Netdiag.exe identifica las confianzas rotas mostrando el siguiente texto:

Prueba de relación de confianza. . . . . . : error
Pruebe para asegurarse de que domainSid of domain 'domainname' es correcto.
[FATAL] Se ha roto el canal seguro al dominio 'nombrede dominio'.
[% código de estado variable %]

Por ejemplo, si tiene un bosque de varios dominios que contiene un dominio raíz ( ), un dominio secundario ( ), un dominio secundario ( ) y un dominio de árbol en el mismo bosque ( ) y si la replicación está fallando entre los controladores de dominio en el dominio secundario ( ) y el dominio de árbol ( , debe comprobar el estado de confianza entre y , entre y , y , y, por último, Contoso.COM B.Contoso.COM entre y C.B.Contoso.COM Fabrikam.COM C.B.Contoso.COM Fabrikam.COM) C.B.Contoso.COM B.Contoso.COM B.Contoso.COM Contoso.COM Contoso.COM Fabrikam.COM .

Si existe una confianza de acceso directo entre los dominios de destino, no tiene que validar la cadena de ruta de acceso de confianza. En su lugar, debe validar la confianza de acceso directo entre el dominio de destino y el dominio de origen.

Para comprobar si hay cambios recientes de contraseña en la confianza, ejecute el siguiente comando:

Repadmin /showobjmeta * <DN path for TDO in question>

Compruebe que el controlador de dominio de destino está entrante y transitivamente replicando la partición del directorio de dominio grabable donde pueden tener efecto los cambios de contraseña de confianza.

Los comandos para restablecer confianzas desde el dominio raíz PDC son los siguientes:

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay

Los comandos para restablecer confianzas del dominio secundario PDC son los siguientes:

netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset /TwoWay

Causa 4: Sesgo de tiempo excesivo

La configuración de la directiva Kerberos en la directiva de dominio predeterminada permite una diferencia de cinco minutos en el tiempo del sistema (este es el valor predeterminado) entre los controladores de dominio KDC y los servidores de destino Kerberos para evitar ataques de reproducción. En algunas documentación se indica que la hora del sistema del cliente y la del destino Kerberos deben estar en un plazo de cinco minutos entre sí. Otra documentación indica que, en el contexto de la autenticación Kerberos, el tiempo que es importante es la diferencia entre el KDC que usa el autor de la llamada y la hora en el destino Kerberos. Además, a Kerberos no le importa si la hora del sistema en los controladores de dominio relevantes coincide con la hora actual. Solo le importa que la diferencia de tiempo relativa entre el KDC y el controlador de dominio de destino esté dentro del sesgo de tiempo máximo que permite la directiva Kerberos. (El tiempo predeterminado es de cinco minutos o menos).

En el contexto de las operaciones de Active Directory, el servidor de destino es el controlador de dominio de origen con el que se contacta con el controlador de dominio de destino. Cada controlador de dominio de un bosque de Active Directory que ejecuta actualmente el servicio KDC es un KDC potencial. Por lo tanto, debe tener en cuenta la precisión de tiempo en todos los demás controladores de dominio con respecto al controlador de dominio de origen. Esto incluye la hora en el propio controlador de dominio de destino.

Puede usar los dos comandos siguientes para comprobar la precisión de la hora:

  • DCDIAG /TEST:CheckSecurityError
  • W32TM /MONITOR

Puede encontrar resultados de ejemplo de DCDIAG /TEST:CheckSecurityError en lasección "Más información". En este ejemplo se muestra un exceso de sesgo de tiempo en los controladores de dominio basados en Windows Server 2003 y Windows Server 2008 R2.

Busque eventos LSASRV 40960 en el controlador de dominio de destino en el momento de la solicitud de replicación con error. Busque eventos que citen un GUID en el registro CNAME del controlador de dominio de origen con el error extendido 0xc000133. Busque eventos similares a los siguientes:

El tiempo en el controlador de dominio principal es diferente del tiempo en el controlador de dominio de copia de seguridad o en el servidor miembro en una cantidad demasiado grande

Los seguimientos de red que capturan el equipo de destino que se conecta a una carpeta compartida en el controlador de dominio de origen (y también otras operaciones) pueden mostrar el error "Se ha producido un error extendido" en pantalla, pero un seguimiento de red muestra lo siguiente:

-> KerberosV5 KerberosV5:TGS Request Realm: <- TGS request from source DC
<- Kerberosvs Kerberosvs:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- Respuesta TGS donde "KRB_AP_ERR_TKE_NYV
<- se asigna a "Vale no válido todavía" <- se asigna a "Vale aún no válido"

La TKE_NYV respuesta indica que el intervalo de fechas en el vale TGS es más reciente que la hora en el destino. Esto indica un sesgo de tiempo excesivo.

Nota

  • W32TM /MONITOR comprueba el tiempo solo en los controladores de dominio del dominio de los equipos de prueba, por lo que debe ejecutar esto en cada dominio y comparar el tiempo entre los dominios.
  • Cuando la diferencia de tiempo es demasiado grande en los controladores de dominio de destino basados en Windows Server 2008 R2, el comando Replicar ahora en DSSITE. MSC produce un error en pantalla "Hay una diferencia de fecha y hora entre el cliente y el servidor". Esta cadena de error se asigna al error 1398 decimal o 0x576 hexadecimal con el ERROR_TIME_SKEW de error simbólico.

Para obtener más información, vea Establecer la tolerancia de sincronización de reloj para evitar ataques de reproducción.

Causa 5: Hay un canal de seguridad no válido o una contraseña que no coincide en el controlador de dominio de origen o destino

Valide el canal de seguridad ejecutando uno de los siguientes comandos:

  • nltest /sc:query
  • netdom verify

Si está en condiciones, restablezca la contraseña del controlador de dominio de destino con NETDOM /RESETPWD.

Solución

  1. Deshabilite el servicio del Centro de distribución de claves (KDC) Kerberos en el controlador de dominio que se reinicie.

  2. Desde la consola del controlador de dominio de destino, ejecute para restablecer la contraseña del controlador de NETDOM RESETPWD dominio de destino de la siguiente manera:

    c:\>netdom resetpwd /server: server_name /userd: domain_name\administrator /passwordd: administrator_password
    
  3. Asegúrese de que los KDC probables y el controlador de dominio de origen (si están en el mismo dominio) de entrada replican el conocimiento de la nueva contraseña del controlador de dominio de destino.

  4. Reinicie el controlador de dominio de destino para actualizar los vales kerberos y reintentar la operación de replicación.

Vea cómo usar los Netdom.exe para restablecer las contraseñas de las cuentas de equipo de un controlador de dominio.

Causa 6: El derecho de usuario "Acceder a este equipo desde la red" no se concede a un usuario que desencadena la replicación.

En una instalación predeterminada de Windows, la directiva de controlador de dominio predeterminada está vinculada a la unidad organizativa (OU) del controlador de dominio. La ou concede acceso a este equipo desde el derecho de usuario de red a los siguientes grupos de seguridad:

Directiva local Directiva de controlador de dominio predeterminada
Administradores Administradores
Usuarios autenticados Usuarios autenticados
Todos Todos
Controladores de dominio de empresa Controladores de dominio de empresa
[Access compatible con versiones anteriores a Windows 2000] Acceso compatible con versiones anteriores a Windows 2000

Si se produce un error 5 en las operaciones de Active Directory, debe comprobar los siguientes puntos:

  • A los grupos de seguridad de la tabla se les concede acceso a este equipo desde el derecho de usuario de red en la directiva del controlador de dominio predeterminado.
  • Las cuentas de equipo del controlador de dominio se encuentran en la unidad organizativa del controlador de dominio.
  • La directiva predeterminada del controlador de dominio está vinculada a la unidad organizativa del controlador de dominio o a unidades organizativas alternativas que hospedan cuentas de equipo.
  • La directiva de grupo se aplica en el controlador de dominio de destino que actualmente registra el error 5.
  • El acceso denegado a este equipo desde el derecho de usuario de red está habilitado o no hace referencia a grupos directos o transitivos que el contexto de seguridad que usa el controlador de dominio o la cuenta de usuario que desencadena la replicación.
  • La prioridad de la directiva, la herencia bloqueada, el filtrado de Instrumental de administración de Microsoft Windows (WMI) o algo parecido, no impide que la configuración de directiva se aplique a los equipos de rol de controlador de dominio.

Nota

  • La configuración de directiva se puede validar con RSOP. Herramienta MSC. Sin embargo, GPRESULT /Z es la herramienta preferida porque es más precisa.
  • La directiva local tiene prioridad sobre la directiva que se define en sitios, dominios y la OU.
  • En un momento, era común que los administradores quitara los grupos "Controladores de dominio de empresa" y "Todos" de la configuración de directiva "Acceder a este equipo desde la red" en la directiva del controlador de dominio predeterminado. Sin embargo, quitar ambos grupos es irreales. No hay ninguna razón para quitar "Controladores de dominio de empresa" de esta configuración de directiva, porque solo los controladores de dominio son miembros de este grupo.

Causa 7: Hay un error de coincidencia de firmas SMB entre los controladores de dominio de origen y de destino

Configuración de directiva Ruta del Registro
Cliente de red de Microsoft: firmar digitalmente las comunicaciones (si el servidor lo acepta) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
Cliente de red de Microsoft: firmar digitalmente las comunicaciones (siempre) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
Servidor de red de Microsoft: firmar digitalmente las comunicaciones (si el servidor lo acepta) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
Servidor de red de Microsoft: firmar digitalmente las comunicaciones (siempre) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature

Debes centrarte en los desajustes de firma smb entre los controladores de dominio de destino y de origen. Los casos clásicos implican una configuración que está habilitada o necesaria en un lado pero deshabilitada en el otro.

Causa 8: fragmentación de paquetes Kerberos con formato UDP

Los enrutadores y conmutadores de red pueden fragmentar o eliminar completamente paquetes de red con formato UDP (Protocolo de datagramas de usuario) de gran tamaño que usan Kerberos y los mecanismos de extensión para DNS (EDNS0). Los equipos que ejecutan familias de sistemas operativos Windows 2000 Server o Windows Server 2003 son especialmente vulnerables a la fragmentación UDP en equipos que ejecutan Windows Server 2008 o Windows Server 2008 R2.

Solución

  1. Desde la consola del controlador de dominio de destino, haga ping al controlador de dominio de origen por su nombre de equipo completo para identificar el paquete más grande admitido por la ruta de red. Para comprobarlo, ejecute el siguiente comando:

    c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472
    
  2. Si el paquete no fragmentado más grande es inferior a 1.472 bytes, pruebe uno de los métodos siguientes (por orden de preferencia):

    • Cambiar la infraestructura de red para que admita adecuadamente fotogramas UDP grandes. Esto puede requerir una actualización de firmware o un cambio de configuración en enrutadores, conmutadores o firewalls.
    • Establezca maxpacketsize (en el controlador de dominio de destino) en el paquete más grande identificado por el comando PING -f -l menos 8 bytes para tener en cuenta el encabezado TCP y, a continuación, reinicie el controlador de dominio cambiado.
    • Establezca maxpacketsize (en el controlador de dominio de destino) en un valor de 1. Esto desencadena la autenticación Kerberos para usar un TCP. Reinicie el controlador de dominio cambiado para que el cambio suba efecto.
  3. Reintente la operación de Active Directory con error.

Causa 9: Los adaptadores de red tienen habilitada la característica de descarga de envío grande

Solución

  1. En el controlador de dominio de destino, abra las propiedades del adaptador de red.
  2. Haga clic en el botón Configurar.
  3. Seleccione la pestaña Avanzadas.
  4. Deshabilite la propiedad IPv4 Large Send Offload.
  5. Reinicie el controlador de dominio.

Causa 10: Dominio kerberos no válido

El dominio kerberos no es válido si se cumplen una o varias de las siguientes condiciones:

  • La entrada del Registro KDCNames contiene incorrectamente el nombre de dominio local de Active Directory.
  • La clave del Registro PolAcDmN y la clave del Registro PolPrDmN no coinciden.

Soluciones

Importante

Siga atentamente los pasos de esta sección. La modificación incorrecta del Registro puede producir graves problemas. Antes de modificarlo, realice una copia de seguridad del Registro para efectuar una restauración en caso de que surjan problemas.

Solución para la entrada del Registro KDCNames incorrecta

  1. En el controlador de dominio de destino, ejecute REGEDIT.

  2. Busque la siguiente subclave en el Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains

  3. Para cada <Fully_Qualified_Domain> en la subclave, compruebe que el valor de la entrada del Registro KdcNames hace referencia a un dominio Kerberos externo válido y no al dominio local u otro dominio del mismo bosque de Active Directory.

Solución para claves del Registro PolAcDmN y PolPrDmN que no coincide

Nota

Este método solo es válido para controladores de dominio que ejecutan Windows 2000 Server.

  1. Inicie el Editor del Registro.

  2. En el panel de navegación, expanda Seguridad.

  3. En el menú Seguridad, haga clic en Permisos para conceder al grupo local Administradores el control total del subárbol SEGURIDAD y sus contenedores y objetos secundarios.

  4. Busque la siguiente subclave en el Registro:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN

  5. En el panel derecho del Editor del Registro, haga clic en ****Sin nombre: REG_NONE registro una vez.

  6. En el menú Ver, haga clic en Mostrar datos binarios.

  7. En la sección Formato del cuadro de diálogo, haga clic en Byte.

    El nombre de dominio se muestra como una cadena en el lado derecho del cuadro de diálogo Datos binarios. El nombre de dominio es el mismo que el dominio kerberos.

  8. Busque la siguiente subclave en el Registro:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN

  9. En el panel derecho del Editor del Registro, haga doble clic en la entrada ****No Name : REG_NONE.

  10. En el cuadro de diálogo Editor binario, pegue el valor de la subclave del Registro PolPrDmN. (El valor de la subclave del Registro PolPrDmN es el nombre de dominio NetBIOS).

  11. Reinicie el controlador de dominio. Si el controlador de dominio no funciona correctamente, vea otros métodos.

Causa 11: Hay un error de coincidencia de compatibilidad del administrador de LAN (compatibilidad con LM) entre los controladores de dominio de origen y de destino

Causa 12: Los nombres de entidad de seguridad de servicio no están registrados o no están presentes debido a una latencia de replicación simple o a un error de replicación.

Causa 13: El software antivirus usa un controlador de filtro de adaptador de red de mini firewall en el controlador de dominio de origen o destino

Estado

Microsoft ha confirmado que se trata de un problema en los productos de Microsoft que se enumeran en la sección "Se aplica a".

Más información

Los errores y eventos de Active Directory, como los descritos en la sección "Síntomas", también pueden producir errores 8453 junto con la siguiente cadena de error similar:

Se denegó el acceso de replicación.

Las siguientes situaciones pueden provocar errores en las operaciones de Active Directory con el error 8453. Sin embargo, estas situaciones no provocan errores con el error 5.

  • El jefe de contexto de nomenclatura (NC) no está permitido con el permiso Replicar cambios de directorio.
  • La entidad de seguridad que inicia la replicación no es miembro de un grupo al que se le concede el permiso de replicación de cambios de directorio.
  • Faltan marcas en el atributo UserAccountControl. Estos incluyen la marca SERVER_TRUST_ACCOUNT y la marca TRUSTED_FOR_DELEGATION.
  • El controlador de dominio de solo lectura (RODC) se une al dominio sin que ADPREP /RODCPREP el comando se ejecute primero.

Salida de ejemplo de DCDIAG /TEST:CheckSecurityError

A continuación se muestra la salida DCDIAG /test:CHECKSECURITYERROR de un controlador de dominio de Windows Server 2008 R2. Este resultado se debe a un sesgo excesivo del tiempo.

Realizar pruebas principales en el servidor de <Site_Name> \ pruebas:<Destination_DC_Name> prueba de inicio: CheckSecurityError
Dc de <Source DC> origen tiene un posible error de seguridad (1398).
Diagnosticar...
Error de sesgo de tiempo entre el cliente y 1 DCs. ERROR_ACCESS_DENIED
o equipo de abajo recibido por:
<Source DC> [ <Source DC> ] Error DsBindWithSpnEx() con el error 1398,
Hay una diferencia de fecha y hora entre el cliente y el servidor.
Omitir DC en <Source DC> la prueba de convergencia del objeto
CN= <Destination_DC> ,OU=Controladores de dominio,DC= <DomainName> ,DC=com, porque
no se puede conectar.
......................... <Destination_DC> error de prueba CheckSecurityError

A continuación se muestra el resultado DCDIAG /CHECKSECURITYERROR de ejemplo de un controlador de dominio basado en Windows Server 2003. Esto se debe a un exceso de sesgo de tiempo.

Realizar pruebas principales
Servidor de pruebas: <Site_Name> \<Destination_DC_Name>
Prueba inicial: CheckSecurityError
La DC <Source DC> de origen tiene un posible error de seguridad (5). Diagnosticar...
Error de sesgo de tiempo entre el cliente y 1 DCs. ERROR_ACCESS_DENIED o hacia abajo recibidos por: <Source DC>
Dc de <Source DC> _has posible error de seguridad (5). Diagnosticar...
Error de sesgo de tiempo: 7205 segundos diferentes entre:.
<Source DC>
<Destination_DC>
[ <Source DC> ] DsBindWithSpnEx() failed with error 5,
Se deniega el acceso.
Omitir DC en la prueba de convergencia del objeto <Source DC> CN= <Destination_DC> ,OU=Controladores de dominio,DC= <DomainName> ,DC=com, porque no podemos conectarnos.
......................... <Destination_DC> error de prueba CheckSecurityError

A continuación se muestra un ejemplo de salida DCDIAG /CHECKSECURITYERROR. Muestra los nombres de SPN que faltan. (El resultado puede variar de un entorno a otro).

Realizar pruebas principales
Servidor de pruebas: <site name>\<dc name>
Prueba omitida por solicitud de usuario: Publicidad
Prueba inicial: CheckSecurityError
* Dr Auth: Beginning security errors check'
KDC encontrado <KDC DC> para el dominio en el <DNS Name of AD domain> sitio <site name>
Comprobar la cuenta de la máquina para DC <DC name> en DC <DC Name>
* Falta SPN :LDAP/ <hostname> .<DNS domain name>/<DNS domain name>
* Falta SPN :LDAP/ <hostname> .<DNS domain name>
* Falta SPN :LDAP/<hostname>
* Falta SPN :LDAP/ <hostname> .<DNS domain name>/<NetBIOS domain name>
* Falta SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>
* SPN found :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root domain DNS name>
* Falta SPN :HOST/ <hostname> .<DNS domain name>/<DNS domain name>
* SPN encontrado :HOST/ <hostname> .<DNS domain name>
* SPN encontrado :HOST/<hostname>
* Falta SPN :HOST/ <hostname> .<DNS domain name>/<NetBIOS domain name>
*Falta SPN :GC/ <hostname> . <DNS domain name> / <DNS domain name> No se puede comprobar la cuenta de la máquina ( <DN path for Dc machine account> ) <DC Name> para on <DC name> .