Richtige Samba-Domäne und Anmeldung WPA Enterprise mit PEAP und Mschapv2

Infrastruktur WLAN
1

Hallo zusammen!

Wir sind gerade dabei, ein Schüler-WLAN (blau) mit RADIUS und WPA Enterprise einzurichten. Dabei sind wir nach der Doku vorgegangen, was letztlich geklappt hat. Vielen Dank an die Autoren!

Ein paar eigentlich kleine (und für einige von euch wahrscheinlich triviale) Unklarheiten, haben uns aber unglaublich viel Zeit gekostet.

Es ist nicht eindeutig beschrieben, was als Samba-Domäne in die /etc/freeradius/3.0/mods-enabled/mschap und /etc/freeradius/3.0/mods-enabled/ntlm_auth eingefügt werden muss. Und auch hier im Forum findet man verschiedene Angaben bzw. auch keine präzisen Angaben, weil keiner (verständlicherweise) seine Domain hier öffentlich macht.

Wir haben also alles Mögliche ausprobiert anhand z.B. folgender Anhaltspunkte:

Bei uns wird in der WebUI oben rechts folgendes angezeigt:
image

Die Netzwerklaufwerke sind unter smb://xxxxxxx.local erreichbar.

In der /etc/samba/smb.conf steht:

workgroup = LINUXMUSTER
realm = LINUXMUSTER.LAN
netbios name = XXXXXXX

So kommen ein paar Möglichkeiten zustande, die man mit Endung und ohne durchprobieren kann…nach einigen Versuchen fanden wir heraus, dass in die oben genannten Dateien in unserem Fall schlicht „linuxmuster.lan“ mit Endung eingetragen werden muss.

Außerdem wird nicht beschrieben, wie sich die Endgeräte der Schüler einwählen müssen:

Unter Android sieht das so aus:

image
image1080×1860 144 KB

Unter Linux so:

image
image503×650 43.8 KB

Und unter iOS geht es ziemlich automatisch - man muss nur dem Zertifikat vertrauen.

Durch Probieren diverser Kombinationen aus falsch eingetragener Samba-Domain und/oder falschen Einstellungen am Client haben wir viel Zeit vertan…

Vielleicht können die Infos ja an entsprechender Stelle in die Doku aufgenommen werden oder sind jemandem hilfreich, der hier sucht.

Vielen Dank!

Grüße Noah

2 „Gefällt mir“
2

Hallo Noah,
vielen Dank für Deine Hinweise.

Um die Doku zu ergänzen, könntest Du mir etwas genauere Hinweise geben, an welcher Stelle diese Infos fehlen ? Netzwerkzugriff über Radius — linuxmuster.net 7.1 Dokumentation
Dort unter Radius konfigurieren …

VG
Chris

3

Hallo Chris,

https://docs.linuxmuster.net/de/latest/systemadministration/network/radius/index.html#ntlm-auth-in-samba-erlauben
Dort unter Radius konfigurieren …

auf der Seite steht zweimal:
„Dabei muss DOMÄNE durch den eigenen Domänennamen (Samba-Domäne) ersetzt
werden.“

Mach daraus sowas:
"Dabei muss DOMÄNE durch den eigenen Domänennamen (Samba-Domäne) ersetzt
werden. Die Samba Domain ist immer gleich der Unix Domain: also der Teil
der hinter server in der Datei /etc/hosts auf dem Server steht.
Beispiel:

127.0.0.1 localhost
10.0.0.1 server.linuxmuster.lan server

Also also das DOMAIN durch linuxmuster.lan ersetzen"

LG

Holger

4

Hallo Chris und Holger!

Vielen Dank für eure schnelle Antwort!

Wie Holger das vorschlägt, könnte das klappen! Allerdings steht bei uns vor linuxmuster.lan eben gerade nicht „server“ sondern ein selbstgewählter Eigenname, den ich eigentlich gerne wieder loswerden würde, was aber wohl nicht so einfach geht, oder?

Der Rest zur Anmeldung der Clients sollte am besten unter die Zeile:

Jetzt sollte die Authentifizierung per WPA2-Enterprise funktionieren, sofern der Testuser in der Gruppe wifi ist. Ein Zertifikat ist nicht erforderlich.

