SPN y su papel en Active Directory y la seguridad

Los Service Principal Names (SPNs) son identificadores únicos en Active Directory utilizados para mapear instancias de servicio a cuentas de servicio para la autenticación Kerberos. Este artículo explica la estructura de SPN, registro, requisitos de unicidad, herramientas (por ejemplo, setspn) e implicaciones de seguridad. Cubre ataques como Kerberoasting, mejores prácticas, métodos de detección y casos de uso avanzados en entornos híbridos, en la nube y contenerizados.

Introducción a los Service Principal Names (SPNs)

¿Qué es un SPN? Incluso un administrador de Windows con algo de experiencia en Active Directory puede desconocer el papel que los Service Principal Names tienen en los entornos de dominio. Un nombre de principal de seguridad (SPN) es un identificador único que vincula una instancia de servicio específica a la cuenta que lo ejecuta, permitiendo a los clientes autenticarse y conectarse al servicio correcto dentro de Active Directory (AD). Esto es particularmente importante en entornos empresariales grandes donde múltiples instancias de un servicio pueden ejecutarse en diferentes servidores. En este artículo discutiremos qué es el SPN de active directory, cuál es su contribución a la seguridad y cómo sus usos continúan expandiéndose en las redes modernas de hoy.

Función de los SPN en la autenticación Kerberos

Así como necesitas un boleto para abordar un avión o entrar a un cine, también necesitas un boleto para acceder a recursos dentro de Active Directory (AD). Cuando un cliente solicita acceso a un servicio alojado en AD, el proceso se desarrolla de la siguiente manera:

1. Un cliente que intenta usar un servicio crea un SPN para ese servicio
2. El cliente solicita al controlador de dominio un ticket utilizando ese SPN
3. El controlador de dominio busca en Active Directory ese SPN
4. Una vez encontrado, el controlador de dominio emite un ticket de servicio
5. El cliente utiliza este ticket para autenticarse en el servicio sin necesidad de una contraseña

Desglosando los conceptos básicos

Componentes de un SPN

SPN consta de múltiples componentes que, cuando se combinan, proporcionan una identidad completa para un servicio específico:

1. Clase de servicio: Este es el nombre de la instancia del servicio, como “MSSQLSvc” para Microsoft SQL Server o “www” para servicios web.
2. Hostname: Especifica el servidor o host donde se ejecuta el servicio. Esto puede ser el nombre NetBIOS de una máquina Windows como “FilerServer” o el nombre de dominio completamente calificado como “fileserver.company.com”
3. Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
4. Puerto (Opcional): Si el servicio se ejecuta en un puerto no estándar, se puede especificar en el SPN.

Ejemplos de SPNs comunes en Active Directory

• Servicios Web – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• Comparticiones de archivos – CIFS/fileserver.contoso.com
• Servicios de Escritorio Remoto – TERMSRV/rdserver.abcdomain.com
• Autenticación LDAP – LDAP/domaincontroller.fabricam.com

SPNs y Active Directory: La conexión

Cómo los SPNs se integran con los objetos de Active Directory

Los SPN son atributos asociados con objetos de AD como cuentas de usuario, cuentas de servicio o objetos de computadora. Funcionan como etiquetas que indican qué servicios se ejecutan bajo qué cuentas. Esta conexión permite que las computadoras utilicen Kerberos para autenticación segura sin enviar contraseñas a través de la red. Cuando se instala o configura un servicio, registra un SPN que permite a Kerberos mapear las solicitudes de autenticación a la cuenta correcta. Sin un SPN configurado adecuadamente, la autenticación de Kerberos fallará, lo que podría causar errores de autenticación y disrupciones del servicio.

Almacenamiento de SPN en el atributo servicePrincipalName

Los SPN se almacenan dentro de Active Directory como parte del atributo servicePrincipalName de un objeto. Este atributo existe en las cuentas de computadora y las cuentas de servicio. Puedes ver este atributo en las propiedades avanzadas de un objeto usando Active Directory Users and Computers como se muestra en la captura de pantalla a continuación.

El atributo contiene una lista de SPN asignados al objeto. Cada entrada de SPN sigue un formato estructurado que incluye el tipo de servicio, el host y el número de puerto opcional.

Puede ver los SPN de un objeto AD utilizando el comando: setspn –L hostname. En el ejemplo a continuación, se ha utilizado el comando para ver la lista de SPN generados por un controlador de dominio para un dominio llamado ABCDomain.com

Importancia de la unicidad de SPN en un bosque de AD

Cada nombre de entidad de servicio debe ser único en todo el bosque de Active Directory. Esta singularidad garantiza que Kerberos pueda enrutar correctamente las solicitudes de servicio a la cuenta adecuada. Los SPN duplicados en diferentes cuentas causan conflictos de autenticación, lo que resulta en comportamientos impredecibles o fallos de autenticación directos.

