Freeradius: upgrade auf 3.2.4: Wifi streikte - aus \ wird \\

Tobias · 3. Juni 2024 um 10:26

Hi zusammen:
Beim automatischen Upgrade hat es irgendwie an der freeradius-Konfiguration was zerschossen, so dass bei uns niemand mehr ins Internet kam.

    Packages with configuration changes:
    -freeradius-config 3.2.3-1 amd64
    +freeradius-config 3.2.4-1 amd64

Ich hätte auch ein diff, kann aber keine problematische Änderung an der Config erkennen.

Server reboot (auf dem auch der freeradius läuft ) hat nicht geholfen.

Rumgespielt mit der Config und die Restriktion --require-membership-of=LINUXMUSTER\wifi
nur in /etc/freeradius/3.2/mods-available/mschap entfernt. Neu starten des Dienstes. Dann tat es wieder.
Ist aber immer noch unklar, ob das wirklich die Ursache ist.

VG, Tobias

Michael · 3. Juni 2024 um 16:02

Hallo Tobias,
normalerweise spuckt doch freeradius -X oder notfalls auch freeradius -XX ziemlich detailliert aus, wo es gerade hakt, oder? Hast Du das ausprobiert?

Viele Grüße,
Michael

maxEG · 3. Juni 2024 um 20:10

Hallo Tobias,
ich habe heute im Zuge des 7.2 Upgrades damit gekämpft, bei mir war es so, dass ich in require-membership zwei mal das Backslash zwischen Domain und Gruppe eintippen musste, damit es einmal ankommt. Ich hatte sowas in den Logs gesehen, dass er die Domain nicht auflösen/trennen konnte. Ich habe das auch beim Eintrag im eap Modul gemacht…
ich habe immer mit
service freeradius debug
getestet
LG
Max

Tobias · 3. Juni 2024 um 21:01

Ihr seid ja Schatzis…
Das wäre ja ein Zufall, wenn es wirklich daran läge: \\ statt \ im require-membership und du das zufällig heute feststellst.
Es kann bei mir eigentlich nur am Update von gestern abend liegen, dass ich unschuldig am Server angeschmissen hatte.
Murphys Law: Deutsch Fortbildung im Haus, die dann weder WLAN noch Apple-TV-Zugriff hatte, weil unsere Apple-TVs über Radius am Netz hängen.

Wenn jemand noch einen Befehl „übrig“ hätte, mit dem man den Wifi-Zugang testen könnte? radtest hat bei mir nicht funktioniert (also per Wifi komme ich rein, während radtest fehlschlägt).
Ich weiß, dass ich schonmal eine einfach CLI-Möglichkeit hatte, eine WIFI-Anmeldung per Radius zuverlässig nachzustellen, statt immer tatsächlich vor Ort mich ins WLAN zu verbinden.

(Fehlt noch, dass ich einen Laptop in den Serverraum stelle, der per LAN angebunden ist, den ich remote dann versuche zusätzlich mit dem WIFI zu verkuppeln… Oder noch besser: der server kriegt eine WIFI-Karte+Antenne und das ganze wird in einer VM simuliert … hi hi hi klingt wie zu Unizeiten, wo man jeden Scheiß ausprobiert hat.)

LG, Tobias

Tobias · 3. Juni 2024 um 22:07

Hi @max, hi @Michael ,

ihr habt beide recht:

freeradius -X ist ziemtlich detailliert und zeigte den Fehler an.
Max hat recht: jetzt ist auf einmal das LINUXMUSTER\wifi nicht mehr gut genug, es muss LINUXMUSTER\\wifi heißen. … Strange.

Wenn man das wie letzte Woche noch konfiguriert (in /etc/freeradius/3.2/mods-enabled/mschap):

        ntlm_auth = "/usr/bin/ntlm_auth --allow-mschapv2 --request-nt-key --domain=LINUXMUSTER --require-membership-of=LINUXMUSTER\wifi --username=%{%{Stripp\
ed-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"

Dann ist die Antwort auch:

freeradius -d /etc/freeradius/3.2 -X
...
(8) mschap: Creating challenge hash with username: xxxxxx
(8) mschap: Client is using MS-CHAPv2
(8) mschap: Executing: /usr/bin/ntlm_auth --allow-mschapv2 --request-nt-key --domain=LINUXMUSTER --require-membership-of=LINUXMUSTERwifi --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}:
(8) mschap: EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
...
(8) mschap:    --> --nt-response=06a5b0866a83150391db9338f24d533c609e7850bb4a5d9e
Could not parse LINUXMUSTERwifi into separate domain/name parts!
(8) mschap: ERROR: Program returned code (1) and output '(null) (0xc000000d)'
(8) mschap: External script failed
(8) mschap: ERROR: External script says: (null) (0xc000000d)
(8) mschap: ERROR: MS-CHAP2-Response is incorrect
(8) eap_mschapv2:     [mschap] = reject

