Je confecte un réseau sans fil pour ~ 150 utilisateurs. En bref, je cherche un guide pour définir RADIUS serveur pour authentifier WPA2 contre un LDAP. Sur ubuntu.
Et la mauvaise nouvelle:
Mise à jour 2009-08-18:
Bien que j'ai trouvé plusieurs ressources utiles, il y a un obstacle sérieux:
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 18384 ), ce qui rend tous les types EAP sécurisés inutiles. Dommage.
Mais une documentation utile pour quiconque intéressé:
Mise à jour 2009-08-19:
J'ai fini par compiler mon propre forfait FreeRadius hier soir - il y a une très bonne recette à - http://www.linuxinsight.com/building-debian-freeradius-package-witheap-tls-ttls-peapp-support .html (voir les commentaires à la poste pour les instructions mises à jour).
J'ai reçu un certificat de http://cacert.org (vous devriez probablement obtenir un "vrai" certifié si possible)
Ensuite, j'ai suivi les instructions à http://vuksan.com/linux/dot1x/802-1x-ldap.html . Ces liens vers http://tldp.org/howto/html_single/8021x-howto/ , qui est une lecture très valable si vous souhaitez savoir comment fonctionne la sécurité WiFi.
Mise à jour 2009-08-27:
Après avoir suivi le guide ci-dessus, j'ai réussi à amener Freeradius à parler à 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:
uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja
Lorsque vous utilisez radtest
, je peux connecter 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
>
Mais quand j'essaie à travers l'AP, il ne volera pas - alors qu'il confirme qu'il figure sur 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 de ce qui précède, mais le message [ldap] user testuser authorized to use remote access
- et l'utilisateur est ensuite rejeté ...
Je vais essayer de répondre à la question de la LDAP ici.
Voici la réponse courte: assurez-vous que le module ldap
est supprimé de la section authenticate
et assurez-vous que le module mschap
est présent dans le authorize
et la section authenticate
. Et ignorerai simplement le "bon mot de passe" connu.
Et maintenant voici la réponse (très) longue.
Comment fonctionne le module LDAP?
Lorsque vous activez le module ldap
dans la section authorize
, voici ce qu'il fait lorsqu'un RADIUS paquet est reçu par freeradius:
ldap.conf
)ldap.conf
).ldap.attrmap
, et les convertit en RADIUS attributs.Lorsque vous activez le module ldap
dans la section authenticate
, c'est ce que FreeRadius fait:
Radius-Accept
paquet sera renvoyé au client, sinon, c'est un échec, menant à un Radius-Reject
paquet.Alors, comment puis-je configurer Freeradius pour faire du travail PEAP/MS-CHAP-V2 avec LDAP?
Le point important ici est que la liaison que l'utilisateur ne fonctionnera que si le serveur Freeeradius peut récupérer le mot de passe ClearText de l'utilisateur à partir du RADIUS paquet il a reçu. Ce n'est que le cas lorsque les 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 qu'il n'est pas disponible par défaut Dans Windows. Si vous souhaitez que vos utilisateurs se connectent avec TTLS/PAP, vous devez les installer un logiciel de suppliant TTLS, ce qui est rarement une option. La plupart du temps, lors du déploiement de wifi avec WPA = Enterprise Securiy, PEAP/MS-CHAP-V2 est la seule option raisonnable.
De sorte que la ligne de fin de la ligne est la suivante: sauf si vous utilisez PAP ou TTLS/PAP, vous pouvez supprimer en toute sécurité le module ldap
de la section authenticate
et, en réalité, vous devez: BLANDING PAS travail.
Si votre test fonctionne lorsque vous utilisez radtest
, cela signifie probablement que le module ldap
est activé dans la section authenticate
: il essaiera de lier en tant qu'utilisateur, et puisque radtest Utilise l'authentification PAP, elle réussira. Mais cela échouera si vous essayez de vous connecter à travers le point d'accès, car vous utilisez PEAP/MS-CHAP-V2.
Ce que vous devriez faire, c'est supprimer le module ldap
de la section authenticate
et assurez-vous d'activer le module mschap
dans authorize
et le authenticate
section. Ce qui va arriver est que le module mschap
s'occupera de l'authentification à l'aide de la NT-Password
Attribut qui est extrait du serveur LDAP lors de la phase authorize
.
Voici ce que votre sites-enabled/default
Le fichier devrait ressembler (sans tous les commentaires):
...
authorize {
preprocess
suffix
eap {
ok = return
}
expiration
logintime
}
authenticate {
eap
}
...
Et voici ce que votre sites-enabled/inner-tunnel
Le fichier devrait ressembler à:
...
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 "non" bon "mot de passe" connu?
Eh bien, vous pouvez l'ignorer en toute sécurité. Il est juste là car le module ldap
n'a pas pu trouver un attribut UserPassword
lors de la récupération des détails de l'utilisateur à partir du serveur LDAP lors de la phase authorize
. Dans votre cas, vous avez le NT-Password
attribut, et c'est parfaitement bien pour PEAP/MS-CHAP-v2
Authentification.
Je suppose que l'avertissement existe car lorsque le module ldap
a été conçu, PEAP/MS-CHAP-v2
n'existait pas encore, donc la seule chose qui semblait avoir un sens à l'époque était de récupérer l'attribut userPassword du serveur LDAP, afin d'utiliser PAP, CHAP, EAP/MD5 ou de ces méthodes d'authentification.
Je vais essayer de répondre à la question OpenSSL ici: la réponse courte est à Utilisez FreeRadius 2.1.8 ou plus, qui inclut OpenSSL . Il est disponible à Ubuntu lucid et Debian Lenny Backports (et finira probablement dans Ubuntu Karmic Backports).
Voici la longue réponse:
Malheureusement, la licence OpenSSL était (un peu) incompatible avec la licence FreeRadius. Par conséquent, le peuple Ubuntu a choisi de fournir un freeeradius binaire non Lié à OpenSSL. Si vous vouliez EAP/TLS, PEAP ou TTLS, vous avait Pour obtenir les sources et les compiler avec le --with-openssl
Option (comme la recette que vous avez utilisée explique).
Mais récemment, le problème de la licence a été corrigé . Les versions FreeRadius 2.1.8 ou plus peuvent être compilées et distribuées avec OpenSSL. La mauvaise nouvelle est que la plus récente distribution d'Ubuntu stable (Karmic Koala) ne comprend que Freeeradius 2.1.0, sans OpenSSL (la même chose vaut pour Debian, puisque Lenny ne contient que Freeradius 2.0.4). J'ai vérifié le karmic-backports, mais il semble que Freeeradius 2.1.8 ou plus ne soit pas téléchargé là-bas, mais il peut être ajouté bientôt, Vérifiez-le ici ). Donc, pour le moment, vous devez soit basculer vers Ubuntu lucide (qui inclut Freeradius 2.1.8) ou coller à la compilation. Pour les utilisateurs de Debian, les choses sont un peu plus lumineuses: les backports 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 backported (cela vous donne également la possibilité d'écrire python modules gratuitement, sans avoir à recompiler avec tous les modules expérimentaux).
J'ai reçu un certificat de http://cacert.org (vous devriez probablement obtenir un "vrai" certifié si possible)
Il y a un "gotcha" avec des certificats "réels" (par opposition aux certificats auto-signés).
J'ai utilisé un signé par Thawte. Cela fonctionne 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 réellement 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 informatique a un certificat pour, disons, www.some-other-web-site.com
, également signé par Thawte, il peut ensuite exécuter une attaque man-in-the-intermédiaire facilement, sans aucun avertissement étant affiché sur l'ordinateur de l'utilisateur!
La solution à cela repose sur 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é. Il faut juste une minute, mais la plupart des utilisateurs ne sauront pas où configurer cela à moins que vous ne leur donniez une procédure claire et assurez-vous que chaque utilisateur le suit. J'utilise toujours des certificats "valides", mais franchement, il est décevant de voir que Windows et MacOSX partagent ce "bogue": faire confiance à l'autorité de certification au lieu du certificat spécifique. Aie...
Selon le rapport de bogue, une simple reconstruction de FreeRadius devrait corriger le problème de support OpenSSH. Il faut seulement faire une fois.
Je ne suis pas sûr de la facilité d'administration avec la configuration. Souvent, plus la configuration est impliquée et détaillée, plus il est facile d'administrer, car la configuration couvrait toutes les bases. Voulez-vous dire que la configuration doit être déposée facilement sur d'autres serveurs? Combien de livres de réseau sans fil vous configurez-vous?
Une fois configuré, l'administration doit être limitée à l'utilisateur de LDAP ajoute, supprime et modifie. Celles-ci devraient être suffisamment faciles à être un script avec LDAPModify (et al) ou trouvez une extrémité frontale graphique de LDAP décente et documenter les processus avec des captures d'écran.
J'ai couru dans le même problème. Je devais télécharger le RADIUS sources et les compiler moi-même.