Administración Centralizada de los Administradores Locales – Parte 1 de 2

Hace un tiempo ya publiqué una nota sobre cómo poder administrar la cuenta administradora local de las máquinas de un Dominio Active Directory (“Habilitar y Renombrar el Administrador Local Usando Group Policies (Directivas de Grupo”). En su momento funcionaba perfectamente, pero una actualización de seguridad de Windows hizo que dejara de ser posible usar ese método (“Microsoft Security Bulletin MS14-025 – Important”)

Esta actualización, evitaba por riesgo de seguridad que la contraseña de usuario esté incluida en una GPO, porque aunque la misma se almacenaba en forma “oscurecida” aún era posible que bajo ciertas circunstancia pueda ser legible

Como una forma de remediar el problema que provoca en la administración centralizada Microsof ha liberado una aplicación adicional que permite volver a hacer la administración centralizada: Local Administrator Password Solution (LAPS)

Vamos a ver su implementación y uso, incluyendo las configuraciones adicionales que hay que hacer

Para esta demostración utilizaré tres máquinas virtuales, un Controlador de Dominio (dc1.ad.guillermod.com.ar), un cliente Windows 8.1 x86 (cl1.ad.guillermod.com.ar) y un segundo cliente Windows 8.1 x64 (cl3.ad.guillermod.com.ar)

El motivo de utilizar dos clientes, uno x86 y otro x64, es simplemente para que veamos como con una única GPO podamos instalar la aplicación adecuada de acuerdo a la plataforma

Por supuesto que lo primero que debemos hacer es descargar la aplicación LAPS completa, tanto las versiones x86 y x64 como su documentación

Yo la he dejado en una carpeta específica (LAPS)

He preparado el Dominio con una Unidad Organizativa llamada “DesktopWks” donde he puesto las cuentas de ambas máquina cliente que utilizaré

Además he creado otra Unidad Organizativa llamada “SoporteDesktops”. En esta he creado un usuario (“Soporte Uno”) pertenciente a un grupo llamado  “AdministradoresDesktop”

Los miembros de este grupo podrán ver la contraseña del administrador local de las máquinas sobre las cuales deleguemos esta opción

La utilización de LAPS implica dos pasos, por un lado la instalación en el cliente de una nueva CSE (Client Side Extension) para que sea procesado por GPO, y por otro lado la instalación de la aplicación para ver las contraseñas donde sea necesario

En DC1 haré la instalación completa, y por GPO haré que se instale automáticamente en el cliente la CSE

Para que se pueda hacer esta instalación en los clientes mediante GPO debemos compartir la carpeta con los permisos adecuados para que las cuentas de máquina tengan acceso al paquete de instalación (MSI)

Comparto como muestran las siguientes capturas de pantalla

Atención a los permisos de seguridad, ya que le debemos permitir acceso a los equipos del Dominio, y por eso agregué con permiso de lectura a “Domain Computers”

 

Comienzo instalando LAPS en DC1, muy sencillo seguir los pasos. Por supuesto la versión x64 por tratarse de un servidor Windows Server 2012 R2

Debemos seleccionar una instalación completa, ya que por omisión instalará solamente la CSE

 

El próximo paso será crear una GPO que se ocupará de hacer la instalación automáticamente en las máquinas cliente, por lo tanto creamos y enlazamos una GPO a “DesktopWks”

Como siempre, nombres a preferencia de cada uno

Y vamos a seleccionar los MSI a instalar

Muy importante: como cualquier instalación de aplicaciones por GPO debemos usar el nombre del compartido, y no un acceso local

Selecionemos la opción “Advanced” así cambiamos algunas de las opciones por omisión

Como vamos a utilizar la misma GPO tanto para x86 como para x64 es conveniente individualizar en el nombre qué plataforma se trata

En forma totalmente análoga debemos proceder para la opción x86, sólo que configuraremos en forma diferente las opciones para que no se instale sobre máquinas x64

Desmarcaremos la opción que se muestra para evitar que este MSI x86 se instale en las máquinas x64

Quedará finalmente así

He hecho una configuración adicional en esta GPO, aunque no he capturado las pantallas. Por omisión está habilitado el llamado “Fast Logon” lo que hace que los sitemas lleguen al escritorio, aún antes que levante la parte de red, y que por lo tanto dificulta la aplicación de GPOs, y especialmente la instalación de aplicaciones

Para no tener problemas he habilitado la siguiente opción: “Computer Configuration / Policies / Administrative Templates / System / Logon / Always wait for the network at computer startup and logon”

Para no demorar, inicio sesión en cada uno de los clientes y fuerzo la aplicación de las GPOs. Como se trata de una instalación de software el sistema indica que debe reiniciar, que por supuesto acepto

Luego del reinicio constato que se ha hecho exitosamente la instalación del componente en cada uno de los clientes

 

En DC1 debemos hacer ahora la configuración necesaria ejecutando PowerShell como administradores

Lo primero es cargar el nuevo módulo disponible, y si deseamos ver cuáles son los nuevos comandos que tendremos disponibles. En todos los casos verificar que los comandos se ejecutan sin errores

Import-Module AdmPwd.ps
Get-Command -Module AdmPwd.ps

Lo primero a configurar es una actualización del Esquema (“Schema”) para crear el nuevo atributo donde se guardará en Active Directory la contraseña del administrador local de las máquinas cliente

Update-AdmPwdADSchema

El siguiente paso es permitir que las máquinas puedan hacer la actualización de la contraseña en el atributo creado

Set-AdmPwdComputerSelfPermission -OrgUnit DesktopWks

Y a continuación permitir que el grupo que se ocupará de la administración de las máquinas clientes puedan leer el atributo. En nuestro caso el grupo es “AdministradoresDesktops”

 

Continuaremos en la próxima nota para no hacer esta nota tan extensa. En la misma veremos cómo solucionar centralizadamente un problema que pareciera no tener solución: no poder cambiar la contraseña del administrador local en forma remota, y no poder habilitar la cuenta predefinida de Administrador por no tener contraseña

A veces los esquemas de seguridad pueden llegar a ser complejos y confusos, el sistema no permite que se almacene la contraseña en forma “oscurecida” en una GPO, pero sin embargo lo podemos hacer utilizando un “script” donde no tiene ninguna forma de ocultarse :S

Continuamos en la siguiente nota “Administración Centralizada de los Administradores Locales – Parte 2 de 2”