IWA en Firefox

IWA en Firefox

El proceso que ocurre cuando usamos el navegador Firefox es casi idéntico al que hemos visto con IE. El browser nos pedirá la clave igualmente si entramos a una zona protegida por IWA de nuestra web:

Para ver que ocurre en este caso, lo primero es localizar el mismo paquete que mostramos anteriormente:

• 5.0.0.2 5.0.0.1 HTTP HTTP/1.1401 Unauthorized (text/html)

IWA usando Firefox 3: Protocolos de autenticación soportados por el servidor

Aquí vemos cómo el servidor vuelve a ofrecer al browser dos métodos de autenticación posibles. No obstante, a diferencia de IE, Firefox selecciona el protocolo NTLM para autenticar al cliente, tal y como se indica en el paquete que envía:

• 5.0.0.1 5.0.0.2 HTTP GET/matricula HTTP/1.1 , NTLMSSP_AUTH, User: \Autorizado

Así vemos cómo Firefox usa NTLM enviando la siguiente información:

• Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGYAAAAYABgAfgAAAAAAAABAAAAAFAAUAEAAAAASABIAVAAAAAAAAAAAAAAABYIIAEEAdQB0AG8AcgBpAHoAYQBkAG8AYwBsAGkAZQBuAHQAZQB4AHAAdXndnVl74H8AAAAAAAAAAAAAAAAAAAAAtgev8QKuphCchFbw8h3kuQcOHxcy6kt1\r\n

Posteriormente el servidor acepta la autenticación NTLM que el cliente Firefox ha seleccionado, y se sirven los contenidos solicitados. No obstante, hemos dicho anteriormente que NTLM, aunque es un protocolo más seguro que Digest, es un protocolo menos seguro que Kerberos actualmente. ¿Por qué Firefox no ha seleccionado Kerberos? El primer problema es que Firefox por defecto no está configurado para usar Negotiate y por tanto no podrá hacer uso de Kerberos. Para solucionar este problema debemos seguir el proceso que se ve en las dos imágenes siguientes:

• Navegar a la página about:config y decir que sí al mensaje de aviso que sale.
• Poner la clave network.negotiate-auth.trusted-uris= 5.0.0.2 (la IP de nuestro servidor web y KDC de Kerberos, mediante doble click). Esta clave lista las máquinas que están autorizadas a usar autenticación integrada, lo que incluye el uso de Kerberos o NTLM entre otros protocolos. Podemos encontrar más información en https.

Configurando Firefox para que negocie el uso de Kerberos

Con Firefox habilitado para usar Negotiate:

Para seguir haciendo pruebas tendremos que eliminar todo dato de las peticiones anteriores. Esto implica:

• Limpiar los datos privados del navegador web.
• “Restart Capture” en Wireshark
• Hacer Mayúsculas + Reload (F5) en el navegador.

Hecho esto podemos repetir la petición que le vamos a hacer al navegador. A continuación seguiremos nuevamente la secuencia de mensajes intercambiados entre navegador y servidor:

• Lo primero es localizar el paquete mediante el cual el servidor indica al browser que se requiere autenticación:
• 5.0.0.2 5.0.0.1 HTTP HTTP/1.1401 Unauthorized (text/html)

Información enviada por la autenticación IWA usando Firefox y negociación

• En esta ocasión sí que podemos ver la petición del cliente para autenticarse mediante Kerberos:
• 5.0.0.1 5.0.0.2 HTTP GET/matricula/ HTTP/1.1 , NTLMSSP_AUTH, User: CLIENTEXP\Cliente
• · Esto envía la siguiente información:
• Authorization: NegotiateTlRMTVNTUAADAAAAGAAYAHoAAAAYABgAkg AAABIAEgBIAAAADgAOAFoAAAASABIAaAAAAAAAAACqAAAABYKIogUBKAoAAAAPQwBMAEkARQBOAFQARQBYAFAAQwBsAGkAZQBuAHQAZQBDAEwASQBFAE4AVABFAFgAUADKyNLUR/dwFwAAAAAAAAAAAAAAAAAAAABHEX2RgT

No obstante, la autenticación sigue fallando porque Firefox 3.0 selecciona las credenciales del usuario local (ClienteXP/Cliente) en lugar de las que hayamos podido introducir cuando nos las ha solicitado. Esto hará que el servidor nos mande un paquete desautorizando la solicitud de autenticación, tal y como se aprecia en la siguiente imagen, al no poder suministrar una identidad de usuario conocida por el KDC (controlador de dominio):

Firefox 3 intentando negociar el uso de Kerberos, pero la identidad del cliente no es válida

