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

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

Solución de Problemas en la Migración del DataCollector de MMA a Azure ARC

  Síntomas Observados Error al Ejecutar Comandos: Al intentar ejecutar los comandos: Import-Module "C:\ODA\Binaries\bin\Microsoft.PowerShell.Oms.Assessments\Microsoft.PowerShell.Oms.Assessments" .\run.cmd Se obtiene el mensaje de error: "ExecPkg not found. File WindowsServerAssessment.execpkg". Ubicación Incorrecta del Archivo WindowsServerAssessment.execpkg: El archivo necesario se encuentra en una ubicación diferente a la esperada: C:\Packages\Plugins\Microsoft.ServicesHub.WindowsServerAssessment\1.7\bin Falta de Estructura de Carpeta Esperada: La carpeta esperada,  C:\ODA\Packages , no existe en el sistema. Errores Registrados en los Logs: En los registros (logs) del sistema se reporta el error: "Missing Mandatory file OmsAssessment.exe". Pasos para Solucionar los Problemas 1. Desinstalación del Microsoft Monitoring Agent (MMA) y Eliminación de Variables de Entorno Desinstala completamente el MMA asegurándote de eliminar todo el software relacionado. Ve...

Utilizar Ansible para implementar sobre Azure

Bien, ya tenemos nuestro servidor Ansible on-premises o en la nube. Ahora vamos a comenzar a usarlo para desplegar algo en Azure. Credenciales Lo primero que debemos hacer es crear las credenciales para poder  comunicar Ansible con nuestra subscripcion de Azure. Para eso vamos a usar la opción application registration del modulo de Active Directory de Azure. o mucho mas fácil ejecutando el siguiente comando desde la interfaz de comandos web de Azure.' az ad sp create-for-rbac --query '{"client_id": appId, "secret": password, "tenant": tenant}' La salida se vera parecida a lo siguiente: {   "client_id": "eexx6xxa-9xx8-4xx6-8xx7-0xx3xx5xx0d5",   "secret": "53xxcxxa-3xxf-4xx8-9xxb-48xxcxx5xx3f",   "tenant": "72xx8xxf-8xx1-4xxf-9xxb-2dxxd0xxdb47" } lo anotamos y luego vamos por la identificación de la subscripcion con el siguiente comando: az account show --query "{ ...