Freeradius Installation und Test

7111 · 30. Oktober 2017 um 15:42

Hallo Liste…

Ich versuche gerade den Freeradius Server aufzusetzen und stecke nach einiger Bastelei nun doch fest.

Nach der Anleitung unter http://docs.linuxmuster.net/de/latest/howtos/radius/installation.html ist der Freeradius nicht gestartet. Trotz De- und Neuinstallation gings auch nicht und schließlich hat mich $ /usr/sbin/freeradius -X drauf gebracht dass die Zertifikate fehlen.
https://www.linuxmuster.net/wiki/anwenderwiki:benutzerrechner:wlan:radius-accesspoint, Abschnitt (E) erklärt prima wie man die Zertifikate erzeugt. Am Ende fehlt allerdings der Hinweis darauf dass die Datei ‘dh’ noch mit nach /etc/freeradius/certs kopiert werden muss. (Oder vielleicht ist sie nur bei meiner Bastelei zwischendurch verschwunden.)
Beim Testen mit ‘steve’ wird der Request jedoch offenbar nicht akzeptiert:

root@server:/etc/freeradius/certs# radtest steve testing 127.0.0.1:1812 10 testing123

Sending Access-Request of id 67 to 127.0.0.1 port 1812
User-Name = "steve"
User-Password = "testing"
NAS-IP-Address = 10.16.1.1
NAS-Port = 10
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=67, length=20

Mir kommt komisch vor dass das Passwort mal ‘testing’, mal ‘testing123’ zu lauten scheint aber wenn ich alle erreichbaren Einträge gleich mache funktionierts auch nicht.

Ich habe alle Hinweise in https://www.linuxmuster.net/wiki/version3:problemkonfiguration-freeradius gelesen. Die ersten beiden sind bei mir ok (bzgl. snmp.conf und symbolische Links), die anderen scheinen in dieser Version von Freeradius nicht mehr vorzukommen.

Oder kann man ‘Access-Reject’ hier ignorieren ?

Danke fürs Mitdenken und schöne Ferien !

Martin

baumhof · 30. Oktober 2017 um 16:38

Hallo Martin,

Sending Access-Request of id 67 to 127.0.0.1 port 1812
User-Name = „steve“
User-Password = „testing“
NAS-IP-Address = 10.16.1.1
NAS-Port = 10
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=67,
length=20

nur so ein Gedanke: der freeradius nimmt nur Anfragen von Cleint IPs an,
die in der /etc/freeradius/clients.conf erlaubt sind.
Steht da die 127.0.0.1 drin?

Bei mir (Auszug):

client ipcop {
ipaddr = 10.16.1.254
secret = geheim
}

LG

HOlger

Cgsman · 30. Oktober 2017 um 17:32

Hi, Martin,

hänge auch gerade am Freeradius.
Hast Du diese Seite schon gesehen ?

http://docs.linuxmuster.net/de/latest/howtos/radius/installation.html#radius-servers-testen

L.G.,
Christoph

P.S.
Das Rejecten darf man NICHT akzptieren !

7111 · 30. Oktober 2017 um 20:35

@ Holger: Ja, in der Anleitung steht ja drin dass man den localhost zu den clients hinzufügen soll und das habe ich auch getan. Villeicht sollte ich mir den Eintrag doch noch mal genauer anschauen, eventuell war mein copy&paste zu oberflächlich.

@Christoph: Ja, das versuche ich abzuarbeiten und ich hänge halt gerade biem Test…

Danke für eueren Input !

baumhof · 30. Oktober 2017 um 20:47

Hallo Martin,

stimmt das radius secret in der clients.conf?

LG
Holger

zefanja · 30. Oktober 2017 um 23:09

Hallo Martin,

um die verschlüsselte Abfrage am RADIUS-Server zu testen, brauchst du ein Tool namens rad_eap_test. Das geht mit dem Standardtool radtest nicht. Für den Test der grundsätzlichen Funktionsweise reicht es aber aus.

Bitte schickt doch mal deine /etc/freeradius/clients und /etc/freeradius/users.

vG

7111 · 31. Oktober 2017 um 10:17

Danke für eure Ideen, ich komme am Montag wieder in die Schule und schau mal was sich ergibt.

