Anleitung/Tipp: Radius Peap-Mschapv2 mit ntlm_auth für WPA2-Enterprise

Hallo,
den Radius auf der Opnsense habe ich nach einer Woche testen in die Ecke geschmissen, weil er einfach nicht mit meinen UnifiAP’s und der AD zusammenarbeiten will. Ich habe daher kurzerhand einen Radius auf dem lmn7-server installiert und eingerichtet. Genauso gut kann man den Radius auf eine eigene Maschine (z.B. den Unificontroller) auslagern. Die folgende Anleitung muss dann nur noch darum ergänzt werden, dass diese Maschine zuerst in die Domäne aufgenommen werden muss. Ich habe für mein Setup keine Sicherheitsbedenken, den Radius direkt auf dem Server zu betreiben, da die Anfragen nur aus einem einzelnen internen Subnetz kommen und ich nur von dort Radiusanfragen zulasse.

1. Freeradius installieren und aktivieren:

#apt install freeradius
#systemctl enable freeradius.service

2. ntlm_auth in samba erlauben:

Einfügen von: ntlm auth = yes in die /etc/samba/smb.conf.

Danach samba-ad-dc neu starten:

#systemctl restart samba-ad-dc.service

3. Radius konfigurieren:

  • Freeradius Zugriff auf winbind geben:

     #usermod -a -G winbindd_priv freerad
     #chown root:winbindd_priv /var/lib/samba/winbindd_privileged/
    
  • Einfügen von ntlm_auth ganz am Anfang unter authenticate unter /etc/freeradius/3.0/sites-enabled in die Dateien default und inner-tunnel:

      authenticate {
          ntlm_auth
          #
    
  • Ändern der Datei unter /etc/freeradius/3.0/mods-enabled/mschap wie folgt:

    Einfügen der Zeilen:

      mschap {
              use_mppe = yes
              with_ntdomain_hack = yes
              # 
    

    Anpassen der ntlm_auth weiter unten; zuerst das Kommentarzeichen # entfernen, dann die Zeile folgendermaßen anpassen:

    ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --domain=DOMÄNE --require-membership-of=DOMÄNE\wifi --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
    

    Dabei muss DOMÄNE durch den eigenen Domänennamen ersetzt werden. Der Teil –require-membership-of=… lässt nur Mitglieder der Gruppe wifi zu. So funktioniert die Wlansteuerung über die WebUI.

  • Ändern der Datei unter /etc/freeradius/3.0/mods-enabled/ntlm_auth; zuerst das Kommentarzeichen # entfernen, dann die Zeile folgendermaßen anpassen:

    exec ntlm_auth {
    wait = yes
    program = "/usr/bin/ntlm_auth --request-nt-key --domain=DOMÄNE --require-membership-of=DOMÄNE\wifi --username=%{mschap:User-Name} --password=%{User-Password}"
    }
    

    Dabei muss DOMÄNE durch den eigenen Domänennamen ersetzt werden.

  • Einfügen der folgenden Zeile in die /etc/freeradius/3.0/users ganz oben:

    DEFAULT     Auth-Type = ntlm_auth
    
  • Freeradius neustarten:

    #systemctl restart freeradius.service
    

WICHTIGE Bemerkung:
Das Defaultverhalten der lmn7 ist, dass ein neu angelegter User immer in der Gruppe wifi ist, d.h. auch alle Schüler dürfen erstmal ins Wlan! Die Steuerung der Gruppenzugehörigkeit geht auf der Konsole über:

#sophomorix-managementgroup --nowifi/--wifi user1,user2,...

Es wäre also extrem umständlich, alle Schüler einzeln aus der Gruppe zu schmeißen. Man kann das aber recht schnell erledigen. Alle User des Systems auflisten und in eine Datei schreiben:

#samba-tool user list > user

Jetzt entfernt man alle User aus der Liste, die immer ins Wlan dürfen sollen. Danach baut man die Liste zu einer Kommazeile um mit:

#less user |  tr '\n' ',' > usermitkomma

Jetzt kann man das an den o.g. sophomorixbefehl übergeben:

#sophomorix-managementgroup --nowifi $(less usermitkomma)

Das kann man natürlich auch alles in ein Script packen.

4. Firewallregeln anpassen:

  • Auf dem Server unter /etc/linuxmuster/allowed_ports den Radiusport 1812 eintragen:

    udp domain,netbios-ns,netbios-dgm,9000:9100,1812
    

    Danach Server neustarten.

  • Auf der Opnsense:

    Hier muss je nach eigenen Voraussetzungen dafür gesorgt werden, dass die AP’s aus dem Wlan-Netz den Server auf dem Port 1812 udp erreichen können. Bei mir sieht die Regel z.B. so aus:

Jetzt sollte die Authetifizierung per WPA2-Enterprise funktionieren, sofern der Testuser in der Gruppe wifi ist. Ein Zertifikat ist nicht nötig.

Sollte das nicht funktionieren hält man den Freeradiusdienst an und startet ihn im Debugmodus.

# service freeradius stop
# service freeradius debug

Jetzt sieht man alle Vorgänge während man sich versucht mit einem Device zu verbinden.

VG

Dominik

5 „Gefällt mir“

Hallo Dominik.
Bist du dabei geblieben? Das ist eine der vielen Fragen, die ich an das v7-Setup habe: Wohin mit welchem Dienst? Es ist ja ein docker-Host mit an Bord aber mir ist weiterhin leider nicht ganz klar, welche Diente dorthin ausgelagert werden – und warum!? (So verstehe ich es z.B. so, dass der RevProxy auf dem Docker-Host laufen soll. Warum kommt der nicht direkt auf die OPNSense??)

Die Radius-WPA2-Enterprise Auth mit Unifi wird bei uns ein zentraler Punkt werden, wenn der coova eines Tages wegfällt. Daher wäre es sehr gut, wenn ich da keinen exotischen Weg einschlage sondern es genauso mache, wie die Mehrheit hier … dein Weg scheint mit der v7 ja zu funktionieren. Machen das andere auch auf diese Weise?

Bei uns sind alle Unifi-Accesspoints bisher hinter dem „blauen“ im „lila/transparenten“ Netz und müssten dann direkt an die OPNSense-FW…

Schönen Gruß,
Michael

Hallo Michael,

Bist du dabei geblieben?

ja: Dominik und ich setzen das so ein.

Das ist eine der /vielen/ Fragen, die ich an
das v7-Setup habe: /Wohin mit welchem Dienst?/ Es ist ja ein docker-Host
mit an Bord aber mir ist weiterhin leider nicht ganz klar, welche Diente
dorthin ausgelagert werden – und warum!?

Beispiele:

  • mrbs
  • postfolio
  • nextcloud
  • webserver
  • mailserver

Warum?
Weil das alles services sind, die von außern erreichbar sein sollten:
also nicht auf dem lmn server laufen sollten.

(So verstehe ich es z.B. so,
dass der RevProxy auf dem Docker-Host laufen soll. Warum kommt der nicht
direkt auf die OPNSense??)

weil der Dockerhost nicht in grün stehen sollte: sondern in Rot.
Deswegen benötigt er seinen eigenen reverse Proxy.
Dass er in Grün steht ist nur in der Appliances so.
Im Produktivbetrieb weiß ich nicht, was auf einem Docker in Grün laufen
soll: ich mache doch keinen Server, der in Grün steht vom Internet aus
erreichbar…

Die Radius-WPA2-Enterprise Auth mit Unifi wird bei uns ein zentraler
Punkt werden, wenn der coova eines Tages wegfällt. Daher wäre es sehr
gut, wenn ich da keinen exotischen Weg einschlage sondern es genauso
mache, wie die Mehrheit hier … dein Weg scheint mit der v7 ja zu
funktionieren. Machen das andere auch auf diese Weise?

bis jetzt sind wir zwei :slight_smile:

LG

Holger

Hallo Michael,

so jetzt in der richtigen Reihenfolge

Ich gehe davon aus, dass es so gedacht ist:

  • der mitgelieferte (interne) Dockerhost kann docker-container aufnehmen, die nach grün passen, also Dienste anbieten, die im grünen Netz Sinn machen. Im Moment ist das meines Wissens nur der Mailservice, der nur innerhalb der Schule läuft. Dazu der ReverseProxy, damit man mehr Dienste andocken könnte.

  • MAn kann also auch den freeradius und unifi-controller z.B. auch auf dem (internen) dockerhost laufen lassen. Ich sehe grade nicht, warum das keine genauso gute Idee ist, wie auf dem lmn-server selbst.

  • Dass auf dem internen dockerhost ein reverse proxy läuft ist nicht schlimm, relevant. Den würde ich auch nicht auf die OpnSense auslagern.

  • für alle von Holger und dir beschriebenen Dienste setzt man einen eigenen dockerhost in orange oder rot. Der hat dann auch seinen eigenen reverse proxy. Ich nenne den externen dockerhost. Momentan setze ich da noch meinen eigens gestrickten ein, will aber auf den ext-dockerhost migrieren, den Frank in github vorgeschlagen hat…

  • Dass auf dem externen dockerhost ein reverse proxy läuft könnte man noch diskutieren. Evtl. klappt das auch mit dem reverse proxy auf der OpnSense, was ich bisher mache, aber das hat noch keiner getestet.

  • Ich habe das OpnSense Portal statt unseres Coovas eingerichtet until further notice. (Wir haben keine Unifi und unsere APs werden dann aus der Cloud auf uns herabregnen, wenn der Dienstleister mal Zeit hat)

VG, Tobias

VG, Tobias

1 „Gefällt mir“

Hi. Jetzt sehe ich klarer. Danke für die ausführlichen Erläuterungen.
Dass man es uU mit mehreren docker-Hosts zu tun hat, war mir bisher irgendwie nie so richtig klar.
Bleiben zwei Fragen:

  • Let’s Encrypt kann auch OPNSense selbst. Sinnvoll?
  • Moodle (selbst gehostet) auf einen normalen LAMP-Server oder auch lieber auch in einen docker Container? Diese Frage hatten wir schon mal ohne richtiges Ergebnis diskutiert, meine ich.

Schöne Grüße
Michael

Hallo zusammen,

ich bin auch auf der Suche nach einer WLAN-Lösung, die für unsere Unifi-APs neben WPA-PSK für schuleigene Geräte und Radius für Schüler-/KollegInnen auch Captive-Portal mit Voucher für Gäste machen kann und bin gespannt, was sich hier als Königsweg etabliert.
Nachdem FreeRadius auf der OPNsense verschiedentlich nicht so toll funktionieren soll (?), hatte ich mir überlegt, netzint-unifi-aut2 einzusetzen, das o.g. wohl alles können soll und dafür nicht mal Radius benötigt, sondern direkt gegen das AD authentifiziert. Hat das jemand im Einsatz und kann berichten? Leider gibt es dafür keine Doku, zumindest habe ich keine gefunden!?

Zum Thema Reverse Proxy / Docker @baumhof: warum stellst Du die genannten Dienste nach „Rot“ und nicht in eine DMZ?

Zum Thema Letsencrypt: hab ich privat für meinen einzelnen Seafile-Server am Laufen und ist dort perfekt. Für den Einsatz in der Schule finde ich das Argument unseres Dienstleisters nachvollziehbar, dort besser mit einem kommerziellen Wildcard-Zertifikat zu arbeiten, wenn man (sehr viel) mehr als eine Maschine mit SSL/TLS versorgen muss. Wirldcar-Zertifikate gibt’s zwar mittlerweile auch von Letsencrypt aber dazu muss man meine ich Zugriff auf den entsprechenden DNS-Server haben.

Viele Grüße,
Jochen

Hallo Jochen,

Zum Thema Reverse Proxy / Docker @baumhof
https://ask.linuxmuster.net/u/baumhof: warum stellst Du die genannten
Dienste nach „Rot“ und nicht in eine DMZ?

ich hab BelWü: ROT ist bei mir eine DMZ: warum soll ich die Strucktur
hinter dem Cisco durch eine weitere DMZ verkomplizieren?

LG

Holger

Na dann komm ich da mal zur Hilfe:

unifi_auth_installation_public.pdf (229,5 KB)

Das ganze ist schon länger öffentlich verfügbar, wir sind nur noch im Aufbau wie wir das öffentlich in Zukunft präsentieren.
Die Anleitung sollte dir aber sicherlich weiter helfen.

Gruß,
Andreas

Hallo Andreas,

super! Vielen Dank!!!:grinning:

Viele Grüße,
Jochen

Achso: Ich kann natürlich auch noch berichten dass das ganze ziemlich gut funktioniert :smiley:

Hi.
cool. Sieht gut aus! Das ganze ist mit v7 auch bereits erprobt? Ich frage nur, weil in der Doku noch LDAP und (noch) nicht AD steht.
Diese Erweiterung gehört auf den gleichen Host, auf dem der Unifi-Controller läuft, nehme ich an?

Wo wir schon dabei sind: in der v7-Anleitung ist auch die Rede von einer unifi-VM. Die gibt es aber nirgendwo. Wenn die Strategie künftig auch hier ist, den Controller + diese Erweiterung in einen docker-Container zu stecken (z.B. diesen hier), dann sollte das irgendwo dokumentiert sein, oder?

Schöne Grüße,
Michael

Hallo zusammen,

wer das selbst machen und nicht dockern möchte:
hier gibt’s wunderbar funktionierende Skripte, um für „fast alle linuxoiden“ OSs in Nullkommanichts einen Unifi-Controller

  • inkl. aller Abhängigkeiten installieren

  • updaten

  • und mit Let’sEncrypt-Zertifikat versehen

zu können.

Viele Grüße,
Jochen

1 „Gefällt mir“

Hallo Jochen. Sagenhaft!
Das nimmt einem viel Arbeit ab …
(Ich frage mich aber weiterhin, welcher Weg der offiziell empfohlene sein wird – nur für den Fall, dass Probleme auftauchen sollten und man nicht mit einer exotischen One-Man-Lösung alleine dastehen will :slight_smile: )

Schöne Grüße,
Michael

Hallo Michael,

ich vermute, dass es hier nie einen offiziellen Weg geben wird, da man ja nicht vorgeben sollte, welche Hardware von welchem Hersteller jemand beschaffen sollte.
Klar haben viele Unifi…

Viele Grüße,
Jochen

Hallo Jochen.
OK, kann man natürlich einsehen. Wenn man das per Docker-Container regeln will, muss der Host aber in das ehemals blaue und jetzt einfach WiFi genannte Netz. Also macht es letztlich kaum einen Unterschied, ob man nun einen weiteren Docker Host aufsetzt im WLAN oder direkt eine VM im passenden Netz zusammen mit den von dir genannten Scripten einsetzt – oder wie siehst du das?

Michael

Hallo Michael,

ich denke, das kommt auf die persönlichen Vorlieben an. Ich persönlich fühle mich (derzeit) mit zwar virtualisierten aber nicht dockerisierten Lösungen sicherer, das liegt aber daran, dass ich mich mit Docker noch nicht ausreichend befasst habe.
Bei uns kommt die VM mit dem Unifi-Controller und dem netzint-plugin in’s Management-Netz, zusammen mit den APs.
Wie und wohin wir dann die ganzen WLANs routen, muss ich demnächst erst ausbaldowern…

Viele Grüße,
Jochen

Hi.
Ich bevorzuge auch die virtualisierte und nicht dockerisierte Lösung – aus den gleichen Gründen wie du: möglichst KISS (das erste „S“ wäre bei einer zusätzlichen docker-Schicht dazwischen kaum zu halten…)

D.h. dass du VLANs hast und die Funknetze dann in jeweils andere VLANs legst, ja?
Bei uns ist der Controller derzeit im WLAN von jedem Gerät aus erreichbar … hatte ich bisher nicht als Risiko eingestuft aber wenn’s auch anders geht, fände ich es auch gut, wenn das Management und das was die User zu sehen bekommen, in zwei unterschiedlichen Subnetzen läuft…

P.S: habe unter Proxmox gerade den docker-Host (der für das grüne Netz gedacht ist) geklont. Den packe ich dann ins WLAN und bin flexibel, ob ich nun docker oder das Script nehme…
Schönen Gruß,
Michael

Genau. Wir planen mehrere WLANs/VLANs für:

  • Lehrer: Authentifizierung gegen AD mit netzint-unifi-auth
  • Schüler: dito
  • schuleigene Geräte: WPA2-PSK
  • Gäste: Captive Portal mit Vouchers
    Klar, „Lehrer“-WLAN heißt trotzdem, dass es nicht in’s Lehrer-Netz geroutet wird, dort darf es ja kein WLAN geben.

Viele Grüße,
Jochen

Ist das eigentlich amtlich bzw gilt das für alle Bundesländer in gleicher Weise? Hier: NDS…

Btw: das von dir vorgeschlagene Script läuft unglaublich gut für die Ersteinrichtung und für Updates. Backups kann es auch gleich mit anlegen. Super Sache!

Hallo Michael,

Kann ich Dir nicht sagen. In BW ist das so.

Viele Grüße,
Jochen