WMI Explorer: Restricción en las políticas de grupo GPO aplicando filtros WMI y querys en SCCM System Center

Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un filtro WMI es un conjunto de consultas WMI (se usa el lenguaje de consulta WMI/WQL) que se puede usar para apuntar a las máquinas a las que se debe aplicar una política de grupo específica.

Por ejemplo, usando el filtro WMI GPO, puede aplicar una política vinculada a una OU solo a las máquinas que ejecutan Windows 10 (una política con dicho filtro WMI no se aplicará a las computadoras con otras versiones de Windows).

¿Para qué se utilizan los filtros WMI en las GPO?

WMI se puede usar cuando varios objetos de dominio (usuarios o equipos) se encuentran en la estructura AD plana en lugar de la unidad organizativa separada, o si se necesita aplicar políticas de grupo, de acuerdo con la versión del sistema operativo, configuración de red, software instalado o cualquier otro criterio que se pueda seleccionar usando WMI. Cuando el cliente procesa dicha política de grupo, Windows verificará el cumplimiento de la consulta WMI especificada, y si se cumplen las condiciones del filtro, la GPO se aplicará en esa máquina.

Lo más habitual en el uso de filtros WMI es distinguir sistemas operativos. Para estes casos las consultas deben hacerse en base al tipo de producto y el tipo de versión del OS.

Tipo de producto:

• ProductType 1 = Desktop OS
• ProductType 2 = Server OS - Solo Domain Controller
• ProductType 3 = Server OS - Excepto Domain Controller

Versiones de sistema operativo:

• Windows Server 2019, Windows Server 2016 y Windows 10 = 10.%
• Windows Server 2012 R2 y Windows 8.1 = 6.3%
• Windows Server 2012 y Windows 8 = 6.2%
• Windows Server 2008 R2 y Windows 7 = 6.1%
• Windows Server 2008 y Windows Vista = 6.0%
• Windows Server 2003 = 5.2%
• Windows XP = 5.1%
• Windows 2000 = 5.0%

Tipo de arquitectura:

• 32 bits = Win32_Processor where AddressWidth="32" // OSArchitecture="32-bit"
• 64 bits = Win32_Processor where AddressWidth="64" // OSArchitecture="64-bit"

Algunos ejemplos de filtros WMI aplicados a GPOs:

Windows 7

select * from Win32_OperatingSystem where Version like "6.1%" and ProductType="1"

Windows 10 

select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"

Windows Server 2016

select * from Win32_OperatingSystem where Version like "10.0%" and ProductType="3"

Windows Server 2019

select * from Win32_OperatingSystem where BuildNumber >= 17763 and ProductType="3" and OSArchitecture="64-bit" 

Cualquier Windows Desktop OS de 32-bit 

select * from Win32_OperatingSystem where ProductType="1" and not OSArchitecture="64-bit" 

No ejecutar en Servidores Windows

select ProductType from Win32_OperatingSystem where (ProductType <> "2") and (ProductType <> "3")

En la siguiente imagen se puede ver un ejemplo de filtrado WMI de una sentencia WQL para consultar la versión de OS Windows 10.

Figura 1: Creación de filtros WMI en la Group Policy Management Console.

Después de crear el filtro WMI, elegimos el filtro WMI y lo aplicamos a una GPO existente.

Figura 2: Aplicar filtro WMI a una GPO existente.

WMI Explorer Tool y como nos puede ayudar a encontrar lo que buscamos para realizar Querys en SCCM.

Después de hacer una introducción a la restricciones en las polítcas de grupo mediante filtros WMI. En esta entrada quería dar a conecer el potencial de WMI Explorer y como nos puede ayudar para encontrar los espacios de nombres, instancias, consultas, clases, propiedades, métodos, parámetros de entrada y de salida necesarios para construir sentencias específicas WQL. Aunque también podemos disponemos de una zona de scripting para VBScript y Powershell.

WMI Explorer permite también conectarse a equipos remotos de una red de dominio que tengan el servicio WMI habilitado y permisos para la administración y acceso remoto WMI control.

En mi caso hice uso de esta herramienta para extraer los namespaces y propiedades WMI para consultas sobre el servicio DNS que posteriormente usé para realizar Queys en SCCM (System Center Configuration Manager).

Un ejemplo del resultado de una consulta WQL conectándose a un equipo remoto del dominio.

Figura 3: WMI Explorer - Ejemplo de consulta WQL en equipo remoto.

Búsqueda en una máquina local de propiedades recusivamente con el criterio "DNS".

Figura 4: WMI Explorer - Búsqueda de clases, propiedades namespaces, etc. en base un criterio de búsqueda.

Métodos encontrados en una clase concreta, parametros de entrada y parámetros de salida.

Figura 5: WMI Explorer - Resultado de clases, métodos y parámetros.

