Estoy configurando una red inalámbrica para ~ 150 usuarios. En resumen, estoy buscando una guía para configurar el servidor RADIUS para autenticar WPA2 contra un LDAP. En Ubuntu
- Obtuve un LDAP que funciona, pero como no está en uso en producción, puede adaptarse fácilmente a cualquier cambio que pueda requerir este proyecto.
- He estado mirando FreeRADIUS, pero cualquier servidor RADIUS funcionará.
- Tenemos una red física separada solo para WiFi, por lo que no hay demasiadas preocupaciones sobre la seguridad en ese frente.
- Nuestros AP son cosas empresariales de gama baja de HP: parecen admitir todo lo que se te ocurra.
- Todo el servidor de Ubuntu, bebé!
Y las malas noticias:
- Ahora, alguien con menos conocimiento que yo eventualmente se hará cargo de la administración, por lo que la configuración debe ser lo más "trivial" posible.
- Hasta ahora, nuestra configuración se basa únicamente en el software de los repositorios de Ubuntu, con excepción de nuestra aplicación web de administración LDAP y algunos pequeños scripts especiales. Por lo tanto, no "buscar el paquete X, deshacer, ./configure"-things si es evitable.
ACTUALIZACIÓN 2009-08-18:
Si bien encontré varios recursos útiles, hay un obstáculo serio:
Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.
Básicamente, la versión de Ubuntu de FreeRADIUS no es compatible con SSL ( error 183840 ), lo que hace que todos los tipos de EAP seguros sean inútiles. Gorrón.
Pero alguna documentación útil para cualquier persona interesada:
- http://vuksan.com/linux/dot1x/802-1x-LDAP.html
- http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius
ACTUALIZACIÓN 2009-08-19:
Terminé compilando mi propio paquete FreeRADIUS ayer por la noche: hay una muy buena receta en http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (Ver los comentarios a la publicación para obtener instrucciones actualizadas).
Obtuve un certificado de http://CACert.org (probablemente debería obtener un certificado "real" si es posible)
Luego seguí las instrucciones en http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Esto enlaza con http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , que es una lectura que vale la pena si quieres saber cómo funciona la seguridad WiFi.
ACTUALIZACIÓN 2009-08-27:
Después de seguir la guía anterior, he logrado que FreeRADIUS hable con LDAP:
He creado un usuario de prueba en LDAP, con la contraseña mr2Yx36M; esto proporciona una entrada de LDAP aproximadamente de:
uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja
Cuando lo uso radtest, puedo conectarme bien:
> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
User-Name = "msiebuhr"
User-Password = "mr2Yx36N"
NAS-IP-Address = 127.0.1.1
NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
>
Pero cuando intento a través del AP, no vuela, mientras que confirma que descubre las contraseñas NT y LM:
...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...
Está claro que las contraseñas NT y LM difieren de las anteriores, pero el mensaje [ldap] user testuser authorized to use remote access, y el usuario luego es rechazado ...

