Mostrando entradas con la etiqueta microsoft. Mostrar todas las entradas
Mostrando entradas con la etiqueta microsoft. Mostrar todas las entradas

martes, 16 de julio de 2019

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}   {}

sábado, 6 de julio de 2019

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

lunes, 8 de abril de 2019

Explorando la red con PowerShell: Escaneo de puertos TCP y barridos ping

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)


PS C:\> 1..254 | % {echo "192.168.88.$_"; ping -n 1 -w 100 192.168.88.$_} | Select-String ttl

Respuesta desde 192.168.88.1: bytes=32 tiempo=2ms TTL=64
Respuesta desde 192.168.88.214: bytes=32 tiempo=2ms TTL=64
Respuesta desde 192.168.88.229: bytes=32 tiempo<1m TTL=128

PS C:\>

Escaneo de puertos TCP

Para probar si un puerto TCP está abierto, podemos usar el cmdlet Test-NetConnection

PS C:\> foreach ($ip in 1..254) {Test-NetConnection -Port 80 -InformationLevel "Detailed" 192.168.88.$ip}



ComputerName            : 192.168.88.1
RemoteAddress           : 192.168.88.1
RemotePort              : 80
NameResolutionResults   : 192.168.88.1
MatchingIPsecRules      :
NetworkIsolationContext : Private Network
InterfaceAlias          : vEthernet (Ether-wifi)
SourceAddress           : 192.168.88.229
NetRoute (NextHop)      : 0.0.0.0
TcpTestSucceeded        : True


ADVERTENCIA: TCP connect to (192.168.88.2 : 80) failed
ADVERTENCIA: Ping to 192.168.88.2 failed with status: TimedOut

ComputerName            : 192.168.88.2
RemoteAddress           : 192.168.88.2
RemotePort              : 80
NameResolutionResults   : 192.168.88.2
MatchingIPsecRules      :
NetworkIsolationContext : Private Network
InterfaceAlias          : vEthernet (Ether-wifi)
SourceAddress           : 192.168.88.229
NetRoute (NextHop)      : 0.0.0.0
PingSucceeded           : False
PingReplyDetails (RTT)  : 0 ms
TcpTestSucceeded        : False


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.

sábado, 23 de marzo de 2019

Nuevos requisitos para la certificacion Azure Administrator Associate

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.

Examinando la alineación de los tópicos de los examenes AZ-100 y AZ-101 con los del nuevo examen AZ-103, se observa que el nuevo examen ya no cubre Logic Apps, Azure Functions, App Service, Azure Site Recovery ni Azure Migrate. Presumo que esos tópicos se moverán a algún otro rol intermedio que se anuncie a futuro, o bien estarían incluidos únicamente en el path de Microsoft Certified Azure Solutions Architect Expert.