Consulta con el equipo de Windows : LDAP

Monitorizando el tipo de consultas LDAP que llegan a nuestros DCs

esplat — Tue, 11 Aug 2009 23:25:00 GMT

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:

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

¿Por qué una consulta LDAP no devuelve todos los resultados y qué tiene que ver el valor MaxPageSize en ello?

esplat — Tue, 04 Aug 2009 20:30:00 GMT

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

Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo

esplat — Thu, 16 Apr 2009 12:59:05 GMT

Hola a todos.

En ocasiones, es posible que necesitemos inventariar los usuarios y/o grupos que tenemos en nuestro Directorio Activo.

En función del método que empleemos para extraer información, puede ser que los resultados obtenidos no sean los correctos o estén incompletos.

Sea, por ejemplo, el grupo big_group (un grupo Global de Seguridad en el dominio) que tiene unos 2000 miembros aproximadamente.

Si intentamos listar los miembros que tiene, obtenemos los siguientes resultados:

dsget group

En este caso, como podemos ver en la captura, la salida de la herramienta no nos devuelve resultados:

ldp.exe

La herramienta ldp.exe trunca los resultados obtenidos, no mostrando la totalidad de miembros del grupo:

Expanding base 'CN=big_group,CN=Users,DC=testdom,DC=local'...

Result <0>: (null)

Matched DNs:

Getting 1 entries:

>> Dn: CN=big_group,CN=Users,DC=testdom,DC=local

2> objectClass: top; group;

1> cn: big_group;

0> member:

1500> member;range=0-1499: CN=user1,CN=Users,DC=testdom,DC=local; CN=user2,CN=Users,DC=testdom,DC=local; CN=user3,CN=Users,DC=testdom,DC=local; CN=user4,CN=Users,DC=testdom,DC=local; CN=user5,CN=Users,DC=testdom,DC=local;...

A través de la herramienta ntdsutil, podemos controlar una serie de parámetros para las políticas LDAP de los DCs del dominio.

Entre otros, tenemos la posibilidad de alterar el valor del parámetro MaxValRange el cual controla el número de valores que se devuelve en una query para cualquier atributo de un objeto en el AD.

Sin embargo, hemos de tener en cuenta diversas consideraciones antes de realizar cualquier cambio en estas políticas:

· Las políticas de LDAP son comunes a todos los DCs del forest. No es posible tener distintos DCs con valores distintos para cada parámetro.

· El hecho de incrementar el número máximo de valores por atributo que nos devuelve un DC (MaxValRange), puede provocar un impacto en el rendimiento de los Controladores de Dominio.

Este valor tomará efecto para todos los atributos de todos los objetos del Directorio Activo, y no sólo para miembros de un grupo o para otro atributo concreto que nos interese.

Tenéis disponible más información sobre el tema aquí:

315071 - How to view and set LDAP policy in Active Directory by using Ntdsutil.exe

http://support.microsoft.com/kb/315071

[…]

• MaxValRange - This value controls the number of values that are returned for an attribute of an object, independent of how many attributes that object has, or of how many objects were in the search result. In Windows 2000, this control is "hard" coded at 1,000. If an attribute has more than the number of values that are specified by the MaxValRange value, you must use value range controls in LDAP to retrieve values that exceed the MaxValRange value. MaxValueRange controls the number of values that are returned on a single attribute on a single object.

Default value:

o Windows 2000 - 1,024

o Windows Server 2003 - 1,500

Como alternativa, y en caso de necesitar un listado de todos los miembros de un grupo (p.ej. de más de 1500 usuarios en Windows Server 2003), os proponemos el uso de scripts para realizar la tarea.

En el siguiente enlace podéis encontrar un ejemplo de implementación de esto:

Scripting Guy: List members of a group

http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0419.mspx

[…] It’s easy enough to list all the members of a group; for example, here’s a script that reports back all the members of the Finance Managers group:

Set objGroup = GetObject _
    ("LDAP://cn=Finance Managers, ou=Finance, dc=fabrikam, dc=com")

For Each strUser on objGroup.Member
        Wscript.Echo strUser
Next

Un saludo a todos,

Javier Rama

El caso del grupo de Domain Admins incompleto

esplat — Wed, 17 Sep 2008 19:29:00 GMT

