Delegación no restringida en DCs: por qué no desactivarla y cómo migrar a KCD/RBCD (Active Directory, Kerberos)

¿Se puede desactivar la delegación no restringida en los controladores de dominio? La respuesta corta es no: forma parte del diseño de Kerberos/Active Directory y volverá a activarse para mantener la autenticación del bosque. La estrategia correcta es eliminarla en servidores miembro y migrar a KCD/RBCD, a la vez que se mitiga el riesgo en DCs con hardening, cuentas no delegables y una supervisión rigurosa.

Índice

Resumen de la pregunta

Los controladores de dominio (DC) aparecen “confiados para delegación” por diseño. ¿Es posible cambiarlo? Si se pudiera, ¿cómo hacerlo sin romper el dominio? Si no es viable, ¿por qué y qué hacer en su lugar?

Conclusión breve

En DCs, no debe intentarse deshabilitar la delegación no restringida. Es intrínseca al rol (KDC, LDAP, CIFS, RPC, GC) y al flujo Kerberos en Active Directory; cualquier intento de forzar su retirada termina revirtiéndose para preservar la funcionalidad del dominio.
En servidores miembro y aplicaciones, sí debe eliminarse la delegación no restringida y migrarse a Kerberos Constrained Delegation (KCD) o Resource‑Based Constrained Delegation (RBCD).
Mitigue el riesgo en DCs marcando cuentas sensibles como “no delegables”, aplicando hardening riguroso y estableciendo monitorización de delegación y cambios de SPNs.

Por qué no se debe desactivar en controladores de dominio

Un controlador de dominio ejecuta servicios que, por definición, deben actuar en nombre de las identidades del bosque para emitir tickets, validar credenciales y proporcionar acceso a recursos críticos:

KDC (Kerberos) para emisión de TGT/TGS.
LDAP/GC para consultas y autenticación.
CIFS/SMB y RPC para operaciones administrativas y de replicación.

Para sostener estos flujos, la cuenta de equipo del DC mantiene el atributo de control que lo marca como TrustedForDelegation. Incluso si se modificase manualmente, el propio ecosistema de AD (replicación, comprobaciones de consistencia de roles y dependencias de servicio) restablecería la condición en, al menos, un DC. Quitarla de todos comprometería la autenticación Kerberos y la emisión de tickets a escala de bosque.

Idea clave: la “delegación no restringida” en DCs no es un capricho: es un requisito funcional. Intentar deshabilitarla genera inestabilidad del KDC y, en última instancia, el sistema tiende a restaurarla.

Qué hacer en su lugar: plan práctico y accionable

Eliminar la delegación no restringida fuera de los DCs

Localice y erradique la delegación no restringida en servidores miembro y aplicaciones (IIS, SQL Server, aplicaciones front‑end) que hoy puedan “suplantar” a cualquier usuario hacia cualquier servicio.

Inventariado rápido con PowerShell (ver sección de “Comprobación y configuración”).
Migración a KCD: permitir delegación únicamente hacia una lista explícita de SPNs back‑end.
Migración a RBCD: preferible en entornos modernos, donde el recurso (back‑end) controla quién puede delegar hacia él.

Proteger cuentas y SPNs sensibles

Marque como no delegables las cuentas y servicios críticos: “La cuenta es confidencial y no se puede delegar”.
Use el grupo Protected Users para impedir cualquier delegación en identidades de alto privilegio cuando sea viable.
Minimice inicios de sesión interactivos en DCs (modelo de niveles/Tier 0) y evite que cuentas privilegiadas inicien sesión en servidores que acepten delegación.

Endurecer la superficie de ataque en DCs

Desactivar servicios innecesarios (p. ej., Spooler de impresión).
Segmentación de red estricta: administración solo desde estaciones seguras; bloquear SMB/WinRM/PowerShell Remoting desde zonas no confiables hacia DCs.
Restringir el privilegio “Enable computer and user accounts to be trusted for delegation”.
Parcheo y EDR: DCs siempre actualizados y protegidos por soluciones EDR/antimalware empresariales.

Supervisión y respuesta

Auditar Kerberos: eventos 4768 (AS) y 4769 (TGS), con atención a forwardable/forwarded y patrones anómalos.
Auditar cambios en directorio: eventos 5136/5137 sobre SPNs, delegación y atributos como msDS-AllowedToActOnBehalfOfOtherIdentity.
Alertar por aparición de equipos con delegación no restringida o por modificaciones de RBCD.