Respuestas:
Trataré de responder la pregunta LDAP aquí.
Aquí está la respuesta corta: asegúrese de que el
ldapmódulo se elimine de laauthenticatesección, y asegúrese de que elmschapmódulo esté presente tanto enauthorizelaauthenticatesección como en la sección. E simplemente ignore la 'No contraseña "conocida".Y ahora aquí está la respuesta (muy) larga.
¿Cómo funciona el módulo ldap?
Cuando activa el
ldapmódulo en laauthorizesección, esto es lo que hace cuando FreeRADIUS recibe un paquete RADIUS:ldap.conf)ldap.conf).ldap.attrmapy los convierte en atributos RADIUS.Cuando activa el
ldapmódulo en laauthenticatesección, esto es lo que hace FreeRADIUS:Radius-Acceptse enviará un paquete al cliente, o de lo contrario, es un error, lo que lleva a unRadius-Rejectpaquete.Entonces, ¿cómo puedo configurar FreeRADIUS para que PEAP / MS-CHAP-v2 funcione con LDAP?
El punto importante aquí es que el enlace ya que el usuario solo funcionará si el servidor FreeRADIUS puede recuperar la contraseña de texto sin cifrar del usuario del paquete RADIUS que recibió. Este es solo el caso cuando se utilizan los métodos de autenticación PAP o TTLS / PAP (y posiblemente también EAP / GTC). Solo el método TTLS / PAP es realmente seguro, y no está disponible por defecto en Windows. Si desea que sus usuarios se conecten con TTLS / PAP, debe hacer que instalen un software suplicante TTLS, que rara vez es una opción. La mayoría de las veces, al implementar WiFi con seguridad WPA Enterprise, PEAP / MS-CHAP-v2 es la única opción razonable.
Por lo tanto, la conclusión es: a menos que esté utilizando PAP o TTLS / PAP, puede eliminar de forma segura el
ldapmódulo de laauthenticatesección y, de hecho, debe: vincularse ya que el usuario no funcionará.Si su prueba funciona cuando la usa
radtest, probablemente significa que elldapmódulo está activado en laauthenticatesección: intentará vincularse como usuario, y dado que radtest usa autenticación PAP, tendrá éxito. Pero fallará si intenta conectarse a través del punto de acceso, ya que está utilizando PEAP / MS-CHAP-v2.Lo que debe hacer es eliminar el
ldapmódulo de laauthenticatesección y asegurarse de activarlomschaptanto enauthorizelaauthenticatesección como en la sección. Lo que sucederá es que elmschapmódulo se encargará de la autenticación utilizando elNT-Passwordatributo que se recupera del servidor LDAP durante laauthorizefase.Así es como
sites-enabled/defaultdebería verse su archivo (sin todos los comentarios):Y así es como
sites-enabled/inner-tunneldebería verse su archivo:¿Qué pasa con la advertencia "No hay contraseña" conocida "?
Bueno, puedes ignorarlo con seguridad. Simplemente está allí porque el
ldapmódulo no pudo encontrar unUserPasswordatributo cuando obtuvo los detalles del usuario del servidor LDAP durante laauthorizefase. En su caso, tiene elNT-Passwordatributo, y eso está perfectamente bien para laPEAP/MS-CHAP-v2autenticación.Supongo que la advertencia existe porque cuando
ldapse diseñó el módulo,PEAP/MS-CHAP-v2todavía no existía, por lo que lo único que parecía tener sentido en ese momento era recuperar el atributo UserPassword del servidor LDAP, para poder usar PAP, CHAP, EAP / MD5 o tales métodos de autenticación.fuente
Intentaré responder la pregunta de OpenSSL aquí: la respuesta corta es usar FreeRADIUS 2.1.8 o superior, que incluye OpenSSL . Está disponible en los backports de Ubuntu Lucid y Debian Lenny (y probablemente también terminará en los backports de Ubuntu Karmic).
Aquí está la respuesta larga:
Desafortunadamente, la licencia de OpenSSL solía ser (algo) incompatible con la licencia de FreeRADIUS. Por lo tanto, la gente de Ubuntu eligió proporcionar un binario FreeRADIUS no vinculado con OpenSSL. Si quería EAP / TLS, PEAP o TTLS, tenía que obtener las fuentes y compilarlas con la
--with-opensslopción (como explica la receta que utilizó).Pero recientemente, el problema de licencia se ha solucionado . Las versiones de FreeRADIUS 2.1.8 o superiores se pueden compilar y distribuir con OpenSSL. La mala noticia es que la distribución estable más reciente de Ubuntu (Karmic Koala) incluye solo FreeRADIUS 2.1.0, sin OpenSSL (lo mismo ocurre con Debian, ya que Lenny solo contiene FreeRADIUS 2.0.4). Revisé los backports de Karmic, pero parece que FreeRADIUS 2.1.8 o superior aún no se han cargado allí (pero puede agregarse pronto, échale un vistazo aquí)) Entonces, por ahora, debes cambiar a Ubuntu Lucid (que incluye FreeRADIUS 2.1.8) o seguir compilando. Para los usuarios de Debian, las cosas son un poco más brillantes: los backports de Lenny incluyen FreeRADIUS 2.1.8. Entonces, si desea algo muy estable y fácil de instalar y mantener, le sugiero que implemente un servidor con Debian Lenny e instale el paquete FreeRADIUS con respaldo (también le brinda la posibilidad de escribir módulos de Python de forma gratuita, sin tener que volver a compilar con todos los módulos experimentales).
Hay una "trampa" con certificados "reales" (a diferencia de los certificados autofirmados).
Usé uno firmado por Thawte. Funciona bien, y los usuarios ven un hermoso certificado "válido" llamado algo así
www.my-web-site.com. Cuando el usuario acepta el certificado, su computadora comprende que todos los certificados emitidos por la misma autoridad de certificación deben ser confiables (lo probé con Windows Vista y MacOSX Snow Leopard). Entonces, en mi caso, si un hacker tiene un certificado para, por ejemplo,www.some-other-web-site.comtambién firmado por Thawte, ¡entonces puede ejecutar un ataque Man-in-the-middle fácilmente, sin que se muestre ninguna advertencia en la computadora del usuario!La solución a esto radica en la configuración de red de la computadora del usuario, para especificar específicamente que solo se debe confiar en "www.my-web-site.com". Solo toma un minuto, pero la mayoría de los usuarios no sabrán dónde configurar esto a menos que les dé un procedimiento claro y se asegure de que todos los usuarios lo sigan. Todavía uso certificados "válidos", pero francamente es decepcionante ver que tanto Windows como MacOSX comparten este "error": confiar en la Autoridad de certificación en lugar del certificado específico. Ay...
fuente
Según el informe de error, una simple reconstrucción de FreeRADIUS debería solucionar el problema de soporte de OpenSSH. Solo necesita hacerse una vez.
No estoy seguro de qué tiene que ver la facilidad de administración con la configuración. A menudo, cuanto más involucrada y detallada es la configuración, más fácil es administrarla, porque la configuración cubrió todas las bases. ¿Quiere decir que la configuración también se debe eliminar en otros servidores fácilmente? ¿Cuántas LAN inalámbricas está configurando?
Una vez configurada, la Administración debe limitarse a que el usuario LDAP agregue, elimine y modifique. Estos deberían ser lo suficientemente fáciles como para ejecutar scripts con ldapmodify (et al) o encontrar una interfaz gráfica de LDAP decente y documentar los procesos con capturas de pantalla.
fuente
Me encontré con el mismo problema. Tuve que descargar las fuentes RADIUS y compilarlas yo mismo.
fuente
Puede usar FreeRADIUS2 (con OpenSSL) + EAP-TLS + WPA2-Enterprice. Aquí hay un tutorial muy detallado . Windows XP SP3 tiene soporte nativo para él, así como Windows 7, Android 2.3, iPhone, Symbian. Pero no sé acerca de la compatibilidad con SLDAP en dicho esquema.
fuente