Ejecución de script VBScript o Powershell en texto o command promt en referencia a la clase y métodos encontrados.

Figura 6: WMI Explorer - Ejeción de scripting VBScript o Powershell en clases y métodos WMI.

Conclusiones

Es una herramienta en la que de la que se puede extraer mucha información y ayudarnos en la elaboración de consultas WQL y recolección de la información ordenada de una máquina local o remota.

Ejemplo de uso: https://devblogs.microsoft.com/scripting/weekend-scripter-the-wmi-explorer-tool

Saludos!

Ejecutar WMIC en equipos remotos de la red local (Windows Management Instrumentation)

Si nos surgen problemas para la ejecución sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.

Un error puede ser que no esté habilitado las llamadas a procedimientos remotos (RPC).

Error:
Descripción = El servidor RPC no está disponible.

Figura 1: Error - "El servidor RPC no está disponible" (wmic).

Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos.

Error:
Descripción = Acceso denegado.

Figura 2: Error - "Acceso denegado" (wmic).

Comprobar que el servicio "Instrumental de administración de Windows" (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución.

Figura 3: Servicios winmgmt (wmic) en Windows.

Habilitar la regla por aplicaciones permitidas del firewal (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo cada caso si se trata de una red privada o de dominio.

Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI.

Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se uno al dominio.

Figura 5: Activar el uso de recurso compartido de archivos e impresoras.

Comprobar que en la consola del equipo remoto haya permisos suficientes para el usuario que ejecutará wmic.

Esto se puede modificar en la consola de Microsoft "wmimgmt.msc", en la pestaña de seguridad, se modifican los permisos para permitir la "Llamada remota habilita" y "Ejecutar métodos".

Figura 6: Permisos de seguridad al Control WMI.

Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows "LocalAccountTokenFilterPolicy" algo ya comentado en este artículo.

Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro.

Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo se detalla como hacerlo.

El valor LocalAccountTokenFilterPolicy se trata básicamente de "deshabilitar" el UAC (User Account Control) para la ejecución de acciones remotas.

Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD:

reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /f

En el siguiente ejemplo se puede ver como se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando "wmic /node", especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota.

wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber

Figura 7: Ejecución remota de "wmic /node".

Saludos!

Ejecutar una CMD en un equipo remoto con psexec

Esto es algo que suelo utilizar en muchos casos cuando los servicios para administraciones remotas que necesito en ese momento no están habilitados en el equipo remoto.

O bien me conecto con este tip para ejecutar una CMD en el equipo remoto y habilitar los servicios que sean necesarios para posteriormente administrar el equipo remoto de forma más cómoda a través del registro remoto (regedit) o los snap-ins MSC (administrador de dispositivos, impresoras, firewall, servicios, etc.) de administración remota añadidos a través de una MMC (Microsoft Management Console).

Como levantamos una CMD con privilegios administrativos ya sea de un administrador local o de dominio podemos ejecutar acciones remotas mediante la consola, "netsh" para la administración de redes o Firewall, "sc" para servicios, "reg" para la manipulación de entradas del registro, "wmic" instrumental de administración de Windows, etc. Aunque como comentaba anteriormente es más cómodo invocar las propias consolas de administración remotas MSC de Microsoft.

Para esto será necesario descargar psexec, parte de la colección de herramientas de Sysinternals de Microsoft.

Haciendo uso de PsExec ejecutamos lo siguiente en una CMD con privilegios de nuestro equipo local.

psexec \\EquipoRemoto -u UserAdmin -p Password cmd.exe

• EquipoRemoto: nombre o IP del equipo remoto al que nos queremos conectar.
• UserAdmin: usuario con privilegios de administrador local o de dominio sobre la máquina remota.
• Password: Passoword del usuario establecido anteriormente.
• Seguidamente indicamos la aplicación a ejecutar de forma remota, en este caso sería una CMD remota, por lo tanto "cmd.exe" o indicar la ruta absoluta para este binario o el que sea. "C:\Windows\System32\cmd.exe"
• Con el parámetro psexec /i indicamos una interacción GUI con ventana del equipo remoto. "C:\Windows\regedit.exe", etc.

Podemos usar el parámetro -h para ejecutar el token de elevación si en el sistema remoto tiene habilitado el UAC. Y el parámetro -s cmd.exe para ejecutar el proceso remoto en la cuenta del sistema.

En la siguiente captura se puede ver un ejemplo y una comprobación consultando las IPs y un whoami de como realmente estamos estamos dentro del equipo remoto.

Figura 1: Ejecución de una CMD en un equipo remoto con psexec.

En el caso de que obtengamos un error de acceso denegado, comparto el siguiente artículo como referencia para realizar la configuración previa WinRM.

• https://www.zonasystem.com/2019/01/ejecutar-wmic-en-equipos-remotos-de-la-red-local-windows-management-instrumentation.html.

Saludos!

Administrar los permisos de un servicio de Windows sobre un objeto

Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows.

Con los permisos NTFS de Windows podemos gestionar las DACL (Discretionary Access Control List) son lista de control de acceso discrecional en las que se pueden controlar quien es el propietario de un objeto y especifica quién tiene permiso y quién no para acceder a dicho objeto.

Sabemos que se pueden conceder DACL a usuarios locales del sistema, de un dominio, equipos o grupos de usuairos sobre uno o varios objetos (ficheros, carpetas o unidades).

¿Se pueden administrar estos permisos a objetos para un servicio de Windows o de terceros?

Si. Se pueden asignar uno o varios servicios a uno o varios objetos de Windows y establecer permisos sobre ellos. Lo que pasa que no se puede hacer una forma gráfica amigable ni de manera trivial como pasa con los usuarios.

Para conceder permisos a un objeto es necesario conocer el SID (Security Identifier) del usuario, equipo, grupo, etc. Que se va asignar a ese objeto. Por ejemplo en el caso de Windows, buscando el nombre de un usuario y asignándolo a un objeto sería suficiente para administrar las DACL de ese usuario sobre un objeto. De forma subyacente el sistema está reconociendo un SID asociado a ese usuario.

Los SID de los usuarios locales de un equipo se registran en la siguiente rama del registro de Windows.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProfileList

Hay otras formas de conocer los SID de usuarios locales así como también usuarios de dominio y equipos. Para conocer estos SID podemos usar WMIC (Windows Management Instrumentation Command-line).

Para listar todos los usuarios locales filtrando por nombre de usuario y SID.

wmic useraccount get name,sid

Igual que lo anterior pero filtrando un nombre de usuario en concreto.

wmic useraccount where (name='USUARIO') get name,sid

Lo mismo pero para usuarios que pertenezcan a un dominio.

wmic useraccount where (name='USUARIO' and domain='DOMINIO') get name,sid

Con PsGetSid (de Sysinternals) para listar los SID de usuarios locales de equipos remotos y el propio SID de la máquina locales y otras remotas. Para ejecutar cualquier herramienta PsTools de forma remota tendremos que conocer las credenciales de un administrador local o de dominio en la máquina remota.

Comentado todo lo anterior vamos a ver como podemos agregar un servicio a un objeto y gestionar sus permisos.

Lo primero que tenemos que averiguar es el nombre asignado a un servicio. Ya sea de Windows o de una aplicación de terceros la forma de conocerlo sería la misma.

En este caso de ejemplo usaré el servicio de Dropbox para Windows. Abrimos una consola de servicios (services.msc) y buscamos el servicio que queremos utilizar. Cuando abrimos el servicio vemos el apartado "Nombre del servicio" será ese el que usaremos.

Figura 1: Nombre del servicio Dropbox para Windows (DbxSvc).

Para conocer su SID asignado por Windows a un servicio usaremos la herramienta de comandos de Windows SC (Service Controller).

sc showsid DbxSvc

Figura 2: Conocer el SID asignado a un servicio de Windows con SC.

Ahora solo quedaría asociar ese SID a un objeto. De forma gráfica perosnalmente no encontré forma de hacerlo, pero si por la herramienta de comandos de Windows ICACLS. Con la que podemos mostrar y gestionar las listas de control de acceso discrecional (DACL) de un objeto.
En este caso agregaremos a la carpeta llamada "test" (que será el objeto) el servicio de Dropbox mediante el SID obtenido anteriormente.

icacls c:\test /grant *S-1-5-80-315955965-2752282644-3851734118-3415690430-1520210413:(f)

Figura 3: Agregando un servicio a un objeto con ICACLS

Ahora vemos como el servicio DbxSvc ya está integrado en el objeto y podremos manipular los permisos de forma gráfica. 

Figura 4: Administrando de forma gráfica los permisos de un servicio agregado a un objeto.

Saludos!

Desinstalar software local o remoto a través de una CMD de Windows

Recientemente buscando la forma de poder desinstalar aplicaciones de forma local y remota solo haciendo uso a través de una shell de Windows Command Prompt. Encontré una forma de poder hacerlo de forma muy fácil y sin hacer uso de tools externas.

Para poder hacer esto haremos uso de la herramienta de comandos WMIC ("Windows Management Instrumentation Command-line"), integrada en Windows 7. Deberemos tener iniciado el servicio WMI de Windows, podremos iniciarlo de forma rápida abriendo una consola con privilegios y escribiendo: net start winmgmt.

Para poder desinstalar una aplicación de un equipo remoto de la red o un dominio, podemos hacer uso de PsExec, una herramienta de linea de comandos incluida en la suite PSTools de la cual ya había comentado en este blog como descargarla y usarla.

Una vez descarga en nuestro equipo local, simplemente tendríamos que ejecutar una CMD de un equipo remoto con PsExec y seguir el procedimiento como si fuese un equipo local, ya que esa CMD es la que equipo remoto al que nos conectamos.

En una CMD de nuestro equipo local escribimos:

psexec \\EquipoRemoto -u UserAdmin -p Password cmd.exe

Donde: EquipoRemoto es el nombre o IP del equipo remoto al que nos queremos conectar, UserAdmin sería un usuario con privilegios de administrador y Password es la contraseña del usuario UserAdmin, acto seguido indicamos la aplicación a ejecutar de forma remota, que para este caso usaremos cmd.exe.

En este ejemplo escogí la aplicación "Passware Kit Enterprise 9.7" para desinstalarla de forma local, pero como ya dije el procedimiento sería el mismo para un equipo remoto una vez tengamos iniciada la consola cmd del equipo remoto en cuestión.

[1] - Como podemos ver la aplicación que quiero desinstalar se visualiza en Progamas y características del Panel de Control de Windows. (esto en el caso de hacerlo de forma local).

Figura 1: Passware Kit Enterprise 9.7 se visualiza instalado en "Programas y características".

[2] - Abrimos una CMD local con altos privilegios administrativos (Tecla Windows+R: escribimos cmd.exe). Una vez abierta escribimos en consola: wmic, y accedemos al modo interactivo del comando, que se nos mostrará con el siguiente prompt: wmic:root\cli>, seguidamente escribimos:

product get name

Para mostrar la lista de aplicaciones instaladas en el equipo y reconocibles.

Nota: Si queremos mostrar más información, como el proveedor y la versión del producto a desinstalar, podemos usar la siguiente sintaxis.

node:HOSTNAME product get name,version,vendor

Donde "HOSTNAME" es el nombre del equipo local. Aunque si habíamos accedido por una cmd.exe remota a otro equipo, será el nombre del equipo remoto.

En este caso para simplificar e usando la primera sintaxis mencionada.
Vemos como se aparece la aplicación que quiero desinstalar, en este caso Passware Kit Enterprise 9.7.

Figura 2: Lista del software instalado en el equipo. (vemos que se muestra Passware Kit Enterprise 9.7).

[3] - Para desinstalar dicha aplicación escribimos:

product where name="NombreExactoDeLaAplicacion" call uninstall

Donde: NombreExactoDeLaAplicacion, es el nombre tal cual se muestra en la lista de aplicaciones (respetando mayúsculas, minúsculas y espacios).
Nos preguntará si estamos seguros de desinstalar la aplicación, presionamos la letra Y para confirmar.

Para verificar que realmente se desinstaló podemos, listar de nuevo las aplicaciones hasta ver que no aparece en la lista o nuevamente desinstalar la aplicación ya desinstalada, en este caso nos mostrará que "No hay instacias disponibles" lo que ya nos da a entender que se desinstaló de nuestro sistema.

Figura 3: Seleccionamos Passware Kit Enterprise 9.7 y lo desinstalamos, después comprobamos que se desinstaló.

[4] - Por último podemos hacer una última comprobación en Programas y características del Panel de control de Windows y comprobar que no se visualiza. (esto en el caso de hacerlo de forma local).

Figura 4: Finalmente comprobamos en "Programas y características" que Passware Kit Enterprise 9.7 ya no se visualiza.

Esta desinstalación es exactamente igual que hacerlo de forma gráfica, es decir que esto, nos tendría más utilidad para llevar a cabo desinstalaciones a equipos remotos de forma subyacente al usuario final, a nivel administrativo.

Para hacer esto de forma no interactiva sin entrar en la consola de WMIC. Podemos usar el parámetro /nointeractive.

Un ejemplo sería. Para listar todos los productos de "Adobe Acrobat" que tengamos instalados en el sistema y desinstalarlos todos de golpe de forma no interactiva.

wmic /node:COMPUTERNAME product where "name like 'Adobe Acrobat%'" call uninstall /nointeractive

Si estamos en un modo interactivo podemos usar solamente product where "name like 'Adobe Acrobat%'" para obtener previamente el listado y no desinstalarlo.

Respecto a si es una desinstalación más o menos limpia, eso dependerá del proceso de programación que tenga software de fabricante dado. Habrá aplicaciones que se desinstalen completamente, sin dejar rastros de carpetas ni rastros en el registro de Windows y habrá otras que no.

Por último, decir que en ocasiones puede que la lista de aplicaciones mostradas no sean todas las que realmente están instaladas en el equipo. Ya que habrá casas comerciales u otros factores que harán que impidan que se listen con WMIC. Con lo cual aquí aconsejo realizar esto por directivas GPO.

Saludos!