Por: Yuri Diógenes / Diana Hernandez

 

1. Introducción

 

En Mayo de este año había escrito lo que fue la parte uno de este documento,  y no daba por hecho que habría una parte 2, mas el día a día me viene mostrando dos cosas:

 

·         Primero que muchas empresas ya se preocupan de hecho con la seguridad de la información e invierten en eso- lo cual es óptimo;

·         Segundo que muchas empresas tienen aplicaciones antiguas que aun no están listas para trabajar en ambiente seguro-lo que es un hecho.

 

Días atrás trabajé en otro caso en donde  el villano parecía ser el sistema operacional, hasta que después de varias pruebas pudimos concluir que no era; sin embargo, hasta llegar a esa conclusión muchas cosas pasaron.

 

Vamos a entender el escenario:

 

·         El cliente tiene una aplicación que hace uso del protocolo LDAP para hacer consultas al Active Directory.

·         El usuario se conecta al AD usando LDAP y pasa las credenciales vía línea de comando.

·         En el pasado este usuario de la aplicación podía usarla sin mayores problemas y hacer sus consultas en AD también sin problemas.

·         Problema: Después de la empresa implementar algunas de las políticas de seguridad el usuario no conseguía utilizar esta aplicación de ninguna forma.

 

 

2. Obteniendo Datos

 

Primero, fue necesario un trabajo de investigación para saber lo que había mudado con respecto de la seguridad, para mi suerte el cliente aún estaba en el inicio de la implementación lo que facilitó mi trabajo pues no tuve mucho problema para hallar una pista fundamental.

 

Una de las políticas que fue implementada fue la que los usuarios solo pudieran efectuar logon en la red en algunas estaciones de trabajo, una política simple pero eficaz, antigua (la tenemos desde NT 3.51) y funcional. Recuerda esa política? Esta en las propiedades de usuario como se muestra abajo:

 

 

 

En este momento usted debe estar pensando: fácil, basta colocar la estación en la cual el usuario está efectuando el logon y listo. Bien, no es así, a pesar que eso también me vino en mente, aun así adicionando la estación a la cual el usuario pudiera efectuar logon, continuábamos recibiendo el error de acceso negado.

 

Fué entonces que resolvimos hacer una prueba corriendo localmente (en el domain controller) y también tuvimos problemas, entonces colocamos el Domain Controller en la lista de computadores autorizados para que aquel usuario hiciera logon y funcionó.

 

Después de esto probamos con otras cosas y siempre que el Domain Controller estaba en la lista de computadores en la cual el usuario podía hacer logon la aplicación que usaba LDAP lograba hacer autenticación.  Intrigante no?

 

3. Haciendo “Narrow Down” del problema...

 

En este momento hubo un cierto “stress” por parte del cliente pues en principio el encontraba que era un hueco en la política de seguridad que solo dejaba al usuario hacer logon cuando el DC estuviese en la lista. Eso fue algo que no me convenció tampoco, ya que estábamos lidiando con una aplicación de terceros y no teníamos conocimiento de cómo funcionaba entonces resolvimos usar una herramienta nuestra para hacer la prueba, fue entonces que utilizamos LDP.EXE.  Cuando estamos conectando vía LDP tenemos la opción de pasar las credenciales de usuario que está haciendo el logon, conforme muestra la figura:

 

 

 

 

Entonces sacamos al DC de la lista de computadores en donde estaba permitido para el usuario efectuar logon y dejamos apenas la estación local a la cual estaba logueado. Resultado:  funcionó sin problemas.

 

 

4. Y porque esto?

 

Ahora que ya sabemos que con nuestro LDAP funciona, resta saber porque, al final no solo tenemos que resolver pero probar el porqué y defender nuestra tesis. Para esto nada mejor que el viejo y buen Network Monitor. Recuerde:  todo lo que pasa por la placa de red del computador al cual usted está investigando es capturado por el netmon, entonces la mejor forma de saber qué es lo que realmente está pasando es mirar los paquetes, claro puede llevar tiempo y puede ser algo que no es tan claro para algunos, por lo tanto le recomiendo comenzar a familiarizarse bien con esto.

 

