FreeRADIUS mit EAP-TTLS und LDAP zur sicheren WLAN Authentifizierung

1. Beschreibung
Warum WPA2 Enterprise?
WPA2 Enterprise ermöglicht es jedem Benutzer eigene Zugangsdaten verwenden zu lassen, falls ein Benutzer keinen Zugriff mehr auf das WLAN Netzwerk haben soll, muss nur dessen Account deaktiviert werden. Bei einem Passphrase geschütztem WPA Netzwerk wäre hier der Austausch der Passphrase notwendig, welche man dann an alle bestehenden Nutzer erneut verteilen muss.

Warum EAP-TTLS?
EAP-TTLS ist eines der flexibelsten EAP Verfahren, da es kaum eine Beschränkung in der Auswahl des Backends zur Passwortverwaltung gibt ( Textdateien, SQL-Datenbanken, Active Directory oder LDAP ).
EAP-TTLS ist wie auch EAP-PEAP ein sogenanntes 2 Phasen Verfahren, hierbei wird in der ersten Phase ein TLS-Tunnel zwischen dem WLAN Client und dem FreeRADIUS-Server aufgebaut.
In der zweiten Phase unterscheiden sich die Verfahren jedoch deutlich, hier unterstützt EAP-PEAP nur MS-CHAPV2, dagegen werden unter EAP-TTLS folgende Verschlüsselungsverfahren unterstützt:

  1. EAP
  2. CHAP
  3. MS-CHAP
  4. MS-CHAPv2
  5. PAP

Sollten die Passwörter im LDAP-Server als besonders sichere „Salted SHA-1“-Hashes hinterlegt sein kann nur PAP in der zweiten Phase eingesetzt werden, wie man in dieser Tabelle erkennen kann:
Protocol and Password Compatibility

Der in der ersten Phase initialisierte TLS-Tunnel schützt die im unverschlüsselten Password Authentication Protocol (PAP) übertragenen Zugangsdaten.

2. Konfiguration des FreeRADIUS Servers
Installation der Software
Auf dem Server werden die folgenden Pakete installiert:

apt-get install freeradius freeradius-ldap freeradius-utils

SSL Zertifikate erzeugen
Während der Installation werden zumindest unter Ubuntu und Debian sogenannte selbst signierte SnakeOil Zertifikate angelegt.
Diese SnakeOil Zertifikate eignen sich zum testen des Aufbaus sollten aber vor der Inbetriebnahme durch Kaufzertifikate oder zumindest durch die Zertifikate einer eigenen CA ausgetauscht werden.

AccessPoints als Clients des FreeRADIUS-Server einrichten
Die AccessPoints werden in der Datei /etc/freeradius/clients.conf eingerichtet:

client {
secret = Passwort
shortname = Symbolischer Name
}

Den FreeRADIUS-Server auf EAP-TTLS konfigurieren
Die zu verwendende Verschlüsselungsmethode wird in der Datei /etc/freeradius/eap.conf eingerichtet:
Zuerst muss der Standard EAP-Typ eingestellt werden:

default_eap_type = ttls

Für die TLS Konfiguration müssen das Server Zertifikat, der Private Key, die Diffie-Hellman Parameter und /dev/urandom als Zufallszahlengenerator angegeben werden:

tls {
private_key_file = /etc/freeradius/certs/radius-key.pem
certificate_file = /etc/freeradius/certs/radius-cert.pem
dh_file = /etc/freeradius/certs/dh.pem
random_file = /dev/urandom
cipher_list = "DEFAULT"
}

Die Diffie-Hellmann Parameter können mit diesem Befehl erzeugt werden:

openssl dhparam 2048 > /etc/freeradius/certs/dh.pem

Zuletzt müssen noch einige EAP-TTLS Konfigurationen angepasst werden:

ttls {
default_eap_type = md5
virtual_server = "inner-tunnel"
}

Warum in der TTLS Konfiguration der default_eap_type auf MD5 gestellt werden muss konnte ich nicht herausfinden, falls man den Wert ändert startet der FreeRADIUS Server nicht mehr.
Der Parameter virtual_server lädt die entsprechende Konfiguration für die Phase 2.

Verbindung zum OpenLDAP Server einrichten
Um den FreeRADIUS-Server an den LDAP Server anzubinden müssen die Verbindungsparameter und die entsprechenden LDAP-Filter in die Datei modules/ldap eingetragen werden:

ldap {
server = ldap.example.org
port = 636 # Oder 389 falls der LDAP-Server keine SSL gesicherten Verbindungen anbietet.
basedn = "dc=example,dc=org"
filter = "(&(objectClass=posixAccount)(uid=%{User-Name}))"
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{User-Name}))"
groupmembership_attribute = "cn=Gruppe,ou=Groups,dc=example,dc=org"
ldap_connections_number=5
dictionary_mapping = ${confdir}/ldap.attrmap
}

Die LDAP Filter in diesem Beispiel müssen nicht unbedingt auf jedem LDAP Setup funktionieren, diese muss man dann an dass jeweiliges Schema anpassen.

Abschließend muß die Umsetzung zwischen den RADIUS und den LDAP Attributen in der Datei /etc/freeradius/ldap.attrmap konfiguriert werden.
Es sollten alle eventuell vorhandenen Attribute gelöscht werden, sodass die Datei die folgenden fünf Zeilen enthält:

