Archivo de la etiqueta: wifi

Powershell Snippets: Obtener la MAC de la tarjeta WIFI de equipos en el AD

Hola a todos,

En ocasiones, hace falta obtener información específica sobre equipos del dominio. Por ejemplo, supongamos que por motivos estadísticos, es necesario sacar un listado de los equipos de una oficina que están encendidos en un momento determinado, y no sólo eso, sino que además se desea obtener la MAC de su interfaz Wi-Fi (para complicar el asunto).

En este caso, está claro que se va a utilizar el módulo de Active Directory de PowerShell, ya que hace falta obtener un listado de equipos. Y por otro lado, es necesario que haya un mecanismo que permita conectarse a las máquinas para acceder a la lista de interfaces de red, y poder leer las que nos interesen.

Afortunadamente, PowerShell dispone de todo lo necesario para llevar a cabo esta tarea. A continuación, un breve desglose con los cmdlets principales:

  • Get-ADComputer -Filter * -SearchBase “OU=Oficina,OU=Empresa,DC=Empresa,DC=com”
    Este cmdlet va a encargarse de obtener todos los equipos del dominio. Además, se especifica
  • get-wmiobject -class “Win32_NetworkAdapter” -computername $comp.DNSHostName -filter “NetConnectionID = ‘Wi-Fi’ ” -ErrorAction “Stop”
    Con este cmdlet se lanza una consulta WMI a los equipos obtenidos previamente, y se le aplica un filtro por el campo “Wi-Fi”. También se puede filtrar por “Ethernet”, o no filtrar en absoluto.
  • New-Object PSObject -prop @{Computer = $comp.DNSHostName; Adapter = $obj.Name; MAC=$obj.MACAddress}
    El último comando importante genera un objeto con los atributos “Computer”, “Adapter” y “MAC”, que se utiliza para crear un archivo CSV al final del script.

Hay una poderosa razón para que este script deba lanzarse desde la PowerShell de un usuario Administrador de Dominio: Se conecta a cada una de las máquinas para consultar su lista de interfaces y quedarnos con aquellas que tienen interfaz Wi-Fi. Si quien lo ejecuta no es administrador de dominio, no va a poder conectar con las máquinas, y por tanto, no podrá generar el listado.

Sin más dilación, aquí tenéis el código de la función.

Se puede pegar tal y como está en una consola de PowerShell e invocarla como un cmdlet cualquiera, o se puede integrar dentro de un módulo, o generar un script (copiando únicamente el código de la función). Las posibilidades son infinitas, sobre todo gracias a que se puede jugar con el cmdlet get-wmiObject para obtener una variedad de información casi ilimitada.

shell

Finalmente, y como un artículo sobre un script nunca queda completo si no incluye capturas de pantalla… aquí está una muestra del CSV resultado de la ejecución del script.

wifiMac

 

Happy Scripting!

Interferencias Wifi

El ritmo de trabajo y vida actual ha enfatizado el uso de tecnologías que nos permiten realizar nuestro trabajo o disfrutar de nuestro ocio con más libertad y comodidad. Todo esto ha sido gracias al desarrollo de las tecnologías inlámbricas. Pero, debido al uso indiscriminado de estas tecnologías en todo tipo de aparatos y al ancho del espectro empleado (que es limitado) podemos encontrarnos con diversos problemas.  Este es el caso de las redes Wifi. Entendamos un poco el asunto. El especto radioelectrico compone un amplio abanico de frecuencias, pero de ellas solamente empleamos para las comunicaciones Wifi la banda de los 2,4GHz (rango de microondas) y desde hace unos años (debido a a que esa frecuencia se liberalizó) la banda de los 5 GHz.  Todo esto se encuentra englobado dentro de la especificación 802.11n.

La banda de los 2,4 GHz es la que normalmente utilizan nuestros aparatos, ya que hay muchos que no soportan otra banda y es la empleada en muchas de las especificaciones anteriores (salvo la 802.11a).  Esta banda, a su vez se subdivide en distintos canales, normalmente 14 (en España).  Cada canal tiene un ancho de 22 Mhz, y entre cada canal hay una separación de 5 MHz; pero claro está para que no interfieran uno con otro debe haber una separación mayor al ancho de banda. Esto hace que para que no interfieran entre sí, tenga que haber una separación de 5 canales. De ahí que los canales empleados normalmente sean el 1, el 6 y el 11. En cuanto a la otra banda la de los 5 GHz presenta ciertas limitaciones ya que tanto la potencia como algunos de sus canles deben estar regulados para no provocar interferencias con las comunicaciones rádar y satélite. 

Veámoslo con un ejemplo práctico: Hemos empleado la red infraestructura de Plain Concepts como ejemplo. Como podéis observar en la imagen inferior, nuestra red se encuentra en el canal 11; en dicho canal se encuentran operando muchas otras redes, Este efecto de compartición del mismo canal se suele llamar interferencia co-canal y se da cuando hay una coexistencia de redes operando en el mismo canal, nuestro caso 8, al compartir el canal la velocidad de transmisión se ve reducida ya quese tienen que establecer turnos para emplearlo.

plain11-pub

