1.- Determinar la salud del DNS

Lo primero que debemos determinar cuándo realizamos una asesoría en AD es la salud del DNS. Una falla en el DNS puede causar muchos problemas en la autentificación, fallo en las aplicaciones, exchange, replicaciones, problemas de respuesta en LDAP, entre otros.

Como describimos anteriormente la revisión del DNS es crítica, para poder determinar el estado de salud de la plataforma, detallaremos unos CMDLET para complementar el Dcdiag.exe, el cual es:

dcdiag /test:DNS /e /v

La opción /e indica que la prueba correrá en todos los servidores de DNS, y /v indica una salida detallada de texto para el resultado de esta prueba. En un ambiente amplio, esto puede tardar un tiempo, pero vale la pena esperar.

Siempre comienzo leyendo desde el final del reporte, donde aparece una tabla como table 1. DCdiag ejecuta 6 pruebas diferentes: Authentication (Auth), Basic Connectivity (Basc), Forwarders (Forw), Delegation (Del), Dynamic Registration Enabled (Dyn) y Resource Record Registration (RReg). La tabla además lista la prueba de External (Ext), la conexión a internet, pero este comando no realiza esa prueba.

En la salida de la tabla 1, muestra cada servidor DNS (El cual usualmente también son los Domain Controlers) del bosque listado por dominio. Lo bueno de eso es que muestra la configuración de dominio del bosque, la cual es de mucha ayuda si eres consultor o ingeniero de soporte y no estas familiarizado con la infraestructura. En los datos de lectura de la tabla, los resultados son:

• PASS: El servidor DNS completa el test.
• FAIL: El servidor DNS falla el test.
• N/A: La prueba no fue ejecutado. Esto ocurre generalmente por una falla en alguna prueba anterior, por lo que no tiene sentido realizar una prueba sobre un servicio que ya sabe que está fallando.

En la tabla 1 podemos ver el valor de esta prueba. Inmediatamente podemos ver los lugares conflictivos. En un bosque de multiple dominio, debes ejecutar este comando con credenciales de Enterprise Admin, u obtendrás resultados fallidos en todas las pruebas de los servidores DNS por que no tienes los privilegios suficientes. Esto es lo que sucede para el dominio EMEA en la tabla 1.

Al termino del reporte se presenta una lista completa de las fallas, donde se pueden ver todos los detalles. Por ejemplo puedo ir a la parte superior del reporte y buscar por Corp-DC02, y obtener los detalles que son mostrados en figure 1.

En este primer paso se presenta muy buena información, se puede construir la configuración del DNS Resolve para cada servidor DNS. Lo principal en este paso, es que se muestra el porque la prueba de Forwarder nos entregaba N/A en la tabla 1. Usando este método podemos elegir el camino entre los resultados “warning”, “failure” y “N/A” de la tabla 1. Y por supuesto lo mejor de todo esto, es que tienes la información de todos los servidores DNS del bosque en un archivo, generado por un solo comando.

2.- Determinando la salud de la replicación del AD

 La herramienta de soporte para Windows Server incluye la opción en Repadmin llamada /replsum. Similar al comando DCdiag /test:dns del Tips 1, /replsum colecciona la información de replicación de todos los DC del bosque. Esto muestra el reporte de en qué momento ocurre la replicación entre los DC, el comando debe ser ejecutado en cada uno de los DC del bosque. Aquí están las opciones más usadas:

Repadmin /replsum /bysrc /bydest /sort:delta

• /bysrc indica la colección de datos de los DC que han replicado en otros DC.
• /bydest indica la colección de datos de los DC que han replicado en otros DC.
• /sort:Delta muestra los resultados en orden decendiente

Un ejemplo de esto se ve en table 2. Aquí se muestran seis DC y gracias a delta se muestran por orden de su última replicación. Aquí podemos ver fácilmente la salud del dominio, excepto para WTEC-DC2, el cual no ha sido replicado de hace cinco días, que arroja el error 1722. Yo sé que este DC se encuentra apagado ya que está siendo movido a un nuevo Data Center.

