WPA2 Enterprise mit freeradius und Win11 22H2

Christoph · 24. Januar 2023 um 19:12

Hallo Tobias,

das müsste in der Datei /etc/freeradius/3.0/mods-available/eap bzw. bei dir /etc/freeradius/3.2/mods-available/eap gehen. Dort gibt es meines Wissens zwei Parameter tls_min_version und tls_max_version.

Viele Grüße
Christoph

tjordan · 25. Januar 2023 um 08:23

Hallo Tobias,

TLS 1.3 wird ab freeradius 3.0.26 unterstützt (enthalten in den Ubuntu Repos für 22.04 LTS).

Wenn man nur TLS 1.3 Unterstützung braucht muss, man die Klimmzüge mit externen Repos nicht machen.

Gruß
Thomas

raabi · 26. Januar 2023 um 12:15

Hallo zusammen!

Auch ich habe hier dieses Problem.
Heißt das - wenn ich den Post von Christoph lese, dass ich auch bei der 3.0 tls_min_version =1.2 und tls_max_version= 1.3 setzen kann und gut isses?

Lg,
Alex

Buster · 27. Januar 2023 um 01:15

Hi,

ich kann verstehen, dass man mit tls_min_version unsichere Protokollversionen verhindern will, aber warum will/sollte man tls_max_version setzen, wenn man kein Problem mit der neuesten Version hat? Das sorgt doch nur wieder für die nächsten Probleme, wenn dann irgendwann mal TLS1.4 längst veröffentlicht ist und TLS1.3 in den Clients per Herstellerupdate abgeschaltet wird.

MfG Buster

tjordan · 27. Januar 2023 um 09:37

Hallo Alex,

kommt drauf an, welche freeradius Version du einsetzt. TLS 1.3 wurde erst mit freeradius 3.0.26 und Win11 erfolgreich implementiert. Mit tls_min_version bzw. tls_max_version kann man festlegen, welche TLS-Versionen durch freeradius verwendet werden sollen. Ältere Geräte können dabei das Nachsehen haben, wenn sie TLS1.2 oder TLS1.3 nicht können.

Es reicht aber nicht in der eap-Konfig den Parameter tls_max_version = 1.3 zu setzen, wenn dein freeradius z.B. auf Version 3.0.21 läuft.

Viele Grüße
Thomas

tjordan · 27. Januar 2023 um 09:46

Hallo Buster,

ich poste einfach mal die Anleitung als Antwort auf deine Frage:

438 # Set min / max TLS version.
439 #
440 # Generally speaking you should NOT use TLS 1.0 or
441 # TLS 1.1. They are old, possibly insecure, and
442 # deprecated. However, it is sometimes necessary to
443 # enable it for compatibility with legact systems.
444 # We recommend replacing those legacy systems, and
445 # using at least TLS 1.2.
446 #
447 # Some Debian versions disable older versions of TLS,
448 # and requires the application to manually enable
449 # them.
450 #
451 # If you are running such a distribution, you should
452 # set these options, otherwise older clients will not
453 # be able to connect.
454 #
455 # Allowed values are „1.0“, „1.1“, „1.2“, and „1.3“.
456 #
457 # As of 2021, it is STRONGLY RECOMMENDED to set
458 #
459 # tls_min_version = „1.2“
460 #
461 # Older TLS versions are insecure and deprecated.
462 #
463 # In order to enable TLS 1.0 and TLS 1.1, you may
464 # also need to update cipher_list below to:
465 #
466 # * OpenSSL >= 3.x
467 #
468 # cipher_list = „DEFAULT@SECLEVEL=0“
469 #
470 # * OpenSSL < 3.x
471 #
472 # cipher_list = „DEFAULT@SECLEVEL=1“
473 #
474 # The values must be in quotes.
475 #
476 # We also STRONGLY RECOMMEND to set
477 #
478 # tls_max_version = „1.2“
479 #
480 # While the server will accept „1.3“ as a value,
481 # most EAP supplicants WILL NOT DO TLS 1.3 PROPERLY.
482 #
483 # i.e. they WILL NOT WORK, SO DO NOT ASK QUESTIONS ON
484 # THE LIST ABOUT WHY IT DOES NOT WORK.
485 #
486 # The TLS 1.3 support is here for future
487 # compatibility, as clients get upgraded, and people
488 # don’t upgrade their copies of FreeRADIUS.
489 #
490 # Also note that we only support TLS 1.3 for EAP-TLS.
491 # Other versions of EAP (PEAP, TTLS, FAST) DO NOT
492 # SUPPORT TLS 1.3.
493 #
494 tls_min_version = „1.2“
495 tls_max_version = „1.2“

