Configuration de RADIUS + LDAP pour WPA2 sur Ubuntu

J'installe un réseau sans fil pour environ 150 utilisateurs. En bref, je cherche un guide pour configurer le serveur RADIUS pour authentifier WPA2 contre un LDAP. Sur Ubuntu.

• J'ai obtenu un LDAP fonctionnel, mais comme il n'est pas utilisé en production, il peut très facilement être adapté aux changements que ce projet peut nécessiter.
• J'ai regardé FreeRADIUS, mais n'importe quel serveur RADIUS fera l'affaire.
• Nous avons un réseau physique séparé juste pour le WiFi, donc pas trop de soucis de sécurité sur ce front.
• Nos points d'accès sont des produits d'entreprise bas de gamme de HP - ils semblent prendre en charge tout ce que vous pouvez penser.
• Tous les serveurs Ubuntu, bébé!

Et la mauvaise nouvelle:

• Je suis maintenant quelqu'un de moins bien informé que moi qui finira par prendre en charge l'administration, donc la configuration doit être aussi "triviale" que possible.
• Jusqu'à présent, notre configuration est basée uniquement sur les logiciels des référentiels Ubuntu, à l'exception de notre application Web d'administration LDAP et de quelques petits scripts spéciaux. Donc pas de "récupérer le package X, untar, ./configure"-things si évitable.

MISE À JOUR 2009-08-18:

Bien que j'aie trouvé plusieurs ressources utiles, il y a un sérieux obstacle:

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.

Fondamentalement, la version Ubuntu de FreeRADIUS ne prend pas en charge SSL ( bug 183840 ), ce qui rend tous les types EAP sécurisés inutiles. Bummer.

Mais une documentation utile pour toute personne intéressée:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

MISE À JOUR 2009-08-19:

J'ai fini par compiler mon propre package FreeRADIUS hier soir - il y a une très bonne recette sur http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (voir les commentaires à la poste pour des instructions mises à jour).

J'ai obtenu un certificat de http://CACert.org (vous devriez probablement obtenir un "vrai" certificat si possible)

Ensuite, j'ai suivi les instructions sur http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Ce lien renvoie à http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , qui est une lecture très intéressante si vous voulez savoir comment fonctionne la sécurité WiFi.

MISE À JOUR 2009-08-27:

Après avoir suivi le guide ci-dessus, j'ai réussi à faire parler FreeRADIUS à LDAP:

J'ai créé un utilisateur de test dans LDAP, avec le mot de passe mr2Yx36M- cela donne une entrée LDAP à peu près de:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

Lors de l'utilisation radtest, je peux me connecter correctement:

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

Mais quand j'essaye à travers l'AP, il ne vole pas - alors qu'il confirme qu'il comprend les mots de passe NT et 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
...

Il est clair que les mots de passe NT et LM diffèrent des précédents, mais le message [ldap] user testuser authorized to use remote access- et l'utilisateur est rejeté plus tard ...

Je vais essayer de répondre à la question LDAP ici.

Voici la réponse courte: assurez-vous que le ldapmodule est supprimé de la authenticatesection et assurez-vous que le mschapmodule est présent à la fois dans authorizeet dans la authenticatesection. Et ignorez simplement le «Pas de« bon mot de passe connu ».

Et maintenant, voici la (très) longue réponse.

Comment fonctionne le module LDAP?

Lorsque vous activez le ldapmodule dans la authorizesection, voici ce qu'il fait lorsqu'un paquet RADIUS est reçu par FreeRADIUS:

1. il essaie de se lier au serveur LDAP (en tant qu'utilisateur invité, ou en utilisant l'identité donnée si une est configurée dans ldap.conf)
2. il recherche l'entrée DN de l'utilisateur à l'aide du filtre sous le DN de base (configuré dans ldap.conf).
3. il récupère tous les attributs LDAP qu'il peut obtenir parmi ceux configurés ldap.attrmapet les convertit en attributs RADIUS.
4. il ajoute ces attributs à la liste des éléments de contrôle du paquet RADIUS.

