Seguridad : Cisco Identity Services Engine

Troubleshooting ISE y fallas de la sincronización del servidor NTP en Microsoft Windows

16 Enero 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (18 Noviembre 2015) | Comentarios

Introducción

Este documento describe un problema se encuentre que cuando el Cisco Identity Services Engine (ISE) y otro Linux-basó los servidores no puede sincronizar con un servidor del Network Time Protocol (NTP) que está instalado en un Microsoft Windows server. Una solución a este problema también se proporciona.

Contribuido por Michal Garcarz, Serhii Kucherenko, y Anastasiya Volkova, ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

  • Configuración CLI de Cisco ISE

  • Conocimiento básico sobre el NTP

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Versión 2012 del Microsoft Windows server

  • Versiones de software 1.3 de Cisco ISE y posterior

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Problema

Después de que usted configure el ISE CLI para utilizar el Microsoft Windows server como NTP, no sincroniza. Se utiliza la configuración de controlador del Default Domain del Microsoft Windows server 2012 (configuración del NTP predeterminada). El ISE señala que la fuente local todavía está utilizada:

ise14/admin# show ntp
Configured NTP Servers:
10.62.145.72

synchronised to local net at stratum 11
time correct to within 11 ms
polling server every 1024 s

remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 9 64 377 0.000 0.000 0.000
10.62.145.72 .LOCL. 1 u 226 1024 377 0.896 -3.998 4.130

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

Todos los parámetros (accesibilidad, retardo, desplazamiento, y jitter) no aparecen estar correctos, y allí son ninguna manera de resolver problemas el problema del CLI (error de la sincronización NTP). Para la confirmación del problema, usted debe ir al nivel de la raíz y utilizar la herramienta NTPQ para preguntar la daemon del ntpd para más detalles:

[root@ise14]# ntpq

ntpq> associations

ind assID status conf reach auth condition last_event cnt
===========================================================
1 53519 9614 yes yes none sys.peer reachable 1
2 53520 9014 yes yes none reject reachable 1

Como se muestra, hay dos asociaciones presentadas. La asociación 53520 se marca como rechazado. Aquí están algunos detalles adicionales para esa asociación:

ntpq> mrv 53520 53520
assID=53520 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10032.150, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,
offset=-32.465, delay=0.898, dispersion=30.345, jitter=4.519,
reftime=d96b0358.fe7c815a Tue, Aug 4 2015 11:24:40.994,
org=d96b08ed.829514cf Tue, Aug 4 2015 11:48:29.510,
rec=d96b08ed.8b022d8d Tue, Aug 4 2015 11:48:29.543,
xmt=d96b08ed.8ac74cca Tue, Aug 4 2015 11:48:29.542,
filtdelay= 0.90 1.20 0.95 0.93 0.87 0.89 1.19 0.93,
filtoffset= -32.47 -27.95 -26.50 -34.32 -27.74 -18.14 -22.54 -23.79,
filtdisp= 15.63 30.97 46.32 61.68 77.05 92.44 107.82 115.48

Es posible confirmar que éste es el servidor NTP previamente configurado (10.62.145.72) para las cuales la sincronización falla. También, el parámetro de la dispersión de la raíz es grande (sobre el ms 10,000). Utilice esta información para confirmar este parámetro del Microsoft Windows server:

C:\Users\Administrator> w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)

Las capturas de paquetes presentan la petición que se envía del ISE, con una dispersión aceptable de la raíz del segundo:

 

Aquí está la respuesta del servidor, que tiene una dispersión de la raíz que sea mayor de diez segundos:

Como consecuencia, el no se valida, que hace el ISE caer la petición y continuar con la fuente de la hora local.

La dispersión de la raíz es un número que indica el error máximo en relación con la fuente de referencia principal en la raíz de la subred de sincronización. Es aumentada en cada servidor NTP. Por abandono, el servidor de Microsoft fija el valor a diez segundos solamente en que se utiliza su propia fuente de la hora local (para indicar que no es una fuente confiable de tiempo). Cuando configuran al servidor NTP de Microsoft con un externo NTP, este valor se deriva del servidor y el problema no existe.

