Requerimientos gMSA:
Para usar la característica gMSA, la infraestructura debe cumplir lo siguiente:
· El nivel del schema de Active Directory debe ser Windows Server 2012
· Un controlador de dominio Windows Server 2012 (o superior) con el Microsoft Key Distribution Service — este servicio es responsable de la generación de passwords
· Modulo PowerShell para administrar Active Directory
· Windows Server 2012/2012 R2 y Windows 8/8.1 pueden utilizer gMSA
· El servicio que utilizara gMSA tiene que ser compatible con este tipo de cuenta. (Debe estar especificado en la documentación.)
Iniciar sesión en un Domain
controller con Windows Server 2012 o 2012 R2
Crear un grupo de Active Directory donde colocaremos los objetos “Computers” que tendrán permiso para usar la gMSA (global managed service Account) que vamos a crear. En nuestro ejemplo creamos el grupo gMSA_group y añadimos como miembro el objeto de active directory correspondiente a nuestro servidor “FS1”
2.
Luego vamos a crear un componente llamado “KDS root key” quien será encargado de administrar los passwords de forma automática para las gMSA. Esto lo hacemos mediante powershell con el siguiente comando. (Abrir el powershell con permisos elevados.)
Comando: Add-KdsRootKey -EffectiveTime
Nota: En teoría hay que dejar que esperar 10 horas a que este componente se replique entre todos los Domain controllers en el bosque de active directory. Por lo tanto deberíamos correr este comando y luego al dia siguiente continuar con los pasos de implementación.
Tip: Para no tener que esperar 10 horas se puede utilizar le siguiente comando.
Comando: Add-KdsRootKey -EffectiveTime ((Get-Date).addhours(-10))
Luego vamos a crear un componente llamado “KDS root key” quien será encargado de administrar los passwords de forma automática para las gMSA. Esto lo hacemos mediante powershell con el siguiente comando. (Abrir el powershell con permisos elevados.)
Comando: Add-KdsRootKey -EffectiveTime
Nota: En teoría hay que dejar que esperar 10 horas a que este componente se replique entre todos los Domain controllers en el bosque de active directory. Por lo tanto deberíamos correr este comando y luego al dia siguiente continuar con los pasos de implementación.
Tip: Para no tener que esperar 10 horas se puede utilizar le siguiente comando.
Comando: Add-KdsRootKey -EffectiveTime ((Get-Date).addhours(-10))
3.
Chequeamos que efectivamente se ha creado la key con el siguiente comando.
Comando: Get-KDSRootKey
Las key se almacenan en Active Directory las podemos ver abriendo la consola “Active Directory Site and Services” con la vista avanzada tal como muestra la imagen.
Creamos una gMSA con el siguiente comando.
Comando: New-ADServiceAccount -name gmsa1 -DNSHostName dc.cds.local -PrincipalsAllowedToRetrieveManagedPassword "gMSA_group"
gmsa1 es el nombre de la gMSA que estamos creando
dc.cds.local es el FQDN del controlador de dominio donde estamos creando la gMSA
gMSA_group es el grupo de servidores que tendrá permisos para utilizar la gMSA
gmsa1 es el nombre de la gMSA que estamos creando
dc.cds.local es el FQDN del controlador de dominio donde estamos creando la gMSA
gMSA_group es el grupo de servidores que tendrá permisos para utilizar la gMSA
Luego de ejecutado el comando podemos ver en la consola de “Active Directory Users and Computers” bajo el contenedor “Managed Services Accounts” la cuenta creada.
. Para usar la gMSA en un servidor primero debemos tener disponible en ese servidor el módulo powershell de Active directory.
Iniciamos sesión en nuestro servidor miembro e instalamos el modulo correspondiente con el siguiente comando.
Comando: Add-WindowsFeature RSAT-AD-PowerShell
5
Instalamos la gMSA en el servidor donde la vamos a utilizar. (Debemos asegurarnos antes que el servidor pertenece al grupo que creamos al principio)
Comando: Install-ADServiceAccount -Identity gmsa1
6.. Podemos ver si quedo la gMSA correctamente intalada con el siguiente comando.
Comando: Test-ADServiceAccount gmsa1
7
8. Ahora podemos configurar un servicio en nuestro servidor miembro para que corra con la gMSA creada y testeada.
El servicio de más arriba es a modo de ejemplo pero no funciona una gMSA con servicios del sistema operativo. Normalmente lo utilizaremos con servicios que no son los del sistema operativo, en ese caso la cuenta gMSA, que en nuestro ejemplo es gmsa1 deberá tener los permisos correspondientes al igual que una cuenta estándar. Por ejemplo si mi servicio requiere que tenga permisos de administrador local debemos agregar gmsa1 como administrador local para que pueda correr el servicio.
También podemos correr una tarea programada con
una cuenta gMSA. La configuración es igual que cuando creamos una tarea
programada la única diferencia es que en el usuario vamos a seleccionar la gMSA
creada.