WPA2 Enterprise mit freeradius und Win11 22H2

Hallo,

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:

  1. fix msi Paket von MS vom 7.1.2023 … hat nicht geholfen

https://catalog.s.download.windowsupdate.com/d/msdownload/update/software/updt/2022/02/windows10.0-kb5010414-x64_2d1f5fe2f99312cbf158f01c7fa2c4994ef2ffec.msu

  1. am vielversprechendsten fand ich diesen Tread:

hier werden zwei Ansätze propagiert:

  • 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 …

Ich wollte euch das mal gleich wissen lassen.

LG

Holger

1 „Gefällt mir“

Vielen Dank!

Ist das Problem in Windows 10 22H2 auch vorhanden oder wird dort noch auch TLS 1.2 gesetzt?

Hallo Fabi,

weiß ich leider nicht: bisher hatte ich noch kein Windows 10, dass da Probleme gemacht hätte: ich nehme also an: nein.

LG

Holger

Hallo,

am vielversprechendsden halte ich derzeit das Abschalten des Credential
Guards:

LG

Holger

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.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13]
„Tlsversion“=dword:00000fc0

Gruß
Andreas

1 „Gefällt mir“

Hallo Andreas,

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.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13]
„Tlsversion“=dword:00000fc0

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.

Viele Grüße

Holger

Hallo,

ich wollte berichten, dass ich den Regpatch von Andreas Heute an zwei
Laptops ausprobiert habe: funktionierte ganz wunderbar.

Tausend Dank Andreas :slight_smile:

LG

Holger

kein Problem :slight_smile:

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?

Was ich da nicht verstehe:
Warum soll freeradius kein TLS 1.3 verstehen können?
Dieser Kommentar: https://www.reddit.com/r/Windows11/comments/xoqz76/comment/iroojpy/ suggeriert zwar, dass freeradius kein TLS1.3 unterstützen würde.

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…

VG, Tobias

Zeitslot heute mittag:

  • snapshot des Servers
  • FreeRADIUS Packages | NetworkRADIUS befolgt, bis kurz vor dem update
  • 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.

mkdir /etc/freeradius/3.2
chown freerad /etc/freeradius/3.2
rsync -avP /etc/freeradius/3.0/ /etc/freeradius/3.2/

VG, Tobias

Hallo Tobias,

… 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).

Ich fasse zusammen für Dummies (also mich).

  1. Backup des Servers
  2. APT url in apt Liste rein und key des Repos integriert (nach dieser
    Anleitung:
    FreeRADIUS Packages | NetworkRADIUS
    )
  3. alle configs von freeradius3.0 zu freeradius 3.2 kopiert mit diesen
    Befehlen
mkdir /etc/freeradius/3.2
chown freerad /etc/freeradius/3.2
rsync -avP /etc/freeradius/3.0/ /etc/freeradius/3.2/

apt update
und dann
apt install freeradius
Das aktualisiert freeradius wegen der neuen Quellen von 3.0 auf 3.2

  1. Startscript des Freeradius in /etc/default/ anpassen, damit die
    configs von 3.2 genommen wird:
# Options for the FreeRADIUS daemon.
FREERADIUS_OPTIONS=""

ändern zu:

# Options for the FreeRADIUS daemon.
FREERADIUS_OPTIONS="-d /etc/freeradius/3.2"
  1. freeradius anhalten und neustarten
    service freeradius stop
    service freeradius start

Fertig: keine configs angepaßt: einfach nur kopiert.

Hab ich was falsch? Oder Vergessen?

LG

Holger

2 „Gefällt mir“

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

Weiß jemand Rat?
Danke und viele Grüße!

Lieber Holger,

GENAU SO!

VG, Tobias

Disclaimer:

  • 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.

Hallo Tobias,

das ist normal, denke ich.

Lies mal die ANleitung bis zum Ende:

  • 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

Hallo,

und falls das nicht reicht:
apt purge PAKETNAME
entfernt ein Paket so richtig (vorsicht: mit configs: also vorher Backup
machen).

LG

HOlger

Hallo zusammen,

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.

Viele Grüße
Klaus

[1] GitHub - linuxmuster/linuxmuster-linbo7: Next generation linbo

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 :wink:

Danke für die Unterstützung!!

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.

VG Daniel

Hallo zusammen,

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

 localstatedir = /var
 sbindir = ${exec_prefix}/sbin
 logdir = /var/log/freeradius
-raddbdir = /etc/freeradius/3.0
+raddbdir = /etc/freeradius/3.2
 radacctdir = ${logdir}/radacct

Last but not least. Nach der Aktion sieht mein /etc/freeradius Verzeichnis so aus:

root@server /etc/freeradius # ls -la
insgesamt 180
drwxr-s--x  11 freerad freerad  4096 Jan 19 23:19 .
drwxr-xr-x 127 root    root    12288 Jan 19 23:21 ..
drwxr-xr-x   8 freerad freerad  4096 Jan 19 23:19 3.0
drwxr-xr-x   9 freerad freerad  4096 Jan 19 23:23 3.2
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 certs
-rw-r--r--   1 root    root     8323 Okt  4 00:04 clients.conf
-rw-r--r--   1 root    root     1420 Okt  4 00:04 dictionary
-rw-r--r--   1 root    root     2661 Okt  4 00:04 experimental.conf
lrwxrwxrwx   1 root    root       28 Okt  4 00:04 hints -> mods-config/preprocess/hints
lrwxrwxrwx   1 root    root       33 Okt  4 00:04 huntgroups -> mods-config/preprocess/huntgroups
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 mods-available
drwxr-xr-x  10 root    root     4096 Jan 19 23:19 mods-config
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 mods-enabled
-rw-r--r--   1 root    root       52 Okt  4 00:04 panic.gdb
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 policy.d
-rw-r--r--   1 root    root    29206 Okt  4 00:04 proxy.conf
-rw-r--r--   1 root    root    30769 Okt  4 00:04 radiusd.conf
-rw-r--r--   1 root    root    20754 Okt  4 00:04 README.rst
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 sites-available
drwxr-xr-x   2 root    root     4096 Jan 19 23:19 sites-enabled
-rw-r--r--   1 root    root     3470 Okt  4 00:04 templates.conf
-rw-r--r--   1 root    root     8536 Okt  4 00:04 trigger.conf
lrwxrwxrwx   1 root    root       27 Okt  4 00:04 users -> mods-config/files/authorize

VG, Tobias

Noch ein Nachtrag, passt dann allerdings nicht mehr ganz zum Thread :face_with_hand_over_mouth:

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 :woman_facepalming:t3:

radius.log.4.gz:Fri Jan 20 12:26:49 2023 : Auth: (25292) Login incorrect (eap_peap: (TLS) Alert write:fatal:protocol version): [<username hier>] (from client BYOD port 1 cli E0-AC-DA-DE-DA-DA)

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.

VG, Tobias