Preguntas para principiantes sobre cómo funciona la autenticación RADIUS y WiFi


11

Soy administrador de red en una escuela secundaria en Sudáfrica, ejecutándome en una red de Microsoft. Tenemos aproximadamente 150 PC en el campus, de las cuales al menos 130 están conectadas a la red. El resto son computadoras portátiles del personal. Todas las direcciones IP se asignan mediante un servidor DHCP.

Actualmente, nuestro acceso wi-fi está limitado a algunas ubicaciones donde se encuentra ese personal. Estamos utilizando WPA con una clave larga que no está disponible para los estudiantes. Que yo sepa, esta clave es segura.

Sin embargo, tendría más sentido usar la autenticación RADIUS, pero tengo algunas preguntas sobre cómo funciona en la práctica.

  1. ¿Las máquinas que se agregan al dominio se autenticarán automáticamente en la red wi-fi? ¿O está basado en el usuario? ¿Pueden ser ambos?
  2. ¿Los dispositivos como un PSP / iPod touch / Blackberry / etc / podrán conectarse a la red WiFi si utiliza la autenticación RADIUS? Me gustaría que esto suceda.

Tengo WAP que admiten la autenticación RADIUS. Solo necesitaría activar la funcionalidad RADIUS desde un servidor MS 2003.

Dado el requisito del dispositivo móvil, ¿sería mejor usar un portal cautivo? Sé por experiencia en aeropuertos que se puede hacer (si el dispositivo tiene un navegador).

Lo que me lleva a preguntas sobre portales cautivos:

  1. ¿Puedo limitar el portal cautivo solo a dispositivos conectados a Wi-Fi? En particular, no quiero tener que configurar excepciones de direcciones MAC para todas las máquinas de red existentes (en mi opinión, solo aumenta la oportunidad de suplantación de direcciones MAC).
  2. ¿Cómo se hace esto? ¿Tengo un rango de direcciones separado para dispositivos de acceso WiFi y luego el portal cautivo enrutará entre las dos redes? Es importante enfatizar que los WAP comparten una red física con otras máquinas que no deben ser portadas en cautiverio.

¡Su experiencia y conocimiento serán apreciados!

Philip

Editar: para obtener un poco más de claridad sobre si un portal cautivo es incluso factible, he hecho esta pregunta .

Respuestas:


6

La autenticación de usuario para Wifi utiliza el protocolo 802.1x .
Para conectar dispositivos se necesita un solicitante WPA como SecureW2.
Dependiendo del solicitante que use, podrá o no podrá hacer un SSO con el inicio de sesión / contraseña del dominio de Windows.
El iPhone y el iPod touch tienen incorporado un solicitante WPA. No sé para PSP / BB. SecureW2 tiene una versión de Windows Mobile.

Estoy seguro de que podría habilitar un portal cautivo para WiFi solo sin tener que crear una red IP. Solo necesita colocar el acceso inalámbrico en un vlan y el acceso por cable en otro vlan y luego colocar el portal entre ambos vlan. Esto es como un firewall transparente.

802.1x necesita tener un suplicante en las computadoras. Si las computadoras que necesitan usar el Wifi son conocidas, solo tiene que configurar el solicitante en ellas y es una gran solución. Si desea que el visitante pueda acceder a su acceso inalámbrico o cosas así, podría ser una pesadilla porque necesitan el solicitante, etc.

Un portal cautivo es un poco menos seguro y necesita que el usuario se autentique manualmente cada vez que se conecta. Puede ser un poco aburrido.

Una buena solución desde mi punto de vista es tener ambos. Un acceso 802.1x que le brinda lo mismo que si estuviera conectado a la LAN y un portal cautivo que le da acceso a menos cosas (acceso al puerto de Internet 80, acceso limitado a la LAN local, ...)


5

Tengo un poco de experiencia en WIFI: he realizado muchas implementaciones en el campus: la ciudad de Las Vegas, la Universidad de Michigan, varios hoteles y complejos de apartamentos ...

Sus clientes no hablan directamente con un servidor RADIUS. El AP (punto de acceso) con capacidad 802.1x hace esto en nombre del cliente. De hecho, no necesita RADIUS para admitir una implementación 802.1x.

1. ¿Puedo limitar el portal cautivo solo a dispositivos conectados a Wi-Fi? En particular, no quiero tener que configurar excepciones de direcciones MAC para todas las máquinas de red existentes (en mi opinión, solo aumenta la oportunidad de suplantación de direcciones MAC).

La suplantación de MAC solo se puede hacer después de que un cliente se asocie. Por lo tanto, su preocupación aquí no tiene por qué ser, ya que uno no puede falsificar una red WIFI sin asociación primero. Usted controla la asociación a través de WPA o WPA2 y otros ...

2. ¿Cómo se hace esto? ¿Tengo un rango de direcciones separado para dispositivos de acceso WiFi y luego el portal cautivo enrutará entre las dos redes? Es importante enfatizar que los WAP comparten una red física con otras máquinas que no deben ser portadas en cautiverio.

¿Puedes hacer eso pero no estoy seguro de lo que esperas lograr? ¿Por qué siente que necesita aislar el acceso WIFI de sus clientes cableados? NOTA: ¡Los VLAN no son una medida de seguridad!

Su solución depende del tipo de AP que tenga y si son compatibles con WPA2. Suponiendo que lo hacen, lo que yo haría es una de las dos cosas en su situación:

Implemente WPA-PSK y controle el acceso LAN a través de políticas grupales y firewalls. También subredizaría la "zona" WIFI y usaría ACL de enrutador para cualquier filtrado interno que necesite. NTLM es bastante seguro en estos días. Este sería mi primer acercamiento. Si hay razones por las que no puede hacer esto, no se ha expandido lo suficiente en su publicación original para decir por qué ...

Mi segundo enfoque sería mirar 802.1x: esto parecería ser excesivo para sus necesidades como se describe, pero facilitaría la administración para cuando un empleado deja la empresa, etc. Si entregan sus computadoras portátiles cuando se van, entonces la opción 1 (WPA-PSK) parece lo suficientemente bueno. Si distribuye el PSK en lugar de introducirlo usted mismo, entonces esta opción es preferible, supongo.

Incluso si los usuarios finales de alguna manera comparten el PSK con extraños, sus puntos finales de LAN todavía están seguros a través de NTLM, ACL y firewalls ...

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.