El mito acerca de ServicePrincipalName (SPN)

  • Article

Por Guillermo Vargas, artículo original de Brian Murphy-Booth

Literalmente, el 99% de todos los problemas de Kerberos giran en torno a una incorrecta, falta, o duplicado del ServicePrincipalName (SPN). Para ser honesto, el concepto de un SPN es tan simple que a menudo estoy confundido que otras personas no lo entienden incluso después de que se los explico. Supongo que los 5+ años que he tenido de ayudar a las personas a configurar y solucionar problemas de Kerberos que finalmente aparece todo muy claro para mí. Me gusta pensar en términos simples en lugar de hacerlos complejos. Se trata de un hábito arrastrado desde mis días de Algebra-1 cuando mi profesor se utilizaba un problema sencillo para explicar un concepto.

Piense del SPN como si fuera un "nombre_de_usuario" que se utiliza para identificar un programa que está ocupado verificando credenciales. Y sólo se nos está permitido hablar con este programa utilizando su " nombre_de_usuario ". Punto. Simple! Sí, eso es todo lo que es un SPN: un "nombre de usuario". Y al igual que con cualquier nombre de usuario, el nombre por sí mismo no es realmente tan importante. Es simplemente hacer la identificación de una persona (o entidad) fáciles de recordar a los seres humanos. En este caso concreto, sin embargo, hay algunas convenciones de nomenclatura para este " nombre_de_usuario ". Bien, así que ¿qué nombre de usuario (SPN) es el correcto? ¿Y dónde debemos establecerla? Estas 2 preguntas son donde se encuentra toda la confusión. Hemos dividido el SPN en 2 partes y ocasionalmente de 3 partes: la primera parte es el "tipo de servicio" y la segunda parte es el nombre de "host". Y a veces la tercera parte que está presente es el "puerto". Sin embargo, al final, todos estas diferentes partes simplemente se utilizan para llegar a este " nombre_de_usuario " que llamamos ServicePrincipalName.

Digamos que quiero conectar a un proceso llamado BrianService.exe. Y el nombre DNS para enrutar mi conexión es blah.overthere.com. Como el diseñador de este servicio raro podría plantear un "tipo de servicio" de BRIAN. Por lo que el SPN sería BRIAN/blah.overthere.com. Está bien, pero… ¿dónde lo establecemos? Simple, sencillo, simple. Si mi proceso de BrianService.exe se está ejecutando bajo "NOMBRE_DE_DOMINIO\Alguna_cuenta", a continuación, establecería el SPN de BRIAN/blah.overthere.com en "NOMBRE_DE_DOMINIO \ Alguna_cuenta". Si mi proceso (BrianService.exe) se ejecutaba como algo como "Servicio de red", "Servicio Local" o "Sistema Local", a continuación, establecería BRIAN/blah.overthere.com en la cuenta de equipo propio que se está ejecutando en ese proceso. Si alguna vez cambia la cuenta que se está ejecutando el programa necesita quitar el SPN de la cuenta original y establecerla en la nueva cuenta, porque no podemos tener el mismo nombre de usuario asignado a varios cuentas en nuestro caso.

Recapitulación. Un SPN es sólo un “nombre” que le hemos dado a un "servicio" que se encuentra en el formato de Tipo_de_Servicio/Nombre_del_Host y ocasionalmente Tipo_de_Servicio/Nombre_del_host:Numero_de_Puerto. Y está enclavado en la cuenta que siempre está controlando la autenticación para ese servicio. También debo señalar que como administrador no eres tú el que decide que puerto usar. Yo solía pensar que tal vez yo podría elegir un número de puerto en un SPN si quería hacer la aplicación más segura, pero es la aplicación de cliente que tiene la decisión si se debe utilizar un puerto.

