La importancia de los SPNs

Leo en esta entrada del blog del equipo de CRM un artículo que resume de manera muy efectiva (no diré entretenida, tampoco hay que pasarse) un tema que más de una vez nos ha dado dolores de cabeza a la gente que trabajamos con Dynamics CRM: los Service Principal Names o SPNs. Atención porque me meto en el tenebroso mundo de los Administradores de Sistemas y puede haber heridos (empezando por mi orgullo).

Los SPNs son nombres que identifican unívocamente las instancias de un servicio. Son atributos del Directorio Activo, pero no están expuestos a través de la interfaz habitual. Permiten un proceso conocido como Delegación Kerberos, mediante el cual se pueden “pasar” credenciales de usuario entre distintos servidores. Entran en juego en un entorno CRM cuando tenemos distribuida nuestra instalación entre distintos servidores. Por ejemplo, si tenemos nuestro servidor de informes (SRS) y nuestro CRM en máquinas distintas. Cuando un usuario pide un informe a CRM, retransmite sus credenciales a SRS para que este lo sirva en su nombre. Si los SPNs no están configurados correctamente, obtendremos el temido mensaje

HTTP Error 401 - Unauthorized

Hay muchos casos en los que se crean automáticamente SPNs para los servicios. Por ejemplo, al instalar SQL Server se crea uno para la cuenta de usuario que ejecuta su servicio. Si luego se cambia este usuario, se pueden acabar duplicando las entradas. O también, cuando un pool de IIS se ejecuta con una identidad distinta a Network Service o sobre un número de puerto no estándar (no es ni el 80 ni el 443). También cuando se crean alias o cabeceras para el servicio. Por ejemplo, si queremos acceder a nuesto CRM con una dirección del estilo crm.miempresa.com

Vamos, que como veis hay un montón de casos en los que tendremos que pegarnos con las SPNs en un entorno mínimamente complejo de CRM. Las herramientas que podemos usar (con mucho respeto) son ADSI Edit y SetSPN están incluidas en las Support Tools, que tendremos que descargar por separado si trabajamos con Windows 2003. En Windows 2008 están preinstaladas en los controladores de dominio. En el artículo se comentan los siguientes escenarios específicos para CRM:

• Uso de host header
• Cambiar la identidad del pool de CRM
• Cambiar la identidad del pool de CRM cuando hay otras aplicaciones en el servidor (i.e. Intranet)

Es un tema complejo y delicado sobre el que no puedo contar mucho más. Tan sólo redirigir (para empezar, a mi mismo) a recursos más o menos digeribles para legos como yo. Por ejemplo, esta Guía de Kerberos para el Administrador con Prisas (la traducción es mía). Suerte.