¿Qué es SPN y cuál es 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.