Está bien, ahora hagamos esto un poco más complicado mediante el uso de nombres más realistas. Pero mientras hacemos esto, quisiera que mantuvieran la fe en lo que he explicado más arriba y que tan simple sean estos conceptos.

  1. 1- Digamos que usted se está conectado a un servidor IIS que tiene el nombre de máquina de "iis-prod-01"

  2. 2- Y supongamos que el nombre de dominio de Active Directory es "EMPRESA.com"

  3. 3- Entonces en el explorador de Internet utilizaríamos una dirección de https://Algun_Nombre_Inventado

  4. 4- El "grupo de aplicaciones también conocido como application pool " (por ejemplo, el proceso de w3wp.exe) se ejecuta en la cuenta de "EMPRESA\Mi_cuenta_de_Servicio"

Sabiendo que el Kerberos del “tipo de servicio web" es "HTTP" (no hay que confundir esto con el tipo de protocolo del navegador) probablemente estás pensando que podemos establecer un SPN de "HTTP/Algún_nombre_inventado" bajo "EMPRESA\Mi_cuenta_de_Servicio". Doh!!!! No! lo siento mucho pero no es así. Estuvo cerca, pero Kerberos probablemente no funcionaría con eso. El problema con esa idea es que usted tiene que saber también cómo la resolución de nombres funciona porque, en definitiva, es la resolución de nombres que dicta cuál debe ser la parte de "nombre del host" del SPN. Si abre un ventana de línea de CMD y hace ping a Algún_nombre_inventado, lo más probable es que se resolverá en Algún_nombre_inventado.EMPRESA.com. Por lo tanto, el SPN que “IE” va a pedir es "HTTP/ Algún_nombre_inventado.EMPRESA.com ". IE no fue programado para solicitar un SPN utilizando el número de puerto así que esa parte del SPN no es necesaria ni ahora ni nunca. ¿Qué sucede si el comando ping mostró el nombre como solo " Algún_nombre_inventado "? A continuación, IE haría uso de Kerberos con un SPN de formato "HTTP/ Algún_nombre_inventado "

Al tratar con nombres de formato NetBIOS, y debido a que la resolución de nombres puede ser afectada por muchas cosas, la clave es asegurarse de que un SPN de ambos formatos "HTTP/ Algún_nombre_inventado " y "HTTP/ Algún_nombre_inventado.EMPRESA.com " se establezca en la cuenta de “EMPRESA\Mi_cuenta_de_Servicio ". O la manera que prefiero decir es que usted siempre necesita crear un SPN que representa el nombre NetBIOS y el nombre totalmente calificado (FQDN).

Ahora bien, me parece escuchar lo que muchos están pensando. "Pero yo pensaba que el artículo aquel de KB dice que establezca el SPN bajo la cuenta de equipo y no de servicio!" Bueno, sí, eso sería preciso * solamente * si la manipulación del proceso de autenticación se estaba ejecutando como "SISTEMA". Si el proceso para ese servicio no se está ejecutando como de SISTEMA (o como servicio de red o servicio local), entonces, NO se puede establecer el SPN bajo la cuenta de equipo (bueno, si se puede pero Kerberos no va a trabajar).

Recapitulación 2: Un SPN debe establecerse realmente en el formato: “TipodeServicio/Nombre_NetBIOS” Y “TipodeServicio/FQDN.

Y * siempre * hay que establecerlo en la cuenta que está ejecutando el proceso y que está controlando la autenticación. Lea los párrafos anteriores un par de veces y sólo mantenga la fe que es realmente así de simple. No, se compliquen con preguntas!!!!

Quiero mencionar una última cosa antes de terminar. Cada vez que un equipo está unido a un dominio, tiene asignado por defecto 2 SPNs: HOST/netbiosName y HOST/FQDN.com.

NetbiosName es el nombre del equipo que va a unirse al dominio y FQDN.com es el nombre del equipo completo. Estos dos SPNs utilizan el de servicio de tipo genérico "HOST" que incluye todos los diversos servicios que ya vienen incluidos en Windows. Por lo tanto, si se conecta a https://machineName o https://machineName.company.com, ya tienes los dos SPNs que controlará Kerberos cuando se utilizan cualquiera de éstos nombres. O si usted se conecta a \\nombre_de_máquina\Nombre_compartido también ya estaría listo para usar Kerberos (UNC necesita un SPN "CIFS" que se incluye también en el servicio de "HOST").