Einrichten von RADIUS + LDAP für WPA2 unter Ubuntu

Ich richte ein drahtloses Netzwerk für ~ 150 Benutzer ein. Kurz gesagt, ich suche nach einer Anleitung, um den RADIUS-Server für die Authentifizierung von WPA2 gegen LDAP einzurichten. Auf Ubuntu.

• Ich habe ein funktionierendes LDAP, aber da es nicht in der Produktion verwendet wird, kann es sehr einfach an die Änderungen angepasst werden, die für dieses Projekt erforderlich sind.
• Ich habe nach FreeRADIUS gesucht, aber jeder RADIUS-Server wird es tun.
• Wir haben ein separates physisches Netzwerk nur für WiFi, also keine allzu großen Sicherheitsbedenken.
• Unsere APs sind HPs Low-End-Unternehmenssachen - sie scheinen alles zu unterstützen, was Sie sich vorstellen können.
• Alles Ubuntu Server, Baby!

Und die schlechten Nachrichten:

• Ich habe jetzt jemanden, der weniger kennt als ich, der irgendwann die Administration übernimmt, also muss das Setup so "trivial" wie möglich sein.
• Bisher basiert unser Setup ausschließlich auf Software aus den Ubuntu-Repositories, mit Ausnahme unserer LDAP-Verwaltungs-Webanwendung und einiger kleiner Spezialskripte. Also keine "Paket X holen, entpacken, ./configure"- Dinge, wenn vermeidbar.

UPDATE 18.08.2009:

Obwohl ich mehrere nützliche Ressourcen gefunden habe, gibt es ein ernstes Hindernis:

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.

Grundsätzlich unterstützt die Ubuntu-Version von FreeRADIUS kein SSL ( Fehler 183840 ), wodurch alle sicheren EAP-Typen unbrauchbar werden. Schade.

Aber einige nützliche Unterlagen für alle Interessierten:

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

UPDATE 19.08.2009:

Ich habe gestern Abend mein eigenes FreeRADIUS-Paket kompiliert - es gibt ein wirklich gutes Rezept unter http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (Siehe die Kommentare zum Beitrag für aktualisierte Anweisungen).

Ich habe ein Zertifikat von http://CACert.org erhalten (wenn möglich, sollten Sie wahrscheinlich ein "echtes" Zertifikat erhalten)

Dann folgte ich den Anweisungen unter http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Hier finden Sie Links zu http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , die Sie unbedingt lesen sollten, wenn Sie wissen möchten, wie die WLAN-Sicherheit funktioniert.

UPDATE 2009-08-27:

Nachdem ich der obigen Anleitung gefolgt bin, habe ich es geschafft, dass FreeRADIUS mit LDAP kommuniziert:

Ich habe in LDAP einen Testbenutzer mit dem Kennwort erstellt. mr2Yx36MDies ergibt einen LDAP-Eintrag von ungefähr:

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

Bei der Verwendung radtestkann ich gut verbinden:

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

Aber wenn ich den AP durchprobiere, fliegt er nicht - obwohl er bestätigt, dass er die NT- und LM-Passwörter herausfindet:

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

Es ist klar, dass die NT- und LM-Passwörter sich von den oben genannten unterscheiden, die Meldung jedoch [ldap] user testuser authorized to use remote access- und der Benutzer wird später abgelehnt ...

Ich werde versuchen, die LDAP-Frage hier zu beantworten.

Hier ist die kurze Antwort: Stellen Sie sicher, dass das ldapModul aus dem authenticateAbschnitt entfernt wurde, und stellen Sie sicher, dass das mschapModul sowohl authorizeim authenticateAbschnitt als auch im Abschnitt vorhanden ist. Und ignorieren Sie einfach das "Kein" "bekanntermaßen gutes" Passwort ".

Und hier ist die (sehr) lange Antwort.

Wie funktioniert das LDAP-Modul?

Wenn Sie das ldapModul in diesem authorizeAbschnitt aktivieren , geschieht Folgendes, wenn FreeRADIUS ein RADIUS-Paket empfängt:

1. Es wird versucht, eine Verbindung zum LDAP-Server herzustellen (als Gastbenutzer oder unter Verwendung der angegebenen Identität, falls eine in konfiguriert ist ldap.conf).
2. Es sucht nach dem DN-Eintrag des Benutzers mithilfe des Filters unter dem Basis-DN (konfiguriert in ldap.conf).
3. Es ruft alle LDAP-Attribute ab, die es unter den in konfigurierten erhalten kann ldap.attrmap, und konvertiert sie in RADIUS-Attribute.
4. Diese Attribute werden der Check Items-Liste des RADIUS-Pakets hinzugefügt.

