La increíble y triste historia de los SPN Duplicados y los Lingering Objects!
Escrito por: Diana Hernandez
Conceptos:
Comencemos por entender que es un SPN: Service Principal Name.
Los Services Principal Names o SPNs, están asociados con el security principal (cuenta de usuario, computador o grupo por ejemplo) en el cual el servicio se ejecuta. El SPN se utiliza para soportar autenticación mutua entre un cliente y el servicio. Un SPN se asocia a una cuenta y una cuenta puede tener más de un SPN.
Para autenticación utilizando Kerberos el uso de SPN es requerido.
La sintaxis básica de un SPN es:
< service type >/< instance name >:< port number >/< service name >
• |
service type . Tipo de servicio, como www (World Wide Web service) o ldap (Lightweight Directory Access Protocol). |
• |
instance name . Nombre de la instancia del servicio. Dependiendo del tipo de servicio, este campo corresponde al nombre o a la IP del host en donde se ejecuta el servicio. |
• |
port number . Numero del puerto utilizado por el servicio si es diferente del estándar. |
• |
service name . Nombre del servicio, si este es diferente del nombre de la instancia. Algunos servicios crean automáticamente sus SPNs mientras que bajo ciertas condiciones para otros (por ejemplo SQL o IIS) generalmente se hace manualmente la creación de estos SPN. Esta operación se puede realizar utilizando la herramienta setspn. Ver el siguiente link para más detalles. Cuando se presenta la situación en que dos servicios tienen el mismo SPN asociado, entonces el evento 11 proveniente del KDC (Kerberos Distribution Center) aparece en el Visor de Eventos del Sistema. El evento se registra cuando el KDC recibe un requerimiento de ticket y el SPN relacionado (que está incluido en el requerimiento) existe más de una vez cuando se verifica en el Catalogo Global. Recordemos que el KDC es el encargado de distribuir los tickets de Kerberos para el proceso de autenticación. Pasos de para solucionar el problema: Paso 1: Identificar las cuentas con el SPN duplicado Para resolver este problema, el primer paso es localizar las cuentas que tienen el mismo SPN asociado. Para eso el método más sencillo es utilizar la herramienta ldifde y hacer una búsqueda en el Directorio Activo. Esta búsqueda se hace en el controlador de dominio en donde se registrar el evento 11. ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=HOST/mycomputer*)" -p subtree Se utiliza el parámetro –t 3268 para especificar que un catalogo global se va a utilizar en la consulta. HOST/mycomputer puede ser remplazado por el SPN que se menciona en el evento 11. Estamos usando el forest root DN para realizar la búsqueda. En el archivo generado, eso es check_SPN.txt hacer una búsqueda por el SPN mencionado en el evento 11. Paso 2: Determinar cual cuenta tiene el SPN incorrecto. Esta parece ser una tarea sencilla. En un caso de soporte particular que estuve trabajando recientemente, el evento 11 hacía referencia al SPN: cifs\host.domain.com (en donde host.domain.com es el FQDN del servidor en donde esta ejecutándose el servicio) ; para mi sorpresa al realizar la búsqueda utilizando la herramienta ldifde, no encontraba ningún SPN como ese en el dominio. Luego de investigar un poco, descubrí que algunos servicios son atendidos por el SPN HOST/host.domain.com como es el caso de CIFS (Common Internet File System). El siguiente link que explica como funciona Kerberos contiene una lista de los SNP que son reconocidos por la cuenta de computador. Para hacer el escenario más interesante, el resultado de mi búsqueda hacía referencia a un objeto cuyo nombre DN incluía las letras “0ACNF”, algo de este estilo: dn: CN=COMPUTERNAME\0ACNF:GUID,OU=Domain Controllers, DC=domain, DC=com. |
Ahora la pregunta es: En donde estaban ubicados estos objetos? El resultado fue que estaban presentes solamente en la partición de lectura de los catálogos globales. Para mi asombro estábamos frente a una situación de SPN duplicados con lingering objects! Interesante verdad?
Para verificar en donde estaban presentes estos objetos se hizo una consulta del siguiente tipo con la herramienta repadmin:
Repadmin /showobjmeta * “DN found on previous query”
Esta consulta solo retorno nombres de Catálogos Globales.
Paso 3: Corregir la cuenta con el SPN incorrecto.
En teoría el problema de los SPN duplicados se debería corregir borrando o modificando el SPN que no está correcto. En mi caso esto no es tan fácil porque el objeto que está creando conflicto se encuentra localizado en una partición de solo lectura (Catalogo Global). Como se resolvió el problema entonces?
Para resolver el problema original fue necesario remover los lingering objects que estaban causando los SPNs duplicados. Se siguió básicamente el KB 314282, con la única observación que los lingering objects de mi escenario tenían objetos hijos y fue necesario removerlos primero antes de poder librarnos de los principales. Estoy incluyendo el link al artículo al que hago referencia.
314282 Lingering objects may remain after you bring an out-of-date global catalog
server back online
https://support.microsoft.com/default.aspx?scid=kb;EN-US;314282
Conclusión:
La historia tuvo un final feliz aunque tal vez Gabriel Garcia Márquez no la hubiera usado para uno de sus libros J
El caso original requirió de varias horas de soporte para podernos deshacer de los eventos 11 ya que involucró varios conceptos en un solo caso, resumiendo:
- SPNs incluidos en el HOST\computername.domain.com
- SPNs duplicados causados por objetos ubicados solamente en los catálogos globales.
- Lingering objects con objetos hijos, lo cual hizo un poco más complicado su eliminación.
Espero la historia haya sido de su agrado…hasta la próxima!