Select Page

Configurando las group managed service accounts

Configurando las group managed service accounts

Hoy voy a tratar de explicar una de las novedades que más me han gustado de Windows 2012 y de la que menos conocimiento se tienen. Las gMSAs

¿Qué son las gSMAs?

En Windows 2008 R2 se introdujeron las Cuentas de Servicio Administradas (Managed Service Accounts o MSAs) y fue una de las características que más se aplaudió. Entre otras cosas, las MSAs nos permitían administrar las passwords o registrar SPN’s de manera totalmente automática. Sin duda, características que ayudarían enormemente a los Administradores de Sistema. Pero eso es la teoría ya que vimos que no estaban soportadas por la mayoría de aplicaciones, como SQL Server, Tampoco valían para múltiples host, mp funcionaban en las tareas programadas, etc… Vamos que valían para más bien poco.

Y llegó Windows 2012

Afortunadamente, Microsoft escucha de vez en cuando y por ese motivo, ahora han introducido las gMSA. Con ellas, podemos programar tareas, utilizarlas en multiples host y, por supuesto, son compatibles con aplicaciones como SQL Server, Pools de IIS, etc…

Requisitos Previos

Para poder hacer uso de las gMSA necesitaremos las siguientes cosas:

  • Un Controlador de Domino con Windows 2012 y los módulos de PowerShell
  • Crear una KDS Root Key
  • Un grupo de seguridad en el que meter las máquinas que usarán nuestra gMS

Configuración de la gMSA

aasdasdVamos al lío. Lo primero que hay que hacer es generar la clave para el KDS (articulo technet). Este paso sólo será necesario llevarlo a cabo una única vez por dominio. Para ello entramos en el DC con Windows 2012, abrimos una consola de PowerShell y le cargamos el módulo de ActiveDirectory (Para cargar módulos utilizamos el cmdlet import-module seguido del nombre del módulo que queremos importar. En este caso ActiveDirectory). Una vez en la consola escribimos el siguiente cmdlet:

Tras este comando podemos irnos a casa y seguir mañana. No es coña, este comando tarda 10 horas en ser efectivo. Esto es una medida de seguridad para estar completamente seguros de que todos los DC’s han replicado y que serán capaces de responder a las peticiones de nuestras cuentas gMSA. No ostante, en entornos de laboratorio, podemos acelerar el proceso escribiendo el siguiente comando:

Nota: Usa el siguiente comando sólo en entornos de laboratorio. Bajo ningún concepto lo uses en tus servidores de producción ya que, el resultado, puede ser catastrófico. El que avisa no es traidor :)

aasdasd

Con la clave creada y replicada en todos los DC’s, podemos seguir adelante.

Ahora vamos a crear un grupo de seguridad que contendrá las cuentas de máquina de los equipos que van a utilizar nuestra cuenta. Se puede hacer el proceso de manera individual pero utilizar grupos hará la administración mucho más flexible. El único punto negativo de utilizar grupos es que los equipos han de ser reiniciados después de añadirlos/eliminarlos del grupo para que el cambio se haga efectivo.

 

Tras crear el grupo, meter las máquinas y reiniciarlas, ya podemos crear la propia cuenta gMSA. En el comando deberemos introducir los siguientes datos:

 

  • Nombre de la cuenta gMSA
  • Nombre dns de la cuenta gMSA
  • Nombre del grupo que utilizara la cuenta

 

Con estos datos claros, construímos el comando quedándonos de la siguiente manera:

Y así quedaría el comando en PowerShell. Si todo va bien, la pulsar intro nos devolverá al command prompt. de lo contrario nos mostrará una alerta en rojo de que algo ha salido mal:

 

Ojo, si recibemv gmsa03s la alerta “Key does not exist” es porque no han transcurrido las 10 horas que comentamos al principio.

Si todo ha salido bien, deberíamos ver nuestra cuenta en el Directorio Activo, bajo la OU “Managed Service Accounts“. Ya solo queda un par de comprobaciones finales para asegurar que todo está como debe. Para ello debemos ir a las máquinas donde vamos a configurar las gMSA e instalar el módulo PowerShell de Active Directory. Una vez instalado, abrimos la consola e importamos el módulo de AD y ejecutamos estos comandos:

El último comando nos devolverá “True” indicando que todo ha ido correctamente. de lo contrario podríamos añadir el comando -verbose para ver qué puede estar pasando.

Tras confirmar que todo está OK, ya sólo queda configurar la cuenta en la aplicación, el servicio o donde queramos usarla. Para ello sólo debemos poner el nombre de la cuenta con el símbolo $ al final y sin especificar contraseña.

En nuestro caso el usuario para los servicios de SQL será:

Espero que, como a mi, os haya servido de ayuda, manteniendo así nuestros entornos un poquito más seguros.

Saludos!

About The Author

Crower

Mi nombre es Mariano de Pedro. Actualmente vivo en Guadalajara donde también trabajo aunque he trabajado durante mucho tiempo en diversas empresas en Madrid.
Llevo trabajando con tecnologías Microsoft más de 15 años

Leave a reply

Si continuas utilizando este sitio, aceptas el uso de las cookies. Más información

Las opciones de cookie en este sitio web están configuradas para "permitir cookies" para ofrecerte una mejor experiéncia de navegación. Si sigues utilizando este sitio web sin cambiar tus opciones o haces clic en "Aceptar" estarás consintiendo las cookies de este sitio.

Cerrar