• Dado que el uso de Kerberos no ha sido satisfactorio, se repite el proceso de autenticación anterior:
• 5.0.0.1 5.0.0.2 HTTP GET/matricula/ HTTP/1.1 , NTLMSSP_AUTH, User: \Autorizado
• Que a su vez transmite estos datos, volviendo a usar de nuevo NTLM:
• Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGYAAAAYABgAfg AAAAAAAABAAAAAFAAUAEAAAAASABIAVAAAAAAAAAAAAAAABYIIAEEAdQB0AG8AcgBpAHoAYQBkAG8AYwBsAGkAZQBuAHQAZQB4AHAAxwuW9Xxz5k8AAAAAAAAAAAAAAAAAAAAA87+S036p6nDFZ3FEA564qmKKCqbK+RjR\r\n

Firefox3 vuelve a usar NTLM ante la imposibilidad de usar Kerberos con el usuario actual

• Este proceso de autenticación usando NTLM si es satisfactorio, al igual que el proceso homólogo que se vio anteriormente (se manda la misma información). No obstante, seguimos sin poder usar Kerberos para autenticarnos.

¿Cómo usar Kerberos con Firefox entonces? Hemos visto que el problema existente tras los cambios hechos es que se tratan de validar con las credenciales de un usuario local y no de un usuario del dominio. Por tanto, ¿Qué pasaría si nuestra identidad de usuario fuese realmente una del dominio? Lógicamente, entonces Firefox debería autenticarnos correctamente siguiendo el proceso que hemos visto anteriormente. Para probar esto, primero tenemos que meter el cliente XP dentro del dominio del servidor. Esto requiere dar los siguientes pasos:

• Modificamos los parámetros de la conexión de red interna entre cliente y servidor (la 5) para que tome como DNS al controlador de dominio (cuya IP es 5.0.0.2)
• Vamos a “panel de control – Sistema – Nombre del equipo – cambiar” y metemos como nombre de dominio “webserver.local” (el dominio al que pertenece el servidor). Para meter una máquina dentro de un dominio es necesario introducir las credenciales de un usuario que tenga privilegios administrativos dentro del dominio. En nuestro caso podemos poner la clave del administrador del dominio para que nos deje hacerlo.
• Reiniciamos el cliente XP para que se apliquen los cambios.

Este proceso se describe en las imágenes siguientes:

Configuración de las tarjetas de red en Windows XP

Asignando en nuestro XP cliente el controlador de dominio como DNS

Introduciendo a nuestro cliente en el dominio

NOTA: Usar Paros podría hacer que la autenticación IWA no funcione correctamente, presumiblemente por el uso de Kerberos en vez de NTLM. Alguna medida de seguridad que posee el protocolo Kerberos no parece ser compatible con la existencia de dicho proxy.

Si al arrancar el cliente XP sale un mensaje que dice “actualizando lista de dominios”, podemos quitarlo pulsando CTRL + ALT + INSERT. Una vez tengamos la pantalla de login disponible, nos metemos en sesión como “Administrador de dominio” en el cliente, arrancando Wireshark para comprobar de nuevo la información enviada en la red 5.

Para ver si esta vez se puede usar Kerberos con Firefox, debemos repetir el proceso ya visto de cambiar en about:config la clave network.negotiate-auth.trusted-uris= 5.0.0.2, debido a que es una configuración que se guarda por cada usuario del sistema. Además, ahora al acceder a la página protegida mediante autenticación IWA debería entrar automáticamente (sin solicitar clave), porque ahora nuestro usuario de inicio de sesión es una identidad reconocida por el dominio. Esta petición final, tras todos los cambios realizados, enviará la siguiente información (no se aportan imágenes porque son esencialmente idénticas a las ya vistas anteriormente):

• Paquete requiriendo autenticación:
• 5.0.0.2 5.0.0.1 HTTP HTTP/1.1401 Unauthorized (text/html)
• Petición del cliente para autenticarsemediante Kerberos:
• 5.0.0.1 5.0.0.2 HTTP GET/matricula HTTP/1.1 , NTLMSSP_AUTH, User: WEBSERVER\Administrador
• Esto envía:
• Authorization: NegotiateTlRMTVNTUAADAAAAGAAYAIYAAAAYABgAng AAABIAEgBIAAAAGgAaAFoAAAASABIAdAAAAAAAAAC2AAAABYKIogUBKAoAAAAPVwBFAEIAUwBFAFIAVgBFAFIAQQBkAG0AaQBuAGkAcwB0AHIAYQBkAG8AcgBDAEwASQBFAE4AVABFAFgAUAAfju16ovA+agAAAAAAAAAAAA
• Y la petición es aceptada. Firefox ahora usa Kerberos con el usuario que haya hecho login en el cliente, que ahora es un usuario válido del dominio y por tanto está reconocido por el controlador (KDC).

Para las siguientes pruebas que haremos sobre la página, se desactivará el acceso IWA en el directorio “matricula” y se sacará a la máquina del dominio entrando como “Administrador de dominio” en el cliente y revirtiendo los cambios vistos. También debemos reiniciar y validarnos como “cliente” sin clave para dejar al cliente como una máquina XP aislada, no perteneciente a ningún dominio.