https://fossies.org/linux/freeradius-server/raddb/mods-available/eap

Gruß
Thomas

Tobias · 27. Januar 2023 um 13:18

Hallo Thomas,

danke fürs Recherchieren dieser Info!

Du hast zwar Recht. Ich habe vielleicht nicht deutlich betont, dass Holger+meine „Anleitung“ dafür war, wenn man freeradius auf dem lmn-server laufen lässt. Meines Wissens läuft der regulär momentan noch auf 18.04 und es gibt keinen upgrade-pfad zu 22.04, oder?

root@server ~ # apt-cache madison freeradius
freeradius |    3.2.1-1 | http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic/main amd64 Packages
freeradius |    3.2.0-1 | http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3.2 | http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3.2 | http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3 | http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
root@server ~ # lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic

Grüße, Tobias

baumhof · 27. Januar 2023 um 15:58

Hallo Tobias,

Du hast zwar Recht. Ich habe vielleicht nicht deutlich betont, dass
Holger+meine „Anleitung“ dafür war, wenn man freeradius auf dem
lmn-server laufen lässt. Meines Wissens läuft der regulär momentan noch
auf 18.04 und es gibt keinen upgrade-pfad zu 22.04, oder?

22.04 auf dem Server kommt mit der lmn 7.2 die gerade „alpha“ ist.
Man kann updaten: das ist aber wirklich noch nichts für produktive
Umgebungen.
Selbst bei mir teste ich das bisher nur in einer VM

LG

Holger

Tobias · 30. Januar 2023 um 17:08

So sieht mein obiges Schnipsel aus, wenn man tatsächlich tls_min_version=1.2 und max_version=1.3 einträgt:

(4)   authenticate {
(4) eap: Expiring EAP session with state 0xb59b219bb650385b
(4) eap: Finished EAP session with state 0xb59b219bb650385b
(4) eap: Previous EAP request found for state 0xb59b219bb650385b, released from the list
(4) eap: Peer sent packet with method EAP PEAP (25)
(4) eap: Calling submodule eap_peap to process data
(4) eap_peap: (TLS) EAP Peer says that the final record size will be 126 bytes
(4) eap_peap: (TLS) EAP Got all data (126 bytes)
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write server done
(4) eap_peap: (TLS) recv TLS 1.2 Handshake, ClientKeyExchange
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS read client key exchange
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS read change cipher spec
(4) eap_peap: (TLS) recv TLS 1.2 Handshake, Finished
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS read finished
(4) eap_peap: (TLS) send TLS 1.2 ChangeCipherSpec
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write change cipher spec
(4) eap_peap: (TLS) send TLS 1.2 Handshake, Finished
(4) eap_peap: (TLS) Handshake state - Server SSLv3/TLS write finished
(4) eap_peap: (TLS) Handshake state - SSL negotiation finished successfully
(4) eap_peap: (TLS) Connection Established
(4) eap_peap:   TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384"
(4) eap_peap:   TLS-Session-Version = "TLS 1.2"
(4) eap: Sending EAP Request (code 1) ID 204 length 57
(4) eap: EAP session adding &reply:State = 0xb59b219bb157385b
(4)     [eap] = handled
(4)   } # authenticate = handled

dann wird halt wieder „1.2“ geredet.

Ebenso das hier:

(8) session-state: Saving cached attributes
(8)   Framed-MTU = 994
(8)   TLS-Session-Information = "(TLS) recv TLS 1.3 Handshake, ClientHello"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHello"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Certificate"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerKeyExchange"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHelloDone"
(8)   TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, ClientKeyExchange"
(8)   TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, Finished"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 ChangeCipherSpec"
(8)   TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Finished"
(8)   TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384"
(8)   TLS-Session-Version = "TLS 1.2"

Woraus man auch schlussfolgern könnte: der client schickt ein „lass mal 1.3 reden“ und der Server antwortet mit „lass mal 1.2 reden“.

Ich werde also morgen rausbekommen, ob die Windows-Personen ins Internet kommen.

VG, Tobias

Rupprecht · 2. Mai 2023 um 06:50

Hallo Zusammen,
nun ist das Preoblem auch bei uns angekommen.

@Tobias: Hat das nun so wie Du es beschreibst mit den Apple Geräten funktioniert?

Bei uns haben nämlich viele ein iPad als Lehrerdienstgerät und wenn ich der Anleitung nun folge, und die iPads aus dem Netz kicke, habe ich auf einen Schlag viele neue Freunde

Gruß,
Markus

Tobias · 2. Mai 2023 um 18:12

Hallo Markus,

jein, musste selbst meinen Thread nochmal verfolgen:

