Hyper-V: Conectar una maquina virtual a otro VMSwitch con PowerShell

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:

PS C:\Users\Administrador> New-VMSwitch -Name vmswitch_prod -NetAdapterName "Ethernet0" -AllowManagementOS $true

Name          SwitchType NetAdapterInterfaceDescription
----          ---------- ------------------------------
vmswitch_prod External   Intel(R) 82574L Gigabit Network Connection

Finalmente, conectamos el adaptador de la máquina virtual al VMSwitch nuevo con el cmdlet Connect-VMNetworkAdapter y verificamos:

PS C:\Users\Administrador> get-vm -Name vm1 | Get-VMNetworkAdapter | Connect-VMNetworkAdapter -SwitchName vmswitch_prod
PS C:\Users\Administrador> get-vm -Name vm1 | Get-VMNetworkAdapter

Name             IsManagementOs VMName SwitchName    MacAddress   Status IPAddresses
----             -------------- ------ ----------    ----------   ------ -----------
Adaptador de red False          vm1    vmswitch_prod 00155D581500 {Ok}   {}

Leer mas

PowerShell: Cambiar el tipo de perfil de red en Windows

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:

PS C:\Windows\system32> Get-NetConnectionProfile

Name             : Unidentified network
InterfaceAlias   : vEthernet (Default Switch)
InterfaceIndex   : 10
NetworkCategory  : Public
IPv4Connectivity : NoTraffic
IPv6Connectivity : NoTraffic

Name             : Network 18
InterfaceAlias   : vEthernet (Ether-wifi)
InterfaceIndex   : 15
NetworkCategory  : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

2-) Utilizando el InterfaceIndex que obtuvimos en el paso anterior, modificamos al tipo de perfil deseado (Las opciones son Private, Public y Domain):

PS C:\Windows\system32> Set-NetConnectionProfile -InterfaceIndex 10 -NetworkCategory Private
PS C:\Windows\system32> Get-NetConnectionProfile



Name             : Unidentified network
InterfaceAlias   : vEthernet (Default Switch)
InterfaceIndex   : 10
NetworkCategory  : Private
IPv4Connectivity : NoTraffic
IPv6Connectivity : NoTraffic


Name             : Network 18
InterfaceAlias   : vEthernet (Ether-wifi)
InterfaceIndex   : 15
NetworkCategory  : Private
IPv4Connectivity : Internet
IPv6Connectivity : NoTraffic

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:

PS C:\Windows\system32> Enable-PSRemoting -Force -SkipNetworkCheck

Leer mas

PowerShell: Determinar el historial de membresias de grupo en Active Directory

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.

PS C:\Users\Administrador>
PS C:\Users\Administrador> $username = "juan"
PS C:\Users\Administrador> $userobj  = Get-ADUser $username
PS C:\Users\Administrador>
PS C:\Users\Administrador> Get-ADUser $userobj.DistinguishedName -Properties memberOf |
>>  Select-Object -ExpandProperty memberOf |
>>  ForEach-Object {
>>     Get-ADReplicationAttributeMetadata $_ -Server localhost -ShowAllLinkedValues |
>>       Where-Object {$_.AttributeName -eq 'member' -and
>>       $_.AttributeValue -eq $userobj.DistinguishedName} |
>>       Select-Object FirstOriginatingCreateTime, Object, AttributeValue
>>     } | Sort-Object FirstOriginatingCreateTime -Descending

FirstOriginatingCreateTime Object                                               AttributeValue
-------------------------- ------                                               --------------
6/7/2019 17:48:59          CN=Administradores clave,CN=Users,DC=seclab,DC=local CN=juan,CN=Users,DC=seclab,DC=local


PS C:\Users\Administrador> 

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

Leer mas

Transferir archivos con PowerShell usando WinRM

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:

Copy-Item -Path "C:\Tools" -Destination "\\FILESERVER\C$" -Recurse

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:

$FileSession = New-PSSession –ComputerName FILESERVER

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:

Copy-Item –Path "C:\Tools" –Destination 'C:\' –ToSession $FileSession -Recurse

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:

$FileSession | Remove-PSSession

Leer mas

Solución al error de autenticación en conexión a Escritorio remoto "Oracle/CredSSP"

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.

Via gpedit.msc:

Vía regedit:

PS C:\Users\Administrator> reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters" /f /v AllowEncryptionOracle /t REG_DWORD /d 2
The operation completed successfully.

PS C:\Users\Administrator>

Luego de parchear los servidores, lo recomendable es revertir el cambio para no dejar el sistema expuesto al robo de credenciales.

Leer mas

Paso a paso: Administración remota de Hyper-V en grupos de trabajo

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:

Set-NetFirewallRule -DisplayGroup 'Windows Management Instrumentation (WMI)' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Event Log Management' -Enabled true -PassThru
Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

Habilitar CredSSP en el servidor:

PS C:\Users\Administrator> Enable-WSManCredSSP -Role Server -Force

Configuración en el cliente

Habilitar el servicio winrm y añadir el host HYPER-V a los equipos de confianza del cliente:

PS C:\Windows\system32> winrm quickconfig
WinRM service is already running on this machine.

PS C:\Windows\system32> winrm set winrm/config/client '@{TrustedHosts="hyperv"}'
Client
    NetworkDelayms = 5000
    URLPrefix = wsman
    AllowUnencrypted = true [Source="GPO"]
    Auth
        Basic = true
        Digest = true
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = true
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    TrustedHosts = hyperv

PS C:\Windows\system32>

Al igual que en el servidor, en el cliente necesitamos una regla de firewall para permitir la administración remota de volúmenes:

Set-NetFirewallRule -DisplayGroup 'Remote Volume Management' -Enabled true -PassThru

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:

Leer mas