Hola nuevamente!
Todos sabemos que para diagnosticar problemas de performance en un servidor debemos configurar contadores de performance de los objetos que deseamos analizar.
Ahora bien, ¿Quién sabe leer toda la información que se genera con el performance monitor?
Solemos tener mucha cantidad de información, muchos contadores, mucha interacción entre ellos y muchas veces se hace imposible lograr una idea de lo que está sucediendo.
Para solucionar este problema contamos con la herramienta llamada PAL.
Esta herramienta de uso libre y gratuito genera reportes gráficos y muy detallados del rendimiento de un servidor.
También analiza rendimiento de Microsoft Exchange, SQL Server y Biztalk Server, entre otros.
Una vez que utilicéis dicha herramienta llegará un momento donde os toparéis con un problema. Sólo funciona cuando los contadores están en inglés.
Para ello se desarrolló una herramienta que realiza la traducción de los logs del Español al Inglés y así ser capaces de poder utilizar el PAL sobre dicho log.
Esta herramienta de traducción puede ser descargada desde aquí.
¿Cómo utilizarla?
Espero que les sea de utilidad.
Hasta la próxima
Gastón Gardonio
Hola a todos. Soy Paula, del equipo de Directorio Activo. Hoy vamos a tratar un tema por el que nos preguntan en Soporte.
A veces, cuando se realizan consultas LDAP a Directorio Activo (utilizando alguna herramienta o programa a medida), no se devuelven todos los resultados que esperamos. Podemos, por ejemplo, solicitar todos los usuarios de una determinada Unidad Organizativa en la que sabemos que hay 3000 usuarios para luego realizar algunas modificaciones sobre ellos. Sin embargo, al ejecutar la consulta LDAP, AD sólo nos devuelve 1000 usuarios, con lo cual la búsqueda no nos sirve...
Este comportamiento se debe a que Directorio Activo devuelve por defecto un máximo número de objetos (1000) en una única búsqueda, aunque los objetos que cumplan los parámetros de búsqueda sean más de ese número por defecto. Este límite viene dado por el valor MaxPageSize de la política LDAP en Directorio Activo.
El valor puede ser modificado y adaptado a las necesidades concretas que tengamos. Para modificar dicho valor es necesario realizar la operación con un usuario con credenciales de Enterprise Admin.
No se recomienda cambiar su valor para recibir un mayor número de objetos en una única consulta LDAP, sino realizar búsquedas paginadas en el Directorio Activo. De esta manera se dividirá la búsqueda en varias búsquedas “más pequeñas” que cumplirán con el límite máximo establecido para cada una de ellas.
¿Por qué no se recomienda cambiar el valor de MaxPageSize?
Porque su modificación puede producir efectos negativos sobre el rendimiento de los DCs y el tráfico generado en la red.
Se puede encontrar más información sobre el valor MaxPageSize y cómo consultarlo y/o modificarlo con ntdsutil.exe en el siguiente enlace:
315071 How to view and set LDAP policy in Active Directory by using Ntdsutil.exe
“MaxPageSize - This value controls the maximum number of objects that are returned in a single search result, independent of how large each returned object is. To perform a search where the result might exceed this number of objects, the client must specify the paged search control. This is to group the returned results in groups that are no larger than the MaxPageSize value. To summarize, MaxPageSize controls the number of objects that are returned in a single search result. Default value: 1,000”
Si se modifican los límites establecidos por defecto existe un problema potencial de rendimiento. Estos límites han sido probados y se seleccionaron por considerarse óptimos o recomendables. Para entornos específicos pueden ser modificados pero siempre teniendo en cuenta que pueden suponer un problema de rendimiento en el futuro. También hay que recordar que el valor se cambia a nivel general en la política LDAP de AD, por lo que afectará a todos los DCs.
¿Cómo resolver la situación sin modificar el valor de MaxPageSize?
La recomendación para realizar consultas LDAP es realizar dichas consultas de manera paginada (los diferentes lenguajes de programación a través de APIs para LDAP ofrecen mecanismos para llevar este tipo de búsquedas a cabo), con lo que se recibirían los datos de 1000 en 1000 (registros), en lugar de modificar el tamaño de la página que nos devuelve Directorio Activo. De hecho, aunque aumentemos el tamaño del valor MaxPageSize, es posible que tampoco sea suficiente y la búsqueda no devuelva todos los resultados esperados (el número de objetos puede crecer en el tiempo y superar el nuevo límite de MaxPageSize).
Se puede encontrar más información sobre las diferentes políticas LDAP, incluyendo MaxPageSize en el siguiente enlace:
3.1.1.3.4.6 LDAP Policies
Como ya se ha comentado, las políticas LDAP proporcionan límites operacionales para consultas/operaciones LDAP y deben ser configuradas de tal manera que garanticen un nivel de servicio aceptable sin impactar al rendimiento de los DCs y evitando así también ataques de denegación de servicio.
Información específica sobre las políticas LDAP en Windows Server 2008:
LDAP policies
“To ensure that domain controllers can support service level guarantees, you can specify operational limits for a number of Lightweight Directory Access Protocol (LDAP) operations. These limits prevent specific operations from adversely impacting the performance of the server and also make the server resilient to denial of service attacks.”
Más información sobre los límites administrativos de LDAP para AD en la información sobre la herramienta Microsoft Exchange Server Analyzer Tool que analiza configuraciones erróneas entre otros:
Microsoft Exchange Server Analyzer Tool – Active Directory settings MaxPageSize is set too high
“The Microsoft® Exchange Server Analyzer Tool queries the Active Directory® directory service to determine the setting for the MaxPageSize value for the LDAPAdminLimits attribute of the Default Query Policy object in the Query-Policies container. If the Exchange Server Analyzer determines that the value for MaxPageSize is greater than 2,500, an error is displayed.
The Lightweight Directory Access Protocol (LDAP) administrative limits balance Active Directory operational capabilities and performance. These limits prevent specific operations from adversely affecting the performance of the server. The limits also make the server resilient to denial of service attacks. Increasing this setting beyond its default value could have an adverse impact on your Active Directory infrastructure.“
Información adicional sobre las búsquedas paginadas:
Espero que la información os resulte útil a la hora de realizar consultas LDAP en vuestro directorio.
Paula Tomás Galed
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:
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
Tipo: DWORD Datos: 10000 (Valor por defecto)
Tipo: DWORD
Datos: 10000 (Valor por defecto)
Tipo: DWORD Datos: 1000 (Valor por defecto)
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
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
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:
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.
Event Source: NTDS LDAP
Event Category: LDAP Interface
Event ID: 1139
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.