R: El protocolo de autenticación Kerberos utiliza tickets de sesión cifrados con una clave simétrica derivada de la contraseña del servidor o servicio al que un usuario de Windows solicita acceso. Para solicitar un ticket de sesión, el usuario debe presentar un ticket especial, llamado ticket de concesión de tickets (TGT) al servicio Kerberos Key Distribution Center (KDC) en un controlador de dominio (DC). Todos los usuarios de Windows obtienen un TGT del KDC al inicio de su sesión de inicio de sesión de Windows después de autenticarse correctamente en el KDC utilizando su contraseña.
El KDC encripta el TGT de un usuario con una clave que deriva de la contraseña de la cuenta de dominio de anuncios krbtgt. La cuenta krbtgt y su contraseña se comparten entre los servicios KDC de todos los DCs de un dominio. La cuenta krbtgt se crea automáticamente como parte del proceso de instalación de dcpromo AD en el primer DC de un dominio. Se muestra en el contenedor Usuarios del complemento Usuarios y equipos de Microsoft Management Console (MMC) de Active Directory y está deshabilitado de forma predeterminada. A diferencia de otras cuentas de usuario de anuncios, la cuenta krbtgt no se puede usar para iniciar sesión de forma interactiva en el dominio. Debido a que es una cuenta incorporada, krbtgt tampoco se puede cambiar de nombre.
Un controlador de dominio de solo lectura (RODC) es un nuevo tipo de DC que Microsoft introdujo en Windows Server 2008. Un RODC aloja particiones de solo lectura de la base de datos de AD. No almacena los hashes de contraseñas de todas las cuentas de usuario en un dominio de Windows; en su lugar, un RODC almacena solo los hashes de contraseñas de las cuentas que se definen en la Política de replicación de contraseñas (PRP) del RODC. Este método significa que el compromiso de un RODC representa mucho menos riesgo que el compromiso de un DC de lectura/escritura clásico (RWDC) que contiene copias de los hashes de contraseña de todas las cuentas de usuario en un dominio. Es por eso que un RODC se puede implementar de una manera que podría considerarse menos segura. Las organizaciones suelen desplegarlos en sucursales o en sus zonas desmilitarizadas (DMZ).
Un RODC actúa como Kerberos KDC para una sucursal o DMZ, y como tal también requiere una cuenta krbtgt. Para garantizar que el krbtgt de un RODC comprometido no se pueda aprovechar para solicitar tickets a otros RODC o RWDC, cada RODC tiene una cuenta krbtgt local especial. Esta cuenta tiene el formato krbtgt123, donde «123» es una cadena de números aleatorios. Esta cadena aleatoria identifica de forma única el RODC y se genera cuando se instala un RODC.
Las diferentes cuentas krbtgt locales de los RODC de un dominio se almacenan en AD y se muestran en Usuarios y equipos de Active Directory en el contenedor Usuarios. Todos los RWDC del dominio también guardan una copia de los hashes de contraseña de las cuentas krbtgt de los RODCs del dominio. Por lo tanto, un TGT emitido por un RODC es válido para solicitar tickets de sesión contra el mismo RODC y también contra cualquier otro RWDC en el dominio.
Si un RODC recibe una solicitud de ticket de sesión basada en un TGT que no es válido, lo que significa que el TGT no fue emitido por el propio RODC, devuelve un error de Kerberos pidiendo al equipo cliente que solicite una nueva solicitud TGT contra el propio RODC. Si el RODC no tiene una copia del hash de contraseña del usuario, el RODC reenvía la solicitud TGT a un RWDC. En este caso, el RODC actúa como proxy, por lo que reenvía la respuesta desde el RWDC directamente al equipo cliente. Al mismo tiempo, el RODC activa el proceso de almacenar en caché el hash de contraseña de usuario para que el RODC pueda crear un TGT para ese usuario en particular en el futuro. El almacenamiento en caché tiene éxito si el PRP del RODC permite que el hash de contraseña de la cuenta de usuario se almacene en caché en el RODC.
Relacionado: ¿Cómo instalo y configuro un controlador de dominio de solo lectura (RODC)?