Solución

Según la documentación de Microsoft, es posible configurar el valor de LocalRootDispersion en el registro. Complete estos pasos para configurar el valor de registro:

  1. Pare el servicio NTP de PowerShell:
    PS C:\Users\Administrator> Stop-Service w32time
  2. Fije el valor de registro a 0:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
  3. Reinicie el servicio:
    PS C:\Users\Administrator> Start-Service w32time
  4. Verifique que el nuevo valor (0) esté señalado:
    C:\Users\Administrator> w32tm /query /status
    Leap Indicator: 0(no warning)
    Stratum: 1 (primary reference - syncd by radio clock)
    Precision: -6 (15.625ms per tick)
    Root Delay: 0.0000000s
    Root Dispersion: 0.0000000s
    ReferenceId: 0x4C4F434C (source name: "LOCL")
    Last Successful Sync Time: 04/08/2015 11:15:32
    Source: Local CMOS Clock
    Poll Interval: 6 (64s)

La herramienta ISE NTPQ debe ahora señalar (un valor bajo del ms 48):

ntpq> mrv 53520 53520
assID=8400 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=48.431, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=8.206,
delay=0.514, dispersion=21.595, jitter=3.456,
reftime=d96b0c49.2c834d26 Tue, Aug 4 2015 12:02:49.173,
org=d96b175c.d472ead9 Tue, Aug 4 2015 12:50:04.829,
rec=d96b175c.d2bf9803 Tue, Aug 4 2015 12:50:04.823,
xmt=d96b175c.d284b95f Tue, Aug 4 2015 12:50:04.822,
filtdelay= 0.90 0.86 0.51 0.87 0.80 0.82 0.85 0.88,
filtoffset= 7.09 5.23 8.21 6.78 2.73 8.43 1.93 9.67,
filtdisp= 15.63 17.56 19.48 21.39 23.32 25.24 27.18 29.08

Esto permite a la sincronización para ocurrir como se esperaba:

ntpq> associations
ind assID status conf reach auth condition last_event cnt
===========================================================
1 53519 9014 yes yes none reject reachable 1
2 53520 9614 yes yes none sys.peer reachable 1

Usted puede también verificar esta información del CLI:

ise14/admin# show ntp
Configured NTP Servers:
10.62.145.72

synchronised to NTP server (10.62.145.72) at stratum 2
time correct to within 80 ms
polling server every 128 s

remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 15 64 377 0.000 0.000 0.000
*10.62.145.72 .LOCL. 1 u 26 128 377 0.514 8.206 3.456

* Current time source, + Candidate , x False ticker

Warning: Output results may conflict during periods of changing synchronization.

Problemas adicionales

Algunas de las más viejas versiones del Microsoft Windows server pudieron tener diversas configuraciones del valor por defecto NTP. Cisco recomienda que usted verifica si estas configuraciones sean correctas y aceptables por el ISE. Verifique estas configuraciones del registro:

  • Cambie el valor habilitado del indicador a 1 para habilitar al servidor NTP:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders
    \NTPServer\Enabled
  • Fije la entrada de registro del tipo al NTP para cambiar el tipo de servidor:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
  • Fije la entrada de registro de los indicadores de la anunciación a 5 para indicar una fuente horaria confiable:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config
    \AnnounceFlags

Problemas de VMware

Los problemas de la sincronización NTP se pudieron causar por el ID de bug 2075424 de VMware (el host de ESXi no sincroniza el tiempo con el servidor NTP).

El problema se resuelve en estas correcciones:

  • Actualización 1 de VMware ESXi 5.5

  • Corrección 4 de VMware ESXi 5.1

  • Corrección 8 de VMware ESXi 5.0

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 119371