Configuración de SPNs: Guía paso a paso

Herramientas necesarias para la configuración de SPN

La herramienta principal para la configuración de SPN es setspn.exe, que viene integrada en los sistemas operativos de Windows Server. Esta herramienta de línea de comandos permite a los administradores leer, modificar y eliminar nombres de entidad de servicio para cuentas de servicio de Active Directory.

En un ejemplo anterior, utilizamos el comando setspn -L para ver el SPN de un objeto de computadora. También puedes usar setspn -S para agregar un SPN. Por ejemplo, para agregar un SPN HTTP a una computadora llamada webserver1, el comando sería:

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

Tenga en cuenta que el comando setspn -S verifica automáticamente si existen SPNs idénticos antes de crear nuevos para evitar entradas duplicadas.

Para eliminar un SPN, utilice el comando setspn -D. También puede usar PowerShell de varias maneras para los SPNs. Por ejemplo, el siguiente cmdlet de PowerShell encontrará todos los SPNs registrados en Active Directory:

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

Mientras que este detectará todos los SPN duplicados.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

Mejores prácticas para el registro de SPN

• Otorgue los permisos mínimos necesarios a las cuentas de servicio para el registro de SPN
• Utilice PowerShell para verificar duplicados antes de registrar un nuevo SPN:
• Realice auditorías periódicas de los SPNs para identificar y eliminar entradas innecesarias o desactualizadas
• Utilice un formato de nombre SPN estandarizado al agregar SPN

Solución de problemas comunes de SPN

Los SPN duplicados pueden causar fallos de autenticación y deben resolverse. Esté atento a los usuarios que informan problemas de acceso intermitentes, ya que esto podría indicar conflictos de SPN. Puede utilizar el comando setspn -x para encontrar duplicados dentro de un solo dominio como se muestra en la captura de pantalla a continuación.

Utilice el comando setspn -F para buscar en todo el bosque. Para resolver SPNs duplicados:

1. Identifique las cuentas que poseen los SPN duplicados.
2. Determine qué cuenta debe poseer legítimamente el SPN.
3. Elimine el SPN de la cuenta incorrecta utilizando setspn -D <SPN> <AccountName>8.
4. Agregue el SPN a la cuenta correcta utilizando setspn -S <SPN> <AccountName>

Además de los duplicados, algunas otras configuraciones erróneas comunes de SPN incluyen:

• Faltan SPNs para servicios
• SPN registrados en cuentas incorrectas
• SPN obsoletos después de cambios en el nombre del servidor

(No es necesario volver a listar las mismas herramientas aquí que ya cubrimos)

Conceptos avanzados de SPN

El papel de los SPNs en entornos multi-servicio y multi-host

Las cuentas de servicio son cuentas de usuario especializadas creadas para servicios que se ejecutan en Windows Server. Ayudan a aislar y proteger cuentas de dominio en aplicaciones críticas como Internet Information Services (IIS). En entornos complejos, a menudo se ejecutan múltiples servicios en la misma máquina, cada uno requiriendo Nombres Principales de Servicio (SPNs) distintos para una autenticación adecuada.

Un ejemplo común es un servidor que aloja una aplicación web podría ejecutar tanto SQL Server como IIS. Cada servicio necesita su propio SPN para garantizar la autenticación correcta de Kerberos:

• Para IIS: HTTP/servername.domain.com
• Para SQL Server: MSSQLSvc/servername.domain.com:1433

En entornos multi-host, donde un servicio se ejecuta en varios servidores para balanceo de carga o failover, la configuración de SPN se vuelve más compleja. Considere una aplicación web alojada en varios servidores (Web01, Web02, Web03) bajo un nombre DNS compartido. En este escenario, los SPNs deben registrarse en una única cuenta de servicio para permitir la autenticación sin interrupciones en todos los hosts:

Casos especiales: HOST SPNs y su comportamiento único

Los SPN de HOST son un tipo especial de SPN que se registran automáticamente en objetos de computadora en Active Directory. Actúan como un identificador general para los servicios que se ejecutan bajo la cuenta del sistema local o la cuenta del servicio de red de una máquina. Esto simplifica la gestión de muchos servicios estándar de Windows y reduce la necesidad de configuración manual de SPN.

La siguiente tabla resume cuándo debe usar HOST SPNs frente a Custom SPNs:

Consejo: Nunca debe modificar manualmente los SPN de HOST ya que son gestionados por AD.

SPNs e implicaciones de seguridad

Por qué es crítico asegurar los SPN en un entorno de AD

La razón por la que la seguridad es importante para los SPN es simple. Las cuentas de servicio a menudo tienen privilegios elevados. También tienen acceso continuo a sistemas críticos dentro de la red y a menudo se olvidan una vez que se crean. Todo esto los convierte en objetivos de alto valor para los atacantes. Comprometer un SPN puede llevar a un acceso no autorizado a servicios críticos y potencialmente permitir a los atacantes moverse lateralmente dentro de la red y escalar sus privilegios