3.- Detalle de replicación para todos los DC del bosque.

 Esta técnica (similar a la del tips número 2) nos entrega mayor detalle. El comando es /repadmin /showrepl * /csv>showrepl.csv. Esta opción de salida en formato CSV, como se muestra en table 3.

Me gusta este comando por que frecuentemente muestra un error en mayor detalle qué el comando /replsum. Además, ofrece un reporte de distintos errores (o errores adicionales, código de error y más) y especifica los datos que /replsum no entrega.

4.- Diagnóstico NTDS

Este punto es esencial para obtener información adicional de los datos en el visor de eventos de Directory Service (DS). Está habilitado por registro en HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS\Diagnostic. Es bastante sencillo. Aquí hay una variedad de atributos que, cuando son habilitados entregan información adicional en los logs de eventos para ayudarte en las tareas de troubleshooting. Los datos válidos de estos registros es una variable de 0 a 5. El valor por defecto es 0, significando una entrega de datos mínima, y añadiendo 5 entrega más datos de los que quieres. Generalmente configuro 3 y reviso si es que llegase a necesitar más información. En ciertos casos, si necesito mayor detalles en la replicación, al valor de “5 replication event” lo cambio a 3, para reproducir el problema. Asegúrate de cambiar el valor a 0 cuando las labores de troubleshooting finalicen.

Los valores más comunes que utilizo son:

• 1 Knowledge Consistency Checker
• 10 Performance Counters
• 13 Name resolution (Relacionado con el DNS)
• 15 Field Engineering
• 18 Global Catalog
• 2 Security Events
• 5 Replication Events
• 8 Directory Acces
• 9 Internal Processing

El valor 9 Internal Processing es útil para obtener información adicional sobre el DS event, esto indica que error interno está ocurriendo. Esto a menudo muestra eventos adicionales que ayudarán en el diagnóstico del problema. Es común añadir un valor mayor a 1. Realizando troubleshooting de replicación, es buena idea habilitar el valor 1 Knowledge Consistency y 5 Replication Events.

El valor 15 Field Engineering entregará diversa información adicional a los logs de DS. A diferencia de los otros diagnósticos, este debe ser ajustado a cinco para que entregue información relevante. Específicamente, esto genera los eventos 1644 y 1643, que mostrarán la ineficiencia en las consultas a LDAP, incluyendo a los clientes que generan las consultas, el tipo de consulta, y la raíz de la consulta. Esto es importante, ya que uno de los dolores de cabeza relacionados con el AD, es el proceso Local System Authority Subsystem Services (LSASS), que se encuentre utilizando suficientes recursos para colgar, o crashear nuestro DC, causando una lentitud en el ingreso del usuario. Una ineficiencia en las consultas a LDAP de parte de los usuarios o aplicaciones puede suponer una enorme carga en LSASS. Habilitando este diagnóstico podemos identificar de manera más rápida al culpable según su nombre o dirección IP. Algunos administradores dejan este diagnóstico habilitado permanentemente en organizaciones ocupadas, pero de nuevo, esto llenará nuestros logs de eventos, y posiblemente esconda o sobre escriba otros eventos importantes en los logs de DS.

5.- Reportes HTML y consola de administración de políticas de grupo.

Seguramente todos los administradores de AD han usado esta herramienta en algún momento, pero pensé que valdría la pena mencionar los valores de los reportes HTML. Aquí hay dos tipos de reportes que uso frecuentemente cuando trato con entornos con los cuáles no estoy familiarizado y por lo general quiero probar las configuraciones de las Group Policy Object (GPO), así como los resultados en un cliente en particular o clientes.