Veamos qué pasa si cambiamos nuestro punto de acceso al canal 4. En este caso vemos que se produce un efecto algo distinto, si bien no hay ninguna señal que esté emitiendo exactamente en el mismo canal, podemos apreciar que se produce un “solapamiento” con otras señales, en concreto hay en total 12 que tanto por la parte superior como inferior están interfiriendo. Al contrario que pasa con el caso anterior, en el cual se establecían turnos y no había ruido como tal, este caso provoca colisiones y que los datos no se reciban correctamente.  Por todo ello, es preferible que haya interferencia cocanal a un solapamiento en las frecuencias de transmisión,  así a la hora de elegir un canal será preferible que nuestro AP elija los estándar (1, 6, 11).

channel4-2-public

Otro dato a tener en cuenta a la hora de establecer la configururación de nuestro punto de acceso es la posibilidad de cambiar de canal. Así, en algunas configuraciones de  AP ofrecen la posiblidad de cambiar automáticamente el canal a otro menos saturado, que bien parece una buena idea esto va a provocar que los clientes wifi se tengan que desasociar y volver a asociar, lo que puede provocar cortes del servicio.

Como apunte final,  quería indicar que el fenómeno de las interferencias muchas veces no es posible evitarlo, pero se pueden minimizar eligiendo canales estándar que estén menos saturados y en la medida de lo posible emplear la frecuencia de 5GHz  para aquellos dispositivos que lo soporten.

RADIUS, NPS y certificados Wildcard (1/2)

Hace un tiempo en Plain Concepts nos planteamos la posibilidad de cambiar la autenticación en la red wifi para poder utilizar nuestro usuario y contraseña de dominio. Este tipo de autenticación es conocida como RADIUS, y en el caso de las redes Wireless el AP o punto de acceso actúa como cliente RADIUS, hablando luego con el servidor RADIUS que realiza la autenticación en última instancia contra el directorio de usuarios correspondiente.

Como servidor RADIUS nos planteamos utilizar NPS (Network Policy Server), un rol incluido dentro de Windows Server de Microsoft, y que podíamos instalar en una VM.

Al intentar utilizar NPS nos encontramos con un problema que es el que intentaremos plasmar en este artículo, así como posibles soluciones.

La configuración es muy simple en el caso del AP, únicamente hay que especificar la dirección IP, el puerto (por defecto RADIUS trabaja con el 1812, y la clave compartida que van a utilizar cliente y servidor):

AP
Nuestro punto de acceso wifi y la configuración para conectarse al servidor RADIUS

Configurar el servidor NPS también es bastante sencillo, definiendo el grupo de usuarios que van a poder acceder a la red interna utilizando su usuario y contraseña corporativos y el método de autenticación a utilizar, en nuestro caso PEAP con MSCHAPv2,  usando como certificado un wildcard que utilizamos para multitud de cosas.

users
Usuarios que van a poder autenticar utilizando RADIUS
wildcard
Configuración del servidor RADIUS / NPS

Completamos el resto de la configuración, cogemos un cliente con Windows 8.1 cualquiera, nos vamos a conectar y ouch! recibimos un error. No tengo pantallazo del mismo, pero si tenemos una bonita traza de red 🙂

Esto es lo que se ve entre el cliente RADIUS (AP) y nuestro servidor RADIUS  / NPS (DC5). Como os comentábamos antes, el servidor RADIUS en última instancia autenticará al usuario contra el directorio correspondiente, en nuestro caso al ser un entorno Windows lo hará contra un Controlador de Dominio utilizando Kerberos, por lo que el instalar el rol de NPS en un DC nos dará mayor rapidez en la operación.

2719        14:02:30 09/08/2013        99.9773874        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = Identity

2720        14:02:30 09/08/2013        99.9832878        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP,PEAP start

2721        14:02:30 09/08/2013        99.9973892        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Client Hello.

2722        14:02:30 09/08/2013        99.9983551        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 HandShake: Server Hello. Certificate.

2724        14:02:30 09/08/2013        100.0173182        svchost.exe        192.168.2.1        DC5         EAP        EAP:Response, Type = PEAP

2725        14:02:30 09/08/2013        100.0180056        svchost.exe        DC5         192.168.2.1        EAP        EAP:Request, Type = PEAP

2726        14:02:30 09/08/2013        100.0374329        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 HandShake: Certificate. Client Key Exchange.

2727        14:02:30 09/08/2013        100.0441988        svchost.exe        DC5         192.168.2.1        TLS        TLS:TLS Rec Layer-1 Cipher Change Spec; TLS Rec Layer-2 HandShake: Encrypted Handshake Message.

2728        14:02:30 09/08/2013        100.0672320        svchost.exe        192.168.2.1        DC5         TLS        TLS:TLS Rec Layer-1 Encrypted Alert

2729        14:02:30 09/08/2013        100.0681224        svchost.exe        DC5         192.168.2.1        EAP        EAP:Failure

 

Toda la comunicación se realiza correctamente pero falla en uno de los últimos pasos. El error que veis en las trazas suele aparecer cuando no se ha podido autenticar correctamente al cliente, es decir, normalmente ocurre cuando las credenciales no son correctas.

Pero nos hemos asegurado de que sean correctas. ¿Qué puede fallar entonces?

Lo veremos en el próximo capítulo 🙂