Cómo se pueden explotar los SPNs débiles

Cuando los SPNS están configurados débilmente, pueden ser explotados a través de ataques como Kerberoasting. Así es como un atacante llevaría a cabo tal ataque:

• Un atacante con privilegios mínimos de dominio puede solicitar tickets de servicio para cualquier SPN Solicita tickets de servicio para estos SPN
• El ticket de servicio, cifrado con el hash de la contraseña de la cuenta de servicio, puede extraerse y llevarse fuera de línea para ser descifrado
• Realiza cracking de contraseñas sin conexión en estos y si la contraseña es débil, los atacantes pueden potencialmente descifrarla y obtener acceso a la cuenta de servicio, a menudo con privilegios elevados

Una vez que el atacante descifra la contraseña de una cuenta de servicio y si esa cuenta tiene altos privilegios, pueden moverse lateralmente a través de la red o escalar su acceso.

Mejores prácticas para asegurar SPNs y cuentas de servicio

A continuación se presenta una lista de las mejores prácticas para mitigar los riesgos de seguridad asociados con los SPNs:

• Utilice contraseñas largas y complejas para cuentas con SPN y cámbielas regularmente
• Evite asignar SPNs a cuentas de alto privilegio como Domain Admins
• Restrinja las cuentas de servicio solo a los permisos necesarios para su función
• Deshabilite el inicio de sesión interactivo para cuentas de servicio
• Monitoree el uso inesperado de comandos relacionados con SPN en PowerShell.
• Dado que cualquier usuario con autenticación de dominio puede buscar SPNs, debe limitar quién puede realizar estas consultas cambiando los permisos en Active Directory.

Detección y mitigación del abuso de SPN

Monitoreo y auditoría de actividades relacionadas con SPN

El monitoreo continuo de su entorno de AD y la auditoría de eventos relacionados con Kerberos pueden ser muy efectivos para prevenir el abuso de SPN. Algunas de las cosas que debería detectar incluyen:

• Solicitudes inusuales de enumeración de SPN ya que los atacantes pueden consultar AD por SPNs utilizando herramientas LDAP.
• Solicitudes frecuentes de tickets de Kerberos ya que cualquier aumento repentino en las solicitudes de tickets de servicio podría indicar un ataque en curso.
• Inicios de sesión de cuentas de servicio desde ubicaciones inesperadas en lugar de las ubicaciones designadas habituales.
• Los intentos fallidos de autenticación como fallos repetidos sugieren ataques de fuerza bruta o de password spraying.

Implementación de estrategias de mitigación contra ataques basados en SPN

Si su organización opera dentro de un entorno de Windows Active Directory, debería considerar los siguientes controles de seguridad preventivos para minimizar el riesgo de abuso de SPN y ataques de Kerberoasting.

• Utilice contraseñas largas y complejas (mínimo absoluto de 14 caracteres) para las cuentas de servicio
• Evite la reutilización de contraseñas en diferentes cuentas y cambie las contraseñas regularmente
• Aplicar el principle of least privilege para limitar los permisos de las cuentas.
• Aplique tiempos de vida más cortos para los tickets Kerberos para minimizar la ventana de ataque
• Revise y elimine regularmente los SPNs obsoletos o innecesarios
• Adopte una estrategia de defensa multicapa que combine una gestión sólida de cuentas de servicio, monitoreo sofisticado y programas regulares de capacitación.

Usando Group Managed Service Accounts y métodos de encriptación fuertes

Implemente Group Managed Service Accounts (gMSAs) para beneficiarse de la gestión automática de contraseñas. Las Group Managed Service Accounts (gMSAs) son cuentas de servicio especializadas en Active Directory que ofrecen características de seguridad mejoradas en comparación con las cuentas de servicio tradicionales. Son particularmente útiles para servidores unidos al dominio que ejecutan servicios como SQL Server, aplicaciones web IIS, tareas programadas y otros servicios que necesitan ejecutarse en un contexto de seguridad con permisos específicos. Utilizar gMSAs eliminará la asignación manual de contraseñas y reducirá el riesgo de robo de credenciales. En cuanto a la encriptación, aplique una encriptación Kerberos AES128/AES256 fuerte mientras deshabilita los tipos de encriptación más débiles DES y RC4 en Active Directory.

Aplicaciones prácticas y casos de uso

Como se mencionó, los SPN se utilizan en la autenticación Kerberos para aplicaciones web y bases de datos. IIS utiliza SPN en el formato “HTTP/ServerName” que se asigna a la cuenta de dominio que ejecuta el grupo de aplicaciones, mientras que “MSSQLSvc/host.domain.com:1433” es un ejemplo de una cuenta de servicio SQL. El papel de los Nombres de Principal de Servicio (SPN) está evolucionando más allá de los casos de uso tradicionales, sin embargo, a medida que las empresas adoptan cada vez más arquitecturas de red híbridas. Hoy en día incluso estamos viendo cómo los SPN facilitan la autenticación segura entre recursos locales y aplicaciones nativas de la nube. Otros ejemplos incluyen:

• Los SPN se utilizan para gestionar identidades y accesos para aplicaciones y servicios contenerizados ubicados en entornos contenerizados.
• Los entornos perimetrales utilizan SPNs para facilitar la comunicación segura entre dispositivos perimetrales y recursos centralizados en la nube.
• Azure AD Connect utiliza SPNs para los servicios de sincronización entre AD local y Azure AD.

También hay un uso creciente de SPNs dentro de los entornos empresariales hoy en día. Por ejemplo, los equipos de seguridad están monitoreando los registros de uso de SPN para detectar intentos de acceso no autorizados o fallos de Kerberos. Otros ejemplos incluyen:

• Single Sign-On (SSO): Los SPN permiten SSO basado en Kerberos a través de múltiples aplicaciones y servicios.
• Integración de aplicaciones: Los SPNs facilitan la comunicación segura entre diferentes aplicaciones y servicios empresariales.
• La autenticación delegada: los SPN permiten que los servicios se autentiquen en nombre de los usuarios para aplicaciones multinivel.

Conclusión

Los Service Principal Names (SPNs) han sido una piedra angular de la autenticación Kerberos desde el inicio de la creación de Active Directory. Han sido un elemento básico para muchos de los servicios clásicos en los que confían los usuarios de la red y los SPNs juegan un papel vital en garantizar operaciones seguras y sin interrupciones a través de numerosos servicios de fondo. A medida que las organizaciones continúan expandiéndose y evolucionando, las aplicaciones de los SPNs se están ampliando hacia cosas como la integración en la nube y el IoT. Con el creciente énfasis en la seguridad en las empresas hoy en día, es muy probable que los SPNs jueguen un papel más importante, adaptándose a nuevas tecnologías y desafíos de seguridad en el paisaje digital en constante expansión.

¿Qué es SPN?

Un Service Principal Name (SPN) es un identificador único que vincula una instancia específica de servicio con la cuenta de Active Directory que la ejecuta. Los SPN deben ser únicos en todo el bosque de Active Directory.

Si dos cuentas tienen el mismo SPN, el controlador de dominio no puede determinar a cuál emitir un ticket, y la autenticación falla. Si ninguna cuenta tiene el SPN, la solicitud falla completamente y el cliente suele recurrir a NTLM, que conlleva sus propios riesgos.

Un SPN registrado en una cuenta de usuario personal en lugar de una cuenta de servicio administrada hace que ese ataque sea viable. La defensa es la higiene de las cuentas de servicio. Use Group Managed Service Accounts. Aplique contraseñas largas y generadas aleatoriamente en cualquier cuenta que aún tenga un SPN. Monitoree el Evento ID 4769 para detectar picos en solicitudes de tickets que delaten el ataque.

Papel de los SPN en la autenticación Kerberos

También son la superficie de ataque para Kerberoasting. Cualquier usuario autenticado en el dominio puede solicitar un ticket de servicio Kerberos para una cuenta con SPN y descifrarlo sin conexión para obtener la contraseña de la cuenta, sin activar un umbral de bloqueo.

1. El cliente construye un SPN para el servicio al que desea acceder.

Un entorno de Active Directory que ejecuta SQL Server, IIS, Exchange y aplicaciones personalizadas necesita que cada servicio se autentique sin solicitar a los usuarios sus credenciales en cada solicitud ni incrustar contraseñas en archivos de configuración. Los Service Principal Names son lo que hace esto posible.

Cuando un cliente solicita acceso a un servicio, el flujo de autenticación Kerberos sigue una secuencia definida:

Los SPN existen en objetos de computadora y cuentas de servicio como un atributo multivalor llamado servicePrincipalNameExpand. Cada entrada en ese atributo representa un servicio registrado. Una cuenta que ejecuta múltiples servicios, o un servicio accesible a través de varios nombres de host, tiene múltiples entradas SPN.

1. El cliente solicita un ticket de servicio al controlador de dominio usando ese SPN.
2. El cliente presenta el ticket al servicio para la autenticación, y no se transmite ninguna contraseña por la red.
3. El controlador de dominio busca el SPN en Active Directory.
4. Una vez encontrado, el controlador de dominio emite un ticket de servicio cifrado con las credenciales de la cuenta de servicio.

Estructura y componentes de SPN

Esta secuencia muestra por qué la precisión del SPN es importante. Un SPN faltante, duplicado o mal configurado interrumpe la búsqueda en el paso 3, causando que la autenticación falle o que se recurra a NTLM.

Componentes de un SPN