Womit ich außerdem noch immer Probleme habe, sind die Firewall-Regeln, die meist nur verkürzt als Bild in der Doku sind, denn die tatsächlichen Einstellungen sind dann doch umfangreicher und detaillierter als die Übersicht vermuten lässt.

Und eine Frage habe ich auch noch - ganz oben auf der Seite (Einrichtung des Schüler-WLANs — linuxmuster.net 7.1 Dokumentation) steht, man soll das Paket linuxmuster-freeradius installieren - dieses gibt es doch aber nicht, oder? Man muss also zwangsläufig den Radius manuell nach Anleitung konfigurieren.

Zur Konfiguration von Unifi: Leider hat Unifi die Oberfläche des Controllers komplett überarbeitet und auch die Grundeinstellung beim ersten Start sieht nun komplett anders aus, wie in der Doku beschrieben. Das ist aber denke ich verkraftbar bzw. kann man, wenn man will ja die alte Oberfläche zurückholen.

Grüße Noah

5

Hallo Noah,

Wie Holger das vorschlägt, könnte das klappen! Allerdings steht bei uns
vor linuxmuster.lan eben gerade nicht „server“ sondern ein
selbstgewählter Eigenname, den ich eigentlich gerne wieder loswerden
würde, was aber wohl nicht so einfach geht, oder?

dann sollte man das so formulieren:
„die Samba Domain ist alles nach dem ersten Punkt“

Im Beispiel: server.linuxmuster.lan
Also: linuxmuster.lan

Zur Konfiguration von Unifi: Leider hat Unifi die Oberfläche des
Controllers komplett überarbeitet und auch die Grundeinstellung beim
ersten Start sieht nun komplett anders aus, wie in der Doku beschrieben.
Das ist aber denke ich verkraftbar bzw. kann man, wenn man will ja die
alte Oberfläche zurückholen.

… stell mal in den Einstellungen des Controllers bei Ansicht auf
„Legacy“ um, dann ist das wieder besser benutzbar.

LG

Holger

6

Hallo Noah!

Vorsicht Falle! Unter Android > 10 muss man zusätzlich noch die CA importieren, dieses Zertifikat bei der Verbindungsherstellung mit angeben und die Domäne eintragen. Sonst klappt der Verbindungsaufbau nicht! Die Option „nicht validieren“ ist mittlerweile funktionslos.

Gruß
Thomas

7

Hallo Thomas!

Danke für den Hinweis, aber das kann ich nicht bestätigen - die Anmeldung geht bei mir mit Lineage 18.1 (Android 11) mit den oben dargestellten Einstellungen.

Aber für den Fall, dass das doch mal nicht klappen sollte: Wo finde ich die CA, die importiert werden muss?

Danke!

Grüße Noah

8

Möglich das Lineage da die Ausnahme ist.

Hier beschrieben Domain angeben bei Android 11 unifi Enterprise WPA2
gab es mehrfach Probleme.

Gruß
Thomas

9

Hallo Thomas!

Den Thread hatte ich auch schon gelesen…und mich schon gefreut, dass es bei mir einfacher geht…

Ich hab mal versucht, aus dem Thread zu extrahieren, was im obigen Fall zu tun ist:
Wenn der Radius also auf dem LM-Server nach der Anleitung in der Doku läuft, dann muss diese Datei den Android-Nutzern bereitgestellt werden:
/etc/linuxmuster/ssl/cacert.crt

Und die am Gerät einzustellende Domain ist wieder die Samba-Domäne wie oben, also z.B. „linuxmuster.lan“

Ist das richtig?

Grüße Noah

10

Hallo Noah,

das hängt vom cn des Zertifikats ab. Da sollte ein fqdn drinstehen…zB. cn=ca.linuxmuster.lan
Die Endung entspricht dann der Domain. Im Zweifel mit openssl x509 -in /etc/linuxmuster/ssl/cacert.crt -text -noout nachschauen.

Gruß
Thomas

1 „Gefällt mir“
11

Hallo Thomas,

das kann ich nicht bestätigen, wir haben keine CA und importieren nichts, aber wenn unter Android, iOS oder Linux das Häckchen bei nicht validieren gesetzt ist, funktioniert die Sache. Wenn es nicht gesetzt ist, funktioniert die Verbindung nicht.

Viele Grüße,
Stefan

12

Hallo Stefan,

dann setzt ihr möglicherweise Geräte mit veralteten Android Versionen ein.
Mit Android 11 QPR1 clients (December 2020 security update) wurde diese Funktion entfernt.