Wenn Sie das ldapModul in diesem authenticateAbschnitt aktivieren , geschieht Folgendes mit FreeRADIUS:

1. Es wird versucht, sich als Benutzer an den LDAP-Server zu binden .
2. Wenn eine Bindung möglich ist, ist die Authentifizierung erfolgreich, und ein Radius-AcceptPaket wird an den Client zurückgesendet. Andernfalls tritt ein Fehler auf, der zu einem Radius-RejectPaket führt.

Wie kann ich FreeRADIUS so konfigurieren, dass PEAP / MS-CHAP-v2 mit LDAP funktioniert?

Der wichtige Punkt hierbei ist, dass die Bindung für den Benutzer nur funktioniert, wenn der FreeRADIUS-Server das Klartextkennwort des Benutzers aus dem empfangenen RADIUS-Paket abrufen kann. Dies ist nur der Fall, wenn PAP- oder TTLS / PAP-Authentifizierungsmethoden verwendet werden (und möglicherweise auch EAP / GTC). Nur die TTLS / PAP-Methode ist wirklich sicher und in Windows standardmäßig nicht verfügbar. Wenn Ihre Benutzer eine Verbindung mit TTLS / PAP herstellen sollen, müssen sie eine TTLS-Supplicant-Software installieren, was selten eine Option ist. Meistens ist PEAP / MS-CHAP-v2 bei der Bereitstellung von WiFi mit WPA Enterprise-Sicherheit die einzig sinnvolle Option.

Das Fazit lautet also: Wenn Sie nicht PAP oder TTLS / PAP verwenden, können Sie das ldapModul sicher aus dem authenticateAbschnitt entfernen , und tatsächlich sollten Sie: binden, da der Benutzer nicht funktioniert.

Wenn Ihr Test bei der Verwendung funktioniert radtest, bedeutet dies wahrscheinlich, dass das ldapModul in diesem authenticateAbschnitt aktiviert ist : Es wird versucht, eine Bindung als Benutzer herzustellen, und da radtest die PAP-Authentifizierung verwendet, ist dies erfolgreich. Wenn Sie versuchen, eine Verbindung über den Zugriffspunkt herzustellen, schlägt dies jedoch fehl, da Sie PEAP / MS-CHAP-v2 verwenden.

Sie sollten das ldapModul aus dem authenticateAbschnitt entfernen und sicherstellen, dass Sie das mschapModul sowohl authorizeim authenticateAbschnitt als auch im Abschnitt aktivieren . Was passiert, ist, dass das mschapModul die Authentifizierung mit dem NT-PasswordAttribut übernimmt, das während der authorizePhase vom LDAP-Server abgerufen wird.

So sites-enabled/defaultsollte Ihre Datei aussehen (ohne alle Kommentare):

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

Und so sites-enabled/inner-tunnelsollte Ihre Datei aussehen:

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

Was ist mit der Warnung 'Kein "bekannt gutes" Passwort'?

Nun, Sie können es ignorieren. Es ist nur da, weil das ldapModul kein UserPasswordAttribut finden konnte , als es während der authorizePhase die Benutzerdetails vom LDAP-Server abrief. In Ihrem Fall haben Sie das NT-PasswordAttribut, und das ist vollkommen in Ordnung für die PEAP/MS-CHAP-v2Authentifizierung.

Ich vermute, die Warnung existiert, da das ldapModul, als es entworfen wurde, PEAP/MS-CHAP-v2noch nicht existierte. Das einzige, was zu diesem Zeitpunkt Sinn machte, war, das UserPassword-Attribut vom LDAP-Server abzurufen, um PAP, CHAP, EAP / zu verwenden. MD5 oder solche Authentifizierungsmethoden.

Ich werde versuchen, die OpenSSL-Frage hier zu beantworten: Die kurze Antwort lautet, FreeRADIUS 2.1.8 oder höher zu verwenden, einschließlich OpenSSL . Es ist in Ubuntu Lucid- und Debian Lenny-Backports verfügbar (und wird wahrscheinlich auch in Ubuntu Karmic-Backports enden).

Hier ist die lange Antwort:

Leider war die OpenSSL-Lizenz früher (etwas) nicht mit der FreeRADIUS-Lizenz kompatibel. Daher haben die Ubuntu-Leute beschlossen, eine FreeRADIUS-Binärdatei bereitzustellen, die nicht mit OpenSSL verknüpft ist. Wenn Sie EAP / TLS, PEAP oder TTLS wollten, mussten Sie die Quellen abrufen und sie mit der --with-opensslOption kompilieren (wie das von Ihnen verwendete Rezept erklärt).