Lorsque vous activez le ldapmodule dans la authenticatesection, voici ce que fait FreeRADIUS:

1. il essaie de se lier au serveur LDAP en tant qu'utilisateur .
2. s'il peut se lier, alors c'est une authentification réussie, et un Radius-Acceptpaquet sera renvoyé au client, ou bien, c'est un échec, conduisant à un Radius-Rejectpaquet.

Alors, comment puis-je configurer FreeRADIUS pour faire fonctionner PEAP / MS-CHAP-v2 avec LDAP?

Le point important ici est que la liaison en tant qu'utilisateur ne fonctionnera que si le serveur FreeRADIUS peut récupérer le mot de passe en clair de l'utilisateur à partir du paquet RADIUS qu'il a reçu. Ce n'est le cas que lorsque des méthodes d'authentification PAP ou TTLS / PAP sont utilisées (et éventuellement aussi EAP / GTC). Seule la méthode TTLS / PAP est vraiment sécurisée, et elle n'est pas disponible par défaut sous Windows. Si vous souhaitez que vos utilisateurs se connectent avec TTLS / PAP, vous devez leur faire installer un logiciel suppliant TTLS, ce qui est rarement une option. La plupart du temps, lors du déploiement du WiFi avec la sécurité WPA Enterprise, PEAP / MS-CHAP-v2 est la seule option raisonnable.

Donc, la ligne de fond est la suivante: à moins que vous n'utilisiez PAP ou TTLS / PAP, vous pouvez supprimer le ldapmodule de la authenticatesection en toute sécurité , et en fait, vous devez: lier car l'utilisateur ne fonctionnera pas.

Si votre test fonctionne lorsque vous utilisez radtest, cela signifie probablement que le ldapmodule est activé dans la authenticatesection: il essaiera de se lier en tant qu'utilisateur, et puisque radtest utilise l'authentification PAP, il réussira. Mais il échouera si vous essayez de vous connecter via le point d'accès, car vous utilisez PEAP / MS-CHAP-v2.

Ce que vous devez faire est de retirer le ldapmodule de la authenticatesection et assurez-vous d'activer le mschapmodule à la fois dans authorizeet dans la authenticatesection. Ce qui se passera, c'est que le mschapmodule se chargera de l'authentification en utilisant l' NT-Passwordattribut qui est récupéré du serveur LDAP pendant la authorizephase.

Voici à quoi sites-enabled/defaultdevrait ressembler votre fichier (sans tous les commentaires):

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

Et voici à quoi sites-enabled/inner-tunneldevrait ressembler votre fichier:

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

Qu'en est-il de l'avertissement "Pas de" bon mot de passe connu "?

Eh bien, vous pouvez l'ignorer en toute sécurité. Il est juste là parce que le ldapmodule n'a pas pu trouver d' UserPasswordattribut lorsqu'il a récupéré les détails de l'utilisateur du serveur LDAP pendant la authorizephase. Dans votre cas, vous avez l' NT-Passwordattribut, et c'est très bien pour l' PEAP/MS-CHAP-v2authentification.

Je suppose que l'avertissement existe parce que lorsque le ldapmodule a été conçu, PEAP/MS-CHAP-v2n'existait pas encore, donc la seule chose qui semblait logique à l'époque était de récupérer l'attribut UserPassword du serveur LDAP, afin d'utiliser PAP, CHAP, EAP / MD5 ou de telles méthodes d'authentification.

Je vais essayer de répondre à la question d'OpenSSL ici: la réponse courte est d' utiliser FreeRADIUS 2.1.8 ou supérieur, qui inclut OpenSSL . Il est disponible dans les backports Ubuntu Lucid et Debian Lenny (et finira probablement aussi dans les backports Ubuntu Karmic).

Voici la longue réponse:

Malheureusement, la licence OpenSSL était (quelque peu) incompatible avec la licence FreeRADIUS. Par conséquent, le peuple Ubuntu a choisi de fournir un binaire FreeRADIUS non lié à OpenSSL. Si vous vouliez EAP / TLS, PEAP ou TTLS, vous aviez pour obtenir les sources et les compiler avec l' --with-openssloption de (comme la recette que vous avez utilisé , explique).