Wenn man die Datei „richtig“ konfiguiert,

ntlm_auth = "/usr/bin/ntlm_auth --allow-mschapv2 --request-nt-key --domain=LINUXMUSTER --require-membership-of=LINUXMUSTER\\wifi --username=%{%{Stripp\
ed-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"

bleibt auch der richtige \ für die DOMÄNE\gruppe übrig:

(0) mschap: Client is using MS-CHAPv1 with NT-Password
(0) mschap: Executing: /usr/bin/ntlm_auth --allow-mschapv2 --request-nt-key --domain=LINUXMUSTER --require-membership-of=LINUXMUSTER\wifi --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}:
(0) mschap: EXPAND --challenge=%{%{mschap:Challenge}:-00}
(0) mschap:    --> --challenge=27d48ada0a8f657d
(0) mschap: EXPAND --nt-response=%{%{mschap:NT-Response}:-00}
(0) mschap:    --> --nt-response=ea09b1f675208c8ed1bc3b4e397e243bbc4555d15873e032
(0) mschap: Program returned code (0) and output 'NT_KEY: D825C40F83D51C615879F4713DE9C491'
(0) mschap: adding MS-CHAPv1 MPPE keys

Tobias · 3. Juni 2024 um 22:40

verstehe ich nicht, ich habe das nicht im eap-Modul.
Das ist bei mir nur configured insofern, als dass unter peap { ... default_eap_type = mschapv2 .... virtual_server = inner-tunnel ... } verwendet und unter mschapv2 { ... } nichts mehr wichtiges steht.

Erst in ntlm_auth steht wieder die ntlm_auth = ... Zeile wie in der Doku.
Die ist erst relevant, wenn ich „PAP“ statt „EAP/mschap“ teste…

Hier zur Vollständigkeit noch meine CLI-debug-kommandos:

PAP authentification mit relevanter config in freeradius/3.2/mods-enabled/ntlm_auth. Hier wird definitiv das Passwort im Klartext übermittelt:

radtest -x -d /etc/freeradius/3.2 -t pap fobi 'JuliZeh:CorpusDelicti'  localhost 0 testing123

EAP-MSCHAPv2 authentification mit relevanter config in freeradius/3.2/mods-enabled/mschap, hier scheint das clear-text-pw nicht beim Server anzukommen.

radtest -x -d /etc/freeradius/3.2 -t mschap fobi 'JuliZeh:CorpusDelicti'  localhost 0 testing123

andere Möglichkeiten von radtest -t type funktionieren bei mir nicht.
der „inner-tunnel“ funktioniert genauso, wenn ich ihn (wie empfohlen in der Konfigurationsdatei) nutze:

radtest -x -d /etc/freeradius/3.2 -t pap fobi 'JuliZeh:CorpusDelicti'  localhost:18120 0 testing123
radtest -x -d /etc/freeradius/3.2 -t mschap fobi 'JuliZeh:CorpusDelicti'  localhost:18120 0 testing123

P.S. bin ganz stolz auf mein Passwort für die Deutsch-Fortbildung, oder?

VG, Tobias

Michael · 4. Juni 2024 um 04:43

Wie immer fällt mir dazu der hier ein:

… oder (um die Diskussion nochmal anzuheizen) auch so:
https://www.reddit.com/r/programming/comments/3qfykp/password_security_why_the_horse_battery_staple_is/

Viele Grüße,
Michael

Tobias · 4. Juni 2024 um 05:23

P.S. der Vollständigkeit hier noch:

Ich benutze die Pakete von networkradius.com, die ihre Konfigurationsdateien bei /etc/freeradius ablegen. Version dort: 3.2.4-1
Debian/Ubuntu-Pakete legen ihre Konfiguration in /etc/freeradius/3.0 ab. Version in ubuntu-jammy: 3.0.26.

Meine Befehle oben enthalten noch /etc/freeradius/3.2/ aus historischen Gründen, sollte eigentlich nicht so sein … ist also nicht so gut, das so hinzubiegen, wie ich das mal gemacht habe. Ich sollte eher dem Paketstandard folgen.

VG, Tobias