Vor kurzem wurde das Lizenzierungsproblem behoben . FreeRADIUS-Versionen 2.1.8 oder höher können mit OpenSSL kompiliert und verteilt werden. Die schlechte Nachricht ist, dass die neueste stabile Ubuntu-Distribution (Karmic Koala) nur FreeRADIUS 2.1.0 ohne OpenSSL enthält (dasselbe gilt für Debian, da Lenny nur FreeRADIUS 2.0.4 enthält). Ich habe die Karmic-Backports überprüft, aber es sieht so aus, als ob FreeRADIUS 2.1.8 oder höher noch nicht hochgeladen wurde). Daher müssen Sie vorerst entweder zu Ubuntu Lucid (einschließlich FreeRADIUS 2.1.8) wechseln oder sich an die Kompilierung halten. Für Debian-Benutzer sieht es etwas besser aus: Die Lenny-Backports enthalten FreeRADIUS 2.1.8. Wenn Sie also etwas sehr stabiles und einfach zu installierendes und zu wartendes wollen, empfehle ich Ihnen, einen Server mit Debian Lenny bereitzustellen und das backportierte FreeRADIUS-Paket zu installieren (es gibt Ihnen auch die Möglichkeit, kostenlos Python-Module zu schreiben, ohne sich neu kompilieren zu müssen) alle experimentellen Module).

Ich habe eine Bescheinigung von http://CACert.org erhalten (wenn möglich, sollten Sie wahrscheinlich ein "echtes" Zertifikat erhalten)

Es gibt ein "Gotcha" mit "echten" Zertifikaten (im Gegensatz zu selbstsignierten Zertifikaten).

Ich habe einen von Thawte signierten verwendet. Es funktioniert einwandfrei und Benutzer sehen ein schönes "gültiges" Zertifikat mit dem Namen "so" www.my-web-site.com. Wenn der Benutzer das Zertifikat akzeptiert, versteht sein Computer das alles von derselben Zertifizierungsstelle ausgestellten Zertifikate als vertrauenswürdig eingestuft werden sollten (ich habe dies mit Windows Vista und MacOSX Snow Leopard getestet)! Wenn in meinem Fall ein Hacker beispielsweise ein www.some-other-web-site.comvon Thawte signiertes Zertifikat besitzt , kann er problemlos einen Man-in-the-Middle-Angriff ausführen, ohne dass auf dem Computer des Benutzers eine Warnung angezeigt wird!

Die Lösung hierfür liegt tief in der Netzwerkkonfiguration des Benutzers, um speziell festzulegen, dass nur "www.my-web-site.com" als vertrauenswürdig eingestuft werden soll. Es dauert nur eine Minute, aber die meisten Benutzer wissen nicht, wo sie dies konfigurieren sollen, es sei denn, Sie geben ihnen ein klares Verfahren und stellen sicher, dass jeder Benutzer es befolgt. Ich verwende immer noch "gültige" Zertifikate, aber ehrlich gesagt ist es enttäuschend zu sehen, dass sowohl Windows als auch MacOSX diesen "Bug" aufweisen: Vertrauen in die Zertifizierungsstelle anstelle des spezifischen Zertifikats. Autsch...

Laut dem Fehlerbericht sollte eine einfache Neuerstellung von FreeRADIUS das OpenSSH-Support-Problem beheben. Es muss nur einmal gemacht werden.

Ich bin mir nicht sicher, was die einfache Administration mit dem Setup zu tun hat. Je komplexer und detaillierter das Setup ist, desto einfacher ist es oft, es zu verwalten, da das Setup alle Grundlagen abdeckt. Müssen Sie die Konfiguration auch einfach auf anderen Servern ablegen? Wie viele WLANs richten Sie ein?

Nach der Konfiguration sollte die Verwaltung auf das Hinzufügen, Löschen und Ändern von LDAP-Benutzern beschränkt sein. Diese sollten einfach genug sein, um entweder mit ldapmodify (et al.) Ein Skript zu erstellen oder ein anständiges grafisches LDAP-Frontend zu finden und die Prozesse mit Screenshots zu dokumentieren.

Ich bin auf dasselbe Problem gestoßen. Ich musste die RADIUS-Quellen herunterladen und selbst kompilieren.

Sie können FreeRADIUS2 (mit OpenSSL) + EAP-TLS + WPA2-Enterprice verwenden. Hier ist eine detaillierte Anleitung . Windows XP SP3 bietet native Unterstützung sowie Windows 7, Android 2.3, iPhone und Symbian. Über die Kompatibilität mit SLDAP in einem solchen Schema weiß ich jedoch nichts.