FreeRadius
Inhaltsverzeichnis
Links
Hilfreiche Dokus
- Konfiguration-freeradius.pdf
- FreeRADIUS HowTos
- heinlein - FreeRADIUS und OpenLDAP
- CONFIGURING FREERADIUS FOR LDAP OVER SSL AUTHENTICATION
- List of RADIUS attributes
Sicherheit
Um die Komunikation von Radius Servern untereinander abzusichern, kann der RadSec Proxy verwendet werden. Dieser nimmt die Anfrage eines Radius Servers auf den Standard UDP Ports an und komuniziert dann mit dem entfernten RadSec Proxy über TCP, abgesichert über Zertifikate.
Eine Doku finden Sie hier
Installation
aptitude install freeradius freeradius-utils Die folgenden NEUEN Pakete werden zusätzlich installiert: freeradius freeradius-common{a} freeradius-mysql freeradius-utils{a} libdbi-perl{a} libfreeradius2{a} libltdl7{a} libnet-daemon-perl{a} libpcap0.8{a} libplrpc-perl{a} libpython2.6{a} ssl-cert{a}
LDAP Modul
aptitude install freeradius-ldap
Konfiguration
Bevor ich hier auf meine Konfigurationsschritte eingehe, habe ich zwei Anmerkungen dazu.
- Meine Konfiguration funktioniert bei mir, obwohl ich in FreeRadius nicht so tief eingestiegen bin um alle Einstellungsmöglichkeiten zu verstehen, bzw immer zu verstehen warum etwas nicht geht. In vielen Dokumentationen findet sich der Hinweis, die original Konfiguration nur Stück für Stück zu anzupassen und nur das zu ändern, was nötig ist um den FreeRadius an seine Umgebung anzupassen. Das ist sicherlich kein schlechter Rat.
- Als Einsteiger in das Thema bin ich immer wieder auf den Hinweis gestoßen, dass die Passwörter im LDAP am besten im Klartext vorliegen sollten, sonnst würde es niocht gehen. Deshalb hier eine Übersicht zur Passwort und Protokoll Kompatibilität. Meiner Ansicht nach sind Klartext Passworte in einer DB/LDAP/Textfile usw. ein klares "No GO". Woher also solche Aussagen?
Windows 7 (und älter) kann ohne zusätzlicher Software NT Hash (ntlm_auth) Passwörter übermitteln. Wenn in der DB/LDAP/Textfile ein MD5 gehashtes Passwort steht, kann Windows 7 (und älter) sich nicht dagegen authentifizieren, da dieses Betriebsysteme nur NT Hash (ntlm_auth) übermittelt.
Ein NT Hash (ntlm_auth) kann nicht mit einem MD5 Hash verglichen werden
Wenn das Passwort also im Klartext (NoGo) vorliegt kann PAP Modul dieses mit dem gesendeten NT Hash vergleichen. Kann man nicht darauf verzichten, dass sich Window 7 (und älter) Clients anmelden können, müssen die Passwörter im LDAP als NT Hash abgelegt werden, oder man installiert secureW2. Diese Software erweitert WIndow 7 um verschiedenen Möglichkeiten der Passwortübermittlung.
Übersicht
Die folgenden Dateien habe ich angepasst, sie finden sich unter Debian/Ubuntu unter /etc/freeradius
- radiusd.conf
- eap.conf
- users
- clients.conf
- proxy.conf
Wenn die Benutzerkonten in einem LDAP Server liegen kommen folgende Konfgurationsdateien hionzu.
- sites-enabled/default
- sites-enabled/inner-tunnel
- ldap.attrmap
- modules/ldap
radius.conf
Die kann man belassen wie sie ist. Ich habe überprüft dass die Einstellungen auf "no" konfiguriert werde, da sonst die Passwörter im Logfile auftauchen, sollte ein Client ein Klartextpasswort übermitteln:
auth_badpass = no auth_goodpass = no
Hiermit kann man im Logfile einen Text hinzufügen um es besser auswerten zu können.
msg_goodpass = "msg_goodpass" msg_badpass = "msg_badpass"
eap.conf
Hier nur die Änderungen, die angepasste Konfigurationsdatei findet sich hier
eap { ... default_eap_type = ttls ... ttls { ... default_eap_type = gtc copy_request_to_tunnel = yes ... } ... }
Eigentlich sollte unter ttls als default_eap_type md5 funktionieren. Das hat bei mir aber zu Problemen geführt, so dass ich auf gtc umgestellt habe. Hierbei übermittelt der Client (ausser windows 7 und älter) im inneren, schon verschlüsselten Tunnel das Passwort als Klartext. PAP wandelt dieses in MD5 um und vergleicht es mit dem in der Datenbank.
users
Für die Datei users habe ich zwei Konfigurationsbeispiele. Hierbei ist der Unterschied, ob ein Realm verwendet wird oder nicht. Ein Realm ist dann notwendig, wenn Nutzer wie zum Beispiel im eduroam Netz, sich nicht nur in Ihrer Heimateinrichtung anmelden können, sondern überall wo das eduroam Netz angeboten wird. Dies ist bei eduroam Weltweit. Damit die Radiussever entscheiden können woher der Nutzer kommt und somit wo der Radius Server steht, der den Nutzer authentifizieren kann wird der Realm benötigt. Ein gültiger Nutzername sieht dann so aus:
Nutzer Trenner Realm v-----------------vv---------- MeineNutzerKennung@example.com
Bei ausschließlich lokaler Anmeldung kann der Realm entfallen
- Konfigurationsbeispiel mit Realm
- Konfigurationsbeispiel ohne Realm
clients.conf
In der clients.conf wird konfiguriert, wer anfragen an den Radius Sever stellen darf.
# Freeradius standart Konfiguration client localhost { ipaddr = 127.0.0.1 secret = testing123 require_message_authenticator = no nastype = other # localhost isn't usually a NAS... } # Zusätzlicher Client - WLAN Accesspoint oder WLAN Router client 10.0.0.10 { secret = testing123 shortname = wlan-router nastype = other }
proxy.conf
proxy server { default_fallback = yes } home_server localhost { type = auth ipaddr = 127.0.0.1 port = 1812 secret = testing123 require_message_authenticator = yes response_window = 20 zombie_period = 40 revive_interval = 120 status_check = status-server check_interval = 30 num_answers_to_alive = 3 max_outstanding = 65536 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server_pool my_auth_failover { type = fail-over home_server = localhost } realm example.com { } realm LOCAL { } realm NULL { } realm DEFAULT { }
Sollte der Verbindungsaufbau an einen anderen Server oder einen Radsec Proxy weitergeleitet werden müssen, wird das in die Default Section eingetragen.
- Hier ein Beispiel für einen lokalen Radsec Proxy
realm DEFAULT { authhost = 127.0.0.1:2084 accthost = 127.0.0.1:2085 secret = testing123 nostrip }
- Hier ein Beispiel für einen entfernten Radius Server
realm DEFAULT { authhost = radius1.dfn.de:1812 accthost = radius1.dfn.de:1813 secret = testing123 nostrip
sites-enabled/default
Enthält die Default Policy für den Verbindungsaufbau mit dem Client. Hier werden die Authentifiezierung (CHAP, MS-CHAP, und EAP) ausgehandelt um den äußeren Tunnel aufzubauen. Einzige Änderung hier, ist der Eintrag für den LDAP Modul in der Sektion authorize - Download default
authorize { ... files ldap expiration logintime pap }
sites-enabled/inner-tunnel
Beinhaltet die Konfiguration für EAP und Einträge für das LDAP Modul. Ich habe nur in der Sektion authorize den Aufruf für das LDAP Modul hinzugefügt - Download inner-tunnel
authorize { ... files ldap expiration logintime pap }
modules/ldap
Hier wird die Verbindung zum LDAP Server konfiguriert. Natürlich muss das an das eigenen System angepasst werden
ldap { server = "ldaps://ldap.example.com" identity = "uid=radius,ou=accounts,dc=example,dc=com" password = "testing123" basedn = "dc=example,dc=com" filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})" base_filter = "(objectclass=posixAccount)" ### Gruppenzugehörigkeit prüfen # groupname_attribute = # groupmembership_filter = # groupmembership_attribute = ### Default values dictionary_mapping = ${confdir}/ldap.attrmap ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 start_tls = no edir_account_policy_check = no keepalive { idle = 60 probes = 3 interval = 3 } }