Violación de restricción en principal de Active Directory que no existe

Síntomas

El error CONSTRAINT_ATT_TYPE es la respuesta LDAP para cuando una operación es denegada porque no cumplió determinadas restricciones.

Como indica Ldapwiki, los motivos para devolver un error CONSTRAINT_ATT_TYPE pueden ser múltiples como pueden serlo las restricciones que pudo haber violado la operación y no siempre está claro qué es lo que fue mal.

Sin embargo, Active Directory sí que suele dar algo más de información sobre qué restricción no fue cumplida en un mensaje que tiene un aspecto similar al siguiente cuando la operación se intentó llevar a cabo usando la interfaz LDAP de Active Directory:

ldap_add: Constraint violation (19)
        additional info: 000021C7: AtrErr: DSID-03200DF3, #1:
        0: 000021C7: DSID-03200DF3, problem 1005 (CONSTRAINT_ATT_TYPE),
data 0, Att 90303 (servicePrincipalName)

En este caso, indica que no se cumplió la restricción con respecto al atributo servicePrincipalName.

Si la operación se intenta realizar con algún cliente de Active Directory como ADSIEdit, proporcionará una línea más de información aún más esclarecedora:

Una de las primeras líneas dice The operation failed because UPN value provided for addition/modification is not unique forest-wide (la operación falló porque el valor UPN proporcionado para la adición o modificación no es único en el bosque).

Además, los códigos 000021C7 y 000021C8 proporcionados en ambos mensajes también nos indican (según documenta Microsoft) que el valor servicePrincipalName o userPrincipalName (respectivamente) no es único.

Es decir, estamos intentando crear un usuario que tenga un principal como [email protected] que ya existe. En un principio, algo bastante normal si ese principal efectivamente ya existe, lo que podemos comprobar usando las herramientas proporcionadas por Microsoft para buscar usuarios en Active Directory o con una búsqueda LDAP usando un filtro como (|([email protected])([email protected])).

El problema sucede cuando obtenemos ese error creando un principal que no existe previamente, algo que no debería ocurrir.

Esto ha empezado a ocurrir a partir de Noviembre de 2021 debido a la actualización KB5008382 de Active Directory al crear determinados principals SPNEGO como HTTP (pero no restringido a este) para un equipo que forma parte de Active Directory.

Es decir, el error CONSTRAINT_ATT_TYPE se puede obtener para principals que no existen cuando se cumplen las siguientes condiciones:

• El parche KB5008382 de Noviembre de 2021 ha sido aplicado a Active Directory.
• Estamos intentando crear un principal SPNEGO como HTTP/[email protected], dns/[email protected] o www/[email protected].
• El equipo para el que se está intentando crear el principal forma parte del dominio. Es decir, en el ejemplo anterior, node1.example.com, myserver.com y webserver.example.net habrían sido unidos al dominio, en el caso de Linux, usando realm join o similar.

Causa

El motivo por el que esto sucede es por el cambio KB5008382 introducido por Microsoft en Noviembre de 2021.

Este cambio extiende las comprobaciones para comprobar que el userPrincipalName (UPN) y servicePrincipalName (SPN) son únicos para incluir también los alias.

Estos alias se configuran en el atributo sPNMappings del DN CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=..., en donde se configuran varias docenas de alias para el principal host.

Una configuración típica tendría un aspecto similar a este:

sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc

Hasta ahora, estos alias eran ignorados al comprobar que un principal era único, pero eso es lo que cambió la actualización KB5008382 para corregir el problema de seguridad CVE-2021-42282.

Cuando unimos el equipo node1.example.com a un dominio Active Directory, eso creará un usuario en AD con el principal HOST/node1.example.com. Si después intentamos crear el principal HTTP/node1.example.com, aunque ese principal no existe en AD, tras el parche de Noviembre AD también comprobará el valor de sPNMappings y encontrará que el principal host tiene un alias http y denegará la operación para crear HTTP/node1.example.com diciendo que no es único.

Mitigación

La información proporcionada en el propio anuncio del cambio KB5008382 indica que este cambio de comportamiento puede ser revertido cambiando la propiedad de dSHeuristics en CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=... para que su valor sea 100.

Sin embargo, esto haría que el dominio se viera afectado de nuevo por la vulnerabilidad CVE-2021-42282. No hay información pública sobre en qué consiste esta vulnerabilidad, pero no es difícil imaginar que permitir que se creen usuarios que duplican un alias de otro usuario pueda suponer un riesgo.

En el caso de que no sea posible cambiar el valor de dSHeuristics para desactivar las nuevas comprobaciones de SPN y UPN, otra solución recomendada por Microsoft es usar una cuenta de administrador del dominio para crear los principals. Sin embargo, esto parece una mala práctica desde el punto de vista de la seguridad y no es aconsejable, especialmente en productos que van a necesitar administrar principals de AD regularmente y necesitan tener guardados los credenciales de una cuenta con la que puedan administrar sus principals.

Probablemente, la manera más segura de evitar el problema es eliminar el equipo temporalmente de Active Directory para crear el principal conflictivo y volver a unirlo a AD después.

Es decir, continuando con el mismo ejemplo:

• Eliminar node1.example.com de Active Directory.
• Crear el principal HTTP/node1.example.com.
• Volver a unir node1.example.com a Active Directory.

Esta operación se debe llevar a cabo con las precauciones necesarias ya que, por ejemplo, eliminar un equipo de Active Directory puede hacer que los usuarios de AD no puedan seguir accediendo a ese equipo y podríamos quedarnos sin accesso si no tenemos un usuario local en el equipo.

Otra solución alternativa podría ser eliminar el alias que nos está produciendo el problema (es decir, en nuestro ejemplo, eliminar http del sPNMappings de host). Sin embargo, los efectos colaterales de un cambio así podrían ser impredecibles.

Solución

Dado que este cambio soluciona un problema de seguridad en Active Directory, es muy poco probable que Microsoft vaya revertirlo a pesar de que introduce un cambio en Active Directory que rompe una práctica establecida desde hace años con muy poca comunicación al respecto (probablemente para evitar que el problema de seguridad fuese explotado in the wild antes de que el parche fuese aplicado).

Hoy por hoy, la única solución es que los productos que provocan el conflicto de SPN/UPN se modifiquen para adaptarse al nuevo funcionamiento de Active Directory o que se aplique alguno de los remedios en la sección anterior.

Créditos

Este documento incluye detalles de la investigación llevada a cabo por Bluemetrix y Cloudera.