FreeRadius: Unterschied zwischen den Versionen

Aus Doku-Wiki
Zur Navigation springenZur Suche springen
 
Zeile 201: Zeile 201:
 
Dieses checkItem hinzufügen
 
Dieses checkItem hinzufügen
 
  checkItem      User-Password                  userPassword
 
  checkItem      User-Password                  userPassword
 +
 +
= Radius testen =
 +
== radtest ==
 +
Wenn die Einrichtung des Freeradius Servers abgeschlossen ist, kann mittel dem Programm radtest getestet werden. Dafür mus das Paket freeradius-utils instaliert sein.
 +
radtest "ANMELDENAME" "PASSWORT" localhost 1812 "SECRET"
  
 
[[Kategorie:Linux]]
 
[[Kategorie:Linux]]
 
[[Kategorie:Anwendungen]]
 
[[Kategorie:Anwendungen]]

Aktuelle Version vom 9. Oktober 2020, 09:43 Uhr

Links

Hilfreiche Dokus

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.

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

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

ldap.attrmap

Dieses checkItem hinzufügen

checkItem       User-Password                   userPassword

Radius testen

radtest

Wenn die Einrichtung des Freeradius Servers abgeschlossen ist, kann mittel dem Programm radtest getestet werden. Dafür mus das Paket freeradius-utils instaliert sein.

radtest "ANMELDENAME" "PASSWORT" localhost 1812 "SECRET"