Obtener un reporte de las GPO es valioso, incluso si eres el administrador de la plataforma, ya que muestra exactamente las configuraciones definidas (de hecho, solo muestra las configuraciones definidas), por lo que no tendrás dificultades para investigar en el editor de políticas para encontrar las que se encuentran establecidas. Esta es una manera rápida de ver si la GPO está definida como esperas que lo esté. Incluso muestra los links, filtros aplicados y otros detalles. Los reportes HTML para la Default Domain Policy son simples de leer y pueden ser expandidos o cerrados por sección según lo necesites, ya que se encuentran en formato HTML. Para obtener este reporte, de click derecho sobre la GPO y selecciona “save report”.

Uno de los problemas a solucionar en las GPO está relacionado con un cliente el cuál molesta al usuario, quien se encuentra a cientos de kilómetros de distancia para ingresar y obtener un GPOResult. Si el usuario ha ingresado en al menos una estación de trabajo, la consola de administración de políticas de grupos (GPMC) puede entregar con un formato HTML el resultado del GPResult que se produce cuando el usuario ingresa.

6.- Diagnóstico de rendimiento para Active Directory.

Si bien hay muchos otros tips para troubleshooting que pude haber añadido, este es uno que probablemente, no del todo conocido. En el troubleshooting del rendimiento de los servidores, hay un conjunto estándar de objetos, incluidos el procesador, disco lógico, memoria del servidor, sistema y así entre otros. Sin embargo hay un objeto de NTDS que nos proporciona contadores relevantes del AD como, DRA, Kerberos, LDAP y contadores incluso relacionados con eventos en NTLM. Además podemos recopilar valores importantes de los datos de nuestro AD mediante el monitoreo de los procesos de LSASS. Recomiendo habilitar los siguientes:

• Object: Process
  • Contadores: % de tiempo de procesado, conjunto de trabajo, y pico de conjunto de trabajo.
• Object: NTDS
  • Contadores: Todos los contadores.

Desafortunadamente hay poca información disponible dentro de lo aceptable. El más útil encontrado es la guía de implementación para la rama de Microsoft Office. Si bien hay muchos contadores y puedes o no estar familiarizados con ellos, aquí hay algunos significados.

• DRA Pending Replication Synchronization: Este es el directorio de sincronización de las colas y los retrasos en la replicación, Microsoft dice que estos valores deben ser lo más bajo posibles y que el hardware está retrasando la replicación. Estos son indicios de que los recursos del DC tienen un alto porcentaje de utilización.
• LDAP Cliente Sessions: Este es el número de sesiones abiertas simultáneamente por clientes LDAP. Esto es útil para determinar la actividad de los clientes de LDAP y si el DC está habilitado para soportar esa carga. Por supuesto los picos se registran durante la autenticación de los clientes lo cual no es un problema necesariamente, pero en largos periodos los altos valores significan un exceso de trabajo para el DC.
• LDAP Bind Time: Este es el tiempo en milisegundos que es necesario para completar la unión de LDAP. La documentación de Microsoft indica que esto debe tener el menor tiempo posible, pero si corres un análisis a través de los logs de análisis de rendimiento (PAL), indicara 15 sobre milisegundos como un warning, y sobre 30 como un error.

En el diagnóstico de procesos LSASS, como en cualquier análisis de rendimiento, debe haber una base establecida. Una nota en el DS blog de Microsoft indica que si una base no está establecida, debe ser utilizado el 80%. Es decir los contadores LSASS no deben superar el 80% de consumo, ya que sobre el 80% indicará una sobre carga, lo que podrá traer una alta demanda de consultas a LDAP, o la falta de recursos en el servidor. La solución es aumentar los recursos del servidor, o disminuir la demanda de consultas, pero tenga en cuenta que el alto uso de recursos puede causar un impacto en el rendimiento del dominio.

Si desea solucionar problemas de recursos, utilize una plataforma x64 en los DC, con diversos procesadores, y 32GB de Ram. Es sorprendente cuanta memoria realmente puede utilizar los recursos LSASS.

Espero que estos tips sean de gran utilidad a la hora de realizar un troubleshooting de AD DS.

Ernesto León, Técnico en Soporte, Blue Solutions.