Un SPN no es un valor único, sino una cadena estructurada compuesta por varios componentes. Entender esa estructura es esencial para un registro correcto, la resolución de problemas y la revisión de seguridad.

Cada SPN sigue un formato definido que identifica el servicio, el host en el que se ejecuta y, opcionalmente, el puerto que utiliza. Los componentes son:

Formatos comunes de SPN en Active Directory

• Cuenta: la cuenta de Active Directory asociada con el servicio. Esto no forma parte de la cadena SPN en sí, sino que es el objeto al que se registra el SPN.
• Puerto (opcional): incluido cuando el servicio se ejecuta en un puerto no estándar (por ejemplo, MSSQLSvc/host.domain.com:1433Expand).
• Clase de servicio: el nombre del tipo de servicio, como MSSQLSvcExpand para Microsoft SQL Server o HTTPExpand para servicios web.
• Nome host: il server o host dove è in esecuzione il servizio, espresso come nome NetBIOS (ad es., FileServerExpand) o come nome di dominio completo (ad es., fileserver.company.comExpand).

El formato ServiceClass/Hostname: PortExpand produce cadenas predecibles y reconocibles en distintos tipos de servicio. Ejemplos comunes incluyen:

• Servicios web: HTTP/webserver.netwrix.comExpand
• SQL Server: MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• Comparticiones de archivos: CIFS/fileserver.contoso.comExpand
• Servicios de Escritorio Remoto: TERMSRV/rdserver.abcdomain.comExpand

Cómo Active Directory almacena y resuelve los SPN

• Autenticación LDAP: LDAP/domaincontroller.fabrikam.comExpand

El atributo servicePrincipalName

Los SPN son atributos asociados con objetos de AD como cuentas de usuario, cuentas de servicio u objetos de computadora. Actúan como etiquetas que indican qué servicios se ejecutan bajo qué cuentas. Esta conexión permite que las computadoras usen Kerberos para una autenticación segura sin enviar contraseñas a través de la red.

Cuando instala o configura un servicio, este registra un SPN que permite a Kerberos asignar las solicitudes de autenticación a la cuenta correcta. Sin un SPN configurado correctamente, la autenticación Kerberos fallará, lo que puede causar errores de autenticación y interrupciones del servicio.

Cuando un cliente solicita acceso a un servicio, construye un SPN para ese servicio, lo envía al controlador de dominio y el DC busca ese SPN en el directorio. Si lo encuentra, emite un ticket de servicio Kerberos. No se transmite ninguna contraseña a través de la red.

Cómo la unicidad de SPN permite la resolución correcta del servicio

Puede ver los SPN de un objeto AD usando el comando: setspn –L hostname. En el ejemplo siguiente, se usó el comando para ver la lista de SPN generados por un controlador de dominio para un dominio llamado ABCDomain.com.

Los SPN se almacenan en Active Directory como parte del atributo servicePrincipalName de un objeto. Este atributo existe en las cuentas de equipo y en las cuentas de servicio y contiene una lista de todos los SPN registrados para ese objeto. Puede verlo a través de la pestaña de propiedades de un objeto en Active Directory Users and Computers, como se muestra en la captura de pantalla a continuación.

HOST SPNs y cuándo AD los gestiona automáticamente

La tabla a continuación resume cuándo usar HOST SPNs frente a SPNs personalizados:

Los HOST SPNs son una categoría especial de SPNs que Active Directory registra automáticamente en los objetos de computadora. Actúan como un identificador universal para los servicios que se ejecutan bajo la cuenta Local System o Network Service en una máquina, cubriendo muchos servicios estándar de Windows sin necesidad de entradas SPN manuales.

Al solucionar problemas de autenticación, los SPN duplicados deben ser de las primeras cosas que se revisen. Use setspn -XExpand para detectar duplicados dentro de un dominio, y setspn -FExpand para buscar en todo el bosque.

Cada SPN debe ser único en todo el bosque de Active Directory. Esta unicidad es lo que permite que Kerberos authentication enrute las solicitudes de servicio a la cuenta correcta. Si dos cuentas tienen el mismo SPN, el controlador de dominio no puede determinar cuál usar, lo que provoca fallos de autenticación, errores intermitentes de inicio de sesión y conexiones de servicio rotas.

Nunca modifique manualmente los HOST SPNs. Active Directory los gestiona automáticamente y los cambios pueden interrumpir servicios clave.

Cómo configurar y administrar SPNs

Paso 1: Identifique el servicio y la cuenta objetivo

Paso 2: Verifique si existen SPN duplicados o existentes

La configuración correcta de SPN es un requisito previo para que la autenticación Kerberos funcione. El proceso sigue una secuencia constante independientemente del tipo de servicio, y omitir pasos es la causa más común de problemas relacionados con SPN.

Antes de registrar, confirme que el SPN no exista ya en otra cuenta. Use los siguientes comandos para consultar el directorio:

