Introducción a las cuentas de servicio administradas de grupo
En este artículo obtendrá información sobre cómo habilitar y usar cuentas de servicio administradas de grupo (gMSA) en Windows Server.
Los protocolos de autenticación que admiten la autenticación mutua, como Kerberos, no se pueden usar a menos que todas las instancias de los servicios usen la misma entidad de seguridad. Por ejemplo, cuando un equipo cliente se conecta a un servicio que usa equilibrio de carga u otro método donde todos los servidores parecen ser el mismo servicio al cliente. Esto significa que todos los servicios tienen que usar las mismas contraseñas o claves para demostrar su identidad. Las cuentas de servicio administradas de grupo son un tipo de cuenta que se pueden usar con varios servidores. Una gMSA es una cuenta de dominio que se puede usar para ejecutar servicios en varios servidores sin tener que administrar la contraseña. Las gMSA proporcionan administración automática de contraseñas y administración simplificada de nombres de entidad de seguridad de servicio (SPN), incluida la delegación de la administración a otros administradores.
Nota:
Los clústeres de conmutación por error no admiten las cuentas de servicio administradas de grupo (gMSA). Sin embargo, los servicios que se ejecutan sobre el Servicio de clúster pueden utilizar una gMSA o una cuenta de servicio administrada independiente (sMSA) si son servicios de Windows, grupos de aplicaciones o tareas programadas, o si admiten gSMA o sMSA de forma nativa.
Los servicios pueden elegir la entidad de seguridad que se va a usar. Cada tipo de entidad de seguridad admite diferentes servicios y tiene limitaciones diferentes.
Principals | Servicios admitidos | Administración de contraseñas |
---|---|---|
Cuenta de equipo del sistema de Windows | Limitado a un servidor unido a un dominio | El equipo administra |
Cuenta de equipo sin sistema de Windows | Cualquier servidor unido a un dominio | Ninguno |
Cuenta virtual | Limitado a un servidor | El equipo administra |
Cuenta de servicio administrada independiente de Windows | Limitado a un servidor unido a un dominio | El equipo administra |
Cuenta de usuario | Cualquier servidor unido a un dominio | Ninguno |
Cuenta de servicio administrada de grupo | Cualquier servidor unido a un dominio de Windows Server | El controlador de dominio administra y el host recupera |
No se pueden compartir entre varios sistemas las cuentas de equipo de Windows, las cuentas de servicio administradas independientes (sMSA) de Windows ni las cuentas virtuales. Cuando se utilizan cuentas virtuales, la identidad también es local en el equipo y el dominio no la reconoce. Si configuras una cuenta para que la compartan los servicios de las granjas de servidores, tendrás que elegir una cuenta de usuario o una cuenta de equipo aparte de un sistema de Windows. En cualquiera de estos dos casos, las cuentas no tienen la funcionalidad de administrar contraseñas con un solo punto de control. Sin la administración de contraseñas, cada organización debe actualizar las claves del servicio en Active Directory y distribuir estas claves a todas las instancias de esos servicios.
Con Windows Server, los servicios y los administradores de los servicios no necesitan administrar la sincronización de contraseñas entre las instancias de los servicios al usar gMSA. La gMSA se crea en Active Directory y, después, se configura el servicio que admite las cuentas de servicio administradas. El uso de gMSA se limita a cualquier máquina que pueda usar (protocolo ligero de acceso a directorios) para recuperar las credenciales de gMSA. Puede crear una gMSA mediante los cmdlets New-ADServiceAccount
que forman parte del módulo de Active Directory. Los siguientes servicios admiten la configuración de identidad de servicio en el host.
Las mismas API que sMSA, de modo que los productos que admiten sMSA admiten gMSA
Los servicios que utilizan el Administrador de control de servicios para configurar la identidad de inicio de sesión
Los servicios que utilizan el Administrador de IIS para los grupos de aplicaciones con el fin de configurar la identidad
Las tareas que utilizan el Programador de tareas.
Requisitos previos
En la siguiente tabla, se indican los requisitos del sistema operativo que se deben cumplir para que la autenticación Kerberos funcione con los servicios que usan gMSA. Los requisitos de Active Directory se indican debajo de la tabla.
Para ejecutar los comandos de Windows PowerShell que se usan para administrar gMSA, se necesita una arquitectura de 64 bits.
Sistema operativo
Elemento | Requisito |
---|---|
Host de la aplicación cliente | Cliente Kerberos que cumpla RFC |
Controladores de dominio del dominio de la cuenta de usuario | KDC que cumpla RFC |
Hosts miembros de los servicios compartidos | |
Controladores de dominio del dominio del host miembro | KDC que cumpla RFC |
Controladores de dominio del dominio de la cuenta de gMSA | Controladores de dominio de Windows Server 2012 disponibles para que el host recupere la contraseña |
Host del servicio backend | Servidor de aplicaciones Kerberos que cumpla RFC |
Controladores de dominio del dominio de la cuenta de servicio de back-end | KDC que cumpla RFC |
Windows PowerShell para Active Directory | Herramientas de administrador de servidor remoto de Active Directory Domain Services |
Active Directory Domain Services
Las cuentas de servicio administradas de grupo tienen los siguientes requisitos en servicios de dominio de Active Directory (AD DS).
El nivel funcional de dominio de Active Directory y bosque deben ser Windows Server 2012 o una versión posterior. Para obtener más información sobre cómo actualizar el esquema, consulte Elevación de los niveles funcionales de dominio y bosque de Active Directory.
Si administra el permiso del host de servicios para usar gMSA por grupo, un grupo de seguridad nuevo o existente.
Si administra el control de acceso a los servicios por grupo, un grupo de seguridad nuevo o existente.
La clave raíz de Servicios de distribución de claves (KDS) para Active Directory debe crearse en el dominio. Se puede comprobar el resultado de la creación en el registro operativo KdsSvc,
Event ID 4004
. Para obtener más información sobre cómo crear la clave raíz de KDS (kdssvc.dll), consulte Creación de la clave raíz de KDS de servicios de distribución de claves.
Implementación de una nueva granja de servidores
El proceso de creación y administración de una granja de servidores que utiliza la característica de gMSA suele incluir las siguientes tareas.
Implementación de una nueva granja de servidores
Adición de hosts miembros a una granja de servidores existente
Retirada de hosts miembros de una granja de servidores existente
Retirada de una granja de servidores existente
Eliminación de un host miembro que perdió su carácter confidencial de una granja de servidores si es necesario
Cuando el administrador de servicios implementa una nueva granja de servidores, debe determinar la siguiente información.
Si el servicio admite el uso de gMSA
Si el servicio requiere conexiones autenticadas de entrada o de salida
Los nombres de las cuentas de equipo de los hosts miembros del servicio que usan la gMSA.
El nombre NetBIOS del servicio.
El nombre del host DNS del servicio.
Los nombres de las entidades de servicio (SPN) del servicio.
El intervalo de cambio de la contraseña (el valor predeterminado es 30 días)
Creación de cuentas de servicio administradas de grupo
Solo puede crear una gMSA si el esquema del bosque es Windows Server 2012 o posterior. También debe implementar la clave raíz de KDS para Active Directory y tener al menos un controlador de dominio de Windows Server 2012 o posterior en el dominio donde desea crear una gMSA.
Importante
Los nombres de cuenta de gMSA deben ser únicos dentro de un nivel de bosque y no solo un dominio. Se producirá un error al intentar crear una cuenta de gMSA con un nombre duplicado, incluso en dominios diferentes.
Para completar los siguientes procedimientos, el requisito mínimo es ser miembro de Administración del dominio o poder crear objetos msDS-GroupManagedServiceAccount
.
Para crear una gMSA con PowerShell, siga estos pasos.
En el controlador de dominio de Windows Server 2012, ejecute Windows PowerShell desde la Barra de tareas.
Escribe los siguientes comandos en el símbolo del sistema de Windows PowerShell y, luego, presiona ENTRAR. (El módulo de Active Directory se carga automáticamente).
New-ADServiceAccount [-Name] <string> -DNSHostName <string> [-KerberosEncryptionType <ADKerberosEncryptionType>] [-ManagedPasswordIntervalInDays <Nullable[Int32]>] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>] [-SamAccountName <string>] [-ServicePrincipalNames <string[]>]
Nota:
Siempre se requiere un valor para el parámetro
-Name
(tanto si se especifica-Name
como si no), donde-DNSHostName
,-RestrictToSingleComputer
y-RestrictToOutboundAuthentication
son requisitos secundarios para los tres escenarios de implementación.Parámetro String Ejemplo Nombre Nombre de la cuenta ITFarm1 DNSHostName Nombre del host DNS del servicio ITFarm1.contoso.com KerberosEncryptionType Todos los tipos de cifrado admitidos por los servidores host Ninguno, RC4, AES128, AES256 ManagedPasswordIntervalInDays Intervalo de cambio de la contraseña en días (si no se especifica, el valor predeterminado es 30 días) 90 PrincipalsAllowedToRetrieveManagedPassword Las cuentas de equipo de los hosts miembros o el grupo de seguridad al que pertenecen los hosts miembros ITFarmHosts SamAccountName Nombre NetBIOS del servicio, si no es el mismo que el de Name ITFarm1 ServicePrincipalNames Nombres de las entidades de servicio (SPN) del servicio http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com, http/ITFarm1/contoso, MSSQLSvc/ITFarm1.contoso.com:1433, MSSQLSvc/ITFarm1.contoso.com:INST01 Importante
El intervalo de cambio de la contraseña solo se puede definir durante la creación. Si necesitas cambiar este intervalo, tendrás que crear una nueva gMSA y definir el intervalo al crearla.
Por ejemplo, para crear una gMSA denominada
ITFarm1
para el grupo, use el siguiente comando. La gMSA permite al servicio usar los tipos de cifrado Kerberos RC4, AES128 y AES256. El servicio puede usar los SPNhttp/ITFarm1.contoso.com/contoso.com
,http/ITFarm1.contoso.com/contoso
,http/ITFarm1/contoso.com
yhttp/ITFarm1/contoso
.Escribe el comando en una sola línea, aunque aquí pueda aparecer con saltos de línea debido a las limitaciones del formato.
New-ADServiceAccount ITFarm1 -DNSHostName ITFarm1.contoso.com -PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$ -KerberosEncryptionType RC4, AES128, AES256 -ServicePrincipalNames http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com, http/ITFarm1/contoso
Para completar este procedimiento, el requisito mínimo es ser miembro de Administradores de dominio, Operadores de cuentas o poder crear objetos msDS-GroupManagedServiceAccount
. Para obtener información detallada sobre el uso de las cuentas adecuadas y las pertenencias a grupos, consulte Grupos de seguridad de Active Directory.
Para crear una gMSA para la autenticación saliente solo con PowerShell, siga los pasos.
En el controlador de dominio de Windows Server 2012, ejecute Windows PowerShell desde la Barra de tareas.
Use el siguiente comando en el símbolo del sistema del módulo de Active Directory para Windows PowerShell.
New-ADServiceAccount [-Name] <string> -RestrictToOutboundAuthenticationOnly [-ManagedPasswordIntervalInDays <Nullable[Int32]>] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>]
En el ejemplo se crea una gMSA con los parámetros de la tabla siguiente.
Parámetro String Ejemplo Nombre Nombre de la cuenta ITFarm1 ManagedPasswordIntervalInDays Intervalo de cambio de la contraseña en días (si no se especifica, el valor predeterminado es 30 días) 75 PrincipalsAllowedToRetrieveManagedPassword Las cuentas de equipo de los hosts miembros o el grupo de seguridad al que pertenecen los hosts miembros ITFarmHosts Importante
El intervalo de cambio de la contraseña solo se puede definir durante la creación. Si necesitas cambiar este intervalo, tendrás que crear una nueva gMSA y definir el intervalo al crearla.
El comando de ejemplo usa estos parámetros como se indica a continuación.
New-ADServiceAccount ITFarm1 -RestrictToOutboundAuthenticationOnly - PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$
Configuración del servicio de identidad de servicio
Para configurar los servicios en Windows Server, consulte los siguientes artículos:
Puede haber otros servicios que admitan gMSA. Para ver información detallada sobre cómo configurar esos servicios, consulta la documentación del producto correspondiente.
Adición de hosts miembros a una granja de servidores existente
Si se usan grupos de seguridad para administrar los hosts miembros, agregue la cuenta de equipo para el nuevo host miembro al grupo de seguridad (al que pertenecen los hosts miembros de la gMSA) mediante uno de los siguientes métodos.
Para completar estos procedimientos, el requisito mínimo es ser miembro de Admins. del dominio o poder agregar miembros al objeto del grupo de seguridad.
Método 1: Usuarios y equipos de Active Directory
Para usar el complemento Usuarios y equipos de Active Directory, consulte Adición de una cuenta de equipo a un grupo y Administración de dominios diferentes en el Centro de administración de Active Directory.
Método 2:
dsmod
Para usar la línea de comandos, consulte Adición de una cuenta de equipo a un grupo.
Método 3: cmdlet de Active Directory de Windows PowerShell
Add-ADPrincipalGroupMembership
Para usar PowerShell, consulte Add-ADPrincipalGroupMembership.
Si usas cuentas de equipo, busca las cuentas existentes y agrega la nueva cuenta de equipo.
Para completar este procedimiento, el requisito mínimo es ser miembro de Administradores de dominio, Operadores de cuentas o poder administrar objetos msDS-GroupManagedServiceAccount
. Para ver información detallada sobre el uso de las cuentas adecuadas y las pertenencias a grupos, consulte Grupos predeterminados locales y de dominio.
Adición de hosts miembros mediante PowerShell
En el controlador de dominio de Windows Server 2012, ejecute Windows PowerShell desde la Barra de tareas.
Escribe los siguientes comandos en el símbolo del sistema del módulo de Active Directory de Windows PowerShell y, luego, presiona ENTRAR:
Get-ADServiceAccount [-Identity] <string> -Properties PrincipalsAllowedToRetrieveManagedPassword
Escribe los siguientes comandos en el símbolo del sistema del módulo de Active Directory de Windows PowerShell y, luego, presiona ENTRAR:
Set-ADServiceAccount [-Identity] <string> -PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>
En el ejemplo siguiente se agrega un miembro a una granja de servidores mediante los parámetros de la tabla.
Parámetro | String | Ejemplo |
---|---|---|
Nombre | Nombre de la cuenta | ITFarm1 |
PrincipalsAllowedToRetrieveManagedPassword | Las cuentas de equipo de los hosts miembros o el grupo de seguridad al que pertenecen los hosts miembros | Host1, Host2, Host3 |
En el ejemplo siguiente se obtienen los miembros actuales de la granja de servidores ITFarm1
.
Get-ADServiceAccount [-Identity] ITFarm1 -Properties PrincipalsAllowedToRetrieveManagedPassword
En el ejemplo siguiente se agregan hosts de miembro a una granja de servidores ITFarm1
existente.
Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host2$,Host3$
Actualización de las propiedades de gMSA
Para completar estos procedimientos, el requisito mínimo es ser miembro de Admins. del dominio u Opers. de cuentas o poder escribir en objetos msDS-GroupManagedServiceAccount.
Abre el módulo de Active Directory para Windows PowerShell y defina las propiedades con el cmdlet Set-ADServiceAccount
.
Para ver información detallada sobre cómo definir estas propiedades, consulte Set-ADServiceAccount en la biblioteca de TechNet o escriba Get-Help Set-ADServiceAccount
en el símbolo del sistema del módulo de Active Directory para Windows PowerShell y pulse ENTRAR para consultarlo.
Retirada de hosts miembros de una granja de servidores existente
Para completar estos procedimientos, el requisito mínimo es ser miembro de Admins. del dominio o poder quitar miembros del objeto del grupo de seguridad.
Si se usan grupos de seguridad para administrar los hosts miembros, quite la cuenta de equipo para el host miembro retirado del grupo de seguridad al que pertenecen los hosts miembros de la gMSA mediante uno de los siguientes métodos.
Método 1: Usuarios y equipos de Active Directory
Para usar el complemento Usuarios y equipos de Active Directory, consulte Eliminación de una cuenta de equipo y Administración de dominios diferentes en el Centro de administración de Active Directory.
Método 2:
drsm
Para usar la línea de comandos, consulte Eliminación de una cuenta de equipo.
Método 3: cmdlet de Active Directory de Windows PowerShell
Remove-ADPrincipalGroupMembership
Para usar PowerShell, consulte Remove-ADPrincipalGroupMembership en la biblioteca de TechNet, o escriba
Get-Help Remove-ADPrincipalGroupMembership
en el módulo de Active Directory para el símbolo del sistema de Windows PowerShell y pulse ENTRAR.
Si usas listas de cuentas de equipo, recupera las cuentas existentes y, luego, agrega todas menos la cuenta del equipo quitado.
Para completar este procedimiento, el requisito mínimo es ser miembro de Administradores de dominio, Operadores de cuentas o poder administrar objetos msDS-GroupManagedServiceAccount
. Para ver información detallada sobre el uso de las cuentas adecuadas y las pertenencias a grupos, consulte Grupos predeterminados locales y de dominio.
Eliminación de hosts miembros mediante PowerShell
En el controlador de dominio de Windows Server 2012, ejecute Windows PowerShell desde la Barra de tareas.
Escribe los siguientes comandos en el símbolo del sistema del módulo de Active Directory de Windows PowerShell y, luego, presiona ENTRAR:
Get-ADServiceAccount [-Identity] <string> -Properties PrincipalsAllowedToRetrieveManagedPassword
Escribe los siguientes comandos en el símbolo del sistema del módulo de Active Directory de Windows PowerShell y, luego, presiona ENTRAR:
Set-ADServiceAccount [-Identity] <string> -PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>
En el ejemplo se quita un miembro a una granja de servidores mediante los parámetros de la tabla siguiente.
Parámetro | String | Ejemplo |
---|---|---|
Nombre | Nombre de la cuenta | ITFarm1 |
PrincipalsAllowedToRetrieveManagedPassword | Las cuentas de equipo de los hosts miembros o el grupo de seguridad al que pertenecen los hosts miembros | Host1, Host3 |
En el ejemplo siguiente se obtienen los miembros actuales de la granja de servidores ITFarm1
.
Get-ADServiceAccount [-Identity] ITFarm1 -Properties PrincipalsAllowedToRetrieveManagedPassword
En el ejemplo siguiente se quitan los hosts de miembro de una granja de servidores ITFarm1
existente.
Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host3$
Eliminación de una gMSA del sistema
Para eliminar del host miembro las credenciales almacenadas en caché de la gMSA use Uninstall-ADServiceAccount
o la API NetRemoveServiceAccount
en el sistema host.
El requisito mínimo para completar estos procedimientos es pertenecer al grupo Administradores u otro equivalente.
Eliminación de una gMSA con PowerShell
En el controlador de dominio de Windows Server 2012, ejecute Windows PowerShell desde la Barra de tareas.
Escribe los siguientes comandos en el símbolo del sistema del módulo de Active Directory de Windows PowerShell y, luego, presiona ENTRAR:
Uninstall-ADServiceAccount <ADServiceAccount>
En el ejemplo siguiente se desinstala una cuenta de servicio administrada de Active Directory de un equipo.
Uninstall-ADServiceAccount ITFarm1
Para obtener más información sobre el cmdlet Uninstall-ADServiceAccount
, en el símbolo del sistema del módulo de Active Directory para Windows PowerShell, escriba Get-Help Uninstall-ADServiceAccount
y pulse ENTRAR o consulte la información de la web de TechNet en Uninstall-ADServiceAccount.