Vamos entonces a la prueba número 1:

 

·         Uso de LDP.EXE para conectarse al AD vía LDAP:

 

1. Cliente hace una petición en el puerto TCP 389:

192.1.16.15            192.7.11.12            TCP      4507 > ldap [SYN]

 

2. Servidor acepta la conexión

192.7.11.12            192.1.16.15            TCP      ldap > 4507 [SYN, ACK]

 

3. El MS LDP (en el lado del cliente) envía entonces un “Bind Request” en donde pasa las credenciales y en este caso utiliza un método NTLM de autenticación:

 

192.1.16.15            192.7.11.12            LDAP     MsgId=13

Bind Request, DN=(null), NTLMSSP_AUTH, User: DOMAINNAME \TestUser

 

Lightweight Directory Access Protocol

    LDAP Message, Bind Request

        Message Id: 13

        Message Type: Bind Request (0x00)

        Message Length: 225

        Response In: 3175

        Version: 3

        DN: (null)

        Auth Type: SASL (0x03)

        Mechanism: GSS-SPNEGO

        GSS-API Generic Security Service Application Program Interface

            NTLMSSP

                NTLMSSP identifier: NTLMSSP

                NTLM Message Type: NTLMSSP_AUTH (0x00000003)

                Lan Manager Response:

F1DC6D4CFFCD04F900000000000000000000000000000000

                    Length: 24

                    Maxlen: 24

                    Offset: 134

                NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8

                    Length: 24

                    Maxlen: 24

                    Offset: 158

                Domain name: DOMAINNAME

                    Length: 18

                    Maxlen: 18

                    Offset: 72

                User name: TestUser

                    Length: 32

                    Maxlen: 32

                    Offset: 90

                Host name: COMPUTADOR1

                    Length: 12

                    Maxlen: 12

                    Offset: 122

                Session Key: 33724B7018EADC94650FCAAB1F6741EF

                    Length: 16

                    Maxlen: 16

                    Offset: 182

                Flags: 0xe2888215

 

4. El servidor envia un mensaje de autenticación con éxito:

 

192.7.11.12            192.1.16.15            LDAP     MsgId=13 Bind Result

Lightweight Directory Access Protocol

    LDAP Message, Bind Result

        Message Id: 13

        Message Type: Bind Result (0x01)

        Message Length: 9

        Response To: 3174

        Time: 0.001953000 seconds

        Result Code: success (0x00) <---------------------- EXITOSO

        Matched DN: (null)

        Error Message: (null)

 

Bien, con esto sabemos exactamente como nuestra aplicación se está comportando durante la autenticación, o sea , está utilizando NTLM.

 

Vamos entonces a la prueba número 2:

 

·         Uso de la aplicación de terceros para conectarse al AD vía LDAP:

 

1. El cliente hace una petición de acceso en el puerto TCP 389 (emitiré ola visualización de los paquetes pues no hay cambio en el comportamiento)

 

2. El servidor acepta la petición.

 

3. El cliente envia entonces el “Bind Request” y ahora viene la diferencia:

 

192.1.16.15            192.7.11.12            LDAP     MsgId=1 Bind Request, DN=CN=TestUser,OU=Test,DC=domainname,DC=local

Lightweight Directory Access Protocol

    LDAP Message, Bind Request

        Message Id: 1

        Message Type: Bind Request (0x00)

        Message Length: 83

        Response In: 998

        Version: 3

        DN: DN=CN=TestUser,OU=Test,DC=domainname,DC=local

        Auth Type: Simple (0x00) <-------------------- Método Simple de Autenticación

        Password: 12345678

 

4. El servidor envia el siguiente resultado:

192.7.11.12            192.1.16.15            LDAP     MsgId=1 Bind Result, invalidCredentials