Schöne Ferien !

Cgsman · 31. Oktober 2017 um 12:40

Alles klar !
Ich bin hier ein Stück weiter:

Bei mir klappt jetzt alles bis auf
a) das Ausfiltern der Gruppen (Sobald ich das berücksichtige:

http://docs.linuxmuster.net/de/latest/howtos/radius/ldap.html
(Zugriffsbeschränkungen aktivieren)

darf keiner mehr ins Wlan. Da scheint die Gruppenzugehörigkeit (bei mir) nicht richtig aufgelöst zu werden. Ansonsten ist bei mir die users-Datei leer - habt Ihr da etwas anderes stehen ?

b) Zertifikate.
Ich würde gerne mit Zertifikaten arbeiten, die ich zum Download anbiete oder per eMail versende. (Nicht so wichtig).

Aber noch ein Tipp:
Bei freeradius -X fliegt ein realer Wlan-Benutzer nach wenigen Sekunden wieder raus ! Es gibt dann auch Probleme mit der nächsten Authentifizierung. Vermutlich “pollt” das Programm immer ein paar Sekunden und kommt nach einer Ausruhezeit aus dem Tritt.
Das bedeutet:
Sobald man ein paar Sekunden im Wlan war, kann man die weitere Funktionalität mit
service freeradius start
anwerfen und auch erwarten, dass es weiterhin klappt.

L.G.
Christoph Gü

P.S.
Bislang sollte man bei der Einrichtung von freeradius nicht alles mischen, was im “alten” und neuen Wiki steht. Es reicht die SPHINX-Doku aus dem neuesten Wiki !

zefanja · 31. Oktober 2017 um 13:52

Hallo Christoph,

Hast du den Gruppenfilter in der /etc/freeradius/radiusd.conf aktiviert? Die beiden Filter die unter Zugriffsbeschränkung stehen unterscheiden sich. Der erste Filter (DEFAULT Group != p_wifi) fragt nicht die LDAP Gruppe direkt ab, sondern die UNIX-Gruppe p_wifi. Die Mitglieder dieser Gruppen sollte eigentlich gleich sein. Vielleicht sind deine Kollegen und Schüler nicht in dieser Gruppe? (Such mal nach p_wifi hier im Forum, ich hab grad vergessen, wie man sich die Mitglieder anzeigen lassen kann).

Falls die da drin stehen, sollte die Authentifizierung klappen. Evtl. das Logging aktivieren (siehe Doku) und mit freeradius -X schauen, woran es liegt.

Wir haben das bei uns teilweise umgesetzt. Ich werde die Doku bei Gelegenheit noch ergänzen.

Wie genau meinst du das? Fliegt der Benutzer bei freeradius -X raus und bei service freeradius start nicht?

vG

Cgsman · 31. Oktober 2017 um 15:19

Hallo zefanja -,

ja, genau so ist es: Im Debugmodus “knallt’s”, im Normalbetrieb geht’ ganz problemlos.
V.G.

Christoph Gü

Cgsman · 31. Oktober 2017 um 19:25

Hallo, liebe Linuxmustermenschen,

ich stehe dicht vor dem Ziel dennoch auf dem Schlauch:
Ich habe in der Doku gesehen, dass man als Lehrer eigentlich nicht mehr viel tun muss, als das WLAN über die SK anzuschalten, sofern der Administrator dies so eingestellt hat (!)
Ok: Habe in der Schulkonsole versuchsweise Klasse 5a das Wlan als Admin eingeschaltet und als Normallehrer einigen Schülern das Wlan im Unterricht freigegeben.

Dennoch kommt, wenn ich in der users-Datei von freerad lediglich eintrug:

Test1

DEFAULT Group != p_wifi
DEFAULT Auth-Type := Reject
  Reply-Message = "Your are not allowed to access the WLAN!"

oder dann später:

Test 2

DEFAULT Ldap-Group == "cn=p_wifi,ou=groups,dc=linuxmuster-net,dc=lokal"
DEFAULT Auth-Type := Reject
   Reply-Message = "Your are not! allowed to access the WLAN!"

immer die Fehlermeldung:

rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=117, length=63
	Reply-Message = "Your are not! allowed to access the WLAN!"

Nehme ich die Zeilen raus, klappt die radius-Anmeldung, man kann das Wlan auch benutzen.
(geprüft direkt und mit radtest)

Der entsprechende Abschnitt in der radiusd.conf:

 server = "localhost"
                identity = "cn=admin,dc=linuxmuster-net,dc=lokal"
                password = brsieebdkdjhakhdksdhakjskdhaksdkajhskdhakjshdkajskjahsdk
                basedn = "ou=accounts,dc=linuxmuster-net,dc=lokal"
                filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
                # base_filter = "(objectclass=radiusprofile)"
                groupmembership_filter = (&(objectClass=posixGroup)(memberUid=%u)

wobei ich hier bereits den base_filter versuchsweise aktiviert habe.
Außerdem fällt auf, dass die filter-Anweisung von der Doku abweicht, aber das macht wohl nix, oder ?

Jedenfalls bemängelt das auth-log von freeradius einen “bad searchfilter”.

Achso, und ich habe den freeradius-Server immer wieder neu gestartet und sogar den slapd.
Und das kommt raus, bei

sophomorix-project -i -p p_wifi

nämlich nur den Admin als Admin, die Lehrer und meine Versuchsklasse alle als Gruppe unter Member Groups, die freigegebenen Schüler als Member by Option. Hieran ändert sich nichts - das scheint alles zu stimmen !

20:26/130 server ~ # sophomorix-project -i -p p_wifi
+----------------------+----------+----------+--------------+-----------------+
|Project:              |          | Members  | Member       | Member          |
|   p_wifi             | Admins   | byOption | Groups       | Projects        |
+----------------------+----------+----------+--------------+-----------------+
|gidnumber: 10040      | administrator| frankefa |5a            |                 |
|LongName:             |          | sittoma  |teachers      |                 |
|  p_wifi              |          |          |              |                 |
|AddQuota: 0 MB        |          |          |              |                 |
|AddMailQuota: 0 MB    |          |          |              |                 |
|MailAlias: 0          |          |          |              |                 |
|MailList: 0           |          |          |              |                 |
|SophomorixStatus: P   |          |          |              |                 |
|Joinable: 0           |          |          |              |                 |
|MaxMembers: 0         |          |          |              |                 |
|CreationTime:         |          |          |              |                 |
|  2016-09-04 13:21:59 |          |          |              |                 |
+----------------------+----------+----------+--------------+-----------------+
|            users: 81 |        1 |        2 |            2 |               0 |
+----------------------+----------+----------+--------------+-----------------+

Danke für jede Hilfe,
Christoph Gü

zefanja · 31. Oktober 2017 um 22:18

Doch, den solltest du ändern zu filter = "(uid=%u)". Daher kommt wahrscheinlich auch deine Fehlermeldung.

Dann klappt die Anmeldung aber für jeden Schüler und Lehrer und man hat keine Einschränkung mehr.

Was für Fehlermeldungen kommen denn noch so, wenn du freeradius -X laufen hast und versuchst einen LDAP Benutzer zu authentifizieren?

vG

Cgsman · 31. Oktober 2017 um 23:47

Danke, Zefanja,

beide Varianten funktionieren !
Ich habe aber eine zweite schließende Klammer vergessen (beim Suchfilterstring) - deswegen immer der “bad request”.

Meine radiusd.conf sieht also so aus:

 ldap {
                #
                #  Note that this needs to match the name in the LDAP
                #  server certificate, if you're using ldaps.
                server = "localhost"
                identity = "cn=admin,dc=linuxmuster-net,dc=lokal"
                password = geheim
                basedn = "ou=accounts,dc=linuxmuster-net,dc=lokal"
                # laut Doku
                # filter = "(uid=%u)" # laut Doku
                # urspruenglich:
                filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"

                # base_filter = "(objectclass=radiusprofile)"
                groupmembership_filter = (&(objectClass=posixGroup)(memberUid=%))

                #  How many connections to keep open to the LDAP server.
                #  This saves time over opening a new LDAP socket for
                #  every authentication request.
                ldap_connections_number = 5

…
Danke für’s Mitdenken und Helfen,
Christoph Gü

P.S. Ich kann komischerweise keine “Beitra ist die Lösung”-Markierung mehr setzen - wieso ???

7111 · 8. November 2017 um 17:36

Ich bin grad am testen und es ergibt sich folgendes:

In meiner clients.conf steht:

client ipcop {
ipaddr = 10.16.1.254
secret = oeboonge
}

client localhost {
ipaddr = 127.0.0.1
secret = testing123
}

…und in der users ist steve die erste nicht auskommentierte Zeile:

steve Cleartext-Password := “testing”

Ein paar Ideen:

Der Daemon läuft tatsächlich, denn der reject würde sonst nicht kommen.
Das Radiussecret testing123 stimmt offenbar, denn wenn ich es beim radtest abändere gibts eine Fehlermeldung.
Das Userpasswort testing scheint bei meinem Problem keine Rolle zu spielen. Es ändert sich nichts wenn ich es ändere.
Wenn der Daemon nicht läuft und ich starte freeradius -X ergibt die Ausgabe für mich keinen Hinweis auf ein Problem und endet mit:

…
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.

In /var/log/freeradius/radius.log erscheint bei jedem Verbindungsversuch folgender Eintrag:

Wed Nov 8 18:22:10 2017 : Error: [ldap] bind to ldap.your.domain:389 failed: Can’t contact LDAP server
Wed Nov 8 18:22:10 2017 : Error: [ldap] (re)connection attempt failed

…und in der Tat fehlen in /etc/freeradius/radiusd.conf die Einträge zum ldap !

Laut Howto in der Doku: “Bei der Installation von Linuxmuster.net wurde bereits die notwendige Konfiguration in der Datei /etc/freeradius/radiusd.conf vorgenommen.”, was für mich heißt dass irgendwo etwas mit den Konfigurationsdateien sehr schief gelaufen ist. Ich habe noch ein Backup von radiusd.conf gefunden wo die Einträge zum ldap richtig enthalten sind, aber der Daemon startet dann nicht mehr und freeradius -X liefert:

…
Unable to open file “/etc/freeradius/snmp.conf”: No such file or directory
…

Und die Datei ist tatsächlich nicht vorhanden.

Sorry für den etwas längeren Post. Gibt es eine Möglichkeit die Konfigurationsdateien nochmals zu erzeugen ?

Danke fürs Mitdenken…

Martin

7111 · 8. November 2017 um 17:43

Hm. Ich habe mal in dem Backup von radiusd.conf die Zeile mit $INCLUDE auskommentiert, also:

snmp = no
#$INCLUDE snmp.conf

…und siehe da, der Daemon startet und:

Sending Access-Request of id 109 to 127.0.0.1 port 1812
User-Name = "steve"
User-Password = "testing"
NAS-IP-Address = 10.16.1.1
NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=109, length=20

Jetzt bin ich mir nicht so ganz sicher ob in den Konfigurationsdateien nicht vielleicht doch noch ein paar Ostereier stecken. Was meint ihr ?

7111 · 8. November 2017 um 17:53

Oha, die Authentifizierung per ldap scheint auch zu funktionieren, denn der entsprechende Test laut http://docs.linuxmuster.net/de/latest/howtos/radius/ldap.html
sieht gut aus:

Sending Access-Request of id 33 to 127.0.0.1 port 1812
User-Name = "xxx"
User-Password = "xxxxxx"
NAS-IP-Address = 10.16.1.1
NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=33, length=20

Gruß
Martin

7111 · 13. März 2018 um 13:59

For the record, falls es mal jemand braucht:

Nach dem Update aller Linuxmuster-Pakete lief die Authentifizierung wieder nicht. Mittels einiger Sucherei hat sich herausgestellt dass die Rechte von /etc/freeradius/users falsch waren. Mit 644 statt 640 gehts.

Laut Doku horcht der Radius Server auf dem Port 1182, aber IMHO müsste das 1812 heißen. Siehe: http://docs.linuxmuster.net/de/latest/systemadministration/network/radius/installation.html#firewall-konfigurieren

Gruß
Martin

zefanja · 14. März 2018 um 12:03

Danke @7111 für den Hinweis. Hab’s geändert.

vG