Comprobación, inventario y cambios seguros

Detectar equipos con delegación no restringida

# Equipos con delegación no restringida (uac: TRUSTEDFORDELEGATION)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
  -Properties TrustedForDelegation,DNSHostName | 
  Select-Object Name,DNSHostName

Alternativa por LDAP (bit a bit: 0x80000 = 524288)

Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=524288)' \`
-Properties DNSHostName | Select-Object Name,DNSHostName

Detectar cuentas marcadas como no delegables

# Cuentas de usuario/servicio con "AccountNotDelegated" (uac: 0x100000)
Get-ADUser -Filter {AccountNotDelegated -eq $true} `
  -Properties AccountNotDelegated | Select-Object SamAccountName,AccountNotDelegated

Quitar delegación no restringida en servidores miembro

# Para un servidor miembro concreto
Set-ADAccountControl -Identity SERVERWEB01$ -TrustedForDelegation:$false

Opcional: dejar preparada KCD "Kerberos only" (ver sección KCD)

(La KCD se configura desde la ficha Delegación del objeto equipo o con msDS-AllowedToDelegateTo)

Marcar cuentas críticas como no delegables

# Evita que una cuenta privilegiada sea delegada por cualquier servicio
Set-ADAccountControl -Identity svc_sqlprod -AccountNotDelegated $true

Añadir usuarios de alto privilegio a Protected Users (cuando sea posible)

Add-ADGroupMember -Identity "Protected Users" -Members "adm\forest\root"

Deshabilitar el spooler de impresión en DCs

# Ejecutar en cada DC (con cambios via GPO preferentemente)
Stop-Service Spooler
Set-Service Spooler -StartupType Disabled

Configurar auditoría avanzada (Kerberos y cambios de objeto)

# Activar "Audit Kerberos Authentication Service" y "Audit Kerberos Service Ticket Operations"
y "Directory Service Changes" (éxito y error) vía GPO (Advanced Audit Policy)
Ejemplo: Validar eventos presentes
Get-WinEvent -LogName Security -MaxEvents 1 | Format-List *

Migración a KCD y RBCD paso a paso

Conceptos básicos

Modelo	Cómo limita la delegación	Cuándo usar	Notas clave
Unconstrained	El servicio puede delegar hacia cualquier SPN	Nunca en miembros; en DCs es inherente	Riesgo alto: TGTs en memoria del servicio
KCD (Kerberos only)	Lista explícita de SPNs en `msDS-AllowedToDelegateTo`	Front‑ends IIS/APP que llaman a pocos back‑ends Kerberos	Sin transición de protocolo; requiere tickets Kerberos
KCD (Any protocol)	Igual que KCD, pero permite S4U2Self/Proxy	Cuando la app recibe credenciales no Kerberos	Requiere TrustedToAuthForDelegation (uac 0x1000000)
RBCD	El back‑end autoriza qué front‑ends pueden delegar hacia él	Entornos modernos, microservicios y despliegues dinámicos	Control granular en el recurso; ideal para CI/CD

Configurar KCD desde la consola

Abra “Usuarios y equipos de Active Directory (ADUC)”.
Localice el objeto equipo del front‑end.
Ficha Delegación → seleccione “Confiar este equipo para la delegación solo a los servicios especificados”.
Elija “Usar solo Kerberos” o “Usar cualquier protocolo de autenticación” según su caso.
Añada los SPNs de los back‑ends permitidos (por ejemplo, MSSQLSvc/sqlprod.contoso:1433, HTTP/api.contoso).

Configurar KCD por PowerShell

# Añadir SPNs permitidos (KCD) al front-end
Set-ADComputer -Identity APP01$ -Add @{'msDS-AllowedToDelegateTo'=@(
  'HTTP/api.contoso.local','MSSQLSvc/sqlprod.contoso.local:1433')}

Activar "TrustedToAuthForDelegation" si requiere transición de protocolo (Any protocol)

Set-ADAccountControl -Identity APP01\$ -TrustedToAuthForDelegation \$true

Configurar RBCD (recomendado)

Con RBCD, el back‑end define quién puede actuar en su nombre. Es ideal para equipos DevOps porque elimina la necesidad de administrar listas de SPNs en cada front‑end.

# Autorizar al front‑end APP01 a delegar hacia el back‑end WEBAPI01 (RBCD)
Esta cmdlet administra el atributo msDS-AllowedToActOnBehalfOfOtherIdentity en WEBAPI01
Set-ADComputer -Identity WEBAPI01$ -PrincipalsAllowedToDelegateToAccount APP01$

Verificar delegaciones RBCD configuradas en un back‑end

(Get-ADComputer -Identity WEBAPI01\$ -Properties PrincipalsAllowedToDelegateToAccount).
PrincipalsAllowedToDelegateToAccount

Buenas prácticas adicionales de defensa

Diseño de identidades por niveles: cuentas de administración Tier 0 (bosque/dominio) separadas de Tier 1 (servidores) y Tier 2 (estaciones), con logon estrictamente segmentado.
Minimizar exposición de SPNs: evite registrar SPNs innecesarios en cuentas de usuario; prefiera cuentas de equipo dedicadas a servicios.
LSA Protection / Credential Guard en servidores miembro críticos para reducir el impacto de robo de credenciales.
Privileged Access Workstations (PAW): administre DCs solo desde estaciones endurecidas sin correo ni navegación.
Backups y recuperación verificados: ante abuso de delegación, la restauración limpia del AD puede ser la última línea de defensa.

Detección y uso de registros

Detección de delegación activa con eventos 4769

Busque picos de solicitudes TGS desde hosts front‑end, presencia de opciones de ticket forwardable/forwarded y accesos a servicios no habituales. Combine con 4768 para correlacionar TGTs recientes del mismo usuario/equipo.

Vigilancia de cambios RBCD y SPNs

# Cambios de directorio (eventos 5136/5137) filtrando por msDS-AllowedToActOnBehalfOfOtherIdentity
$FilterXml = @"
&lt;QueryList&gt;
  &lt;Query Id="0" Path="Security"&gt;
    &lt;Select Path="Security"&gt;*[System[(EventID=5136) or (EventID=5137)]] and
    *[EventData[Data[@Name='AttributeName']='msDS-AllowedToActOnBehalfOfOtherIdentity']]&lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;
"@
Get-WinEvent -FilterXml $FilterXml

Descubrimiento de SPNs anómalos

# Listar SPNs por equipo y detectar duplicados
Get-ADComputer -Filter * -Properties ServicePrincipalName |
  ForEach-Object {
    $_.ServicePrincipalName | ForEach-Object {
      [PSCustomObject]@{Host=$.Name; SPN=$}
    }
  } | Group-Object SPN | Where-Object {$_.Count -gt 1} |
  Select-Object Name,Count

Preguntas frecuentes

¿Qué diferencia hay entre KCD “solo Kerberos” y “cualquier protocolo”?

“Solo Kerberos” exige que el usuario llegue al front‑end ya autenticado con Kerberos. “Cualquier protocolo” permite que el front‑end convierta otras credenciales (NTLM, formularios, tokens) en una identidad Kerberos mediante S4U2Self/Proxy, lo cual requiere activar TrustedToAuthForDelegation en el front‑end y aumenta la superficie de ataque. Use esta opción solo cuando sea imprescindible y con RBCD o listas KCD muy acotadas.

¿RBCD permite escenarios entre dominios?

RBCD funciona de forma natural dentro del bosque. En escenarios entre bosques, depende del tipo de confianza y de si la información de identidad y SPNs está disponible para evaluación; en entornos complejos es preferible mantener la delegación dentro de límites claros de bosque o usar soluciones de federación.

¿Los RODCs cambian algo en la delegación?

Los controladores de dominio de solo lectura reducen el riesgo al no almacenar secretos de cuentas no cacheadas y al limitar la superficie de administración local; sin embargo, siguen siendo parte esencial de la topología Kerberos/AD y no son el lugar para experimentar con la eliminación de la delegación inherente al rol.

¿Si desmarco “confiar para delegación” en un DC, qué pasa?

Se arriesga a romper flujos Kerberos y servicios críticos. Además, los mecanismos de consistencia del directorio tienden a mantener el dominio operativo restableciendo la condición en, al menos, un DC. El resultado neto: inestabilidad y exposición a fallos de autenticación.

Errores comunes y cómo evitarlos

Intentar convertir todos los DCs en “no delegables”. Esto no es compatible con la arquitectura de AD.
Dejar servidores web o de aplicaciones con delegación no restringida. Son objetivos de alto valor para el robo de TGTs y ataques de relay.
Uso indiscriminado de “Any protocol”. Amplía la superficie de ataque; prefiera “Kerberos only” o RBCD.
No marcar cuentas privilegiadas como “no delegables”. Un único front‑end vulnerable podría suplantarlas hacia múltiples back‑ends.
No auditar cambios de RBCD/SPNs. La falta de visibilidad dificulta detectar abusos y persistencia.

Guía de implementación por fases

Fase	Acciones clave	Entregables	Riesgos mitigados
Descubrimiento	Inventario de unconstrained; cuentas y SPNs críticos; mapas de flujo	Lista de hosts con TrustedForDelegation; lista de SPNs	TGTs expuestos en servicios de usuario
Diseño	Definir KCD/RBCD; decidir “Kerberos only” vs “Any protocol”	Matriz front‑end ↔ back‑end (SPNs)	Delegaciones excesivas
Migración	Aplicar KCD/RBCD; marcar cuentas no delegables	AD actualizado; scripts y GPOs	Suplantación lateral
Hardening	Deshabilitar Spooler; segmentación; EDR; PAWs	Baseline de seguridad en DCs	Exposición de credenciales
Monitorización	SIEM: 4768/4769, 5136/5137; alertas por nuevos unconstrained	Dashboards y alertas	Persistencia y escalada

Checklist operativo

Confirmar que ningún servidor miembro mantiene delegación no restringida.
Completar diagramas de delegación front‑end ↔ back‑end con sus SPNs.
Aplicar RBCD por defecto; KCD solo si hay limitaciones.
Marcar cuentas privilegiadas como “no delegables” y, cuando aplique, moverlas a Protected Users.
Restringir SeEnableDelegationPrivilege a un conjunto mínimo de administradores.
Deshabilitar Spooler en DCs y miembros que no impriman.
Establecer y revisar alertas SIEM para 4768/4769 y 5136/5137.
Validar periódicamente que no aparecen nuevos equipos con TrustedForDelegation fuera de los DCs.

Ejemplos prácticos de scripts

Exportar equipos con delegación no restringida

# Requiere RSAT-AD-PowerShell
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties DNSHostName,OperatingSystem |
  Select-Object Name,DNSHostName,OperatingSystem |
  Export-Csv .\equipos_unconstrained.csv -NoTypeInformation -Encoding UTF8

Marcar múltiples cuentas como no delegables

# Lista en CSV con SamAccountName
Import-Csv .\cuentas_criticas.csv | ForEach-Object {
  Set-ADAccountControl -Identity $_.SamAccountName -AccountNotDelegated $true
}

Crear alerta por aparición de nuevos unconstrained

# Ejecución programada que notifica diferencias respecto al último inventario
$prev = @()
if (Test-Path .\unconstrained_prev.json) {
  $prev = Get-Content .\unconstrained_prev.json | ConvertFrom-Json
}
$curr = Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties DNSHostName |
  Select-Object -ExpandProperty DNSHostName
$added = $curr | Where-Object {$_ -notin $prev}
$removed = $prev | Where-Object {$_ -notin $curr}
if ($added -or $removed) {
  # Enviar correo/alerta según su canal interno
  Write-Host "Nuevos: $($added -join ', '); Quitados: $($removed -join ', ')"
}
$curr | ConvertTo-Json | Set-Content .\unconstrained_prev.json

Conclusiones

La delegación no restringida en controladores de dominio no es una opción que pueda desactivarse sin consecuencias: es un pilar del funcionamiento de Kerberos y AD. La estrategia sensata es no tocarla en DCs, eliminarla en servidores miembro y migrar a KCD/RBCD con listas estrictas de servicios, a la vez que se blindan las cuentas y se vigila continuamente el directorio. Con este enfoque, el riesgo práctico se reduce de manera drástica sin comprometer la disponibilidad del dominio.

En una línea

No intente quitar la delegación no restringida a los DCs; sí elimínela en servidores miembro, migre a KCD/RBCD y refuerce controles de cuentas, hardening y auditoría para reducir la superficie de ataque.