Monitorizando el tipo de consultas LDAP que llegan a nuestros DCs
Hola de nuevo. Volvemos a la “carga” con LDAP. Hoy vamos a hablar sobre cómo obtener un logging detallado de las consultas LDAP llevadas a cabo por un controlador de dominio. Esto puede resultarnos útil a la hora de comprobar el tipo de consultas LDAP que se efectúan, comprobar si están optimizadas en cuanto a objetos recorridos, etc.
Para qué nos sirve
Los datos obtenidos pueden ayudarnos a determinar, por ejemplo, si hay un cliente que está efectuando muchas consultas y que, en principio, no debería estar realizando, lo que puede indicar la presencia de alguna aplicación no deseada.
También puede ayudarnos a determinar si es necesario indexar algún atributo concreto para optimizar un tipo de búsqueda concreta que se realiza de forma frecuente y con un filtro que utiliza un atributo específico no indexado (lo que provoca recorrer innecesariamente múltiples objetos por cada búsqueda).
Es posible que estemos realizando la búsqueda en un scope o ámbito muy amplio y con un DN base muy general cuando podemos restringirla a una OU concreta y no a todo el sub-árbol del dominio: si buscamos usuarios de una oficina concreta que cumplen un requisito y sabemos que todos los usuarios de dicha oficina están en una OU específica, deberíamos utilizar dicha OU como DN base de la búsqueda y no todo el dominio.
Este logging de las consultas LDAP se realiza en el visor de sucesos en forma de eventos. Los eventos generados proporcionan, además de los datos del cliente y la propia consulta, información adicional como el tiempo empleado en las queries LDAP y los objetos recorridos.
Para leer información sobre cómo funcionan las búsquedas LDAP: How Active Directory Searches Work
Cómo configurar este nivel de logging
Para conseguir este nivel de logging, en los DCs hay que hacer varias modificaciones en el registro para:
- Definir lo que consideramos una búsqueda LDAP costosa/ineficiente
- Habilitar el log de eventos de diagnóstico de Directorio Activo para Field Engineering
En primer lugar hay que definir los límites a partir de los cuales se considera que una consulta es costosa/ineficiente. Estos límites se especifican en términos de objetos recorridos, y sólo se registrarán eventos que superen estos límites.
Una búsqueda costosa es aquella que visita un alto número de objetos. La eficiencia de una búsqueda se mide comparando el número de registros devueltos con respecto al número de registros visitados. Es decir, si la búsqueda devuelve 300 objetos después de recorrer 300 objetos, entonces estamos ante una búsqueda eficiente.
Los límites se especifican con creando o modificando los siguientes valores de la clave de registro que se proporciona a continuación (si se desea que se muestren todas las consultas LDAP, el valor de ambos límites deberá ser 1, aunque esto puede suponer un incremento no deseado de la carga de CPU del DC):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
- Valor: Expensive Search Results Threshold
Tipo: DWORD
Datos: 10000 (Valor por defecto)
- Valor: Inefficient Search Results Threshold
Tipo: DWORD
Datos: 1000 (Valor por defecto)
Con estos valores por defecto, una búsqueda se considerará costosa si el DC recorre más de 10000 objetos (Expensive Search Results Threshold). Una búsqueda se considerará ineficiente si recorre más de 1000 objetos (Inefficient Search Results Threshold) y se devuelve como resultado menos de un 10% de los objetos visitados.
Los valores de Expensive e Inefficient Search Results Threshold son valores subjetivos, por lo que habrá que adecuarlos al entorno y al tipo de consultas que se efectúen en los DCs.
Se puede encontrar más información sobre estos valores en el siguiente enlace:
Creating More Efficient Microsoft Active Directory-Enabled Applications
Hasta aquí ya hemos determinado nuestros valores límite de lo que consideramos una búsqueda costosa o ineficiente. Sin embargo, esto no es suficiente para generar los eventos.
Los eventos de log de actividad LDAP se generan en el visor de sucesos de Directorio Activo en la categoría de Field Engineering. Por lo tanto, tendremos que activar el log de diagnóstico de esta categoría en los DCs en los que queramos monitorizar la actividad LDAP.
Para ello es necesario modificar el siguiente valor de la clave de registro que se muestra a continuación:
HKLM\system\CCS\Services\NTDS\Diagnostics
- Valor: 15 Field Engineering
Datos: 5
Nota: Para que los valores sean efectivos no es necesario reiniciar el DC en el que se modifiquen
A partir de dicho momento, por cada query LDAP costosa/ineficiente aparecerá en el Visor de Sucesos de Directory Services un evento 1644 de categoría Field Engineering con la información de la búsqueda, tipo, filtro, ámbito de búsqueda (scope), entradas recorridas, entradas encontradas, etc.:
Event Type: Information
Event Source: NTDS General
Event Category: Field Engineering
Event ID: 1644
Description:
Internal event: A client issued a search operation with the following options.
Client:
127.0.0.1
Starting node:
DC=dominio,DC=com
Filter:
(objectClass=computer)
Search scope:
subtree
Attribute selection:
[types_only]
Server controls:
Visited entries:
3448
Returned entries:
7
Otro tipo de log de diagnóstico que puede resultar útil es el siguiente, que nos permite obtener información sobre el tiempo empleado en las búsquedas:
- Valor: 16 LDAP Interface Events
Datos: 3
Después de habilitarlo obtendremos un evento 1139 de LDAP Interface indicando el tiempo que ha costado realizar cada búsqueda:
**
Event Type: Information
Event Source: NTDS LDAP
Event Category: LDAP Interface
Event ID: 1139
Description:
Internal event: Function ldap_search completed with an elapsed time of 30 ms.
Para revisar los eventos generados por los DCs y obtener, por ejemplo, todos los eventos con ID 1644 y fuente NTDS General de todos los DCs que estemos monitorizando, podemos usar una herramienta como EventCombMT . La herramienta EventCombMT se puede descargar desde el siguiente enlace:
También es recomendable que aumentemos el tamaño del log de Directory Services, ya que se van a generar varios eventos por cada consulta LDAP registrada, lo que podría provocar que dicho visor de sucesos llegara a su tamaño máximo.
Hasta la próxima.
Paula Tomás Galed