Ir al contenido principal

Implementar Group Managed Service Accounts



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))

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


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.

Entradas más populares de este blog

Probando Workplace join en Windows Server 2012 R2

Buen día, La idea del día de hoy es hacer un laboratorio de prueba para probar la característica Workplace join de Windows Server 2012 R2. La función de esta característica es poder realizar Single-Sign-On desde dispositivos IOs y Android para consumir datos y servicios en nuestra red corporativa, dado que estos dispositivos no pueden ser incluidos como objetos en nuestro Active Directory. Para poder realizar este laboratorio vamos a necesitar tener un dominio de Active Directory, también necesitaremos implementar Active Directory Federation Services y Active Directory Certification Services, este ultimo para emitir certificados internamente en nuestra organización. En mi caso ya tengo un laboratorio con un dominio creado y el controlador de dominio correspondiente, también eh implementado el rol de Active Directory Certificate Services para los certificados. El foco principal que quiero abordar aquí son los pasos correspondientes a la implementación de la característica Workpl...

Crear servidor Ansible

Servidor Ansible Comenzamos instalando un sistema operativo CentOS 7 minimal, podemos hacerlo sobre una maquina virtual Hyper-V, Vmware o en la nube. En Centos 7 instalación mínima por defecto no se tiene conexión a la red dado que las interfaces ethernet no vienen habilitadas de forma predeterminada. Ejecutar comando " nmcli d " para un listado rápido de las interfaces de red instaladas en el equipo. Ejecutar el comando " nmtui " para abrir el Network manager Editar las interfaces y configurar en automático IPv4 y marcar la opción "Conectar de forma automática"  para obtener dirección IP desde un servidor DHCP. Ejecutar " Service Network Restart " Instalar el repositorio EPEL para Centos 7 Ejecutar " yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm " Instalar ansible Ejecutar " yum install ansible " Ejecutar " yum install python-pip " Ejecutar " pip inst...

Comandos para instalar prerequisitos Exchange 2010 SP3 en Windows Server 2008 R2 SP1

Import-Module ServerManager Add-WindowsFeature AS-NET-Framework,AS-HTTP-Activation,RSAT-ADDS,RPC-over-HTTP-Proxy,Web-Basic-Auth,Web-Windows-Auth,Web-Digest-Auth,Web-Net-Ext,Web-ASP-Net,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Client-Auth,Web-HTTP-Redirect,Web-HTTP-Tracing,Web-Dyn-Compression,Web-Metabase,Web-WMI,Web-Lgcy-Mgmt-Console