Cerrar
InicioDirectivas de GrupoConfigurar Local Administrator Password Solution (LAPS) vía GPO en nuestro Directorio Activo

Configurar Local Administrator Password Solution (LAPS) vía GPO en nuestro Directorio Activo

Cuantas veces nos habremos encontrado con la cuenta de administrador (u otras cuentas) local de los equipos o servidores miembros de un dominio con la misma contraseña, la cual se ha establecido en el proceso de instalación y luego no se ha vuelto a actualizar. Esto seguramente os sonará, no creo que sea nada nuevo para muchos de vosotros, pero claramente es una mala práctica por muchas razones, lo cual debemos evitar. Este tipo de configuraciones son muy comunes, pero voy a mostraros como podemos revertir esta situación y hacer que las cuentas locales tengan contraseñas seguras, que se actualicen cada cierto tiempo, además de que tengamos una forma segura de almacenarlas y visualizarlas.

La idea es  tener el mismo principio que la gestión del cambio de contraseñas de los usuarios del dominio, pero con algunas diferencias:

  • La contraseña se cambia de forma automática y establece una contraseña aleatoria (en base a patrones que definimos nosotros)
  • Cada usuario local de cada equipo del dominio tendrá una contraseña diferente
  • La contraseña se almacena en un nuevo atributo del Directorio Activo y sólo estará visible para los grupos de seguridad que definamos