Hola, somos Tolu Igbon y Paula Tomás. Hace unos días tuvimos un caso en el que se utilizaba un script para realizar una consulta LDAP (utilizando el proveedor LDAP y determinar los miembros del grupo Domain Admins. Este script devolvía únicamente parte de los miembros del grupo, mientras que, a través de la consola de Usuarios y Equipos de Directorio Activo (dsa.msc) se obtenía un número mayor de miembros (la totalidad de ellos).

Se observó que la misma consulta en otro script que utilizaba el proveedor WinNT sí devolvía efectivamente todos los miembros del grupo Domain Admins, así como también los devolvía la ejecución del comando Net Group “Domain Admins”

Sin embargo, tanto ADSIEdit como LDP.EXE devolvían resultados parciales iguales a los que se recibían utilizando el script con el proveedor LDAP.

Ejecutamos el comando LDIFDE para obtener un volcado completo del contenedor USERS del dominio donde residen nuestros usuarios y grupos:

LDIFDE –d “CN=Users,DC=Nombredominio,DC=com” –f ARCHIVOSALIDA.TXT

En el archivo de salida vimos que, de nuevo, sólo aparecía parte de los usuarios en el atributo member del grupo Domain Admins.

dn: CN=Domain Admins,CN=Users,DC=Dominio,DC=com

changetype: add

objectClass: top

objectClass: group

cn: Domain Admins

description: Designated administrators of the domain

member: CN=User1,CN=Users, DC=Dominio,DC=com

member: CN=User2,CN=Users, DC=Dominio,DC=com

member: CN=User3,CN=Users, DC=Dominio,DC=com

member: CN=User4,CN=Users, DC=Dominio,DC=com

Posteriormente, comparamos los atributos de los usuarios que SÍ aparecían como miembros del grupo Domain Admins con los de los usuarios que NO aparecían.

Averiguamos que los usuarios que no aparecían tenían el atributo PrimaryGroupID establecido a 512. Este valor corresponde al grupo “Domain Admins”.

dn: CN=User5,CN=Users, DC=Dominio,DC=com

changetype: add

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

…………………………….

memberOf: CN=Enterprise Admins,CN=Users, DC=Dominio,DC=com

memberOf: CN=Administrators,CN=Users, DC=Dominio,DC=com

…………………………

primaryGroupID: 512

Sin embargo, los demás usuarios que sí aparecían como miembros del grupo “Domain Admins” tenían el atributo PrimaryGroupID establecido a 513, correspondiente al grupo “Domain Users”.

dn: CN=User1,CN=Users, DC=Dominio,DC=com

changetype: add

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

…………………………….

memberOf: CN=Group1,CN=Users, DC=Dominio,DC=com

memberOf: CN=Domain Admins,CN=Users, DC=Dominio,DC=com

…………………………

primaryGroupID: 513

Este comportamiento es por diseño, y aparece descrito en el siguiente artículo:

275523 Setting Primary Group Excludes the User from the Group Membership in Active Directory http://support.microsoft.com/default.aspx?scid=kb;EN-US;275523

A traves de LDAP/ADSI, un usuario no aparece como memberOf (miembro de) su grupo primario. Dicho grupo tampoco muestra los member (miembros) que lo tengan como grupo primario.

Del mismo modo, y por diseño, los usuarios no aparecen como miembros del grupo “Domain Users”, al ser éste el grupo primario de la mayoría de los usuarios por defecto.

Para que los usuarios deseados aparezcan como miembros del grupo “Domain Admins” a través de ADSI/LDAP, hay que cambiar su grupo primario a través de la consola Usuarios y Equipos de Directorio Activo y establecerlo a “Domain Users”, por ejemplo.

Se puede encontrar más información en los siguientes artículos de KB:

321360 How to use native ADSI components to find the primary group http://support.microsoft.com/default.aspx?scid=kb;EN-US;321360

297951 How to use the PrimaryGroupID attribute to find the primary group for a user http://support.microsoft.com/default.aspx?scid=kb;EN-US;297951

Esperamos que os haya resultado interesante.

- Tolu Igbon && Paula Tomás Galed

El caso del usuario deshabilitado que se valida (por LDAP)

esplat — Fri, 15 Aug 2008 01:28:00 GMT

Hola a todos,

Soy Paula, del equipo de Directorio Activo. Recientemente tuvimos un caso en el que un usuario deshabilitado podía realizar una conexión a LDP y no recibía ningún error (aunque posteriormente no podía navegar por el árbol de la partición del dominio).

A la hora de realizar el BIND mediante la herramienta LDP.EXE, el mensaje recibido era el siguiente (indicando aparentemente que se había realizado la autenticación con las credenciales del usuario deshabilitado user1):

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3

{NtAuthIdentity: User='user1'; Pwd= <unavailable>; domain = 'haledomain'.}

Authenticated as dn:'user1'.

Si obtenemos unas trazas de red de dicha conexión, se muestra un BIND exitoso:

Hora	Origen	Destino	Prot	Detalles
12:59:07.370	192.168.1.1	192.168.1.2	LDAP	LDAP:Search Request, MessageID: 32, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:07.380	192.168.1.2	192.168.1.1	LDAP	LDAP:Search Result Entry, MessageID: 32
12:59:14.269	192.168.1.1	192.168.1.2	LDAP	LDAP:Search Request, MessageID: 33, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:14.280	192.168.1.2	192.168.1.1	LDAP	LDAP:Search Result Entry, MessageID: 33
12:59:14.770	192.168.1.1	192.168.1.2	LDAP	LDAP:Bind Request, MessageID: 35, Version: 3
12:59:14.780	192.168.1.2	192.168.1.1	LDAP	LDAP:Bind Response, MessageID: 35, Status: Sasl Bind In Progress
12:59:14.790	192.168.1.1	192.168.1.2	LDAP	LDAP:Bind Request, MessageID: 36, Version: 3
12:59:14.981	192.168.1.2	192.168.1.1	LDAP	LDAP:Bind Response, MessageID: 36, Status: Success

En condiciones normales, un usuario deshabilitado no puede realizar una conexión LDAP a Directorio Activo ya que se deniega su acceso indicando que sus credenciales son inválidas:

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3

{NtAuthIdentity: User='user1'; Pwd= <unavailable>; domain = 'haledomain'.}

Error <49>: ldap_bind_s() failed: Invalid Credentials.

Server error: 8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece

Este mensaje de red se puede observar también en la respuesta obtenida del DC (servidor LDAP) en las trazas de red:

Hora	Origen	Destino	Prot	Detalles
13:12:04.417	192.168.1.1	192.168.1.2	LDAP	LDAP:Search Request, MessageID: 73, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
13:12:04.417	192.168.1.2	192.168.1.1	LDAP	LDAP:Search Result Entry, MessageID: 73
13:12:12.208	192.168.1.1	192.168.1.2	LDAP	LDAP:Bind Request, MessageID: 76, Version: 3
13:12:12.208	192.168.1.2	192.168.1.1	LDAP	LDAP:Bind Response, MessageID: 76, Status: Sasl Bind In Progress
13:12:12.208	192.168.1.1	192.168.1.2	LDAP	LDAP:Bind Request, MessageID: 77, Version: 3
13:12:12.278	192.168.1.2	192.168.1.1	LDAP	LDAP:Bind Response, MessageID: 77, Status: Invalid Credentials

Revisando el visor de sucesos de Seguridad del DC de nuestro entorno de pruebas tras realizar el intento de conexión con el usuario deshabilitado user1, observamos la siguiente secuencia de eventos:

Event Type: Failure Audit

Event Source: Security

Event Category: Account Logon

Event ID: 672

Date: 8/14/2008

Time: 1:09:24 PM

User: NT AUTHORITY\SYSTEM

Computer: HALEDC01

Description:

Authentication Ticket Request:

User Name: user1

Supplied Realm Name: haledomain

User ID: -

Service Name: krbtgt/haledomain

Service ID: -

Ticket Options: 0x40810010

Result Code: 0x12

Ticket Encryption Type: -

Pre-Authentication Type: -

Client Address: 127.0.0.1

Certificate Issuer Name:

Certificate Serial Number:

Certificate Thumbprint:

Event Type: Success Audit

Event Source: Security

Event Category: Logon/Logoff

Event ID: 552

Date: 8/14/2008

Time: 1:09:24 PM

User: HALEDOMAIN\administrator

Computer: HALEDC01

Description:

Logon attempt using explicit credentials:

Logged on user:

User Name: administrator

Domain: HALEDOMAIN

Logon ID: (0x0,0x27F79)

Logon GUID: {94b7a00d-5198-8f5c-d90b-566add369611}

User whose credentials were used:

Target User Name: user1

Target Domain: haledomain

Target Logon GUID: -

Target Server Name: HALEDC01.haledomain.com

Target Server Info: HALEDC01.haledomain.com

Caller Process ID: 3256

Source Network Address: -

Source Port: -

Event Type: Failure Audit

Event Source: Security

Event Category: Account Logon

Event ID: 680

Date: 8/14/2008

Time: 1:09:24 PM

User: NT AUTHORITY\SYSTEM

Computer: HALEDC01

Description:

Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Logon account: user1

Source Workstation: HALEDC01

Error Code: 0xC0000072

Event Type: Failure Audit

Event Source: Security

Event Category: Logon/Logoff

Event ID: 531

Date: 8/14/2008

Time: 1:09:24 PM

User: NT AUTHORITY\SYSTEM

Computer: HALEDC01

Description:

Logon Failure:

Reason: Account currently disabled

User Name: user1

Domain: haledomain

Logon Type: 3

Logon Process: NtLmSsp

Authentication Package: NTLM

Workstation Name: HALEDC01

Caller User Name: -

Caller Domain: -

Caller Logon ID: -

Caller Process ID: -

Transited Services: -

Source Network Address: 192.168.1.1

Source Port: 2768

En cambio, en el visor de sucesos del DC del entorno que aparentemente autenticaba al usuario deshabilitado se podían ver los siguientes eventos:

Event Type: Failure Audit

Event Source: Security

Event Category: Account Logon

Event ID: 672

Date: 8/14/2008

Time: 1:06:53 PM

User: NT AUTHORITY\SYSTEM

Computer: HALEDC01

Description:

Authentication Ticket Request:

User Name: user1

Supplied Realm Name: haledomain

User ID: -

Service Name: krbtgt/haledomain

Service ID: -

Ticket Options: 0x40810010

Result Code: 0x12

Ticket Encryption Type: -

Pre-Authentication Type: -

Client Address: 127.0.0.1

Certificate Issuer Name:

Certificate Serial Number:

Certificate Thumbprint:

Event Type: Success Audit

Event Source: Security

Event Category: Logon/Logoff

Event ID: 552

Date: 8/14/2008

Time: 1:06:53 PM

User: HALEDOMAIN\administrator

Computer: HALEDC01

Description:

Logon attempt using explicit credentials:

Logged on user:

User Name: administrator

Domain: HALEDOMAIN

Logon ID: (0x0,0x27F79)

Logon GUID: {94b7a00d-5198-8f5c-d90b-566add369611}

User whose credentials were used:

Target User Name: user1

Target Domain: haledomain

Target Logon GUID: -

Target Server Name: HALEDC01.haledomain.com

Target Server Info: HALEDC01.haledomain.com

Caller Process ID: 3256

Source Network Address: -

Source Port: -

Event Type: Failure Audit

Event Source: Security

Event Category: Account Logon

Event ID: 680

Date: 8/14/2008

Time: 1:06:53 PM

User: NT AUTHORITY\SYSTEM

Computer: HALEDC01

Description:

Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Logon account: user1

Source Workstation: HALEDC01

Error Code: 0xC0000072

Event Type: Success Audit

Event Source: Security

Event Category: Account Logon

Event ID: 680

Date: 8/14/2008

Time: 1:06:53 PM

User: HALEDOMAIN\Guest

Computer: HALEDC01

Description:

Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Logon account: Guest

Source Workstation: HALEDC01

Error Code: 0x0

Los tres primeros eventos son iguales en ambos casos:

· El evento 672 indica que se ha intentado realizar una autenticación por KERBEROS con el usuario user1 y se ha devuelto el error 0x12. Este código de error se traduce al siguiente mensaje que indica que el usuario ha sido “revocado”:

KDC_ERR_CLIENT_REVOKED à Clients credentials have been revoked

· El evento 552 indica que se está intentado realizar una conexión al DC utilizando el usuario user1.

· A continuación se muestra el evento 680 indicando que el intento de autenticación del usuario user1 ha resultado fallido y proporciona el código de error 0xC0000072 correspondiente al siguiente mensaje (cuenta de usuario deshabilitada):

STATUS_ACCOUNT_DISABLED à The referenced account is currently disabled and may not be logged on to.

El evento que aparece a continuación de los anteriores es distinto en ambas situaciones:

· En el primer caso (el usuario no puede realizar la conexión LDAP – comportamiento esperado), se recibe el evento 531 indicando que la cuenta de usuario está actualmente deshabilitada: Account currently disabled

· En el entorno que aparentemente permite la conexión del usuario aparece el mismo intento fallido de autenticación pero se observa que, inmediatamente después, existe un intento exitoso de autenticación del usuario Invitado o Guest (evento 680).

Por lo tanto, en realidad no es el usuario user1 el que se está autenticando en el BIND de la conexión LDAP (aunque sea esa la percepción desde el cliente LDAP), sino que su autenticación es denegada y automáticamente se realiza otra autenticación con el usuario Invitado porque dicho usuario se encontraba HABILITADO en el entorno.

La razón de que el usuario posteriormente no pudiera acceder a los datos de la partición del dominio era precisamente por haber realizado la autenticación con la cuenta Invitado, ya que por defecto esta cuenta no tiene permisos de lectura sobre AD.

Es importante resaltar que la recomendación es que la cuenta Invitado permanezca deshabilitada por motivos de seguridad.

Más información sobre la cuenta Invitado (Guest):

User and computer accounts

Threats and Countermeasures. Chapter 5: Security Options

Microsoft Security: Windows 2000 Server Baseline Security Checklist

- Paula Tomás Galed