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
ldap
módulo se elimine de laauthenticate
sección, y asegúrese de que elmschap
módulo esté presente tanto enauthorize
laauthenticate
secció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
ldap
módulo en laauthorize
sección, esto es lo que hace cuando FreeRADIUS recibe un paquete RADIUS:ldap.conf
)ldap.conf
).ldap.attrmap
y los convierte en atributos RADIUS.Cuando activa el
ldap
módulo en laauthenticate
sección, esto es lo que hace FreeRADIUS:Radius-Accept
se enviará un paquete al cliente, o de lo contrario, es un error, lo que lleva a unRadius-Reject
paquete.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
ldap
módulo de laauthenticate
sección y, de hecho, debe: vincularse ya que el usuario no funcionará.Si su prueba funciona cuando la usa
radtest
, probablemente significa que elldap
módulo está activado en laauthenticate
secció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
ldap
módulo de laauthenticate
sección y asegurarse de activarlomschap
tanto enauthorize
laauthenticate
sección como en la sección. Lo que sucederá es que elmschap
módulo se encargará de la autenticación utilizando elNT-Password
atributo que se recupera del servidor LDAP durante laauthorize
fase.Así es como
sites-enabled/default
debería verse su archivo (sin todos los comentarios):Y así es como
sites-enabled/inner-tunnel
debería verse su archivo:¿Qué pasa con la advertencia "No hay contraseña" conocida "?
Bueno, puedes ignorarlo con seguridad. Simplemente está allí porque el
ldap
módulo no pudo encontrar unUserPassword
atributo cuando obtuvo los detalles del usuario del servidor LDAP durante laauthorize
fase. En su caso, tiene elNT-Password
atributo, y eso está perfectamente bien para laPEAP/MS-CHAP-v2
autenticación.Supongo que la advertencia existe porque cuando
ldap
se diseñó el módulo,PEAP/MS-CHAP-v2
todaví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-openssl
opció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.com
tambié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