¿Qué es la cuenta krbtgt?
krbtgt es una cuenta que Active Directory crea automáticamente en cada dominio. Viene deshabilitada y nadie inicia sesión con ella, pero es una de las más importantes del directorio: el servicio de Kerberos de los controladores de dominio usa su clave para firmar y cifrar todos los tickets de acceso (TGT) que entrega a usuarios y equipos.
Si un atacante obtiene esa clave, puede fabricar sus propios tickets para cualquier usuario, incluidos los administradores del dominio, con la duración que quiera. Es el ataque conocido como Golden Ticket, y sigue funcionando aunque cambies las contraseñas de los usuarios, porque el ticket falso se firma con la clave de krbtgt, no con la del usuario.
¿Por qué rotarla?
En muchos dominios la contraseña de krbtgt no ha cambiado desde que se creó el dominio, hace años. Mientras no se cambie, una clave robada en un incidente pasado sigue siendo útil para el atacante.
Las guías de bastionado más usadas coinciden en un límite: la guía STIG de Windows Server, sus equivalentes de CIS y Microsoft Defender for Identity señalan como riesgo una contraseña de krbtgt con más de 180 días. Rotarla de forma periódica limita la ventana en la que una clave robada sirve de algo.
¿Por qué se cambia dos veces?
La cuenta krbtgt guarda un historial de sus dos contraseñas más recientes, para que los tickets emitidos antes del cambio sigan siendo válidos. Por eso, un solo cambio no basta: la clave anterior sigue aceptándose. Al cambiarla una segunda vez, la clave original sale del historial.
¿Cuánto esperar entre los dos cambios? Microsoft indica esperar al menos 10 horas, que es la vida máxima predeterminada de los tickets de usuario y de servicio. Si en tu dominio esos valores son mayores, espera más que el valor configurado. Además, confirma que el primer cambio ya se replicó a todos los controladores de dominio.
Antes de empezar
- Revisa que la replicación esté sana. Si un controlador de dominio no replica, se quedará con la clave anterior y habrá fallas de autenticación.
- Ten un respaldo reciente del Directorio Activo y un plan de recuperación probado.
- Ubica los controladores de solo lectura (RODC). Cada uno tiene su propia cuenta, con nombre del tipo
krbtgt_12345, y se rota por separado. - Define una ventana de mantenimiento y avisa a los responsables de aplicaciones que dependen de Kerberos. Algunos sistemas que no son Windows pueden necesitar volver a autenticarse.
- Si la cuenta nunca se ha rotado, pruébalo con calma: los dominios muy antiguos pueden seguir usando cifrados obsoletos (DES o RC4) y presentar errores de replicación al cambiarla.
¿Cómo revisar cuándo se cambió por última vez?
Desde una consola de PowerShell con el módulo de Active Directory:
Get-ADUser krbtgt -Properties PasswordLastSet |
Select-Object Name, PasswordLastSetPara ver también las cuentas de los controladores de solo lectura:
Get-ADUser -Filter 'Name -like "krbtgt*"' -Properties PasswordLastSet |
Select-Object Name, PasswordLastSetSi la fecha tiene más de 180 días, o no la reconoces, conviene planear la rotación.
Paso a paso
1. Verifica la replicación
repadmin /replsummary
repadmin /showreplNo continúes si hay errores. Corrígelos primero.
2. Haz el primer cambio
Tienes dos caminos:
- El script de Microsoft
New-KrbtgtKeys.ps1. Es el método recomendado: revisa el entorno, permite simular el cambio antes de hacerlo y verifica la replicación. Ejecútalo primero en su modo de revisión o simulación. - La consola Usuarios y equipos de Active Directory. Activa Ver › Características avanzadas, entra al contenedor Users, haz clic derecho en
krbtgty elige Restablecer contraseña. Escribe cualquier contraseña: el sistema genera automáticamente una contraseña segura en su lugar.
3. Confirma que el cambio llegó a todos los controladores
Get-ADDomainController -Filter * | ForEach-Object {
$dc = $_.HostName
$u = Get-ADUser krbtgt -Server $dc -Properties PasswordLastSet
[pscustomobject]@{ DC = $dc; PasswordLastSet = $u.PasswordLastSet }
}Todos deben mostrar la misma fecha y hora.
4. Espera el tiempo necesario
Al menos 10 horas, o más si cambiaste la vida máxima de los tickets. Durante este tiempo, vigila los eventos de Kerberos y los reportes de los usuarios.
5. Haz el segundo cambio y vuelve a verificar
Repite los pasos 2 y 3. Al terminar, la clave anterior ya no es válida en ningún controlador.
6. Repite con los RODC y agenda la siguiente rotación
Rota las cuentas krbtgt_##### de los controladores de solo lectura con el mismo procedimiento. Después agenda la siguiente rotación en un máximo de 180 días. Esta tarea se puede automatizar como parte del mantenimiento continuo del directorio.
Si sospechas un compromiso
Si hay indicios de que alguien obtuvo la clave de krbtgt, cambiarla dos veces seguidas, sin esperar invalida de inmediato los tickets falsos, pero también obliga a todos a volver a autenticarse y puede interrumpir servicios. Hazlo dentro de un plan de respuesta a incidentes, junto con el resto de las acciones de contención, y no como una tarea aislada.
Errores comunes
- Hacer los dos cambios seguidos en un mantenimiento normal, lo que invalida las sesiones de todos sin necesidad.
- No revisar la replicación antes y después.
- Olvidar las cuentas de los controladores de solo lectura.
- Tener un filtro de contraseñas personalizado en los controladores de dominio que impide el cambio. Microsoft documenta una solución en su artículo KB2549833.
- Rotarla una vez y no volver a hacerlo.