Auditar la el historial de actividad de PowerShell es algo que puede venir útil en caso de incidentes de seguridad o con fines de documentación. En este post, se muestra como habilitar una transcripción detallada de la actividad de PowerShell mediante directivas de grupo.
En una nueva directiva de grupo, ir a "Configuración del equipo > Directivas > Plantillas Administrativas > Componentes de Windows > Windows Powershell" y seleccionar "Activar la transcripción de Powershell". Aquí debe habilitarse la política y seleccionar un directorio donde se guardaran las transcripciones.
Despues de un gpupdate /force para forzar la aplicación de la nueva política, podemos probar si la nueva configuración está en efecto corriendo un comando de PowerShell:
Y finalmente revisar que los comandos ingresados esten siendo registrados en el directorio especificado:
Eso es todo, en otro post se mostrará como utilizar Start-Transcript para registrar los comandos de una sesión individual.
Para conectar una máquina virtual a un VMSwitch distinto al que tiene asignada o asignarle uno por primera vez en caso de que no este conectada, se puede seguir el siguiente ejemplo. En primer lugar, verificar a que switch virtual está conectada la VM (si es que tiene alguno asignado):
PS C:\Users\Administrador> get-vm-Name vm1 | Get-VMNetworkAdapter
Name IsManagementOs VMName SwitchName MacAddress Status IPAddresses
---- -------------- ------ ---------- ---------- ------ -----------
Adaptador de red False vm1 00155D581500 {Ok} {}
En este caso se ve que el adaptador de esta VM no está conectado a ningún switch virtual. Como este servidor aún no tiene ningún VMSwitch, empiezo verificando las interfaces físicas disponibles en el equipo:
PS C:\Users\Administrador> Get-NetAdapter
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
Ethernet0 Intel(R) 82574L Gigabit Network Conn... 4 Up 00-0C-29-F7-C4-22 1 Gbps
vEthernet (int_switch) Hyper-V Virtual Ethernet Adapter 12 Up 00-15-5D-58-15-01 10 Gbps
En este servidor la interfaz física Ethernet0 está libre, con el siguiente comando creo un VMSwitch asociado a la misma:
En ocasiones, al tratar de configurar WinRM para conexiones remotas con PowerShell, recibimos un error debido a que PowerShell considera inseguro realizar conexiones sobre una red pública. Para resolver esto es necesario modificar el perfil de red que Windows asigna a los adaptadores de red, a continuación se muestra como hacer este cambio.
1-) Identificar el adaptador de red cuyo perfil necesitamos modificar:
Como alternativa, podría usarse el parametro SkipNetworkCheck al habilitar el PSRemoting para que se ignore el tipo de perfil establecido en el adaptador de red:
Hay ocasiones en donde es necesario conocer en que momento un usuario fué agregado a un grupo, en estos casos, esta información puede extraerse de Active Directory gracias a ciertos atributos existentes en los metadatos de replicación.
Como se ve en la salida del script anterior, con esto puede determinarse en que fecha un usuario fué agregado a uno o mas grupos. Podría ser que necesitamos esa información con fines forenses, o bien para determinar que membresias de grupo podrían ser reducidas en caso de que algún usuario experimente problemas de "token bloat". El script es una colaboración de Ashley McGlone, ex Premier Field Engineer de Microsoft, aquí puede verse el articulo original.
Por último vale mencionar que ademas de funcionar con cuentas de usuario, puede utilizarse con cuentas de equipos, sustituyendo Get-ADUser por Get-ADComputer
A continuación comparto una recopilación de algunos comandos útiles a la hora de explorar la red utilizando PowerShell.
Barridos ping
Para descubrir todos los hosts activos de una red de forma rápida podemos realizar un barrido ping o ICMP. En este ejemplo se usa un operador de rango para hacer ping a todas las IP's de una red /24 y del resultado filtramos los que contienen la linea TTL, que son los que nos interesan (esto excluye las IP's que respondieron con tiempo de espera agotado)
El comando anterior arroja resultados muy verbose para mi gusto, la siguiente alternativa facilita probar un rango de puertos y da como resultado una salida mas limpia:
PS C:\> 1..1024 | % { echo ((new-object Net.Sockets.TcpClient).Connect("192.168.61.1",$_)) "$_ is open" } 2>$null
22 is open
80 is open
443 is open
PS C:\>
Eso es todo. En una próxima entrada analizaremos opciones para probar puertos UDP con PowerShell.
Mover archivos con PowerShell es sencillo siempre que tengamos acceso vía SMB al servidor remoto. Por ejemplo, para copiar la carpeta "C:\Tools" y todo su contenido (-Recurse) al servidor FILESERVER por SMB, basta con el siguiente comando:
El comando asume que las credenciales utilizándose son válidas en el equipo remoto. En caso de que el servidor no tenga habilitado el SMB, puede lograrse lo mismo mediante WinRM. Los requisitos son los siguientes:
PowerShell 5.0 en el equipo local y en el remoto
WinRM debe estar habilitado (Viene configurado por defecto desde Windows Server 2012 en adelante, en caso de que esté deshabilitado puede habilitarse con Enable-PSRemoting -Force)
Los puertos 5985 (HTTP) y 5986 (HTTPS) deben estar habilitados.
Ambos equipos deben estar en dominio. Si la estación de trabajo desde donde se está administrando el servidor está en un grupo de trabajo, seguir las siguientes instrucciones.
Primero, crear una sesión remota y guardarla dentro de una variable:
El comando es muy similar al anterior, el único cambio es que en este caso utilizamos el parametro ToSession y le pasamos la variable de la sesión creada previamente:
A pesar de ser similar al comando anterior, esta vez la transferencia se realizó vía WinRM. Una vez terminada la transferencia, es buena practica remover la sesión que creamos:
La semana pasada pasé el examen AZ-100: Microsoft Azure Infrastructure and Deployment que en ese momento era uno de los dos examenes necesarios para obtener la certificación Microsoft Certified: Azure Administrator Associate. Habiendo ya agendado el siguiente exámen, el AZ-101: Microsoft Azure Integration and Security, se anuncia en el blog Born to Learn un camino simplificado para esta certificación en el cual solo se requiere pasar solo un examen para obtener esta certificación. Por fortuna, el equipo de Microsoft Learning tomó algunas decisiones para hacerse cargo de las inconveniencias que puedan tener las personas que ya estaban siguiendo este track:
Los que ya pasaron el examen AZ-100, obtendran automáticamente la certificación Microsoft Certified: Azure Administrator Associate a partir del 1 de mayo del 2019.
Los que ya tomaron el examen AZ-101, hayan pasado o no, recibiran un voucher para tomar cualquier examen de Microsoft que se imparta a traves de Pearson VUE.
Las actualizaciones de Mayo del 2018 trajeron sorpresas para los administradores de entornos donde las conexiones RDP dejaron de funcionar repentinamente. Microsoft publicó un articulo donde detalla el alcance de la vulnerabilidad de CredSSP cuyos parches trajeron consigo este inconveniente que se presenta principalmente en los casos donde el cliente ya tiene las actualizaciones de 05/2018 y el servidor aún no cuenta con las mismas.
El error que se presenta al intentar conectarse desde un cliente actualizado a un servidor sin el parche es el siguiente:
An authentication error occurred. The function requested is not supported.This could be due to CredSSP encryption oracle remediation
Error de autenticacion. No se permite la funcion solicitada.Puede deberse a una actualizacion de Oracle de cifrado CredSSP
Desde luego la solución mas recomendable es aplicar la actualización en clientes y servidores que se manejaran vía RDP, pero en casos donde es imperioso acceder a un servidor que aún no esta parchado es posible cambiar el comportamiento del cliente para que ignore la vulnerabilidad utilizando políticas de grupo o directamente modificando el registro, el cambio requiere un reinicio para tomar efecto.
Para administrar remotamente un servidor Hyper-V en casos donde la estación de trabajo o el servidor están en un grupo de trabajo, deben realizarse algunas configuraciones previas que detallo en esta entrada.
Configuración en el servidor Hyper-V
Habilitar la administración remota:
PS C:\Users\Administrator> Configure-SMRemoting.exe -Enable
Server Manager Remoting is now enabled: Enabled remote access.
PS C:\Users\Administrator>
Crear las reglas de firewall necesarias para la administración remota:
Agregar el hostname y dirección IP del servidor al archivo C:\Windows\System32\Drivers\etc\hosts
Modificar la política de seguridad local (gpedit.msc) para permitir delegación de credenciales (agregar wsman/* en la lista de servidores para poder administrar cualquier servidor remoto):
Configurar las opciones de seguridad COM con la utilidad ubicada en C:\Windows\System32\dcomcnfg.exe, aquí debemos permitir el acceso remoto para anonymous logon:
Comprobamos la conectividad al servidor Hyper-V remoto, en este caso utilizando credenciales alternativas:
Una nueva característica de Hyper-V en Windows Server 2016 es la de virtualización anidada o nested virtualization, que nos permite ejecutar un hipervisor como ESX o KVM dentro de un guest de Hyper-V. Este feature muy útil para ambientes de laboratorio se habilita por máquina virtual con el comando Set-VMProcessor sobre la VM apagada.
Para comprobar si la virtualización anidada ya esta habilitada en una VM utilizar Get-VMProcessor:
Como la mayoria de los features disponibles en Hyper-V corriendo sobre Windows Server 2016, la virtualización anidada también puede utilizarse en Windows 10 con Hyper-V. Esto requiere Windows 10 versión 1607 en adelante.
En un servidor corriendo Windows Server 2003 que debía montar unas unidades de red NFS, me topé con el siguiente caso:
Al intentar mapear un NFS export desde el explorador de Windows se recibe el error “Network Path not found”. Lo mismo sucede con los comandos net use y mount.
Si ahí terminara la cosa, sería una buena justificación para culpar al NFS, pero lo mas raro es el otro síntoma:
Al escribir la ruta de red desde el menú ejecutar, se puede acceder al export NFS correctamente, aunque se siente algo de lentitud al recorrer directorios o copiar archivos.
Las primeras pruebas realizadas -sin éxito- fueron tan básicas como crear un nuevo perfil de usuario y verificar que el servicio "Estación de trabajo" esté iniciado. Luego de algunas búsquedas de problemas similares, intenté verificar la negociación de versión de NFS y descartar alguna que algún recurso NFS accedido anteriormente haya dejado una configuración residual de AnonymousUID o AnonymousGID en el registro. Llegué a intentar soluciones tan desesperadas como tratar de engañar al Windows con un enlace simbólico al NFS.
Ejecuto Process Monitor y dejo corriendo las trazas sin filtros, intento montar con net use el NFS share y con la función find de Process Monitor busco la cadena de texto correspondiente a la dirección IP del servidor NFS. Aquí encuentro la primera pista útil, en el path que llama el proceso explorer puede verse una cadena de texto extraña en la ruta del export NFS, con un resultado de BAD_NETWORK_NAME.
Comparando esta traza con otra tomada en un sistema que funciona correctamente se comprueba que desde luego, esa cadena de texto es completamente anormal. Otra busqueda revela que RDPNP, que es el lo que se agrega al path del NFS, es un proveedor de red controlado por la librería mpr.dll (Multiple Provider Router):
The Multiple Provider Router (MPR) handles communication between the Windows operating system and the installed network providers. It enables Windows to present an integrated network to the user.When the MPR starts, it checks the registry to determine which network providers are installed on the system and the order they should be cycled through. It loads all registered network provider DLLs and uses them to process subsequent WNet calls made by the user interface or other applications.
Curioso por conocer la evidente diferencia entre los mecanismos para acceder a un recurso de red mediante net use y acceder mediante el menú ejecutar, y ya con la librería mpr.dll ya en la mira, le dí una revisión al libro de Mark Russinovich "Windows Internals: 6th Edition", un libro "viejo" para los estándares de los libros de IT (Basado en Windows Vista y Server 2008), pero aún así vigente en su mayor parte. El siguiente diagrama muestra que hay dos vías para llegar a un recurso de red NFS, via el Multiple Provider Router o vía User Mode.
Esto explica porque es posible acceder al NFS share vía el menú ejecutar pero no es posible montarlo, pero aún no resuelve el problema. El siguiente paso fué un sfc /scannow seguido de una verificación del hash del archivo mpr.dll y posteriormente compararlo con el mismo archivo en otro servidor funcional. También se compararon permisos entre ambos archivos, lectura y ejecución, todo se ve normal en el archivo en sí.
Paso al registro, toca revisar los Network Providers, estos son unos mini-redirectores proveídos por Microsoft o terceros para acceder a servicios de Red como SMB, NFS, Unidades compartidas mediante Terminal Server y WebDav, estos redirectores están seteados en la clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder, usualmente deben verse como en la siguiente imagen:
En el sistema afectado esta clave tiene un solo provider, correspondiente al componente SnacNP del fabricante Symantec:
Mientras que en otro sistema funcional se ve que el SnacNP se antepone a los demas providers:
Al intentar desinstalar el software encuentro que el mismo ya no está presente en el sistema, lo cual es bueno, pero evidentemente su instalación/desinstalación fue errática, ya que cuando fue instalado el SnacNP de Symantec sobrescribió completamente el valor existente en este sistema, en lugar de simplemente agregar la cadena de texto necesaria.
Otra curiosidad es que al intentar agregar los providers manualmente desde Centro de Redes y Recursos Compartidos > Configuración del Adaptador > Configuración avanzada, había una pestaña ausente:
Mientras que en un servidor sano vemos lo siguiente:
Finalmente el problema se corrigió editando el registro y agregando las cadenas faltantes (LanmanWorkstation, RDPNP y Nfsclientnp) al registro. Con esto ya apareció la pestaña de Network Providers que no se veía anteriormente, se logró montar la unidad NFS y la performance del recorrido por los directorios mejoró notablemente.
Por último, dejo algunos enlaces interesantes sobre el uso de las herramientas de sysinternals para troubleshooting en Windows:
Hace unos días Microsoft anunció que el Subsistema de Windows para Linux ya salió de version beta. Esta característica, que estaba disponible para usuarios de Windows Insider ya desde el año pasado, pasa ahora a ser un feature estable que estará disponible en los releases generales del sistema operativo.
Antes de instalar el feature, debemos verificar que nuestra versión de Windows es la 1607 en adelante, desde Configuración > Sistema > Acerca de, o desde PowerShell:
Luego del reinicio, en el Windows Store, hay 3 distribuciones de Linux que podemos elegir:
ubuntu
sles12
opensuse-42
Para instalar ubuntu desde PowerShell, ir a Configuración --> Actualización y Seguridad --> Para programadores y elegir Modo de programador. Luego de esto, con el comando bash se iniciará la descarga de ubuntu. Al finalizar la descarga, deben configurarse las opciones regionales y el nombre de usuario.
Si se presenta algún problema durante la instalación desde el Windows Store, este articulo de MSDN recopila los problemas mas comunes que se presentan y como solucionarlos.
En Windows Server 2016, Microsoft introdujo una nueva característica de Failover Clustering disponible exclusivamente para el rol Hyper-V. Se trata de Node Fairness, una funcionalidad pensada para mantener balanceada la carga de los nodos del cluster redistribuyendo maquinas virtuales cuando detecta que algún nodo esta sobrecargado. Las maquinas virtuales se mueven a nodos con menor carga mediante migraciones en vivo y por lo tanto sin disrupción de servicios.
El feature viene activo por defecto y ya sea mediante Powershell o la consola de Failover Cluster Manager, puede desactivarse, configurar cuando entrará en acción y ajustar la agresividad de la heuristica que utiliza el cluster para determinar cuando un nodo esta sobrecargado.
AutoBalancerLevel
Hay 3 niveles de agresividad para esta heuristica:
Como puede verse, AutoBalancerLevel esta por defecto establecido en 1, un valor bastante relajado, que indica que si la CPU o memoria llegan al 80% de uso deberá empezar a hacer migraciones en vivo de maquinas virtuales a otros nodos del cluster.
Para ajusta el valor de AutoBalancerLevel con PowerShell:
Otro valor configurable es AutoBalancerMode, que determina en que momentos se verificará la carga de trabajo de los nodos, por defecto viene establecido 2, lo cual hace uso de los nuevos nodos agregados al cluster para rebalancear la carga de VMs y también controla cada 30 minutos que ningún nodo este sobrecargado, de forma que si algún nodo del cluster falla y las maquinas virtuales migran a otros nodos, Node Fairness se encargará de corregir la distrubución de carga de VMs en los nodos sobrevivientes.
Para modificar estos valores desde la consola Failover Cluster Manager, en las propiedades del clúster, modificar las opciones de la pestaña equilibrador:
Salvo excepciones por necesidades específicas, la configuración por defecto es apropiada para la mayoría de los escenarios. Node Fairness respeta las políticas existentes de anti-affinity ypossible owners configuradas en el cluster.
Balanceo de VMs en Virtual Machine Manager
En un clúster manejado por VMM, Node Fairness se desactiva automáticamente en favor del feature Dynamic Optimization presente desde Virtual Machine Manager 2012, cuya funcionalidad es equivalente e incluso va un poco mas allá, permitiendo configurar que el balanceo ocurra en schedules establecidos por el administrador.
Recientemente estuve realizando un deployment del controlador SDNv2 de Microsoft Network Controller en un ambiente de pruebas, para esto utilice la plantilla de servicio para VMM disponible en el Github de Microsoft. La tarea terminaba con un warning e inspeccionando la consola de las 3 máquinas virtuales en todas aparecía el siguiente error:
Luego de otros intentos fallidos tratando de determinar si se trataba de que el VHD de Windows Server 2016 estuviese dañado, me fijé en un detalle mas básico que omití modificar en el template de VMM, la zona horaria establecida en la plantilla era distinta a la del Domain Controller del lab, y para complicar aún mas el escenario, el servidor VMM también tenía otra zona horaria. Luego de corregido este detalle el deployment del servicio finalizó correctamente. Si bien este no era mi caso, otra causa de este error podría ser que la cuenta especificada en la plantilla para unir el equipo al dominio no cuente con privilegios para hacerlo.
En otros casos donde el origen del error no sea tan evidente, puede montarse el VHD de la VM problemática y revisarse la ruta %WINDIR%\Panther\ para investigar que datos arroja el log del sysprep.