Mais récemment, le problème de licence a été résolu . Les versions 2.1.8 ou supérieures de FreeRADIUS peuvent être compilées et distribuées avec OpenSSL. La mauvaise nouvelle est que la distribution Ubuntu stable la plus récente (Karmic Koala) ne comprend que FreeRADIUS 2.1.0, sans OpenSSL (il en va de même pour Debian, car Lenny ne contient que FreeRADIUS 2.0.4). J'ai vérifié les backports de Karmic, mais il semble que FreeRADIUS 2.1.8 ou supérieur n'y ait pas encore été téléchargé (mais il pourrait être ajouté bientôt, consultez-le ici). Donc pour l'instant, vous devez soit passer à Ubuntu Lucid (qui inclut FreeRADIUS 2.1.8), soit s'en tenir à la compilation. Pour les utilisateurs de Debian, les choses sont un peu plus lumineuses: les rétroportages de Lenny incluent FreeRADIUS 2.1.8. Donc, si vous voulez quelque chose de très stable, et facile à installer et à entretenir, je vous suggère de déployer un serveur avec Debian Lenny, et d'installer le paquet FreeRADIUS rétroporté (il vous donne également la possibilité d'écrire des modules python gratuitement, sans avoir à recompiler avec tous les modules expérimentaux).

J'ai obtenu un certificat de http://CACert.org (vous devriez probablement obtenir un "vrai" certificat si possible)

Il y a un "gotcha" avec de "vrais" certificats (par opposition aux certificats auto-signés).

J'en ai utilisé un signé par Thawte. Cela fonctionne très bien et les utilisateurs voient un beau certificat "valide" nommé quelque chose comme www.my-web-site.com. Lorsque l'utilisateur accepte le certificat, son ordinateur comprend que tous les certificats émis par la même autorité de certification doivent être approuvés (j'ai testé cela avec Windows Vista et MacOSX Snow Leopard)! Donc dans mon cas, si un pirate possède un certificat, par exemple, www.some-other-web-site.comégalement signé par Thawte, alors il peut facilement lancer une attaque Man-in-the-middle, sans qu'aucun avertissement ne soit affiché sur l'ordinateur de l'utilisateur!

La solution à cela réside profondément dans la configuration réseau de l'ordinateur de l'utilisateur, afin de spécifier spécifiquement que seul "www.my-web-site.com" doit être approuvé. Cela ne prend qu'une minute, mais la plupart des utilisateurs ne sauront où le configurer que si vous leur donnez une procédure claire et assurez-vous que chaque utilisateur la suit. J'utilise toujours des certificats "valides", mais franchement, il est décevant de voir que Windows et MacOSX partagent ce "bug": faire confiance à l'autorité de certification au lieu du certificat spécifique. Aie...

Selon le rapport de bogue, une simple reconstruction de FreeRADIUS devrait résoudre le problème de prise en charge d'OpenSSH. Cela ne doit être fait qu'une seule fois.

Je ne sais pas quelle facilité d'administration a à voir avec la configuration. Souvent, plus la configuration est impliquée et détaillée, plus elle est facile à administrer, car la configuration couvre toutes les bases. Voulez-vous dire que la configuration doit également être supprimée sur d'autres serveurs? Combien de LAN sans fil configurez-vous?

Une fois configurée, l'administration doit être limitée aux ajouts, suppressions et modifications d'utilisateurs LDAP. Celles-ci devraient être assez faciles pour soit script avec ldapmodify (et al) ou trouver un frontal graphique LDAP décent et documenter les processus avec des captures d'écran.

J'ai rencontré le même problème. J'ai dû télécharger les sources RADIUS et les compiler moi-même.

Vous pouvez utiliser FreeRADIUS2 (avec OpenSSL) + EAP-TLS + WPA2-Enterprice. Voici un HOW-TO très détaillé . Windows XP SP3 a un support natif pour cela ainsi que Windows 7, Android 2.3, iPhone, Symbian. Mais je ne connais pas la compatibilité avec SLDAP dans un tel schéma.