Gruß
Thomas

P.S. Ja, richtig unter iOS muss man nur das Zertifikat akzeptieren und unter Linux kann man die Zertifikatsprüfung deaktiveren. Natürlich habt ihr eine CA. Ist Bestandteil von linuxmuster.net.

13

Hallo Stefan,

Die Option „nicht validieren“ ist mittlerweile funktionslos. >

das kann ich nicht bestätigen, wir haben keine CA und importieren
nichts, aber wenn unter Android, iOS oder Linux das Häckchen bei nicht
validieren gesetzt ist, funktioniert die Sache. Wenn es nicht gesetzt
ist, funktioniert die Verbindung nicht.

die Formulierung von Thomas ist nicht ganz korrekt, aber auch nicht falsch.
Ich würde es so schreiben:

„Die Option „nicht validieren“ ist mittlerweile bei einigen Android 11
Systemen funktionslos oder nicht mehr vorhanden.“

Es stimmt: auch wir haben Android 11 Geräte bei denen es ohne ca import
nicht mehr klappt.
Es gibt aber auch welche, bei denen es klappt.

„Gefühlt“ würde ich sagen: kurzzeitig war das in Android 11 abgestellt
(also das „vertrauen“ selbstsignierter Zertifikate. Inzwischen scheint
es wieder zu gehen. Anders kann ich mir nicht erklären, warum im letzten
Jahr keiner mehr kam mit „WLAN geht nicht“.

Vor allem, dass im Januar 120 Referendare ans Seminar kamen: und bei
keinem machte Android ein Problem (dafür ist Win11 22H2 explodiert …
war auch geil) läßt mich vermuten, dass die das wieder reingemacht haben.

„wir haben keine CA“ ist aber auch falsch: natürlich habt ihr eine CA:
euer Server ist das: der ist die Certification Authority die die
Zertifikate signiert.
Und die müßtet ihr auf den Clients importieren, wenns mal soweit ist.

Disclaimer: … ich weiß das alles nicht so genau: berichtigt mich, wenn
was nicht stimmt… ihr dürft aber auch sagen, wenn ihr meint, dass das
so stimmt :slight_smile:

LG

Holger

14

Hallo Holger,

oh…ich hab grad auch was gelernt. Unter Android 13 gibts eine neue Funktion, nicht mehr nur SystemCA oder eigene CA, sondern auch „Bei der ersten Verwendung als vertrauenswürdig akzeptieren“. Evtl. does that the trick?

Gruß
Thomas

15

Hallo zusammen!

Was Holger schreibt, klingt plausibel.

Die Ausgabe von
openssl x509 -in /etc/linuxmuster/ssl/cacert.crt -text -noout
ist u.a.:
CN = LINUXMUSTER.LAN

Vielleicht sollte das dann auch noch in die Doku.

Danke!

Grüße Noah

16

Hallo zusammen,

ich habe jetzt nicht herausfinden können, ab welcher Android-Version das jetzt eingeführt wurde, aber gestern konnte ich das mal testen.
Ich habe ein Gerät mit Android 13 Patchstand 5.2.2023.
Da kann man bei der Einrichtung der WLAN-Verbindung, nachdem man das Netz ausgewählt hat, unter CA-Zertifikat die Option „Bei der ersten Verwendung als vertrauenswürdig…“ auswählen. Dann muss man nur noch Benutzernamen und Kennwort (optional einen anonymous User) angeben. Beim Verbindungsaufbau wird dann das CA-Zertifikat angezeigt, und gefragt, ob man es akzeptieren möchte. Tut man jenes, kommt ein erfolgreicher Aufbau zustande.

Das klappt freilich NUR, wenn euer RADIUS die vollständige Zertifikatskette ausliefert.
Also im Zweifel mit openssl prüfen oder einfach das Zertifikat im Editor öffnen und schauen. Wenn da nur einmal -------Begin Certificate-------------Buchstabensalat-----------End Certificate----------- auftaucht, dann liefert der RADIUS nur sein Serverzertifikat ohne Zertifikat der Zertifizierungsstelle, also keine Zertifikatskette aus.

in dem Fall z.B.
cat server.pem ca.pem > fullchain.pem # fügt das Zertifikat der Zertifizierungsstelle und das Serverzertifikat zu einem neuem Zertifikat, welches die Zertifikatskette enthält, zusammen
chgrp freerad fullchain.pem # ändert die Benutzergruppe auf freerad, damit die Benutzer der gruppe das Zertifikat verwenden können
chmod 640 fullchain.pem # passt die Berechtigungen für das Zertifikat auf Besitzer rw, Gruppe r an

und unter /etc/freeradius/3.2/mods-enabled/eap (ggf. auch /etc/raddb/mods-enabled/eap bzw. /etc/freeradius/3.0/mods-enabled/eap je nach Server-Distribution bzw. RADIUS-Version)
den Pfad für das Serverzertifikat in der Sektion tls-common anpassen z.B. von server.pem auf fullchain.pem.

Dienst neustarten:

systemctl restart freeradius.service

Jetzt liefert der RADIUS die Zertifikatskette aus und bei der ersten Verbindungsherstellung mit der oben beschrieben Methode wird die CA dann nach dem Akzeptieren importiert.

Wunderbar, welcome back to WPA-Enterprise Android!

Gruß
Thomas

2 „Gefällt mir“
17

Hallo Thomas,

vielen Dank für deine fundierten Uutersuchungen.
Dachte ich doch, dass da was passiert sein mußte…

Kannst du abschätzen was mit den schon im WLAN befindlichen Geräten
passiert, wenn ich vom server.pem auf das frisch zusammengestellte
fullchain.pem umstelle, passiert?
Meinst du die fangen an zu flennen?

LG

Holger

18

Hallo Holger,

nope…das juckt die Clients nicht. Das Serversignatur an sich ändert nur dann, wenn du ein neues Serverzertifikat erstelltst. Die Clients bekommen die Info „Hier ist mein Ausweis und hier zusätzlich noch die Ausweisbehörde“. Die Clients sagen: „Den Ausweis kenn ich schon, das reicht mir“.

Gruß
Thomas

1 „Gefällt mir“
19

Hallo Thomas,

aber vermutlich muss man bei Let’s-Enrypt-Zertifikaten alle paar Wochen wieder das Zertifikat abnicken - oder gibt es da auch einen Mechanismus?

Beste Grüße

Jörg

20

Hallo Jörg,

generell ist die Empfehlung für RADIUS, nicht mit öffentlichen Zertifikaten zu arbeiten.

Warum? Der Sinn von RADIUS-Zertifikaten liegt ja in der Vertrauensstellung zwischen den Endgeräten und der Wifi-Infrastruktur der Organisation. Wenn man mit öffentlichen Zertifikaten arbeitet, stammen alle Zertifikate aus einer Quelle, die außerhalb der Organisation, in dem Fall bei der öffentlichen Zertifizierungsstelle, liegt. Das führt das Prinzip des Organisationsvertrauens ad absurdum.

Vollkommen unpraktikabel wird es, wenn man auch andere Authentisierungsmethoden mit RADIUS als EAP-PEAP betreiben will. Will man z.B. für schuleigene mobile Endgeräte Authentisierung mit Client-Zertifikat (EAP-TLS) verwenden, müssten auch die Client-Zertifikate durch die externe öffentliche CA signiert werden. Welche Folge hätte das für mein Funknetz? JEDES Gerät, welches mit einem Zertifikat aus der public CA daher kommt, aus der auch mein Serverzertifikat stammt, könnte sich per EAP-TLS in mein Funknetz einwählen. Also quasi alles was z.B. durch DigiCert ausgestellt wurde, kommt in mein Funknetz und ich habe nicht mal die Möglichkeit das zu verbieten, solange das Zertifikat gültig ist, denn ich habe keine Gewalt über die Zertifizierungsstelle und kann daher auch nicht das Zertifikat zurückziehen oder die CRL der Zertifizierungsstelle als Kontrollmechanismus für RADIUS einbinden. Spinnt man den Gedanken ganz zu Ende, kann jeder mit einem LetsEncrypt-Zertifikat in das Funknetz, bei dem ein RADIUS-Server mit LE-Zertifikaten arbeitet. Beide stammen ja aus der gleichen Zertifizierungsstelle und sind somit vertrauenswürdig.

Daher bietet sich RADIUS mit LetsEncrypt zu betreiben aus mehreren Gründen nicht an.

Gruß
Thomas

1 „Gefällt mir“