mal wieder eines der Probleme, die man nicht haben will.
Heute kamen 130 neue Nutzer in unser WPA2 Enterprise WLAN (unifi mit freeradius auf dem Server).
Davon hatten >10 Windows 11.
4 davon konnten icht ins WLAN.
Meine Analyse zeigte: alle bei denen es nciht ging, hatten Win11 22H2 drauf. Alle bei denen es ging hatten win11 21H2 drauf (keine ahnung, warum das nicht updatet … Windows kennt wohl keinen funktionierenden updateautomatismus?).
Recherche bestätigte meine Vermutung: mit 22H2 hat MS an der authentifizierung von WPA2 Enterprise rumgedreht (geben sie auch zu). Viele haben seit dem Probleme.
Lösungswege sind:
fix msi Paket von MS vom 7.1.2023 … hat nicht geholfen
Win11 22H2 nutzt TLS 1.3 was der freeradius nicht kann. Entweder forced man TLS1.2 am Radius oder man gebietet Win11 TLS1.2 zu verwenden (per Regpatch)
Der Credential Guard spuckt rein, der neuerdings per default eingeschaltet ist. Man solle ihn abschalten
Ich werde wohl erstmal einen RegPatch erstellen (eine .reg Datei) die die NUtzer per Doppelklick einspielen können, der Win11 auf TLS 1.2 zwingt: mal sehen, ob es hilft …
Hallo, ich konnte das Lösen mit diesem Reg-Patch unter Windows 11 22H2.
Nachdem das in der Registry aktiv war, konnten die Benutzer sich wieder anmelden.
Hallo, ich konnte das Lösen mit diesem Reg-Patch unter Windows 11 22H2.
Nachdem das in der Registry aktiv war, konnten die Benutzer sich wieder
anmelden.
Danke für den Hinweis.
Ich hatte Heute 2 Stunden lang an zwei frisch installierten Win11 22H2
Laptops verschiedene Methoden den Credential Guard zu deaktivieren
versucht (ich hab später auch virtualization based Security
abgeschaltet): alles ohne Erfolg.
Das verbieten von EAPv13 wäre jetzt auch mein nächster Schritt.
Ich teste das MOrgen in der Schule.
Hi,
ist das nicht Käse? Einem Windows-System per Regpatch vorzuschreiben, dass es ein (vermutlich) sichereres Protokoll TLS1.2 statt TLS1.3 verwenden soll?
Allerdings dieser Post hier suggeriert, dass 3.2.x TLS1.3 unterstützt:
Dann wiederum: wie kriegt man 3.2.x zum Laufen? Immerhin hab ich das bei mir auf dem Server, d.h. unter 18.04 LTS… (wovon wir dieses Jahr ja wegmigrieren müssten, oder?)
Interessanterweise bietet die Unterstützer-Firma von freeradius dafür noch Pakete:
Es kann mal ja jemand das Upgrade versuchen. Ich werde das auch tun, sobald ich einen Zeitslot habe, wo ich jemand mit Win11 22H2 bei der Hand habe…
Vor dem Update auf freeradius 3.2 sah der misslungene Versuch mit der Windows-Kiste (vermutlich Win11 v22H2, hab ich nicht gecheckt) so aus:
service freeradius debug
...
2) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(2) authenticate {
(2) eap: Expiring EAP session with state 0x5aded75b5b10ce51
(2) eap: Finished EAP session with state 0x5aded75b5b10ce51
(2) eap: Previous EAP request found for state 0x5aded75b5b10ce51, released from the list
(2) eap: Peer sent packet with method EAP PEAP (25)
(2) eap: Calling submodule eap_peap to process data
(2) eap_peap: Continuing EAP-TLS
(2) eap_peap: Peer indicated complete TLS record size will be 251 bytes
(2) eap_peap: Got complete TLS record (251 bytes)
(2) eap_peap: [eaptls verify] = length included
(2) eap_peap: (other): before SSL initialization
(2) eap_peap: TLS_accept: before SSL initialization
(2) eap_peap: TLS_accept: before SSL initialization
(2) eap_peap: <<< recv UNKNOWN TLS VERSION ?0304? [length 00f6]
(2) eap_peap: TLS_accept: SSLv3/TLS read client hello
(2) eap_peap: >>> send UNKNOWN TLS VERSION ?0304? [length 0058]
(2) eap_peap: TLS_accept: SSLv3/TLS write server hello
(2) eap_peap: >>> send UNKNOWN TLS VERSION ?0304? [length 0001]
(2) eap_peap: TLS_accept: SSLv3/TLS write change cipher spec
(2) eap_peap: TLS_accept: TLSv1.3 early data
(2) eap_peap: TLS_accept: Need to read more data: TLSv1.3 early data
(2) eap_peap: In SSL Handshake Phase
(2) eap_peap: In SSL Accept mode
(2) eap_peap: [eaptls process] = handled
(2) eap: Sending EAP Request (code 1) ID 207 length 105
(2) eap: EAP session adding &reply:State = 0x5aded75b5811ce51
nach dem Update auf 3.2 dann mit dem gleichen Gerät so:
service freeradius debug
...
(2) # Executing group from file /etc/freeradius/3.2/sites-enabled/default
(2) authenticate {
(2) eap: Expiring EAP session with state 0xb3d88663b2ef9f6e
(2) eap: Finished EAP session with state 0xb3d88663b2ef9f6e
(2) eap: Previous EAP request found for state 0xb3d88663b2ef9f6e, released from the list
(2) eap: Peer sent packet with method EAP PEAP (25)
(2) eap: Calling submodule eap_peap to process data
(2) eap_peap: (TLS) EAP Peer says that the final record size will be 247 bytes
(2) eap_peap: (TLS) EAP Got all data (247 bytes)
(2) eap_peap: (TLS) Handshake state - before SSL initialization
(2) eap_peap: (TLS) Handshake state - Server before SSL initialization
(2) eap_peap: (TLS) Handshake state - Server before SSL initialization
(2) eap_peap: (TLS) recv TLS 1.3 Handshake, ClientHello
(2) eap_peap: (TLS) Handshake state - Server SSLv3/TLS read client hello
(2) eap_peap: (TLS) send TLS 1.2 Handshake, ServerHello
(2) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write server hello
(2) eap_peap: (TLS) send TLS 1.2 Handshake, Certificate
(2) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write certificate
(2) eap_peap: (TLS) send TLS 1.2 Handshake, ServerKeyExchange
(2) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write key exchange
(2) eap_peap: (TLS) send TLS 1.2 Handshake, ServerHelloDone
(2) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write server done
(2) eap_peap: (TLS) Server : Need to read more data: SSLv3/TLS write server done
(2) eap_peap: (TLS) In Handshake Phase
(2) eap: Sending EAP Request (code 1) ID 56 length 1004
(2) eap: EAP session adding &reply:State = 0xb3d88663b1e09f6e
yeah!
Ich muss in Ruhe noch testen, ob die Konfigurationen beim Laden dieselben sind (sieht man oben in den debug meldungen).
Konfigurationstechnisch musste ich „nur“ folgendes machen:
root@server /etc # git diff default/freeradius
diff --git a/default/freeradius b/default/freeradius
index ac4cb68..43b1e83 100644
--- a/default/freeradius
+++ b/default/freeradius
@@ -1,7 +1,6 @@
# Options passed to the FreeRADIUS deamon.
#
-FREERADIUS_OPTIONS=""
-
+FREERADIUS_OPTIONS="-d /etc/freeradius/3.2"
# If FreeRADIUS is being used on a SysVinit system
# and FREERADIUS_OPTIONS has not been set and the
@@ -13,3 +12,4 @@ FREERADIUS_OPTIONS=""
#
FREERADIUS_CONF_LOCAL="/usr/local/etc/freeradius"
außerdem habe ich vorsichtshalber (nach dem debian-upgrade) die konfiguration kopiert.
… das ist die noch bessere Lösung, als die, bei der man jeden Client
erwischen und patchen muss (es werden ja immer mehr: eigentlich ein
Glück, dass MS das mit den automatischen Updates noch immer episch
versaut … wie soll man sonst erklären, dass im Januar noch immer 90%
der Win11 Installtionen auf „vor Oktober 2022“ updates rumrutschen).
Argh, jetzt hat es mir bei dem Update auf 3.2 den FreeRadius zerschossen. Mist.
Wie kann ich das FreeRadius-Paket wieder komplett runterwerfen und wegen mir neu installieren? Ich hab das mit apt-get remove, apt-get update und install etc. gemacht, aber das will nicht…
root@server:~# apt-get update
OK:1 http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu bionic InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu bionic-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu bionic-backports InRelease
OK:5 http://de.archive.ubuntu.com/ubuntu bionic-security InRelease
OK:6 https://deb.linuxmuster.net lmn71 InRelease
Paketlisten werden gelesen... Fertig
root@server:~# apt-get install --reinstall freeradius
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
libhiredis0.13 libmysqlclient20 libpq5 mysql-common
Verwenden Sie »apt autoremove«, um sie zu entfernen.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0 B von 1.704 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 142944 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../freeradius_3.2.1-1_amd64.deb ...
Entpacken von freeradius (3.2.1-1) über (3.2.1-1) ...
freeradius (3.2.1-1) wird eingerichtet ...
Job for freeradius.service failed because the control process exited with error code.
See "systemctl status freeradius.service" and "journalctl -xe" for details.
invoke-rc.d: initscript freeradius, action "restart" failed.
● freeradius.service - FreeRADIUS multi-protocol policy server
Loaded: loaded (/lib/systemd/system/freeradius.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2023-01-18 19:33:12 CET; 5ms ago
Docs: man:radiusd(8)
man:radiusd.conf(5)
http://wiki.freeradius.org/
http://networkradius.com/doc/
Process: 1877 ExecStartPre=/bin/chown freerad:freerad /var/run/freeradius (code=exited, status=226/NAMESPACE)
Trigger für ureadahead (0.100.0-21) werden verarbeitet ...
Trigger für systemd (237-3ubuntu10.56) werden verarbeitet ...
Wie gesagt: es scheint nichts an der 3.0-Config geändert worden zu sein (sagt mir git von etckeeper). Das Erstellen von 3.2-Verzeichnis war nur so eine Idee, es wie bei 3.0 zu machen. Wenn man die Anpassung nämlich nicht macht, wird die Konfig direkt in /etc/freeradius/[radiusd.conf|etc.] erwartet…
Ich habe allerdings verschwiegen, dass an der logrotate-Config-Datei etwas geändert wurde, das kann ich noch posten.
Laut Webseite von freeradius ist erst mit dem major upgrade auf 4.0 eine Änderung in den Konfigs zu erwarten - daher vermutlich nicht mit 3.0 → 3.2.1. Aber 3.2.1 ist auch als stabil zu betrachten laut Webseite.
Zu guter letzt: ich habe nur einige Kollegen-Geräte und mein Android-derivat und eben den Test-Win11 Laptop getestet. Morgen wird klar sein, ob grundsätzlich die K1/K2 und das gesamte Kollegium weiterhin ins WLAN kommt.
freeradius 3.2 erwartet die Konfig in /etc/freeradius . Dort liegt sie aber nicht, sondern in /etc/freeradius/3.0 … deswegen die kleinen kopieraktionen und die Anpassung in /etc/default/freeradius
Erst danach wird ein systemctl start freeradius auch funktionieren.
VG, Tobias
schön, wenn es eine Lösung für zwischendurch gibt.
Generell kann es aber nicht empfohlen werden, externe Repositories in den LMN Server einzubinden. Oder kann der Support das dann noch überblicken wenn etwas nicht läuft?
Die Empfehlung könnte sein auf Linuxmuster 7.2 upzudaten und Ubuntu auf die Version 22.04 zu heben, so wie es in [1] beschrieben ist. In Ubuntu 22.04 ist auch freeradius in der Version 3.2 enthalten.
Hab meinen Fehler gefunden:
In Punkt „2. APT url in apt Liste“ etc. habe ich bereits gemäß der externen Anleitung auch „Finally, update the APT database and install the packages:“ gemacht. Da war ich zu voreilig…
Ich bin auf mein Snapshot zurück, das ich vorab gemacht hatte und dann hat das Update funktioniert. Läuft auch alles wieder sauber. @Holger: vielleicht ist ein kleiner Hinweis in Deiner Anleitung bei 2. gut, dass noch kein Update erfolgen darf? Für übereifrige Blindfische wie mich
Hallo zusammen,
super dass es schon eine Anleitung zum Upgrade des Freeradius gibt! Vielen Dank @baumhof und @Tobias!
Bei mir an der Schule habe ich dasselbe Problem heute auch erstmalig festgestellt.
Ich habe das Update gemäß Anleitung durchgeführt und es scheint alles funktioniert zu haben.
Eine Ergänzung: Es ist sinnvoll den freeradius zu stoppen, bevor man das Update anwirft.
melde mich nochmal, weil ich erst heute festgestellt habe, dass ja der apt full-upgrade wegen der falschen/fehlenden Konfigurationsparameter beim Vergleich von 3.0 und 3.2 nicht durchläuft - ein weiteres Installieren hilft da im Nachklapp.
Jetzt habe ich also heute erstmalig die neuen freeradius-3.2 Pakete vollständig installiert.
Hat zur Folge, dass 3.2 natürlich doch eigene Konfigurationsdateien direkt nach /etc/freeradius/* schreibt - und somit dementsprechend auch angepasst werden könnte nach der originalen Anleitung… Wer also sehr gründlich sein will, der installiert (irgendwie) freeradius-3.2 vollständig und versucht anhand der Anleitung bei docs.linuxmuster.net die Authentifizierung erneut anzupassen. Ich würde wetten, dass das immernoch funktioniert, werde es aber selbst nicht ausprobieren.
Wie auch immer, ich halte es allerdings nicht für falsch, mit der alten Konfiguration von 3.0 das Paket 3.2 zubetreiben - in dem man in /etc/default/freeradius die Konfigurationsverzeichnis entsprechend setzt.
Dazu noch ein Hinweis: Es gibt an einer Stelle in der Konfiguration ein Hinweis auf die Location: /etc/freeradius/3.2/radiusd.conf. Dort habe ich an dieser einen Stelle 3.0 durch 3.2 ersetzt
Noch ein Nachtrag, passt dann allerdings nicht mehr ganz zum Thread
Seit meiner Umstellung hat eine Mac-User-Kollegin sich versucht einzuloggen und jetzt stelle ich aus den Logs fest, dass der MAC wohl die TLS Version 1.3 nicht mag
Dass sie schon Recht hat mit ihrer Vermutung „gerade hat es doch noch funktioniert“, hab ich auch eine erfolgreiche Zeile vor meiner Umstellung:
radius.log.7.gz:Tue Jan 17 11:59:54 2023 : Auth: (67636) Login OK: [<username hier>] (from client BYOD port 8 cli E0-AC-DA-DE-DA-DA)
Lang lebe die Protokoll-Version, die bald sterben wird!
Ich hab noch keine Ahnung, ob das alle treffen wird, könnte schon.
Vielleicht muss sie nur „entfernen“ und „hinzufügen“ der Internetverbindung und das wird neu ausgehandelt.
Vielleicht müssen Mac-User ein Update machen (unwahrscheinlich)
Vielleicht klappts auch so einfach nicht bei einzelnen Mac-Usern… dann müsste man vielleicht in den TLS-Versions einstellungen ein Minimum von 1.2 und ein Maximum von 1.3 einstellen. Das stand irgendwo, dass es diese Konfiguration in freeradius gibt. Doch wo man das genau machen muss, das muss dann erst noch getestet werden.