Version 3.2 aus den fremden Quellen installiert
"tls_min_version=1.2 und max_version=1.3 " einstellen, damit nicht nur Windows mit 1.3 zufrieden ist, sondern auch noch MAC mit 1.2.
hab jetzt aber mal nachgeschaut: bei mir ist die konfiguration mit min_version und max_version in der DAtei /etc/freeradius/3.2/mods-available/eap allerdings auskommentiert. Weiß also grade nicht, ob ein min und ein max aktiv ist.

Da die Mac-User sich anmelden können und sich nicht beschweren, vermute ich, dass entweder die Macs/iOS doch mit 1.3 inzwischen zufrieden sind oder dass ein min/max automatisch eingestellt ist.

Wiedermal genüßlich zurücklehnen und zusehen, dass Linux mal wieder keine Probleme mit keiner der Versionen oder Konfigurationen gehabt hat oder hätte… aber wen interessiert das schon?

Viele Grüße, Tobias

aktueller Stand bei mir:

dpkg -l | grep freeradius
ii  freeradius                             3.2.2-1                                         amd64        high-performance and highly configurable RADIUS server
ii  freeradius-common                      3.2.2-1                                         all          FreeRADIUS common files
ii  freeradius-config                      3.2.2-1                                         amd64        FreeRADIUS default config files
ii  freeradius-utils                       3.2.2-1                                         amd64        FreeRADIUS client utilities
ii  libfreeradius3                         3.2.2-1                                         amd64        FreeRADIUS shared library
root@server /etc/freeradius # apt-cache madison freeradius
freeradius |    3.2.2-1 | http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic/main amd64 Packages
freeradius |    3.2.1-1 | http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic/main amd64 Packages
freeradius |    3.2.0-1 | http://packages.networkradius.com/freeradius-3.2/ubuntu/bionic bionic/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3.2 | http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3.2 | http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
freeradius | 3.0.16+dfsg-1ubuntu3 | http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Rupprecht · 3. Mai 2023 um 09:34

Ok, dann habe ich es jetzt auch einmal so gemacht, wie es Holger oben beschrieben hat. Ich warte, ob es Probleme gibt.

By the way: Ich hoffe, ihr macht eine Anleitung, wie man das wieder Rückgängig macht, wenn das Update auf 7.2 kommt. Nicht dass da dann etwas klemmt.

Gruß,
Markus

baumhof · 3. Mai 2023 um 11:58

Hallo Markus,

By the way: Ich hoffe, ihr macht eine Anleitung, wie man das wieder
Rückgängig macht, wenn das Update auf 7.2 kommt. Nicht dass da dann
etwas klemmt.

… was soll da rückgängig gemacht werden können?

LG

Holger

Rupprecht · 10. Mai 2023 um 05:53

Hi Holger,
naja …

Ich sage es jetzt einmal so: Ich habe daheim einen Debian Server, wo ich experimentierfreudiger bin. Da kam es in den Jahren schon einmal vor, dass man von einem Programm eine neuer Version gebraucht hat. Dann kam irgendwann das große Upgrade. Neue Abhängigkeiten … Jetzt ist da aber ewas installiert, was eine andere Versionsnummer hat. Jetzt sollen andere Pakete installiert werden, die von dieser oder jener Version abhängen. Auf einmal klemmt es. Daheim hat man da schon immer irgendwie eine Lösung gefunden, aber in der Schule wäre das der „Herzinfarkt“. Darum die Frage: Wenn 7.2 konmmt: Muss ich etwas beachten? Ist mit Problemen zu rechnen?

Übrigens auch bei mir: Es kam keine Rückmeldung, dass bei den iPads etwas nicht mehr geht nach dem Update.

Gruß,
Markus

baumhof · 10. Mai 2023 um 08:46

Hallo Markus,

ich kann nur die Erfahrungen mitteilen, die ich und zwei andere, von denen ich weiß (Thomas und Dominik), beim upgrade von 7.1 auf das Beta von 7.2 hatten: wir haben keine Probleme beobachten können, außer den schon erwähnten mit „Austeilen/Einsammeln/Klassenarbeit“, die aber wie gesagt, schon in Reparatur sind und derzeit mit händischen Nacharbeiten fast gänzlich gelößt werden können.

LG

Holger

dominik · 8. September 2023 um 13:41

Hallo zusammen,

ich habe heute das Update auf 7.2 vorgenommen. Wegen der geänderten FreeRADIUS-Version musste ich zusätzlich zur Update-Anleitung noch die neuen Paketquellen für FreeRADIUS einbinden (FreeRADIUS Packages | NetworkRADIUS).
Danach lief alles super.

Viele Grüße
Dominik