Rotar la contraseña de krbtgt de forma segura en AD

Las claves de la cuenta krbtgt cifran y firman todos los TGT del dominio. Quien las posea puede falsificar un golden ticket para cualquier identidad, con cualquier pertenencia a grupos, mientras la clave siga siendo válida. En muchos dominios esa clave no ha cambiado desde la creación del dominio, lo que significa que cada compromiso pasado, cada copia de seguridad antigua y cada DCSync realizado por un contratista que se marchó hace tiempo sigue produciendo tickets válidos. La rotación periódica de krbtgt es el único control que pone fin a esa exposición.

El procedimiento en sí son dos restablecimientos de contraseña. Lo que lo hace seguro es todo lo que lo rodea: entender el historial de claves, confirmar la replicación, gestionar las cuentas de los RODC y elegir entre el modo rutinario y el modo incidente. Esta guía amplía la sección sobre el doble restablecimiento de Hardening de Kerberos.

Por qué dos restablecimientos y por qué importa la separación

Cuando se restablece krbtgt, el DC conserva la clave anterior junto a la nueva. Se acepta un TGT cifrado con cualquiera de las dos. Esto es lo que evita una interrupción: los tickets emitidos un minuto antes del restablecimiento siguen siendo válidos.

• Tras el restablecimiento 1: clave actual = K1, clave anterior = K0. Los golden tickets falsificados con K0 siguen funcionando.
• Tras el restablecimiento 2: clave actual = K2, clave anterior = K1. K0 ha desaparecido, así que se rechazan los tickets falsificados con la clave original.

Si el restablecimiento 2 se produce demasiado pronto, también se rechazan los TGT legítimos emitidos con K0 justo antes del restablecimiento 1. Los usuarios ven errores de autenticación hasta que bloquean y desbloquean la sesión o vuelven a iniciarla, y los servicios con sesiones de larga duración pueden fallar. La separación segura es la vigencia máxima del TGT más el desfase de reloj, una vez que la replicación ha convergido.

# Leer la directiva Kerberos de la Default Domain Policy
$gpo = Get-GPO -Name 'Default Domain Policy'
$report = [xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)
$report.GPO.Computer.ExtensionData.Extension.Account |
    Where-Object { $_.Type -eq 'Kerberos' } |
    Select-Object Name, SettingNumber

Si la consulta no devuelve nada, la directiva no está definida explícitamente y se aplican los valores predeterminados. MaxTicketAge (horas, 10 de forma predeterminada) es la vigencia del TGT, MaxRenewAge (días, 7 de forma predeterminada) la ventana de renovación y MaxClockSkew (minutos, 5 de forma predeterminada) la tolerancia. Las solicitudes de renovación se validan con la clave actual o la anterior, así que un TGT emitido con K0 no puede renovarse tras el restablecimiento 2 en ningún caso.

Medir: estado actual

