Información general de las cuentas de servicio administradas delegadas
Se introduce un nuevo tipo de cuenta conocido como cuenta de servicio administrada delegada (dMSA) en Windows Server 2025, que permite la migración de una cuenta de servicio tradicional a una cuenta de equipo con claves administradas y totalmente aleatorias, al tiempo que deshabilita las contraseñas originales de la cuenta de servicio. La autenticación de dMSA está vinculada a la identidad del dispositivo, lo que significa que solo las identidades de máquina especificadas asignadas en Active Directory (AD) pueden acceder a la cuenta. El uso de dMSA ayuda a impedir la recopilación de credenciales mediante una cuenta en peligro (kerberoasting), que es un problema común con las cuentas de servicio tradicionales.
Comparación entre dMSA y gMSA
dMSA y gMSA son dos tipos de cuentas de servicio administradas que se usan para ejecutar servicios y aplicaciones en Windows Server. Un administrador administra una dMSA y se usa para ejecutar un servicio o una aplicación en un servidor específico. AD administra una gMSA y se usa para ejecutar un servicio o una aplicación en varios servidores. Ambas ofrecen una seguridad mejorada y una administración simplificada de contraseñas. dMSA difiere en:
- Uso de conceptos de gMSA para limitar el ámbito de uso mediante Credential Guard para enlazar la autenticación de la máquina.
- CG se puede usar para mejorar la seguridad en dMSA rotando automáticamente las contraseñas y enlazando todos los vales de cuenta de servicio. Las cuentas heredadas se deshabilitan para mejorar aún más la seguridad.
- Aunque las gMSA están protegidas con contraseñas de generación automática y autorrotación de máquinas, las contraseñas siguen sin estar enlazadas a la máquina y pueden ser robadas.
Funcionalidad de dMSA
dMSA permite a los usuarios crearlos como una cuenta independiente o reemplazar una cuenta de servicio estándar existente. Cuando una dMSA reemplaza a una cuenta existente, se bloqueará la autenticación a esa cuenta existente mediante su contraseña. La solicitud se redirige a la Autoridad de seguridad local (LSA) para autenticarse mediante dMSA, que tiene acceso a todo lo que la cuenta anterior podría acceder en AD.
Durante la migración, dMSA aprende automáticamente los dispositivos en los que se usará la cuenta de servicio que se usará para moverse de todas las cuentas de servicio existentes.
dMSA usa un secreto aleatorio (derivado de la credencial de la cuenta de máquina) que mantiene el controlador de dominio (DC) para cifrar vales. El secreto se puede proteger aún más habilitando CG. Aunque los secretos que se utilizan en la dMSA se actualizan periódicamente en una época como una gMSA, la diferencia clave es que el secreto de dMSA no se puede recuperar ni encontrar en ningún lugar distinto del controlador de dominio.
Flujo de migración para dMSA
Un concepto rápido del proceso de flujo de migración para una dMSA implica los pasos siguientes:
- La directiva de CG se puede configurar para proteger la identidad de las máquinas.
- Un administrador inicia y completa la migración de la cuenta de servicio.
- La cuenta de servicio actualiza el servidor de concesión de vales (TGT).
- La cuenta de servicio añade la identidad de máquina para permitir principios.
- La cuenta de servicio original se deshabilita.
Tome nota de lo siguiente al migrar dMSA:
- No se puede migrar desde una cuenta de servicio administrada ni una gMSA a una dMSA.
- Espere al menos dos duraciones de vale (equivalente a 14 días) después de modificar el descriptor de seguridad (SD) antes de completar la migración de dMSA. Se recomienda mantener un servicio en el estado de inicio durante cuatro duraciones de vale (28 días). Retrase la migración si los controladores de dominio tienen particiones o se interrumpe la replicación durante la incorporación.
- Preste atención a los sitios en los que los retrasos de replicación son más largos que el tiempo de renovación de vales predeterminado de 10 horas. El atributo groupMSAMembership se comprueba y actualiza en cada renovación de vales y cada vez que la cuenta de servicio original inicia sesión durante el estado de "inicio de la migración", que añade la cuenta de máquina al groupMSAMembership de la dMSA.
- Por ejemplo, dos sitios usan la misma cuenta de servicio y cada ciclo de replicación tarda más de 10 horas por duración del vale. En este escenario, se pierde una pertenencia a grupos durante los ciclos de replicación iniciales.
- La migración requiere acceso a un controlador de dominio de lectura y escritura (RWDC) para consultar y modificar el SD.
- La delegación sin restricciones deja de funcionar una vez completada la migración si la cuenta de servicio antigua estaba usándola. Si usa una dMSA protegida por CG, la delegación sin restricciones deja de funcionar. Para más información, consulte Consideraciones y problemas conocidos al usar Credential Guard.
Advertencia
Si va a migrar a una dMSA, todas las máquinas que usan la cuenta de servicio deben actualizarse para admitir dMSA. Si no es así, las máquinas que no admiten dMSA producirán un error en la autenticación con la cuenta de servicio existente una vez que la cuenta se deshabilite durante la migración.
Atributos de cuenta para dMSA
En esta sección se describe cómo cambian los atributos de dMSA en el esquema de AD. Estos atributos se pueden ver mediante el complemento Usuarios y equipos de Active Directory o la ejecución de ADSI Edit en el controlador de dominio.
Nota:
Los atributos numéricos establecidos para la cuenta indican que:
- 1 - Se ha iniciado la migración de la cuenta.
- 2 - Se ha completado la migración de la cuenta.
La ejecución de Start-ADServiceAccountMigration realiza los siguientes cambios:
- A la cuenta de servicio se le concede lectura genérica para todas las propiedades de dMSA.
- A la cuenta de servicio se le concede la propiedad de escritura para msDS-groupMSAMembership.
- msDS-DelegatedMSAState se cambia a 1.
- msDS-ManagedAccountPrecededByLink se establece en la cuenta de servicio.
- msDS-SupersededAccountState se cambia a 1.
- msDS-SupersededManagedServiceAccountLink se establece en dMSA.
La ejecución de Complete-ADServiceAccountMigration realiza los siguientes cambios:
- La cuenta de servicio se elimina de la lectura genérica para todas las propiedades de dMSA.
- La cuenta de servicio se elimina de la propiedad de escritura en el atributo msDS-GroupMSAMembership.
- msDS-DelegatedMSAState se establece en 2.
- Los nombres de entidad de seguridad de servicio (SPNs) se copian de la cuenta de servicio a la cuenta de dMSA.
- msDS-AllowedToDelegateTo se copia si procede.
- msDS-AllowedToActOnBehalfOfOtherIdentity, el descriptor de seguridad se copia si procede.
- La directiva de AuthN asignada, msDS-AssignedAuthnPolicy, de la cuenta de servicio, se copia.
- dMSA se añade a cualquier silo de directivas AuthN del que la cuenta de servicio fuera miembro.
- El bit de control de cuentas de usuario (UAC) de confianza "Autenticación para delegación" se copia si estaba activado en la cuenta de servicio.
- msDS-SupersededServiceAccountState se establece en 2.
- La cuenta de servicio se deshabilita mediante el bit de deshabilitación de UAC.
- El SPNs se elimina de la cuenta.
Dominios de dMSA
Los dominios sirven como agrupaciones lógicas que definen límites de autenticación, que se suelen usar al integrar diferentes versiones de AD entre dominios o bosques. Son especialmente importantes en entornos de dominio mixtos en los que es posible que algunos dominios no admitan completamente todas las características de dMSA. Al especificar dominios, dMSA puede garantizar la comunicación y el flujo de autenticación adecuados entre dominios.
Los administradores pueden usar dominios para especificar qué dominios o componentes de directorio pueden autenticarse y acceder a la cuenta dMSA. Esto garantiza que incluso los dominios secundarios más antiguos, que pueden no admitir características dMSA de forma nativa, puedan interactuar con las cuentas al tiempo que se mantienen los límites de seguridad. Al habilitar una transición más fluida y la coexistencia de características en entornos mixtos, los dominios ayudan a garantizar la compatibilidad sin poner en peligro la seguridad.
Por ejemplo, si tiene un dominio principal denominado corp.contoso.com que se ejecuta en Windows Server 2025 y un dominio secundario anterior denominado legacy.corp.contoso.com que se ejecuta en Windows Server 2022, puede especificar el dominio como legacy.corp.contoso.com.
Para editar esta configuración de directiva de grupo para su entorno, vaya a la siguiente ruta de acceso:
Configuración del equipo\Plantillas administrativas\System\Kerberos\Habilitar inicios de sesión de cuentas de servicio administradas delegadas
Consulte también
Configuración de cuentas de servicio administradas delegadas