Hallo.
Heute hat es endlich geklappt: Wir konnten unseren freeRADIUS-Server endlich dazu bringen, selbst-signierte Zertifikate auszuliefern und zusätzlich nur die Gruppe „teachers“ ins WLAN zu lassen. Nun haben wir die Situation, die wir haben wollten: Es gibt ein WLAN, in das man nur noch gelangt, wenn mindestens eine der beiden Bedingungen erfüllt ist:
- man ist Mitglied der Gruppe „teachers“ oder
- man hat das gültige Client-Zertifikat auf dem Gerät (das per MDM auf die Tablets geschoben werden kann).
Hintergrund: Bisher haben wir allen Tablets per relution-Richtlinie die Einstellungen für das Geräte-WLAN mit PSK verpasst. Diesen Schlüssel kannte zwar niemand, doch er hat sich trotzdem auf irgendeinem Weg in der Schülerschaft verbreitet. Eigentlich kann man ihn nicht auf verwalteten Geräten auslesen, doch wir haben die Vermutung, dass ja nur ein Gerät dabei sein muss, bei dem „
was-auch-immer “ anders läuft und schon kann das Passwort ans nächste Gerät gegeben werden (Apple-Feature → Bordmittel) 
Aus diesem Grund haben wir über eine Alternative nachgedacht und sind nun bei Zertifikaten und EAP-TLS gelandet. Der Weg dahin war allerdings steinig und ich war mehrfach kurz davor alles in die Ecke zu werfen … als es dann aber heute Morgen endlich erfolgreich lief 
.
Ich schreibe die Vorgehensweise daher hier so gut es geht auf, damit andere hoffentlich schneller ans Ziel kommen:
Schritt 1: Die Theorie – hier im Forum lief das Thema ja schon öfter. So hat beispielsweise @tjordan schon öfter unermüdlich erklärt, wie das Verfahren prinzipiell funktioniert. Ich verlinke dennoch nochmal diesen Text, der mir beim Verständnis des ganzen Prozesses enorm geholfen hat: understanding the process of setting up eap-tls server/client certs
Schritt 2: Die Zertifikate – diese Seite erklärt sehr gut, wie man den freeRADIUS-Server konfigurieren muss, damit er selbst-signierte Zertifikate erstellt und bereit stellt. Das schöne daran ist: Es sind die Bordmittel, die freeRADIUS sowieso mitbringt. Man muss bei der Erneuerung des/der Client-Zertifikate also keine Klimmzüge machen:
Die dort gezeigte Vorgehensweise passt noch nicht ganz auf Apple-Geräte. Das hat uns auch nochmal echt Zeit und Mühe gekostet: Es ist scheinbar so, dass der Import des .p12-Zertifkates „neuerdings (?)“ einen Verschlüsselungsalgorithmus „für den Container“ verwendet, den die iOS-Geräte noch nicht verstehen Daher haben wir im Makefile des freeRADIUS-Containers bei den certs diese Option verwendet:
# Option -legacy eingefügt, damit der Import von p12-Datei auf iOS klappt! (14.04.2024)
client.p12: client.crt
$(OPENSSL) pkcs12 -legacy -export -in client.crt -inkey client.key -out client.p12 -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
chmod g+r client.p12
client.pem: client.p12
$(OPENSSL) pkcs12 -legacy -in client.p12 -out client.pem -passin pass:$(PASSWORD_CLIENT) -passout pass:$(PASSWORD_CLIENT)
chmod g+r client.pem
cp client.pem $(USER_NAME).pemDamit erhält man eine .p12-Datei, die entweder direkt auf die iOS-Geräte gepusht werden kann oder aber über ein MDM wie z.B. relution bereitgestellt werden kann . Damit funktioniert dann auch die Installation mit dem Passort, das man in der Datei client.cnf gesetzt hat! Das ging vorher nie – es wurde zwar nach einem Passwort gefragt, doch das Client-Zert konnte trotzdem nicht geöffnet werden!
Schritt 3: Der Test – Es gibt ein Tool für die Konfiguration namens eapol_test, das man
auf dem freeRADIUS-Server schnell nachinstallieren kann. Es heißt:
apt install eapoltestFür dieses Tool haben wir uns eine Konfiguration gebastelt, die so aussieht:
cat eapol_test_tls.conf
#
# Usage: eapol_test -c eapol_test_tls.conf -p 1812 -s <localhost-secret aus clients.conf>
#
network={
key_mgmt=WPA-EAP
eap=TLS
anonymous_identity="TestUser"
# Uncomment to validate the server's certificate by checking
# it was signed by this CA.
ca_cert="./certs/ca.pem"
# supplicant's public cert
client_cert="./certs/client.crt"
# supplicant's private key
private_key="./certs/client.key"
# password to decrypt private key
private_key_passwd="super-geheimer-Schlüssel-für-das-Client-Cert aus client.cnf"
}Wenn man das Tool durchlaufen lässt, sollte da am Ende stehen: SUCCESS
Das lief hier zunächst nicht richtig! Ich habe daher auch den freeRADIUS-Server ganz häufig im Debug-Modus laufen lassen (freeradius -X oder aber freeradius -XC → Configuration appears to be OK) und genau gelesen, welche Warnungen der Server ausspuckt. Einiges davon konnte man ganz schnell beheben, wie z.B. das Deaktivieren der nicht mehr notwendigen Datei „dh“ (Diffie-Hellman), über die sich der freeRADIUS-Server beschwert hat. Das war aber nur eine Warnung, von der ich nicht weiß, wie ausschlaggebend das am Ende war.
Schritt 4: Das Unifi-WLAN mit RADIUS-Profil –
Im Unifi-Controller haben wir ein neues WLAN-Profil eingerichtet:
und das passende RADIUS-Profil dazu eingerichtet:
Das Shared-Secret befindet sich auf dem freeRADIUS-Server unter
clients.conf .Warum dort bei uns die Ports 1912 und 1913 und nicht die Standard-Ports 1812 und 1813 eingetragen sind, steht nochmal auf einem anderen Blatt, da wir auf dem v7-Server im Moment zwei Instanzen für freeRADIUS verwenden. Die genauen Umstände warum und wieso, werden hier erläutert. Auf diese Weise ist bei uns gewährleistet, dass der „Original-freeRADIUS-Server“ alle in ein anderes WLAN lässt, die zur Gruppe
p_wifi gehören. Der „neue/parallele freeRADIUS-Server“ sorgt hingegen dafür, dass nur Mitglieder der Gruppe teachers bedient werden! Es ist natürlich gut möglich, dass man das auch irgendwie eleganter über nur eine Instanz regeln kann 
– aber „Hey: wfm!“
Schritt 5: Die Firewall – Die OPNSense-Firewall muss Zugriff von den Unifi-Accesspoints (bei uns nicht im gleichen Netz wie der v7-Server!) auf die RADIUS-Ports des v7-Servers erlauben! Daher habe ich auf der OPNSense eine Regel erstellt bzw erweitert, die das erlaubt (ALIAS für die Ports verwenden!)
Schritt 6: Das MDM – Das Bereitstellen der Zertifikate im relution-MDM + Richtlinie
Als das alles erledigt war, habe ich zunächst die beiden Dateien ca.der sowie client.p12 über die Nextcloud auf ein Tablet geholt und nacheinander aktiviert. Wie das geht, ist z.B. hier mit Screenshots hinterlegt:
Jetzt kommt der spannende Moment: das WLAN auf dem Endgerät auswählen und nachschauen, ob die Verbindung jetzt ohne weiteres Zutun funktioniert! Nach viel Frust und Fehlversuchen, hat das heute endlich geklappt. Man kann den Prozess auf dem freeRADIUS-Server verfolgen, wenn man ihn im Debug-Mode laufen lässt, also wie oben schon erwähnt: freeradius -X). Man kann aber auch unter /var/log/freeradius/radius.log mitlesen …
Schritt 7: Das Verteilen – Jetzt kann man die Zertifikate auch per relution verteilen lassen. Dazu haben wir auf dem Relution-Server zunächst die beiden Zertifikate ca.der und client.p12 unter Einstellungen -> Zertifikate hochgeladen und anschließend eine neue Richtlinie erstellt, die so aussieht:
!)
Diese Richtlinie haben wir dann auf ein paar Testgeräten verteilt und siehe da: Nun ist es so wie es sein soll: Wenn man das Zertifikat nicht installiert hat, wird man nach Username/Passwort gefragt (und nur „teachers“ kommen rein) und wenn man es installiert hat, kommt man direkt ohne eigene Credentails rein. Auf diese Weise hoffen wir, dass mit dem Wildwuchs der Geräte im WLAN endlich Schluss ist. Produktiv läuft das ganze aber bisher nicht … die Testphase kann jetzt aber beginnen und ich bin froh, dass es endlich funktioniert hat. An der Länge der Anleitung sieht man ja schon, wie komplex das ganze am Ende geworden ist…
Der Vollständigkeit halber sei auch nochmal https://www.openxpki.org/ genannt (Tipp von @tjordan ). Ohne dass ich es mir genauer angesehen habe: Damit hat man die Zertifikate noch besser im Blick, da man dann eine eigene PKI („Public Key Infrastruktur“) betreibt.
Die hier vorgestellte Methode und insbesondere Erneuerung der Zertifikate funktioniert bisher natürlich alles andere als automatisch. Wenn nach einem Jahr (die max Gültigkeitsdauer für Apple-Zertifikate liegt meines Wissens bei 397 Tagen ) das Zertifikat ausläuft, muss es natürlich möglichst geräuschlos auf den Clients erneuert werden. Die eigentliche Erneuerung des client-Zertifikats auf dem freeRADIUS-Server geht zum Glück jetzt total einfach, da man nur „make client“ verwenden muss, doch danach muss der freeRADIUS-Server einmal neu gestartet werden und noch wichtiger: das neue client-Zertifikat muss natürlich wieder per Richtlinie auf alle Geräte. Ob und wie zuverlässig dieser Schritt klappt, steht bisher noch in den Sternen. Es wäre natürlich fatal, wenn die Richtlinie mit dem neuen Zertifikat nicht rechtzeitig ausgeliefert werden kann und dann eines morgens alle Geräte offline sind, weil das Zertifikat abgelaufen ist. Daher suche ich noch einen Weg, wie man das z.B. über die relution-API per Cronjob o.ä. machen könnte. Wenn also jemand noch einen guten Tipp diesbzgl hat, würde ich mich freuen…
So, das wär’s für Erste. Mal sehen, wer bis hierhin durchgehalten hat … und nun bin ich gespannt, ob das jemand gebrauchen kann und es so oder so ähnlich bei sich nachmacht. Auch wenn es hier vielleicht einfach klingt – das war es nicht, denn die Sache ist schon ziemlich komplex! Und ohne dieses Forum wäre das auch nicht gelungen
Viele Grüße,
Michael
