Autenticación de Kerberos en IIS 7.0

Una de las novedades que introduce IIS 7.0 en la autenticación de Windows (NTLM o Kerberos) es que ahora se realiza en modo Kernel por defecto. Este cambio se introdujo principalmente por dos motivos:

1) El cambio supone significativas mejoras de rendimiento.

2) Se simplifica el despliegue del protocolo de autenticación Kerberos.

Precisamente sobre el segundo punto es sobre el que os quería hablar. Para los que alguna vez os hayáis peleado con la configuración Kerberos, sabréis que requiere realizar una serie de pasos no necesariamente triviales como:

· Verificar que IIS está configurado para soportar autenticación por Kerberos (W3SVC/…/NTAuthenticationProviders = “Negotiate,NTLM” )

· Registrar los Service Principal Names (SPNs) para las cuentas de servicio

· Configurar las cuentas de servicio como Trusted for Delegation en directorio activo (si vamos a hacer delegación de credenciales)

· Etc.

Podéis encontrar una referencia más completa sobre configuración de Kerberos en el siguiente artículo:

How to use SPNs when you configure Web applications that are hosted on IIS 6.0

https://support.microsoft.com/kb/929650/en-us

En IIS 6.0 (y anteriores versiones) debíamos registrar dos SPNs para cada sitio web, un SPN para el nombre NetBios del servidor y otro para el FQDN (Fully Qualified Domain Name), ambos asociados a la cuenta bajo la que corre el servicio (la identidad del application pool en IIS 6.0):

setspn.exe –a HTTP/webServer DOMAIN\AppPoolAccount

setspn.exe –a HTTP/webServer.domain.com DOMAIN\AppPoolAccount

De esta forma, cuando un cliente (por ejemplo Internet Explorer) pida un ticket de Kerberos al KDC (Key Distribution Center) para autenticarse contra nuestro servidor web, dicho ticket irá cifrado con la clave de la cuenta DOMAIN\AppPoolAccount, y únicamente dicho servicio será capaz de descifrar el ticket. Estas claves simétricas en las que se basa Kerberos se obtienen a partir de las contraseñas de la cuentas (tanto para cuentas de usuario como cuentas de máquina) pasándolas por un algoritmo criptográfico.

En IIS 7.0 (configurado por defecto) ya no se utilizará la clave de la cuenta de servicio para descifrar el ticket de Kerberos que recibe de Internet Explorer (continuando con el ejemplo anterior). Ahora se utilizará la clave de la cuenta de máquina del servidor (DOMAIN\webServer$ ) puesto que la autenticación se realiza en modo Kernel. Por lo tanto, debemos o bien registrar los SPNs asociados a la cuenta de máquina, o simplemente no registrarlos.

setspn.exe –a HTTP/webServer DOMAIN\webServer$

setspn.exe –a HTTP/webServer.domain.com DOMAIN\webServer$

Si no registramos los SPNs específicos para el service class de HTTP, el KDC utilizará el SPN de HOST para crear los tickets. Dicho SPN siempre existe puesto que se crea cuando se agrega la máquina al dominio.

Por lo tanto, y con esto enlazo con el principio del post, un sitio web alojado de IIS 7.0 autenticaría mediante Kerberos por defecto sin necesidad de configurar los SPNs. En este sentido se ha facilitado el despliegue considerablemente, y se espera que reduzcan gran parte de los incidentes de soporte relacionados con Kerberos.

Por compatibilidad hacia atrás, tenemos dos opciones para que Kerberos se comporte de la misma manera en IIS 7.0 que en anteriores versiones:

1) Deshabilitar la autenticación en modo Kernel (no recomendado)

2) Habilitar el atributo useAppPoolCredentials en la configuración de IIS 7.0

Con el atributo useAppPoolCredentials habilitado, la autenticación se realiza en modo Kernel pero se utiliza la clave de la cuenta de servicio para descifrar el ticket de Kerberos. Para habilitar dicho atributo podemos ejecutar el siguiente comando:

C:\Windows\System32\inetsrv>appcmd set config -section:windowsauthentication /useAppPoolCredentials:true

Podemos comprobar la configuración de la autenticación de un sitio web específico ejecutando el siguiente comando:

C:\Windows\System32\inetsrv>appcmd list config "Default Web Site" -section:windowsauthentication

<system.webServer>

<security>

<authentication>

<windowsAuthentication enabled="true" useAppPoolCredentials="true">

<providers>

<add value="Negotiate" />

<add value="NTLM" />

</providers>

</windowsAuthentication>

</authentication>

</security>

</system.webServer>

Hasta la próxima,

- Daniel Mossberg

Comments

• Anonymous
  January 28, 2009
  Este post me ha ahorrado un buen rato de investigación, :D.