Registrar un SPN duplicado puede causar fallos de autenticación y ser difícil de diagnosticar después.

Paso 3: Registre el SPN con setspn

Antes de registrar un SPN, identifique dos cosas: la clase y formato de servicio necesarios, y la cuenta de Active Directory que ejecutará el servicio. Para servicios estándar (SQL Server, IIS, Exchange), la clase de servicio está bien documentada. Para la cuenta, prefiera una Active Directory service account dedicada o, cuando sea posible, una Group Managed Service Account (gMSA) en lugar de una cuenta compartida o personal.

Para SQL Server que se ejecuta en un puerto no estándar:

Use setspn -SExpand (agregado seguro) para registrar el SPN. La bandera -S verifica automáticamente duplicados antes de crear la entrada, haciéndolo más seguro que la antigua bandera -A:

Paso 4: Verifique el registro

También puede registrar SPN mediante PowerShell usando los cmdlets Set-ADUser o Set-ADComputer, lo que es útil para implementaciones automatizadas o registros masivos.

También puede verificar usando PowerShell:

Después de registrar, confirme que el SPN aparece en la cuenta correcta:

La salida debe listar el SPN recién registrado junto con cualquier otro ya asignado a esa cuenta.

Paso 5: Pruebe la autenticación Kerberos

Corrección de configuraciones erróneas comunes de SPN

La mayoría de los problemas de SPN se clasifican en pocas categorías. Cada uno requiere una solución específica:

En el Visor de eventos de Windows, una solicitud exitosa de ticket de servicio Kerberos aparece como Evento ID 4769. Si la autenticación vuelve a NTLM, es probable que el SPN esté ausente, mal formado o registrado en la cuenta incorrecta.

Con el SPN registrado, pruebe que la autenticación Kerberos sea exitosa. Conéctese al servicio usando credenciales de dominio, luego ejecute klistExpand para confirmar que el DC emitió un ticket de servicio Kerberos (no un ticket NTLM).

Mejores prácticas para el registro de SPN

• SPN duplicados: Use setspn -DExpand para eliminar el SPN de la cuenta incorrecta y luego verificar que permanezca en la correcta. Los duplicados suelen aparecer tras renombrar servidores o migrar cuentas.
• SPN obsoletos tras renombrar un servidor: Se deben eliminar los SPN antiguos que hacen referencia al nombre de host anterior y registrar nuevos con el nombre actual.
• SPN faltantes: Si Kerberos falla y vuelve a NTLM, verifique si el SPN existe usando setspn -QExpand. Regístrelo si no está presente.
• SPN registrados en la cuenta incorrecta: Elimínelos con setspn -DExpand y vuelva a registrarlos en la cuenta de servicio correcta.

Establecer prácticas consistentes para la gestión de SPN reduce tanto las fallas operativas como el riesgo de seguridad:

• Realice auditorías regulares de PowerShell para identificar SPN registrados en cuentas inapropiadas.
• Asigne SPNs a cuentas de servicio dedicadas, no a cuentas de usuario personales ni a cuentas de Domain Admin.
• Use setspn -SExpand (no -A) al registrar para evitar duplicados accidentales.
• Utilice un formato de nombres estandarizado en todo su entorno para simplificar las auditorías.

Riesgos de seguridad de SPNs mal configurados

Kerberoasting

• Conceda a las cuentas los permisos mínimos necesarios. El registro SPN requiere acceso de escritura al atributo servicePrincipalNameExpand, que no debe concederse de forma amplia.

Las cuentas de servicio asociadas con SPNs están entre las identidades más atacadas en Active Directory. A diferencia de las cuentas de usuario estándar, a menudo tienen privilegios elevados, mantienen acceso persistente a sistemas críticos y rara vez se revisan una vez creadas. Esta combinación genera riesgos de seguridad asociados con SPNs mal configurados.

Ataques de ticket plateado

Un atacante puede solicitar el ticket, extraerlo y realizar un descifrado de contraseñas sin conexión sin activar bloqueos ni generar ruido significativo en la red.

Kerberoasting es la técnica de ataque basada en SPN más común. Cualquier usuario autenticado en el dominio, incluidas cuentas con pocos privilegios, puede solicitar un ticket de servicio Kerberos para cualquier SPN en el directorio. Ese ticket está cifrado con el hash de la contraseña de la cuenta de servicio.

El cifrado RC4 hace que este ataque sea significativamente más rápido porque los tickets Kerberos cifrados con RC4 son más fáciles de descifrar que los modernos protegidos con AES, por lo que Microsoft está eliminando activamente RC4 en entornos AD.

Si la cuenta de servicio usa una contraseña débil o reutilizada, el atacante puede recuperar las credenciales en texto plano y obtener acceso al servicio, a menudo con privilegios elevados.

