Configuración de RADIUS + LDAP para WPA2 en Ubuntu

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 ...

Trataré de responder la pregunta LDAP aquí.

Aquí está la respuesta corta: asegúrese de que el ldapmódulo se elimine de la authenticatesección, y asegúrese de que el mschapmódulo esté presente tanto en authorizela authenticatesecció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 la authorizesección, esto es lo que hace cuando FreeRADIUS recibe un paquete RADIUS:

1. intenta vincularse al servidor LDAP (como usuario invitado o utilizando la identidad dada si hay una configurada ldap.conf)
2. busca la entrada de DN del usuario utilizando el filtro debajo del DN base (configurado en ldap.conf).
3. recupera todos los atributos LDAP que puede obtener entre los configurados ldap.attrmapy los convierte en atributos RADIUS.
4. agrega esos atributos a la lista de elementos de verificación del paquete RADIUS.

Cuando activa el ldapmódulo en la authenticatesección, esto es lo que hace FreeRADIUS:

1. intenta vincularse al servidor LDAP como usuario .
2. si puede vincularse, entonces es una autenticación exitosa, y Radius-Acceptse enviará un paquete al cliente, o de lo contrario, es un error, lo que lleva a un Radius-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 la authenticatesección y, de hecho, debe: vincularse ya que el usuario no funcionará.

Si su prueba funciona cuando la usa radtest, probablemente significa que el ldapmódulo está activado en la authenticatesecció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 la authenticatesección y asegurarse de activarlo mschaptanto en authorizela authenticatesección como en la sección. Lo que sucederá es que el mschapmódulo se encargará de la autenticación utilizando el NT-Passwordatributo que se recupera del servidor LDAP durante la authorizefase.

Así es como sites-enabled/defaultdebería verse su archivo (sin todos los comentarios):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

Y así es como sites-enabled/inner-tunneldebería verse su archivo:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

¿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 un UserPasswordatributo cuando obtuvo los detalles del usuario del servidor LDAP durante la authorizefase. En su caso, tiene el NT-Passwordatributo, y eso está perfectamente bien para la PEAP/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.

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).

Obtuve un certificado de http://CACert.org (probablemente debería obtener un certificado "real" si es posible)

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...

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.

Me encontré con el mismo problema. Tuve que descargar las fuentes RADIUS y compilarlas yo mismo.

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.