Seguimiento de eventos en ADSI
Windows Server 2008 y Windows Vista presentan el Seguimiento de eventos en las interfaces de servicio de Active Directory (ADSI). Algunas áreas del proveedor LDAP ADSI tienen una implementación subyacente compleja o que implica una secuencia de pasos que dificulta el diagnóstico de problemas. Para ayudar a los desarrolladores de aplicaciones a solucionar problemas, el seguimiento de eventos se ha agregado a las siguientes áreas:
Análisis y descarga de esquemas
La interfaz IADs en ADSI requiere que el esquema LDAP se almacene en caché en el cliente para que los atributos se puedan serializar correctamente (como se describe en el documento Modelo de esquema ADSI). Para conseguirlo, ADSI carga el esquema para cada proceso (y para cada servidor/dominio LDAP) en memoria, ya sea desde un archivo de esquema (.sch) que se guarda en el disco local o descargándolo del servidor LDAP. Los distintos procesos en la misma máquina cliente usan el esquema almacenado en caché en el disco si está disponible y aplicable.
Si el esquema no se puede obtener del disco o del servidor, ADSI usa un esquema predeterminado codificado de forma predeterminada. Cuando esto ocurre, los atributos que no forman parte de este esquema predeterminado no se pueden serializar y ADSI devuelve un error al recuperar estos atributos. Varios factores podrían provocar que esto suceda, incluidos los problemas al analizar el esquema y los privilegios insuficientes para descargar el esquema. A menudo es difícil determinar por qué se usa un esquema predeterminado concreto. El uso de Seguimiento de eventos en esta área ayudará a diagnosticar más rápidamente el problema y solucionarlo.
Cambio y configuración de la contraseña
ChangePassword y SetPassword emplean más de un mecanismo para realizar la operación solicitada en función de la configuración disponible (como se describe en Configuración y modificación de contraseñas de usuario con el proveedor LDAP). Cuando se produce un error en ChangePassword y SetPassword, puede ser difícil determinar exactamente por qué y el seguimiento de eventos le ayudará a solucionar problemas con estos métodos.
Caché de vínculo ADSI
ADSI intenta reutilizar internamente las conexiones LDAP siempre que sea posible (consulte Almacenamiento en caché de conexión). A la hora de solucionar problemas, es útil realizar un seguimiento si se ha abierto una nueva conexión para la comunicación con el servidor o si se ha utilizado una conexión existente. También puede ser útil realizar un seguimiento del ciclo de vida de la memoria caché de conexión (a veces denominada caché de vinculación) y su creación o cierre, y si se ha producido una referencia de conexión. En el caso de un vínculo sin servidor, ADSI llama al localizador de controlador de dominio para seleccionar un servidor para el dominio del contexto del usuario. ADSI mantiene una memoria caché de la asignación de servidor de dominio para las conexiones posteriores. El seguimiento de eventos ayuda a realizar un seguimiento de la selección del controlador de dominio y, por tanto, resulta útil para solucionar problemas relacionados con la conexión.
Habilitación del seguimiento e inicio de una sesión de seguimiento
Para activar el seguimiento ADSI, cree la siguiente clave del registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\ProcessName
ProcessName es el nombre completo del proceso del que desea realizar un seguimiento, incluida su extensión (por ejemplo, "Svchost.exe"). Además, puede colocar un valor opcional de tipo DWORD denominado PID en esta clave. Es muy recomendable fijar este valor y realizar el seguimiento de solo un proceso concreto. De lo contrario, se realizará un seguimiento de todas las instancias de la aplicación especificada por ProcessName.
A continuación, ejecute el comando siguiente:
tracelog.exe -start sessionname **-guid #**provider_guid -f filename -flag traceFlags -level traceLevel
sessionname es simplemente un identificador arbitrario que se usa para etiquetar la sesión de seguimiento (deberá hacer referencia a este nombre de sesión más adelante al detener la sesión de seguimiento). El GUID del proveedor de seguimiento ADSI es "7288c9f8-d63c-4932-a345-89d6b060174d". filename especifica el archivo de registro en el que se escribirán los eventos. traceFlags podría ser uno de los siguientes valores:
Marca | Valor |
---|---|
DEBUG_SCHEMA |
0x00000001 |
DEBUG_CHANGEPWD |
0x00000002 |
DEBUG_SETPWD |
0x00000004 |
DEBUG_BINDCACHE |
0x00000008 |
Estas marcas determinan de qué métodos ADSI se realizará el seguimiento, según la tabla siguiente:
Marca | Método |
---|---|
DEBUG_SCHEMA |
|
DEBUG_CHANGEPWD |
|
DEBUG_SETPWD |
|
DEBUG_BINDCACHE |
|
Puede combinar marcas mediante la combinación de los bits adecuados en el argumento traceFlags. Por ejemplo, para especificar las marcas DEBUG_SCHEMA y DEBUG_BINDCACHE, el valor adecuado de traceFlags sería 0x00000009.
Por último, la marca traceLevel debe ser uno de los siguientes valores:
Marca | Valor |
---|---|
TRACE_LEVEL_ERROR |
0x00000002 |
TRACE_LEVEL_INFORMATION |
0x00000004 |
TRACE_LEVEL_INFORMATION hace que el proceso de seguimiento registre todos los eventos, mientras que TRACE_LEVEL_ERROR hace que el proceso de seguimiento registre solo los eventos de error.
Para finalizar el seguimiento, ejecute el siguiente comando:
tracelog.exe -stop sessionname
En el ejemplo anterior, sessionname es el mismo nombre que el que se proporcionó con el comando que inició la sección de seguimiento.
Comentarios
Es más eficaz realizar un seguimiento de los procesos específicos especificando un PID determinado que realizar un seguimiento de todos los procesos de un equipo. Si necesita realizar un seguimiento de varias aplicaciones en la misma máquina, podría haber un impacto en el rendimiento; hay una salida de depuración sustancial en las secciones del código orientadas al rendimiento. Además, los administradores deben tener cuidado de establecer correctamente los permisos de los archivos de registro cuando se rastrean varios procesos; de lo contrario, cualquier usuario podría ser capaz de leer los registros de seguimiento, y otros usuarios podrán realizar el seguimiento de procesos que contengan información segura.
Por ejemplo, supongamos que el administrador configura el seguimiento de una aplicación "Test.exe" y no especifica un PID en el registro para realizar un seguimiento de varias instancias del proceso. Ahora otro usuario quiere realizar un seguimiento de la aplicación "Secure.exe". Si los archivos de registro de seguimiento no están restringidos correctamente, todo lo que el usuario debe hacer es cambiar el nombre de "Secure.exe" a "Test.exe" y se realizará el seguimiento. En general, es mejor realizar un seguimiento de solo los procesos específicos durante la solución de problemas y quitar la clave del Registro de seguimiento tan pronto como se realice la solución de problemas.
Dado que la activación del seguimiento de eventos producirá archivos de registro adicionales, los administradores deben supervisar cuidadosamente el tamaño de los archivos de registro; la falta de espacio en disco en el equipo local puede causar una denegación de servicio.
Escenarios de ejemplo
Escenario 1: El administrador ve un error inesperado en una aplicación que establece contraseñas para cuentas de usuario, por lo que tomaría los siguientes pasos para solucionar el problema usando el seguimiento de eventos.
Escriba un script que reproduzca el problema y cree la clave del registro.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe
Inicie una sesión de seguimiento y establezca traceFlags en 0x2 (DEBUG_CHANGEPASSWD) y traceLevel en 0x4 (TRACE_LEVEL_INFORMATION), con el comando siguiente:
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
Ejecute cscript.exe con su script de prueba para reproducir el problema y, a continuación, finalice la sesión de seguimiento:
tracelog.exe -stop scripttrace
Eliminar la clave del registro
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\cscript.exe
Ejecute la herramienta ETW Tracerpt.exe para analizar la información de seguimiento del registro:
tracelog.exe -start scripttrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\adsi.etl -flag 0x2 -level 0x4
Escenario 2: El administrador quiere realizar un seguimiento de las operaciones de análisis y descarga de esquemas en una aplicación ASP denominada w3wp.exe que ya se está ejecutando. Para ello, el administrador seguiría los siguientes pasos:
Crear la clave del registro
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe
y dentro de esa clave, cree un valor de tipo DWORD que se llame PID y ajústelo al ID del proceso de la instancia de w3wp.exe que se está ejecutando actualmente en el equipo local.
A continuación, crean una sesión de seguimiento y establecen traceFlags en 0x1 (DEBUG_SCHEMA) y traceLevel en 0x4 (TRACE_LEVEL_INFORMATION):
tracelog.exe -start w3wptrace -guid #7288c9f8-d63c-4932-a345-89d6b060174d -f .\w3wp.etl -flag 0x1 -level 0x4
Reproduzca la operación que necesita solución.
Finalice la sesión de seguimiento:
tracelog.exe -stop w3wptrace
Elimine la clave de registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\adsi\Tracing\w3wp.exe.
Ejecute la herramienta ETW tracerpt.exe para analizar la información de seguimiento del registro:
tracerpt.exe .\w3wp.etl -o -report