Movimiento lateral a través de cuentas de servicio comprometidas

Cómo defenderse contra ataques basados en SPN

Escalada de privilegios a través de SPNs de alto privilegio

Los SPN registrados en cuentas con permisos excesivos, especialmente cuentas con derechos de Domain Admin o acceso sin restricciones a sistemas críticos, representan las configuraciones de mayor riesgo. Un ataque Kerberoasting exitoso contra una de estas cuentas no solo compromete un servicio; puede otorgar al atacante control a nivel de dominio.

Detección de Kerberoasting y enumeración de SPN

Una consecuencia natural del Kerberoasting es el ataque de ticket plateado. Una vez que un atacante descifra el hash de la contraseña de una cuenta de servicio, puede usarlo para forjar tickets de servicio Kerberos completamente sin conexión, sin interacción adicional con el controlador de dominio. Estos tickets plateados otorgan acceso persistente al servicio objetivo y son especialmente difíciles de detectar porque evitan completamente el DC.

Las cuentas de servicio suelen tener acceso a múltiples sistemas. Cuando un atacante compromete una, obtiene un punto de apoyo que permite movimiento lateral a través del entorno. Debido a que las cuentas de servicio a menudo se excluyen de las reglas estándar de monitoreo y detección de anomalías, este movimiento puede pasar desapercibido durante largos períodos.

La monitorización continua de su entorno AD es la primera línea de defensa. Los indicadores a vigilar incluyen:

La defensa contra ataques basados en SPN opera en tres áreas: detectar el abuso temprano, responder eficazmente cuando ocurre y reforzar el entorno para reducir la superficie de ataque antes de que suceda un incidente.

• Consultas inusuales de enumeración de SPN. Los atacantes suelen usar herramientas LDAP para listar todos los SPN en un dominio durante el reconocimiento.
• Inicios de sesión de cuentas de servicio desde hosts inesperados o en horarios inusuales.

Restringir quién puede consultar SPNs modificando permisos en Active Directory reduce la ventana de reconocimiento disponible para atacantes con pocos privilegios.

Contención y respuesta al abuso de SPN

• Un aumento repentino en el Evento ID 4769 (solicitudes de tickets de servicio Kerberos), especialmente aquellos que usan cifrado RC4 (tipo de cifrado 0x17), indica fuertemente Kerberoasting, ya que los atacantes prefieren tickets RC4 para un descifrado más rápido.
• Intentos repetidos de autenticación fallida, que pueden indicar ataques de fuerza bruta o password-spraying contra credenciales comprometidas.

Cuando se detecta un abuso basado en SPN, la prioridad es limitar la capacidad del atacante para usar las credenciales comprometidas:

• Restablezca inmediatamente la contraseña de la cuenta de servicio afectada con una credencial larga generada aleatoriamente.
• Revise si la cuenta tiene más privilegios de los que requiere su función y reduzca esos privilegios.
• Revise todos los sistemas a los que la cuenta de servicio tiene acceso y audite la actividad reciente en busca de signos de movimiento lateral.

Endurecimiento de cuentas de servicio habilitadas para SPN

El endurecimiento proactivo elimina muchas de las condiciones que hacen viables los ataques basados en SPN:

• Utilice contraseñas largas generadas aleatoriamente (mínimo 25 caracteres) para las cuentas de servicio y cámbielas según un calendario definido.
• Revoca cualquier ticket Kerberos activo emitido a la cuenta restableciendo las claves de cifrado Kerberos de la cuenta (no se necesita un restablecimiento de krbtgt para mitigar tickets silver; restablecer la contraseña de la cuenta de servicio invalida los tickets falsificados).
• Desactive el inicio de sesión interactivo para cuentas de servicio para limitar su utilidad si se ven comprometidas.
• Aplica el principio de menor privilegio. Las cuentas de servicio deben tener acceso solo a los sistemas y datos que su función requiere.

Uso de gMSA y cifrado AES para eliminar el riesgo persistente

• Migre a Group Managed Service Accounts siempre que sea posible, ya que automatizan la gestión de contraseñas y dificultan significativamente el Kerberoasting.

Las Group Managed Service Accounts (gMSAs) son cuentas de servicio especializadas que eliminan por completo la necesidad de gestionar contraseñas manualmente. Active Directory gestiona las contraseñas de gMSA automáticamente, rotándolas según un calendario definido con credenciales largas y generadas aleatoriamente que los administradores de servicio y de dominio nunca ven ni manejan directamente.

SPN en entornos híbridos y modernos

Por defecto, Windows rota las contraseñas gMSA cada 30 días, y el intervalo está controlado por el atributo msDS‑ManagedPasswordInterval (o el parámetro ManagedPasswordIntervalInDays al crear el gMSA), que solo puede establecerse en el momento de la creación.