Lightweight Directory Access Protocol

    LDAP Message, Bind Result

        Message Id: 1

        Message Type: Bind Result (0x01)

        Message Length: 94

        Response To: 997

        Time: 0.001954000 seconds

        Result Code: invalidCredentials (0x31) <-------------- ERROR

        Matched DN: (null)

        Error Message: 80090308: LdapErr: DSID-0C090334, comment:

AcceptSecurityContext error, data 531, vece

 

Ahora que tenemos un escenario que funciona y uno que no funciona ya podemos decir que:

·         Consulta LDAP vía LDP.EXE está usando el método de autenticación NTLM;

·         Consulta LDAP vía aplicación de terceros está usando autenticación simple;

 

El protocolo LDAP implementado por Microsoft puede tener los siguientes métodos de autenticación:

 

Método de Autenticación

Descripción

LDAP_AUTH_SIMPLE

Autenticación simple con texto limpio.

LDAP_AUTH_NTLM

Autenticación NT Lan Manager

LDAP_AUTH_DPA

Autenticación distribuida, usada por MMS (Microsoft Membership System)

LDAP_AUTH_NEGOTIATE

Generic security services (GSS)

LDAP_AUTH_SSPI

Método antiguo el cual está incluido por compatibilidad retroactiva.

Fuente de la Tabla: White Paper Understanding LDAP

 

Ahora viene la pregunta: que tiene que ver el método de autenticación de usuario con la política de seguridad que define en que estaciones de trabajo el usuario se puede autenticar?

 

 

Veamos entonces como el proceso ocurre:

 

1. La aplicación de terceros envia una consulta LDAP para el AD usando el método de autenticación simple (LDAP_AUTH_SIMPLE). Este tipo de método enviar una cadena que contiene apenas el nombre de usuario y contraseña;

2. Cuando el DC recibe esta petición de autenticación del cliente  el DC entonces verifica las credenciales de usuario así como las propiedades de conexión para verificar si el computador en el cual el usuario está localizado está en la lista de computadores autorizados para dicho usuario;

3. Como la aplicación envia una petición simple de autenticación LDAP , el nombre del computador no está incluido en el paquete entonces el DC utiliza el nombre NetBIOS de el mismo para hacer la autenticación.

4. El DC entonces verifica que el nombre NetBIOS de el mismo está contenido o no en la lista de computadores (atributo userWorkstations) autorizados y en este caso como no está entonces retorna un “Access Denied”.

 

Ahora nos queda fácil entender  el porqué cuando colocamos el nombre del DC en la lista de autenticación funcionaba. El problema no ocurre con NTLM ya que el nombre del computador está incluido como lo muestra la captura de red presentada anteriormente. Vamos a revisar los campos contenidos en el paquete LDAP utilizando NTLM:

 

                NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8

                    Length: 24

                    Maxlen: 24

                    Offset: 158

                Domain name: DOMAINNAME

                    Length: 18

                    Maxlen: 18

                    Offset: 72

                User name: TestUser

                    Length: 32

                    Maxlen: 32

                    Offset: 90

                Host name: COMPUTADOR1

                    Length: 12

                    Maxlen: 12

                    Offset: 122

                Session Key: 33724B7018EADC94650FCAAB1F6741EF

                    Length: 16

                    Maxlen: 16

                    Offset: 182

                Flags: 0xe2888215

 

 

5. Conclusión

 

Ambiente seguro es algo de extrema importancia en estos días, por lo tanto tan importante como esto es un ambiente de validación de las políticas de seguridad, principalmente cuando estamos saliendo de un ambiente en donde existen aplicaciones antiguas que no se preocupan por aspectos de seguridad. Implementar nuevas políticas trae beneficios al negocio pero también puede tornarse en un dolor de cabeza en caso que no sea bien planeado.

 

6. Referencias

 

Understanding LDAP

http://www.microsoft.com/windows2000/techinfo/howitworks/activedirectory/ldap.asp

 

User-Workstations Attribute

http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/adschema/a_userworkstations.asp 

 

User Security Attributes

http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/security_properties.asp