En este artículo os presento dos tecnologías presentes en el servidor que tienen como misión securizar los despliegues de Active Directory: Los objetos de ajuste de password o PSO (Password Setting Object) y las cuentas de servicio administradas de grupo o GMSA (Group Management Service Account)

Si te ves reflejado en la siguiente MALA práctica de seguridad, entonces te interesa leer el resto del artículo.

Necesitamos instalar un servicio, por ejemplo, SQL Server. El instalador me pide una cuenta de Active Directory para que el servicio presente credenciales. Muy bien, creamos una cuenta de usuario con un nombre interesante, por ejemplo, SQLService y la usamos al instalar la aplicación. Todos contentos, bueno, no del todo.

La razón es que esta cuenta también está sujeta a la política de caducidad de contraseñas del directorio que, si no la hemos cambiado, hace que, al cuadragésimo segundo día, sea necesaria cambiarla porque si no la aplicación SQL Server no funcionará. En cualquier caso, lo que solemos hacer es establecer el ajuste de la cuenta para que la contraseña no caduque nunca, y así evitar la política de Kerberos mencionada anteriormente.

Pues bien, eso es una mala praxis de seguridad, porque podríamos ofrecer todo el tiempo del mundo a un supuesto malware que realizara ataques de fuerza bruta de sobre el servicio.

La solución pasa por usar las cuentas de servicio administradas.

Como puedes ver en la imagen, existe un contenedor de Active Directory para este tipo de objetos. Te reto a que verifiques desde qué versión del servidor está presente.

Las GMSAs no se pueden crear con la interfaz gráfica, sino con Powershell.

Son tres comandos, uno que crea la cuenta, otro que indica el servidor que puede cambiar la contraseña de la cuenta (y aquí está la cuestión) y el tercero, que instala la cuenta en el servidor que la usará, en nuestro ejemplo SQL Server.

Como podrás imaginar, ahora ya no es el administrador quien se responsabiliza de cambiar la contraseña de la cuenta antes que esta caduque, sino un servidor, preferentemente el servidor que expone la aplicación.

Por lo tanto, las cuentas que usamos en los servicios ya pueden tener un password que caduque sin que el servicio se detenga. Hemos ganado el notable.

Si te interesa el sobresaliente, entonces sigue leyendo, porque hace falta la participación de otra tecnología del servidor: Los objetos de ajuste de password o PSOs.

Observa las flechas de la imagen.

La longitud del password es de 20 caracteres (extremadamente fuerte) y la caducidad es de 5 días. Gracias a este objeto PSO (que asociaremos con la GMSA anterior), conseguiremos lo deseado, es decir, que la cuenta de servicio de nuestra aplicación tenga un password muy fuerte, con una caducidad muy frecuente y sobre todo, que nosotros los administradores no debemos preocuparnos de ello en el futuro.

¿A qué esperas para sacar un 10?

*Si quieres seguir aprendiendo sobre Active Directory, no te pierdas esta formación.