Para los servicios que no soportan gMSAs, aplique cifrado Kerberos AES-128 o AES-256 y desactive explícitamente los tipos de cifrado más débiles RC4 y DES en Active Directory. El cifrado RC4 es el predeterminado usado en ataques de Kerberoasting; eliminarlo obliga a usar AES, que es significativamente más resistente a la descifrado offline.

• Nunca asigne SPNs a cuentas con membresías en Domain Admin u otros grupos de alto privilegio.

SPNs y Microsoft Entra Connect

El papel de SPNs se ha ampliado más allá del tradicional Active Directory local a medida que las organizaciones adoptan arquitecturas híbridas y cargas de trabajo en contenedores. SPNs siguen siendo relevantes dondequiera que se utilice la autenticación Kerberos y, en algunos contextos nuevos, permiten patrones de autenticación que no existían en el diseño original de AD.

SPN en entornos containerizados

Autenticación delegada en aplicaciones multinivel

Microsoft Entra Connect utiliza SPNs para sus servicios de sincronización entre Active Directory local y Entra ID (anteriormente Azure AD). La cuenta del servicio de sincronización requiere SPNs configurados correctamente para autenticarse en ambos directorios. Los SPNs mal configurados o ausentes pueden interrumpir silenciosamente la sincronización del directorio, causando que los datos de identidad queden obsoletos en todo el entorno híbrido.

Delegación Kerberos permite que un servicio se autentique en recursos descendentes en nombre de un usuario. Esto es común en aplicaciones multinivel donde un front-end web necesita pasar la identidad del usuario a una base de datos backend.

Las cargas de trabajo en contenedores que se ejecutan en Windows Server pueden usar gMSAs y, por extensión, SPNs, para Active Directory security. Las implementaciones de Kubernetes y Docker en hosts unidos al dominio pueden configurarse para solicitar credenciales gMSA, lo que permite que los servicios en contenedores se autentiquen en recursos integrados con AD usando Kerberos sin incrustar credenciales en las imágenes de contenedores.

Los SPN son fundamentales para esto: la delegación se configura en la cuenta de servicio que posee el SPN, y cada salto en la cadena de autenticación depende de SPN correctamente registrados.

Los SPN son fundamentales y cada vez más objetivo

La delegación sin restricciones, donde un servicio puede suplantar a cualquier usuario en cualquier recurso, representa una superficie de ataque significativa y debe reemplazarse por delegación restringida o delegación restringida basada en recursos siempre que sea posible.

Los Service Principal Names han sido una piedra angular de la autenticación Kerberos desde el inicio de Active Directory. Permiten una autenticación segura de servicios sin contraseña en entornos empresariales, pero solo cuando están correctamente configurados, auditados regularmente y estrictamente gobernados.

Netwrix ofrece herramientas diseñadas específicamente para los dos desafíos de seguridad SPN de mayor prioridad: detectar ataques en curso y mantener la visibilidad de los cambios en AD que introducen riesgo.

Cómo puede ayudar Netwrix

A medida que las organizaciones se expanden hacia infraestructuras híbridas, contenedores y sistemas de identidad integrados en la nube, los SPN aparecen en más lugares y están vinculados a cuentas con un acceso más amplio que nunca.

El cálculo de amenazas ha cambiado en consecuencia. Kerberoasting se ha convertido en una de las técnicas de movimiento lateral más comúnmente observadas en brechas empresariales, precisamente porque los SPN son tanto ubicuos como poco supervisados. Las configuraciones erróneas que antes causaban fallos de autenticación ahora forman parte de la superficie de ataque.

Comprender los SPN, cómo están estructurados, cómo los resuelve AD y cómo los atacantes explotan configuraciones débiles es el primer paso para protegerlos. Los pasos operativos cubiertos en este artículo proporcionan una base. Sobre eso, la supervisión continua, auditorías regulares de SPN y, cuando sea posible, la migración a gMSA ayudan a las organizaciones a adelantarse a la amenaza.

Netwrix Threat Manager detecta ataques basados en identidad, incluyendo Kerberoasting, consultas de enumeración SPN y solicitudes sospechosas de tickets de servicio en Active Directory local y Entra ID.

Se correlaciona con actividad anómala a nivel de cuenta. Cuando un usuario con pocos privilegios solicita repentinamente 50 tickets de servicio, los equipos de seguridad lo ven como una alerta consolidada única en lugar de entradas de registro aisladas.

Solicite una demostración para ver cómo Netwrix puede ayudarle a detectar el abuso de SPN, auditar los cambios en AD en tiempo real y reducir la superficie de ataque antes de que los adversarios la exploten.

Netwrix Auditor registra cada cambio en el atributo servicePrincipalName en todo su entorno AD, con valores antes y después y la cuenta responsable de cada cambio. Cuando se registra un SPN en una cuenta de alto privilegio o se elimina inesperadamente de una cuenta de servicio, Auditor muestra ese cambio de inmediato.