checkItem $GENERIC$ radiusCheckItem
replyItem $GENERIC$ radiusReplyItem
checkItem LM-Password sambaLmPassword
checkItem NT-Password sambaNtPassword
checkItem SMB-Account-CTRL-Text acctFlags

3. Konfiguration der AccessPoints
Mittlerweile unterstützen die gängisten AccessPoints und WLAN-Router das RADIUS-Protokoll, hierbei sind immer folgende Angaben zu machen:

  1. IP-Adresse des RADIUS-Servers
  2. Der RADIUS-Server Port: 1812
  3. Das Shared Secret aus der clients.conf

Nun sollte man ein funktionsfähiges WPA2 Enterprise Setup besitzen, falls es zu Problemen kommt kann man den FreeRADIUS in einem ziemlich gesprächigem Modus starten:
freeradius -vv

RADIUS und EAP als Protokolle und FreeRADIUS als Software sind recht komplexe Themengebiete, also nicht gleich aufgeben falls etwas nicht klappt.
Für alle die sich tiefer mit der Materie auseinandersetzen wollen kann ich folgende RFCs empfehlen:
RFC zu RADIUS: http://www.ietf.org/rfc/rfc2865.txt
RFC zu EAP-TTLS: http://tools.ietf.org/html/rfc5281

9 thoughts on “FreeRADIUS mit EAP-TTLS und LDAP zur sicheren WLAN Authentifizierung

  1. Pingback: Anonymous
  2. Hallo,

    die Anleitung ist toll, aber spätestens bei den TLS Settings stellt sich mir die Frage, wo ich diese Werte setzen muss, sprich in welcher Datei. Ein paar Zeilen mehr wären hier äußerst hilfreich gewesen, so muss ich leider weiter nach einer brauchbaren Anleitung suchen.

    MfG
    Sven

    1. In dem Abschnitt „Den FreeRADIUS-Server auf EAP-TTLS konfigurieren“ wird auf die eap.conf hingewiesen, da die TLS Konfiguration zu diesem Abschnitt gehört wird die Konfiguration entsprechend auch dort eingetragen.

  3. Blöde Frage zum Thema Zertifikate: Wenn man die SnakeOil-Zertifikate durch „richtige“ ersetzen will – worauf sollten diese dann ausgestellt sein? Auf IP-Adressen geht ja nicht, und auf den Hostname des RADIUS-Servers würde ja erfordern, dass der Client den schon per DNS auflösen kann – obwohl er möglicherweise ja noch gar kein Netz hat?!

    1. Hallo,

      auf IP-Adressen kann man Zertifikate ausstellen, allerdings nur mit einer eigenen CA 😉
      Üblicherweise stelle ich durch die Organisations CA ein SAN Zertifikat mit allen benutzten IP-Adressen und Hostnamen des RADIUS Servers aus.

      MfG
      Dominik

      1. Danke für die Antwort. „Eigene CA“ ist natürlich ok für Clients, die das eigene root-cert z.B. per GPO aufgedrückt bekommen haben, aber für BYOD wäre das weniger praktisch. Bei Kaufzertifikaten dagegen kann ich mW nur mit Namen arbeiten – gegen welche Namen geprüft werden könnte, ist mir in der Phase der Netzanmeldung dagegen ein Rätsel … Vielleicht werde ich durch ein paar Experimente schlauer 🙂

        1. Hallo Dominik,
          Wenn die eigene interne CA steht, dann müsste doch eingentlich ein subCA Zertifikat erstellt und auf dem Radius installiert werden, damit dieser die weiteren Zertifikate ausstellen kann, die dann im WLAN genutzt werden, oder?
          Welches Format muss ich beim Export der Zertifikate auf der CA verwenden, damit der freeradius diese auch akzeptiert? Ich habe nun schon mehrere Versionen probiert, aber der radius Server startet nach dem Austausch der Zertifikate nicht mehr. Gibt es dazu eine brauchbare Anleitung im Netz?

          Viele Grüße
          Stephan Frank

          1. Hallo Stephan,

            du gehst vermutlich in Richtung EAP-TLS, damit sich die Clients mittels Client-Zertifikaten authentifizieren?
            Zumindest mein Artikel bezieht sich auf EAP-TTLS, hierbei wird genauso wie für EAP-PEAP ein Zertifikat nur zur Authentifizierung des RADIUS-Servers gegenüber den Clients genutzt, damit Sie die Gegenseite überprüfen können an die sie im nächsten Moment ihren Benutzernamen und Kennwort übermitteln. Das Zertifikat hat hier den gleichen Nutzen, den man beispielsweise von einem SSL-Webserver kennt.

            Ansonsten hast du natürlich Recht, eine richtige interne CA hat eine (möglichst Offline) Root-CA und diese stellt dann eine subCA aus. Mittels dieser subCA kannst du dann Clientzertifikate für die EAP-TLS Authentifizierung erstellen.
            Die Ausstellung der Zertifikate für die Clients übernimmt aber nicht der FreeRADIUS, dies ist eine Aufgabe für den Admin 🙂

            Ich verwende üblicherweise Zertifikate im PEM Format.

            Was gibt denn ein manueller Start des FreeRADIUS mit vollen Debuginformationen aus?
            An die Infos kommst du mit folgendem Kommando:
            freeradius -xx oder radiusd -xx

            Viele Grüße
            Dominik Kupschke

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.