Ahora bien, como vamos a conseguir esto sin tener que ir equipo por equipo cambiando contraseñas, utilizando complejos scripts de PowerShell junto con GPOs,  etc.. pues con LAPS (Local Administrator Password Solution (LAPS). Es una herramienta de MSFT  que hará todo el trabajo por nosotros, únicamente debemos realizar una serie de tareas en nuestra infraestructura IT:

  • Instalar LAPS (la parte de servidor) en algún DC (no RODC)
  • Crear una GPO para configurar los ajustes que necesitemos para cambiar las contraseñas de las cuentas locales
  • Definir los grupos de seguridad del dominio que tendrán acceso a leer y modificar los nuevos atributos en donde se almacenará la contraseña de la cuenta local que hemos configurado
  • Instalar LAPS (la parte de cliente) vía GPO/Script (yo utilizaré el proceso de instalación desde una GPO)

Como siempre (o casi), voy a utilizar un pequeño esquema de red de una topología en estos días muy común que seguro alguno de vosotros tiene. Una infraestructura con múltiples sedes, controladores de dominio de sólo lectura, servidores de ficheros en cada sede y todo ello conectado vía VPN, MPLS, etc… claramente el esquema es de otra configuración que tengo pero lo he adaptado un poco porque me parecía que podría ser  interesante:

La idea era “complicar” algo más el despliegue y el tener sedes siempre suma algo de complejidad, porque hay que tener en cuenta anchos de banda entre sedes, replicaciones de AD, etc.. En este artículo la idea sería configurar las GPO en algún controlador de dominio de la sede principal, que el resto de controladores de dominio se repliquen y luego configurar el instalador de LAPS para que esté disponible localmente. De esta forma los equipos no atraviesen la VPN para conectarse a la carpeta compartida en donde tenemos el instalador, evitando así consumos innecesarios de conectividad dejando los enlaces VPN disponible para otros usos más importantes.

Habiendo introducido un poco el articulo, empecemos con las primeras configuraciones de LAPS, lo primero instalar LAPS, el cual descargaremos de aquí: https://www.microsoft.com/en-us/download/details.aspx?id=46899&751be11f-ede8-5a0c-058c-2ee190a24fa6=True

El proceso de instalación es muy simple, únicamente debemos fijarnos que en este caso debemos hacer instalación de la parte de “servidor” y elegir la instalación las Management Tools:

Una vez que se haya completado el proceso de instalación, nos habrá creado en la carpeta %systemdrive%\Windows\PolicyDefinitions la plantilla que debemos utilizar para configurar nuestra GPO:

Como siempre que queramos utilizarla en nuestras directivas de dominio, debemos copiar los ficheros que están con el recuadro naranja (ubicación %systemdrive%\Windows\PolicyDefinitions\AdmPwd.admx y %systemdrive%\Windows\PolicyDefinitions\en-US\AdmPwd.adml) en sus respectivas carpetas dentro de PolicyDefinitions que tenemos dentro de SYSVOL (tal cual muestro en la siguiente captura). De esta forma, tendremos la plantilla de LAPS disponible para configurarla en la consola de las Directivas de Grupo (GPMC.MSC) de nuestro controlador de dominio, haciendo que además, esto se replique en el resto de controladores de dominio de nuestro Directorio Activo:

Lo siguiente será modificar el esquema (para ello vuestro usuario tiene que estar en el grupo de Administradores de Esquema del dominio), simplemente ejecutamos los siguientes cmdlets desde una consola de PowerShell en modo Administrador:

Eso ha creado dos atributos nuevos, en los cuales se van a almacenar dos valores importantes: la contraseña y la fecha de caducidad de la misma. Importante, donde vemos estos atributos… en una cuenta de equipo. Si vamos a las propiedades de una cuenta de equipo veremos que ya tiene dos nuevos atributos:

  • ms-Mcs-AdmPwd: Contraseña
  • ms-Mcs-AdmPwdExpiration: Fecha de expiración de la contraseña

Ahora mismo no tiene nada establecido, puesto que no tiene LAPS instalado y ni hemos configurado la GPO que realice dicho cambio en la contraseña del usuario local que decidamos manejar.

Ahora, el siguiente paso para ir completando la configuración inicial, es que tenemos que quitar todos los permisos extendidos de todos los usuarios que no queramos que puedan ver la contraseña establecida, para ello nos conectamos con el editor ADSI en el Contexto de nomenclatura predeterminado:

Ahora nos vamos a la OU donde tengamos la cuentas de equipo, nos vamos a sus propiedades, a la pestaña de seguridad  y en la configuración de seguridad avanzada para xxx (el nombre de vuestra OU) es donde retiraremos el permiso de Todos los permisos extendidos a los usuarios o grupos que queramos evitar  el acceso a la contraseña establecida en el atributo correspondiente:

Ahora debemos permitir a los equipos del dominio que puedan escribir en los atributos ms-Mcs-AdmPwd y ms-Mcs-AdmPwdExpiration, para ello tenemos que ejecutar el siguiente cmdlet: Set-AdmPwdComputerSelfPermission -OrgUnit <OU_de_Equipos> . En mi caso he borrado la información que no puedo mostrar, pero creo que se entiende perfectamente, con esto ya le hemos dado acceso a la cuentas de equipo a escribir en esos atributos:

En cuanto a permisos nos queda una última cosa, crear dos grupos de seguridad para delegar los permisos de quien puede ver la contraseña y quien puede restablecerla si fuese necesario:

Estos son los dos cmdlets necesarios, simplemente tenemos que sustituir los valores que tengamos en nuestro Directorio Activo y poco más:

Set-AdmPwdReadPasswordPermission -OrgUnit <OU donde queremos delegar las tareas> -AllowedPrincipals <Nombre del grupo al cual le queremos dar accesos de Leer la contraseña>

Set-AdmPwdResetPasswordPermission -OrgUnit <OU donde queremos delegar las tareas> -AllowedPrincipals <Nombre del grupo al cual le queremos dar accesos de Restablecer la contraseña>

Pues ahora nos queda configurar la GPO que nos permitirá realizar el cambio de contraseña del usuario local que queramos, eso sí, sólo de un usuario local (esta es la limitación más importante que le veo, pero bueno, entiendo que no deberíamos tener más de un usuario local en las máquinas). Abrimos la consola de Administración de Directivas de Grupo (GPMC.MSC), nos vamos a la Configuración del Equipo, Directivas, Plantillas administrativas: definiciones de directiva – LAPS (esto ahora está disponible por la plantilla que hemos copiado antes en PolicyDefinitions) y editamos las diferentes configuraciones:

Complejidad de la contraseña:

La cuenta sobre la que queremos que se aplique esta directiva, simplemente escribimos su nombre tal cual esté creada en el equipo/servidor (administrador, admin, sistemasadmin, etc..)

Esto habilitará LAPS con la configuración anterior, de tal forma que sea LAPS quien gestione el cambio de contraseña de la cuenta local indicada

Ahora nos queda vincular la GPO a la OU donde tengamos los equipos a los que queramos que tenga efecto, y a nivel de “servidor” ya tenemos todo lo que necesitamos. Pero ahora, nos queda instalar LAPS en los puestos “cliente”, para ello tenemos que buscar la forma de hacer el despliegue del instalador en todos los equipos, tenemos varias alternativas:

  • Script: un cmd utilizando la siguiente línea de ejecución
    • msiexec /i \\servidor\carpetacompartida\LAPS.x64.msi /quiet
    • msiexec /i \\servidor\carpetacompartida\LAPS.x86.msi /quiet
  • GPO: instalación de software
  • Manual: siguiente, siguiente, siguiente

Yo claramente he elegido que se realice la instalación de LAPS para los clientes adminstrados (así le llama la documentación oficial) desde una GPO, para ello lo primero que haré será ubicar los ficheros de instalación (LAPS.x64.msi y LAPS.x86.msi) en un servidor y compartiendo la carpeta de la siguiente forma. Lo primero es crear una carpeta con el nombre GPOTools, compartirla con el nombre GPOTools$ y establecer los siguientes permisos (como esto es para asignar una instalación de software da nivel de equipo (en el inicio del equipo), sólo necesito establecer permisos de lectura (SMB y NTFS) sólo para el grupo de Equipos del Dominio):

Si alguien quiere utilizar otro grupo puede, pero yo en este caso como quiero que se instale a todos los equipos del dominio (excepto DCs), me parece redundante (en innecesario) crear un grupo y hacer miembro de ese grupo al de Equipos del dominio. Ahora bien, esto lo haré en algún servidor de cada oficina remota, para que los equipos de cada sede se conecten al recurso compartido de un servidor local, evitando así tirar de la VPN para estas cosas en horas de producción, además de que ralentizaría el proceso de instalación y depende la cantidad de máquinas que tengáis el usuario puede verse impactado. Hagamos una simulación fácil con respecto al esquema anterior y con los caudales que había simulado:

Ahora imaginemos que en cada sede remota tenemos 30 equipos a los cuales queremos instalar LAPS, cada instalador ocupa 945kb, yo estimo los siguientes esfuerzos de línea por equipo:

  • Tiempo de descarga: 2 segundos
  • Ancho de banda utilizado: 1Mbps

Así en “frío” teniendo 200Mbps simétricos en la sede central y 100Mbps en cada sede, parece que no tendríamos problemas en desplegar de forma centralizada LAPS, pero si en vez de 1 equipo por sede ahora hacemos una cálculo más “real” por sede:

  • Equipos: 100
  • Tiempo de descarga por equipo: 3 segundos
  • Ancho de banda utilizado: 100Mbps en la sede central y en la sede

Aún así parece que los números encajan para una sede, pero ahora le vamos a poner tres sedes más con el mismo número de equipos por sede:

  • Equipos: 300
  • Tiempos de descarga por equipo: 9 segundos
  • Ancho de banda utilizado. 300Mbps en la sede central, 100Mbps en cada sede

Ahora ya el tema de empieza a poner más crítico, si en vez de 3 sedes tenemos 10 y 50 equipos sede ya costaría algo más mover todo. Además, de que tendríamos más latencias y los tiempos se alargarían, las conexiones en ese momento (ciertamente sólo se haría una primera vez hasta que se instalase el LAPS). OJO, que estos datos son más que ficticios, inventados y los cálculos muy superficiales sin tener en cuenta cosas como:

  • Latencias propias de la linea
  • % de ocupación de las líneas en otros servicios
  • % de IOPS que le estamos añadiendo al servidor de ficheros que tiene los instaladores en la sede central
  • Etc.. Etc..

Insisto, hay más cosas en las que debemos fijarnos, medirlas y así tener un escenario 99% real para saber como podríamos afrontar una instalación remota de este software (minúsculo por cierto).

Bueno, ahora que ya os he despistado un poco sigamos con la configuración de la GPO para hacer el despliegue del software, ya teníamos la carpeta compartida y los permisos establecidos y los instaladores dentro de dicha carpeta, ahora nos falta la GPO. Abrimos el editor de directivas de grupo (GPMC.MSC) y creamos una nueva directiva, editamos la GPO y nos vamos Configuración del equipo – Directivas – Configuración de software  y pulsamos con el botón secundario del ratón encima de Instalación de Software y vamos a Nuevo – Paquete

En el explorar que se nos abre nos vamos a la ruta compartida donde tenemos los ficheros de instalación  elegimos el paquete que queremos desplegar, en mi caso el LAPS.x64

ahora nos indica que será un  implementación Asignada (a nivel de equipo es lo único que podemos hacer), y pulsamos en Aceptar

Ahora ya tenemos nuestro paquete de instalación listo

Únicamente tenemos que vincularla a la OU donde queramos que se aplique y listo, si ahora reiniciamos algún equipo veremos que en el inicio del mismo se aplicará dicha GPO e iniciará el proceso de instalación:

Pues ahora que ya tenemos el software instalado, al GPO que habíamos creado al principio debería tener el efecto deseado y cambiar la contraseña de la cuenta local que hemos especificado en dicha GPO. Si todo ha funciona bien, ahora debemos comprobar que la contraseña se ha establecido en el atributo correspondiente, para ello tenemos que ver dicho atributo en la cuenta de equipo (si, la cuenta de equipo):

Esa sería la contraseña para la cuenta local del equipo que queríais cambiar, pero si nos fijamos en la fecha de caducidad no es fácil hacer la conversión (porque es un texto), para ello podemos ejecutar el siguiente comando (w32tm):

Ahora que ya habéis visto la parte dificil de como ver la contraseña, vamos a ver la fácil .. en el servidor donde habéis instalado el LAPS con las herramientas administrativas, en la carpeta en donde se ha instalado LAPS tenéis la siguiente utilidad AdmPwd.UI

Una vez abierta ya veis que es muy sencilla, podemos buscar por el nombre del equipo y ya conocemos la contraseña de la cuenta local.

Esto no implica que no necesitemos igualmente los permisos en el AD para poder visualizarla, para ello habíamos creados los diferentes grupos. Pues ahora solo quedaría desplegar el LAPS vía GPO al resto de equipos, y en cuestión de minutos tenemos todas las cuentas locales de todos los equipos con contraseñas complejas y todas diferentes!!

Teniendo en cuenta el tema de las sedes, las líneas, etc.. yo veo dos opciones:

  • Crear una GPO para aplicarla a la OU de  equipos de cada y que el paquete de instalación esté en una carpeta compartida de cada servidor de cada sede
  • Crear una única GPO para todas las sedes pero la ruta en vez de ser \\servidor\recursocompartido\fichero.msi utilizaría rutas DFS \\dominio.com\EspaciodeNombres\GPOTools\fichero.msi

Ahora os comento lo de DFS, publicamos la ruta de los ficheros de instalación vía DFS, nos permitirá sólo configurar una GPO e igualmente los equipos irán al servidor más cercano (debéis tener bien configurado los Sites en Directorio Activo), puesto que utilizará como conexión el destino más cercano en base a la información del AD. Eso sería perfecto, porque las carpetas compartidas que hay en los servidores las tenemos que tener igual, pero de esta forma las tenemos sincronizadas si queremos añadir más software para instalar vía GPO y nos evita tener que crear una GPO de instalación por centro. Al crear la GPO y buscar el paquete de instalación, la ruta donde el equipo tratará de buscar el fichero será la que hayas especificado al elegir el fichero, por lo que si hacemos referencia al servidor … tendremos que hacer una por sede para que vaya al servidor más cercano. si lo hacemos vía DFS, el equipo sabrá a cual es el destino más cercano a él. Para mi sería la mejor opción y la más optima en cuanto a la utilización de los recursos de red local y enlaces WAN.

Ahora ya es cuestión de que vosotros valoréis los esfuerzos, cual sería la mejor forma de hacerlo en función de vuestras topologías (Red, Vpn, Active Directory), pero yo tengo claro que DFS es mi opción.

Por último, como ya tenemos cambiadas las contraseñas de la cuentas locales y así lo hará cada x días que hayáis configurado en la directiva, quedaría un último paso para securizar las cuentas locales, sería automatizar las membresías de los grupos locales de los equipos. Sobre todo me refiero a los grupos de administradores locales, aquí os dejo un artículo de hace algunos mes (creo que ya años) que os puede servir como referencia para plantearos vuestros propio escenario: GPO: Securizando Administradores Locales en un Dominio

Secure_admins_Locales_4.jpg

Se pueden hacer muchísimas cosas con las GPO, deberían ser o son nuestra Navaja Suiza de los administradores de Directorio Activo, nos permitirán automatizar y securizar nuestro entorno en cuestión de minutos.

Espero que os sea de utilidad!!!

The next perpetual r
Microsoft Teams docu
26 COMENTARIOS
  • Alfredo Coindreau / 9 enero, 2020

    Muchas gracias por tremendo aporte, después de leer la documentación oficial de LAPS precisamente LAPS_OperationsGuide.pdf, me parece una muy buena síntesis, ahora solo queda implementar.

    Saludos.

  • Alberto / 2 febrero, 2020

    Jajajaja de verdad creen que con eso el sistema está seguro? La navaja suiza, tiene su contra-sable siempre del otro lado. No pequen de soberbios, por que despues muchas companias pierden millones de dolares al ser hackeadas. Deberían ser más responsables en publicar información a mansalva. Es necesario combatir el cibercrimen, pero esto se hace con educación, el eslabon flojo siempre es el usuario, ningun sistema es seguro mientras sean humanos quienes los manejen, especialmente si estos humanos son estupidos.

  • Adolfo F / 21 febrero, 2020

    Hola Santiago, buenos dias
    Muchas gracias por el excelente articulo, voy a armar un LAB para implementarlo y me sera de mucha utilidad tu paso a paso.
    Gracias!!
    Adolfo

  • Albe / 9 abril, 2020

    Hola,

    Cualquier usuario de dominio por defecto tiene permisos para leer los objetos del árbol de Active Directory. Con un LDAP Browser o con las RSAT conectándose a la consola de dsa.msc puede buscar un objeto tipo equipo, revisar su ficha de atributos y pescar la contraseña actual.

    ¿Estoy en lo cierto?

    Buen artículo!
    Un saludo.

      • Jose Antonio Delgado / 7 julio, 2020

        Buenos días Santiago,

        Sé que depende de cada organización pero me gustaría saber si recomiendas dejar ese permiso solo para administradores del dominio o sería seguro aplicarlo a los usuarios estándar del centro de soporte.

        Tengo dudas acerca de cuál de las dos es peor ya que si usamos administradores de dominio las credenciales podrían utilizarse en los equipos comunes por el CAU con el riesgo que eso supone para la organización completa pero tampoco tengo claro si es peligroso aplicarlo en sus usuarios comunes.

        Muy buen artículo y muchas gracias de antemano.

          • Jose Antonio Delgado / 8 julio, 2020

            Hola Santiago

            Me refiero a qué usuario tiene acceso al uso de LAPS para adquirir contraseñas de administradores locales. Si es recomendable usar un usuario más elevado con el que además tienen acceso a los servidores y o si por el contrario mejor evitar usar esos usuarios y dar el permiso al propio usuario estándar del técnico.

            Un saludo.

  • Luis Renteria / 28 agosto, 2020

    Muy buen trabajo Santiago, muy completa la guía.
    Tengo una duda, de que forma podría utilizar los permisos que asigné en el grupo ACL Reestablecer y ACL Lectura.

    Ósea me refiero si hay alguna herramienta donde puedas realizar dichas funciones.

    Saludos.

  • Daniel Pinto / 27 octubre, 2020

    Excelente articulo, muchas gracias.
    dada vuestra experiencia, tienes los comandos para revocar los permisos de lectura al grupo de seguridad y poder asignarlos a otro grupo???

    De antemano gracias.

  • Mary / 25 enero, 2021

    Buenos días, muy buen artículo, quisiera saber que pasa cuando el equipo se sale del dominio? se conserva la clave? Gracias,

  • Fareck / 11 abril, 2021

    Buen dia, si tengo un problema de relacion de confianza entre la pc y el servidor, como recupero el acceso a eelo si no me deja entrar por ningun lado?

  • Berni / 9 mayo, 2021

    Hola, en primer lugar indicar que me parecido un buen aporte de información. Quisiera saber si con LAPS se pueden administrar más de una cuenta local de máquina o si solo funciona para una cuenta unitaria. Saludos

  • Paloma / 6 agosto, 2021

    Buenas.

    ¿ Hay alguna manera de recuperar/visualizar la password de administrador que se modifica por laps de una máquina restaurada de un backup ?

    Muchas gracias.

  • Christian Garcia / 2 mayo, 2023

    Estaba buscando una guia completa como estas, muchas gracias.
    ¿Solo tengo una consulta, creo que hoy en día el proceso es mas sencillo si se tiene Windows 10 u Windows 11, no es necesario instalar el cliente no?

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This