# Cuentas krbtgt de todos los dominios del bosque, incluidas las cuentas krbtgt_ de los RODC
(Get-ADForest).Domains | ForEach-Object {
    Get-ADUser -Server $_ -Filter 'SamAccountName -like "krbtgt*"' `
        -Properties PasswordLastSet, msDS-KeyVersionNumber |
        Select-Object @{n='Domain';e={$_.DistinguishedName -replace '^.*?,DC=','DC='}},
                      SamAccountName, PasswordLastSet, msDS-KeyVersionNumber
}

En la primera ejecución lo normal es un PasswordLastSet que se mide en años. Cada dominio tiene su propio krbtgt; un bosque con varios dominios necesita una rotación en cada dominio. Cada RODC tiene una cuenta krbtgt_NNNNN, vinculada desde el objeto de equipo del RODC mediante msDS-KrbTgtLink:

Get-ADComputer -Filter 'PrimaryGroupID -eq 521' -Properties msDS-KrbTgtLink |
    Select-Object Name, msDS-KrbTgtLink

Auditar: primero, el estado de la replicación

Un restablecimiento que no ha llegado a todos los DC grabables es peligroso. Un DC que no ha recibido el restablecimiento 1 sigue emitiendo TGT con K0, y si después el restablecimiento 2 se replica antes de que el 1 haya convergido, los DC acaban con historiales de claves distintos y rechazan los tickets de los demás. No inicie nunca una rotación mientras la replicación esté fallando.

# Resumen de replicación de todo el bosque: todas las columnas "fails" deben ser 0
repadmin /replsummary

# Errores por DC
Get-ADReplicationFailure -Target (Get-ADDomain).DNSRoot -Scope Domain |
    Select-Object Server, Partner, FailureCount, LastError

Corrija los errores, confirme que todos los DC son accesibles y asegúrese de disponer de una copia de seguridad reciente y probada del estado del sistema de al menos un DC por dominio antes del primer restablecimiento.

Planificar el cambio

La primera rotación en un dominio cuyo krbtgt no ha cambiado en años merece un registro de cambio en condiciones, aunque el comando en sí tarde segundos.

Inventaríe lo que depende de tickets de larga duración. Pregunte a los responsables de las aplicaciones por los servicios que se autentican una vez y mantienen una sesión Kerberos durante días: hosts Linux que usan keytabs con tickets renovables, servidores de aplicaciones con clientes Kerberos personalizados y trabajos por lotes de larga duración. Estos son los sistemas que notarán el restablecimiento 2.

Elija la ventana. El restablecimiento 1 es invisible para los usuarios si la replicación está sana. El restablecimiento 2 es el que puede sacar a la luz problemas, así que prográmelo al inicio de una jornada laboral con el personal de soporte presente, no de noche, cuando nadie notará una integración rota hasta la mañana siguiente.

Orden en un bosque con varios dominios. Las rotaciones en distintos dominios son independientes, porque el krbtgt de cada dominio solo firma los TGT de ese dominio; los tickets entre dominios Kerberos a través de las confianzas usan en su lugar las claves de las cuentas de confianza. Empiece por un dominio secundario pequeño para ensayar, después la raíz del bosque y a continuación los demás dominios. No los ejecute todos en la misma ventana.

RODC. En modo rutinario, rote las cuentas krbtgt_NNNNN de los RODC después de la cuenta del dominio, un RODC cada vez, confirmando que el RODC y sus asociados de replicación grabables coinciden en la nueva versión de clave antes de continuar. Las sucursales con enlaces lentos son donde las comprobaciones de convergencia le salvan.

Evidencias. Registre el msDS-KeyVersionNumber y el PasswordLastSet de cada cuenta antes y después. Los auditores y los equipos de respuesta a incidentes preguntarán cuándo cambió la clave por última vez, y la respuesta debe ser un documento, no una suposición.

Aplicar: rotación rutinaria con New-KrbtgtKeys.ps1

Use New-KrbtgtKeys.ps1, publicado originalmente por Microsoft y mantenido ahora por la comunidad en GitHub, en lugar de llamadas improvisadas a Set-ADAccountPassword. El script ofrece un modo informativo, un modo de simulación que ejecuta el procedimiento sobre cuentas krbtgt de prueba que él mismo crea, y un modo de restablecimiento real. En modo real restablece la cuenta elegida en el emulador de PDC (o en el DC de origen del RODC para las cuentas de RODC), fuerza la replicación de un solo objeto de la cuenta a todos los DC y comprueba que cada DC informa de la nueva versión de clave. Lea su menú con atención y ejecute primero los modos informativo y de simulación en cada dominio.

Una rotación rutinaria tiene este aspecto:

1. Ejecute el script en modo informativo y lea el informe: DC descubiertos, accesibilidad, versión de clave en cada DC.
2. Ejecute el modo de simulación sobre las cuentas de prueba; confirme que la replicación llega a todos los DC.
3. Restablecimiento 1 del krbtgt del dominio en modo real. Confirme que msDS-KeyVersionNumber se ha incrementado en todos los DC.
4. Espere al menos MaxTicketAge + MaxClockSkew (24 horas es un valor predeterminado cómodo).
5. Restablecimiento 2 en modo real, con las mismas comprobaciones.
6. Repita para las cuentas krbtgt_NNNNN de los RODC y para todos los demás dominios del bosque.

Sea cual sea la contraseña proporcionada, el DC genera su propio valor aleatorio para krbtgt, así que no hay nada que guardar en una bóveda.

Programe la rotación rutinaria al menos cada 180 días y, además, después de que se marche cualquier administrador Tier 0, después de una restauración de AD desde medios de copia de seguridad que hayan escapado a su control y después de cualquier sospecha de DCSync o exposición de NTDS.dit.

Modo incidente

Cuando tiene pruebas de que krbtgt está comprometido (un DCSync desde un origen inesperado, indicadores de golden ticket, una copia de seguridad de un DC robada), quiere que la clave antigua desaparezca ahora, no mañana.

1. Primero, elimine la capacidad del atacante de leer la nueva clave: restablezca o deshabilite las cuentas Tier 0 comprometidas, elimine los derechos DCSync ilegítimos (consulte encontrar derechos DCSync) y aísle los hosts comprometidos.
2. Realice el restablecimiento 1, espere solo a que la replicación converja en todos los DC (minutos, no horas) y después realice el restablecimiento 2.
3. Acepte el impacto: todos los TGT del dominio quedan invalidados. Los usuarios se vuelven a autenticar en su siguiente acceso a un recurso o inicio de sesión; los servicios de larga duración pueden necesitar reinicios.
4. Repita el doble restablecimiento al final de la recuperación, cuando esté seguro de que la persistencia ha desaparecido.

Forzar la replicación entre restablecimientos es más importante en modo incidente, porque no dispone del margen de tiempo para absorber un enlace lento:

# Enviar el objeto krbtgt a todos los DC desde el emulador de PDC
$pdc = (Get-ADDomain).PDCEmulator
$krbtgt = (Get-ADUser krbtgt).DistinguishedName
Get-ADDomainController -Filter 'IsReadOnly -eq $false' | ForEach-Object {
    Sync-ADObject -Object $krbtgt -Source $pdc -Destination $_.HostName
}

Verificar

# La versión de clave y pwdLastSet deben coincidir en todos los DC grabables
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    Get-ADUser krbtgt -Server $dc -Properties msDS-KeyVersionNumber, PasswordLastSet |
        Select-Object @{n='DC';e={$dc}}, msDS-KeyVersionNumber, PasswordLastSet
}

# Los metadatos de replicación muestran cuándo y dónde se originó el cambio de contraseña
Get-ADReplicationAttributeMetadata -Object (Get-ADUser krbtgt).DistinguishedName `
    -Server (Get-ADDomain).PDCEmulator -Properties unicodePwd, pwdLastSet |
    Select-Object AttributeName, LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity, Version

Los RODC no almacenan el secreto del krbtgt del dominio, así que compruebe de la misma forma sus propias cuentas krbtgt_NNNNN después de rotarlas. En el lado de la seguridad, un restablecimiento de krbtgt genera los eventos 4724 (intento de restablecimiento de contraseña) y 4738 en el DC donde se ejecutó. Genere alertas para esos eventos fuera de las ventanas de cambio planificadas: un restablecimiento inesperado de krbtgt es o bien un error, o bien un atacante borrando su rastro. Avise al SOC de las rotaciones planificadas con antelación para que la propia rotación no desencadene un incidente.

Qué rompe

• Un restablecimiento 2 demasiado temprano invalida TGT legítimos: los usuarios ven accesos denegados o solicitudes de credenciales hasta que vuelven a iniciar sesión, y los servicios que tienen tickets fallan hasta que se reinician.
• El retraso de la replicación entre restablecimientos provoca errores de autenticación intermitentes que dependen del DC al que llegue cada cliente. Por eso las comprobaciones de convergencia no son opcionales.
• Las sesiones y servicios de larga duración que almacenan TGT en caché durante días (algunos servicios Linux con k5start, servidores de aplicaciones con tickets renovables, sesiones VPN autenticadas con Kerberos) pueden necesitar reinicios tras el restablecimiento 2.
• El modo incidente invalida todos los TGT a la vez, así que cuente con un pico de llamadas al service desk y planifique las comunicaciones con antelación.
• Las contraseñas antiguas de krbtgt anteriores a AES implican que la primera rotación es también la primera vez que krbtgt tiene claves AES, lo que puede poner en evidencia clientes que solo gestionaban RC4. Consulte deshabilitar RC4 en Kerberos.

Lecturas relacionadas: el área de Kerberos y autenticación, identificar los activos Tier 0 para encontrar todo lo que podría filtrar la nueva clave, y el plan de recuperación del bosque, donde el doble restablecimiento es un paso obligatorio.