04.04.2021

7936

MAC-Bypass mit Mikrotik und 802.1x Credentials

Hallo,

ich habe dank aqui mein WLAN erfolgreich auf mikrotik-AP mit Radius-Authentifizierung und dynamischer VLAN-Zuordnung umgestellt.

Jetzt stehe ich vor dem Problem, dass ich ein Web-Radio ins WLAN bringen muss, kann aber keine Weg für einen MAC-Bypass finden, da die MAC-Adresse vom WLAN-AP (cAP ac) nicht an den Radius-Server (opnsense) übermittelt wird.

Kann es sein das ich den Wald nicht vor lauter Bäumen sehe? Kann mir jemand mit einem Tipp weiterhelfen?

Vielen Dank im Voraus.

Raddi

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 665386

Url: https://administrator.de/contentid/665386

Ausgedruckt am: 24.11.2024 um 00:11 Uhr

37 Kommentare

Neuester Kommentar

Grüße

Zitat von @raddi:

Hallo,

ich habe dank aqui mein WLAN erfolgreich auf mikrotik-AP mit Radius-Authentifizierung und dynamischer VLAN-Zuordnung umgestellt.

Super gemacht, aber für einfache Gräte wie WEB Radio oder Streaming TV Steckern am TV Gerät vollkommen ungeeignet.

Jetzt stehe ich vor dem Problem, dass ich ein Web-Radio ins WLAN bringen muss, kann aber keine Weg für einen MAC-Bypass finden, da die MAC-Adresse vom WLAN-AP (cAP ac) nicht an den Radius-Server (opnsense) übermittelt wird.

Für wichtige interne Geräte, die kein VLAN können oder unterstützen kann man auch den Radius des Routers selber nutzen.
Hier Stellt man im Security Profile ebenfalls MAC Authentification ein. Aber nutzt im WLAN Menü im Reiter die Accsess List. Falls das auch nicht zum Erfolgt führt. Setzt man auf dem WLAN Interface einen Virtuellen AP auf, der dann über diese Profil Konfiguration, auf den internen Radius zugreift.

Kann es sein das ich den Wald nicht vor lauter Bäumen sehe? Kann mir jemand mit einem Tipp weiterhelfen?

Wer höhere Sicherheit will, muss auch den Vorgedanken haben, oder in die Projektbetrachtung einbeziehen, dass nicht alle Gräte, besonders aus dem Bereich Media oder Smarthome mit VLAN klarkommen.

Vielen Dank im Voraus.

Raddi

Es ist immer das Abwägen zwischen Sicherheit auf einem Interface, was ich bei Firmennetzwerken durchaus verstehe, aber zu Hause ? Auch Mikrotik Router OS bringt einen Radius Server Dienst mit, der Interface-genau, auch ohne VLAN eine gewisse Grundsicherheit bereitstellt. Klar ist das mit den VLANs besser ! Nur hat man nicht immer Endgeräte die das unterstützen. Also Virtuell AP. Mit eigenen Regeln. Diesen Bereich kann man natürlich auch mit eigenen Firewall-Regeln absichern.

Ich hoffe ich habe nicht den ganzen Wald dem Kahlschlag zu Preis gegeben. Aber es geht. Zumal man dem DHCP Server für den VirtAP in der Adressvergabe so einschränken kann, dass sich dort nicht unnötig viele Geräte anmelden können ;)
Weiterhin gibt es in den WLAN Einstellungen einen Punkt "Count Station" ! Die einfach runter drehen, dass sich maximal die Geräte anmelden können, die kein VLAN können. Wenn du dort 3 Counts einstellst, dann "redet" der AP, egal ob Hardware Real, oder Virtuell , mit nur 3 Geräte ! Jeder weitere oder erneute Anmeldeversuch mit einem 4 oder 4+ Geräte wird nicht beantwortet.

Vor dem Wald, ohne Bäume
KAI

Oben sind 2 Denkfehler enthalten die der "Kai" eigentlich wissen sollte, aber im Eifer des Gefechts wohl übersehen hat.

Gerade Mac Bypass ist dafür da Endgeräte OHNE einen integrierten 802.1x Client Radius kontrolliert ins WLAN zu bringen. Ob mit oder ohne dynamischer VLAN Zuweisung ist dabei unerheblich, denn das ist nur ein zusätzlicher Radius Parameter.
Der Radius Server auf dem Mikrotik ist KEIN vollständiger Radius Server sondern nur ein sehr rudimentärer und proprietärer Subset der diese Authentisierung nicht machen kann. Siehe dazu hier:

Mikrotik hEX CAPsMAN + Radius + User-Manager - Authentifizierung für WLAN funktioniert nicht
und
Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik
Generell kommen also ALLE WLAN Endgeräte mit VLANs als solchen klar. Ob aber deren Anwendungen wie mDNS/Bonjour, Multicasting, Streaming usw. Routing fähig sind ist eine andere Frage. Das hat der "Kai" ebenfalls leider etwas ungeschickt und widersprüchlich ausgedrückt oben.
Fazit:
Mit Mac Bypass kannst du ALLE Endgeräte auch Radius authentisieren ob mit oder ohne dynamisches VLAN ist dabei nur eine Frage der Radius Parameter.
Wichtig wäre für die Antwort deiner Frage zu wissen ob du eine kombinierte Abfrage, also 802.1x und Mac machst oder ob du nur eine reine Mac Authentisierung ohne 802.1x realisierst ?

Hallo

danke für Eure Ausführungen.

@kai:
Die Lösung mit 802.1x und VLAN war wohlüberlegt, da diese die beste Umsetzung der Anforderungen (keine Weitergabe von WLAN-Schlüsseln, kein Tausch von Netzwerkanschlüssen, individuelle Nutzungsbegrenzung, verschieden Firewall-Einstellungen, Netzwerksegmentierung, Gast-WLAN) ermöglicht.
Und ja die Kids von heute sind sehr kreativ wenn es darum geht Nutzungsbeschränkungen oder Sicherheitseinstellungen zu umgehen. 😉
Auch hatte ich den Bypass schon angedacht aber noch nicht umgesetzt. Als ich mich jetzt daran versucht habe, stellte ich fest, dass die MAC-Adresse nicht an den Radius-Server übermittelt wird und ich da in einer Sackgasse steckte.

@aqui:
Die Abfrage soll kombiniert laufen, d.h. 802.1x als Standard und MAC-Adresse als Bypass.
Aktuell nutze ich den Radius-Server der Opnsense. Der reicht für meine Zwecke bisher vollkommen aus.

Beste Grüße
raddi

stellte ich fest, dass die MAC-Adresse nicht an den Radius-Server übermittelt wird und ich da in einer Sackgasse steckte.

Bei richtig konfiguriertem Mac Baypass übermittelt der Authenticator immer die Mac Adresse des Supplicants. Das sieht der Standard so vor und jedes Endgerät auf der Welt hat ja nunmal eine Mac Adresse ansonsten wäre eine Netzwerk Kommunikation bekanntlich unmöglich.
Wenn die nicht übermittelt wird dann hast du dort entweder etwas falsch konfiguriert oder der Mac Filter spielt dir bei 802.1x einen Streich !
Hilfreich wäre mal wenn du den Freeradius Daemon in der OPNsense stoppst und dannach manuell mit "-X" im Debug Mode neu startest. Dort kannst du dann sehr genau sehen was der Authenticator an den Radius übermittelt. (Siehe dazu auch HIER mit Debug Beispielen).
Vermutlich nutzt du im MT den "Schrotschuss" Filter
/caps-man access-list
add mac-address=00:00:00:00:00:00 action=accept
Der alle Mac Adressen ungeprüft durchreicht. Den musst du natürlich anpassen wenn du eine doppelte Authentisierung machen willst.

Hallo aqui,
den von Dir als "Schrotschuss" bezeichneten Filter setzte ich gemäß Deinem Hinweis hier ein.
Du hast Recht, die MAC-Adresse wird an den Radius übermittelt, aber erst zusammen mit Benutzernamen und Passwort.
Damit kann der Bypass nicht funktionieren, oder? Wie muss ich die Konfiguration anpassen?

Indem du die Mac des Gerätes vom Filter ausnimmst.

Und wie mache ich das?
Muss ich jede Ausnahme im capsman eintragen oder geht das auch im Radius.
Sorry wenn ich so doof frage, aber ich mache das nur als Hobby 😬.
Ich habe auch noch das hier beim Radius-Server dazu gefunden. Hatte aber noch keine Zeit zum Ausprobieren. Ist auch die Frage wie in die opnsense integrieren? 🤔
Vielleicht hast Du ja noch eine Idee?

Das mit dem FreeRadius Link ist eine interessante Alternative die ich auch noch nicht auf dem Radar hatte bei kombinierter Authentisierung. Damit ginge das natürlich auch und ist ein cleverer Ansatz, da man dann nur eine einzige Datei "authorized_macs" pflegen muss.
Interessanter Ansatz den es mal zu testen gilt !!! Danke für den Link

Ansonsten musst du in der Tat jeden non .1x Client aus dem Capsman Filter nehmen. 00:00:... bedeutet ja das alles ungetestet durchrauscht.
Da ist der Ansatz über den Radius etwas eleganter, da zentraler.

Also ich habe jetzt eine ganze Weile rumexperimentiert, leider ohne Erfolg.
Ich stelle mich zu doof an die Sache mit dem MAC-Bypass zum laufen zu bringen.
Der Radius spuckt einen Haufen Fehlermeldungen aus:

/etc/freeradius/3.0/mods-enabled/files[15]: Configuration item "compat" is deprecated  
/etc/freeradius/3.0/mods-enabled/files[3]: Cannot use deprecated configuration item "compat"  
/etc/freeradius/3.0/mods-enabled/files[3]: Invalid configuration for module "authorized_macs"  

Oder:

/etc/freeradius/3.0/sites-enabled/default[422]: Failed to find "files" as a module or policy.  
/etc/freeradius/3.0/sites-enabled/default[422]: Please verify that the configuration exists in /etc/freeradius/3.0/mods-enabled/files.
/etc/freeradius/3.0/sites-enabled/default[422]: Failed to parse "files" entry.  
/etc/freeradius/3.0/sites-enabled/default[273]: Errors parsing authorize section.

Oder:

/etc/freeradius/3.0/sites-enabled/default[283]: Failed to find "authorized_macs" as a module or policy.  
/etc/freeradius/3.0/sites-enabled/default[283]: Please verify that the configuration exists in /etc/freeradius/3.0/mods-enabled/authorized_macs.
/etc/freeradius/3.0/sites-enabled/default[283]: Failed to parse "authorized_macs" entry.  
/etc/freeradius/3.0/sites-enabled/default[273]: Errors parsing authorize section.

Ich raffe es nicht vor mein Fehler ist.
Ich habe das Gefühl, dass die Anleitung nicht zu meiner Radius-Version passt. das Wiki ist auch schon von 2016 😖
Vielleicht hat aqui ja eine Idee

Sieht so aus als ob der diese Dateien nicht findet. Ggf. absoluten Pfad vergessen in der Angabe oder Gruppen und User Zugehörigkeit falsch gesetzt ?
Ich checke das kommende Woche mit dem FreeRadius hier, da mich die Kombi Lösung mit der zentralen "authorized_mac" Datei auch interessiert.

So, gemäß Anleitung den FreeRadius customized:

Datei "authorized_macs" in /etc/freeradius/3.0/ mit dem nano Editor angelegt
Datei mit chmod 640 entsprechende Rechte gesetzt
Datei mit chown freerad:freerad in die richtige Gruppe und User gesetzt
Dann Datei /etc/freeradius/3.0/mods-available/files erweitert am Ende

#
files authorized_macs {
        # The default key attribute to use for matches.  The content
        # of this attribute is used to match the "name" of the
        # entry.
        key = "%{Calling-Station-ID}"

        usersfile = ${confdir}/authorized_macs

        #  If you want to use the old Cistron 'users' file
        #  with FreeRADIUS, you should change the next line
        #  to 'compat = cistron'.  You can the copy your 'users'
        #  file from Cistron.
        #  compat = no
} 

Die Datei policy.conf musst du nicht ändern, die passt nur unterschiedliche Mac Schreibweisen an, das kann man auch entsprechend in der Datei authorized_macs in der Schreibweise berücksichtigen.
Tricky wirds jetzt in der Datei /sites-available/default Da suchst du mit dem Editor die Stelle "preprocess und scrollst weiter bis zur Stelle "eap" Dort fügst du dann den Code Schnipsel aus der Anleitung vor dem "eap" ein:

        #
        # If this is NOT 802.1x, assume mac-auth. We check this by testing
        # for the presence of the EAP-Message attribute in the request.
        if (!EAP-Message) {
                # Now check against the authorized_macs file
                authorized_macs

                if (!ok) {
                        reject
                }
                else {
                        # accept
                        update control {
                                Auth-Type := Accept
                        }
                }
        }

        else {
#
        eap {
                ok = return
#               updated = return
                }
        }
        # 

ACHTUNG: die geschweiften Klammern richtig setzen !!
Fertisch

Wenn du jetzt den FreeRadius mit "-X" startet sollte er ohne Fehler in den Status "Ready to process requests" gehen.
Achte in den Debug Outputs nochmal auf:
.# Loading module "files" from file /etc/freeradius/3.0/mods-enabled/files
files {
filename = "/etc/freeradius/3.0/mods-config/files/authorize"
acctusersfile = "/etc/freeradius/3.0/mods-config/files/accounting"
preproxy_usersfile = "/etc/freeradius/3.0/mods-config/files/pre-proxy"
}
.# Loading module "authorized_macs" from file /etc/freeradius/3.0/mods-enabled/files
files authorized_macs {
usersfile = "/etc/freeradius/3.0/authorized_macs"
key = "%{Calling-Station-ID}"
}
.# Loaded module rlm_expr
Das stellt dann sicher das alles korrekt geladen wurde und danach dann die Logik gilt:

Wenn User gültige 802.1x Credentials hat kommt er durch OHNE zusätzliche Mac Auth
Hat er keine 802.1x Credentials wird eine Mac Auth gemacht mit der Mac Adresse in der zentralen "authorized_macs" Datei.

Ein Test im Debug Mode sollte das dann verifizieren.
Danach kann man dann den Dienst wieder mit "systemctl restart freeradius" starten.

Sorry, das ich mich jetzt erst zurückmelde.
Ich werde das mal in den nächsten Tage ausprobieren ohne das WLAN lahmzulegen 😆

Ein paar Probleme müssen da ja trotzdem noch gelöst werden:
- wie bringe ich dem MAC-Bypass die VLAN-IDs bei
- funktioniert das Ganze auch mit dem Radius-Plugin der Opnsense?

Falls jemand schon einen Lösungsansatz hat, wird dieser gerne genommen.

Bis dahin

Raddi

funktioniert das Ganze auch mit dem Radius-Plugin der Opnsense?

Sollte dazu identisch sein:
Mikrotik - mehrere VLANs auf cAP AC mit CAPsMAN

Hallo,
nach mehreren Anläufen hatte ich heute endlich die Zeit das Ganze ausführlich zu testen.

Ich habe die Anpassungen (hoffentlich richtig) gemäß aquis Hinweisen vorgenommen. Kann sie aber nicht testen, da keine Anfragen beim Radius ankommen. 😖
Im Log des Mikrotik kann ich die Verbindungsversuche erkennen.

Aber der Log des Radius bleibt stumm. 🤔

Muss ich noch irgendwo die Konfiguration des RouterOS anpassen?

da keine Anfragen beim Radius ankommen.

Hast du einen Ping Check gemacht vom MT auf den Radius ??
Dazu nimmst du immer das Ping Tool der WinBox (oder CLI) und setzt unbedingt die Source IP auf eines der MT IPs die den Radius Server erreichen können.
Der Radius MUSS pingbar sein. Ansonsten besteht ja dann keine IP Connectivity zw. Radius und MT und da ist es dann logisch das alles stumm bleibt.

Muss ich noch irgendwo die Konfiguration des RouterOS anpassen?

Davon ist dann auszugehen wenn der Ping fehlschlägt.
Könntre aber auch an einer falschen IP des Radius liegen. Oder....sofern du einen Winblows NPS als Radius nutzt an dessen lokaler Winblows Firewall. Die blockt bekanntlich alles was aus fremden IP netzen kommt und wenn der MT als Absender eine zum Winblows Server nicht lokale IP verwendet bleibt die da hängen ! Beachte das !!
Wenn du einen Freeradius benutzt dann lässt du auf der Konsole mal ein tcpdump laufen mit tcpdump portrange 1812-1813 und startest dann einen Radius Zugriffs Versuch.
Dann solltest du in jedem Falle eingehende Radius Request Pakete sehen.
Wenn nicht hast du ein grundsätzliches IP Connectivity oder... Firewall Problem was du erstmal fixen solltest.

Ergänzung:
Die Verbindung zwischen MT und Radius funktioniert, da die regulären Anfragen funktionieren (mit Name+Passwort) nur die Anfragen die in den MAC-Bypass laufen sollen kommen nicht beim Radius an.

Sorry für das Missverständnis.

nur die Anfragen die in den MAC-Bypass laufen sollen kommen nicht beim Radius an.

Dann werden sie sehr wahrscheinlich (oder sogar sicher) gar nicht erst ausgesendet !
Wenn das gleiche Gerät aber .1x Requests sendet und die auch am Radius ankommen ist das ein recht sicheres Indiz dafür das die MT Konfig fehlerhaft ist.
Ohne die dann im Detail zu kennen um zu checken wo der Fehler dort ist ist ein Troubleshooting nicht einfach....

Die Konfiguration ist dank Deiner Unterstützung hier: Problem mit Radius-Abfrage beim Mikrotik CAPsMAN entstanden und sollte der Anleitung entsprechen.
Die Meldung in der Debug-Ausgabe, dass die Konfiguration mit dem MAC-Bypass geladen wurde kommt auch.

Kann es sein, dass der MT die Daten nicht weitergibt weil es keine WPA EAP Anfrage ist? Das Web-Radio das ich zum Testen nutzen kann kein WPA EAP nur WPA PSK Für solche Fälle soll ja der Bypass sein. In der Config steht ja auch

        # If this is NOT 802.1x, assume mac-auth. We check this by testing
        # for the presence of the EAP-Message attribute in the request.

Wenn ich es mit einem anderen Gerät versuche kommen die Anfragen an, werden aber wegen falscher Login-Daten abgelehnt.
Ich denke ich muss dem MT irgendwie sagen, dass er die Anfragen trotzdem an den Radius senden soll.
Kann es sein, dass ich die Konfiguration gemäß Deiner Anleitung hier: WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN ergänzen muss oder kommen die sich in die Quere?

kann kein WPA EAP nur WPA PSK

Nein, denn das PSK definierst du ja vorher immer statisch und musst du dann ja wie bei allen anderen Clients dort auch statisch eingeben.

Der MT lässt aber den Client nur dann ins Netz wenn auch zusätzlich die Mac Adresse im Radius authentisiert wurde !

Die vorgeschlagene Lösung ist eine reine MAC-Authentifizierung mit PSK oder irre ich mich da?
Ziel ist aber ein Bypass zu Benutzername/Password, für die Geräte die kein 802.1x können z.B. Webradio.
Meine Konfiguration sieht aktuell so aus:

Wenn ich es richtig verstanden habe ist die MAC-Adresse 00:00:00:00:00:00 dazu da alle zu akzeptieren (von dir als Schrotschuss bezeichnet). Also sollte er jede MAC-Adresse akzeptieren, oder?

Eine kombinierte Konfiguration EAP und PSK hatte ich auch schon getestet, hat aber auch nicht funktioniert. Entweder kam die Abfrage des PSK oder des Benutzernamens und Passworts.

Ich habe keine Idee wie ich dem MT sage, dass er die MAC übermitteln soll wenn keine Zugangsdaten eingegeben werden.

Die vorgeschlagene Lösung ist eine reine MAC-Authentifizierung mit PSK oder irre ich mich da?

Da irrst du nicht, das ist richtig !

Wenn ich es richtig verstanden habe ist die MAC-Adresse 00:00:00:00:00:00 dazu da alle zu akzeptieren

Du meinst die der Ausnahme Liste, oder ?
/caps-man access-list
add mac-address=00:00:00:00:00:00 action=accept
Ja, das ist richtig weil MT bei dem Setup immer eine kombinierte Abfrage macht Mac und .1x und beides passen muss um Zugang zu bekommen.
Mit der o.a. ACL hebelt man quasi die MAB Funktion statisch aus indem man generell alle Macs auf Accept setzt und nur noch die .1x Anfrage über Zugang ja oder nein entscheidet.

Wenn ich das richtig verstehe muss dem MT jetzt noch sagen, wenn er keine 802.1x daten bekommt soll er die MAC-Adresse als Zugangsdaten an den Radius zu senden damit der Bypass greifen kann.
Die Frage ist nur wie? Bisher bleibt der MT stumm.

Das ist ne sehr gute Frage… Bei den besseren Herstellern kann man die Reihenfolge customizen und das so setzen das nach einem positiven Hit die nachfolgende Auth nicht mehr gemacht wird oder man das mit einem Radius Attribut steuern kann.
Ggf. Mal ein kurzes Mail an den MT Support schicken und fragen ?!

@raddi, ich hatte aus anderen Gründen mit ähnlichen Gedanken zu tun und bin auch dies Diskussion verwiesen worden
Wenn ich mich hier durchlese, warum steigst du nicht auf

Private-Passphrase in der access-list

um?
Damit könntest für die verschiedenen Gerätegruppen ein eigenständiges PSK-Kennwort vergeben und kannst dies dann (hoffentlich, muss mich da auch noch einlesen)

Wireless Radius-Attribute wie bspw. Mikrotik-Wireless-PSK

den verschiedenen VLANs zuordnen.
Die Kids kennen nur ihre PSK-Kennwort(er) und deren Geräte kann man dann problemlos über FW-Regel einschränken.
Wenn die Kids selber Geräte haben wie Webradio-Player gibt es halt ein Extra PSK-Kennwort für diese Geräte, welche in ein VLAN kommen, wovon nur aus z.B. Webradio erreicht werden kann mittels alles sperren und explizitem freigeben und einer Drosslung der Geschwindigkeit < 1Mbit/s.

Ich komme von hier: Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik

es müsste im Prinzip möglich sein: https://forum.mikrotik.com/viewtopic.php?t=24406

Hallo PackElend,

diese Idee hatte ich auch schon und sollte auch umsetzbar sein.
Es wird dann wohl eine MAC-basierte Authentifizierung und der Radius gibt ein individuelles PSK zurück. Auch VLAN -Zuweisung etc. sollte damit funktionieren.

Nachteile:

Die Anmeldung ist geräte- und nicht nutzerbezogen
Die Lösung funktioniert nur im WLAN nicht im LAN
Mein Radius-Server (auf der opnsense) bietet dafür keine Web-GUI (wäre zu verschmerzen)

Daher habe ich diese Variante nicht umgesetzt.

Aktuell habe ich noch eine Anfrage beim Mikrotik-Support laufen. Allerdings ist da seit 3 Wochen keinerlei Reaktion erfolgt. Ich warte mal noch ab.
Eine weitere Alternative wäre ein zusätzliches WLAN mit PSK, aber die stören sich dann wieder gegenseitig

Zitat von @raddi:
Es wird dann wohl eine MAC-basierte Authentifizierung und der Radius gibt ein individuelles PSK zurück. Auch VLAN -Zuweisung etc. sollte damit funktionieren.

Nachteile:

Die Anmeldung ist geräte- und nicht nutzerbezogen

Man muss die MAC im voraus kennen, dass nervt mich, damit ist immer Handarbeit nötig, dass einzige was mit dann einfällt ist nen "kiosk", worüber die Geräte angemeldet werden können. Damit hätte einen art Nutzerbezug aber macht

Zitat von @raddi:
Eine weitere Alternative wäre ein zusätzliches WLAN mit PSK, aber die stören sich dann wieder gegenseitig

zwei SSIDs nötig, WPA-PSK und WPA-EAP

wenn

/caps-man access-list
add action=accept private-passphrase=PPSK_User1 vlan-id=VLAN_User1 vlan-mode=use-tag comment=User1
add action=accept private-passphrase=PPSK_User2 vlan-id=VLAN_User2 vlan-mode=use-tag omment=User2

klappen würde, wäre es schon einiges erreicht aber laut DPSK Dynamic WPA2 PSK support - MikroTik aber vielleicht geht dies nun in v7.x?

evtl. wäre auch https://radiusdesk.com/ aber ist nicht viel darüber zu lesen und das Forum wird scheint auch weniger aktiv bedient.

Dann Fällt mir nur noch ne Lösung über Automation Platformen, dann kann es aber auch schnell fragil werden und es gibt keine APIs die man ohne grösseren Aufwand ansprechen kann, siehe https://doc.freeradius.org/index.html
Mir Fallen da ein:

aber da kommt wohl einiges an ausprobieren hinzu, finde nur etwas hilfreiches, um mal zwischen Ansible und RunDeck zu differnrzieren:

(n8n.io kann auch mit RunDeck sprechen: https://n8n.io/integrations/n8n-nodes-base.rundeck wenn man etwas über ein WebForm aufbauen möchte)

Hallo

Zitat von @PackElend:

wenn

/caps-man access-list
add action=accept private-passphrase=PPSK_User1 vlan-id=VLAN_User1 vlan-mode=use-tag comment=User1
add action=accept private-passphrase=PPSK_User2 vlan-id=VLAN_User2 vlan-mode=use-tag omment=User2

klappen würde, wäre es schon einiges erreicht aber laut DPSK Dynamic WPA2 PSK support - MikroTik aber vielleicht geht dies nun in v7.x?

Laut der von Dir zitierten Diskussion hier forum.mikrotik.com/viewtopic.php?t=24406#p119449 sollte es mit

Mikrotik-Wireless-Psk

funktionieren. Käme auf einen Versuch an. Braucht dann aber wohl einen externen Radius.
Leider habe ich momentan weder Zeit noch Hardware um das zu testen.

Wie die Umsetzung von Mikrotik-Attributen mit einem Radius-Server funktioniert, ist sehr gut im VLAN HowTo von aqui beschrieben. Das sollte mit dem Mikrotik-Wireless-Psk Attribut analog funktionieren.

Zitat von @PackElend:

Dann Fällt mir nur noch ne Lösung über Automation Platformen, dann kann es aber auch schnell fragil werden und es gibt keine APIs die man ohne grösseren Aufwand ansprechen kann, siehe https://doc.freeradius.org/index.html

Ich nutze wie gesagt einen den Radius auf meiner Opnsense für die Verwaltung der Zugänge. Der hat eine Web-Oberfläche, die auch die Zuordnung der VLANs unterstützt.

geht leider nicht so ist gibt nochmal einen anderen Wiki-Eintrag der das sauber trennt, bin noch nicht dazu gekommen, dass dort zu schreiben

https://wiki.mikrotik.com/wiki/Manual:CAPsMAN#Access_List

private-passphrase ist kein client matching parameter
MAC-Bypass mit Mikrotik und 802.1x Credentials#

Ich nutze wie gesagt einen den Radius auf meiner Opnsense für die Verwaltung der Zugänge. Der hat eine Web-Oberfläche, die auch die Zuordnung der VLANs unterstützt.

aber andere Benutzer (nicht Admins) sind nicht in der Lager eigene Geräte ihrem "Benutzerkonto/VLAN" hinzufügen?

Eine erste Lösung macht baut gerade https://forum.mikrotik.com/memberlist.php?mode=viewprofile&u=75040 mit einem Skript, er hatte es mir gestern gezeigt.
Anhand des Hotspot-Konto (Anmeldung) wird das Gerät, welches sich gerade am HS anmeldet in das zum Konto hinterlegten VLAN hinzugefügt. Die Zuordnung geht dann über die Access-List. Ist super charmant, dann bleiben nur noch so Kandidaten wie Chromecast zu lösen.

aber andere Benutzer (nicht Admins) sind nicht in der Lager eigene Geräte ihrem "Benutzerkonto/VLAN" hinzufügen?

Damit würde man ja logischerweise auch den Bock zum Gärtner machen und ein Port Security Design völlig ad absurdum führen wenn jeder die Regeln bestimmt.

Zitat von @aqui:

aber andere Benutzer (nicht Admins) sind nicht in der Lager eigene Geräte ihrem "Benutzerkonto/VLAN" hinzufügen?

Damit würde man ja logischerweise auch den Bock zum Gärtner machen und ein Port Security Design völlig ad absurdum führen wenn jeder die Regeln bestimmt.

Ich glaube wir reden hier immernoch etwas einander vorbei.
Diese Fragen sind immer mit dem Hintergrund das der gewöhnliche Benutzer nicht EAP oder Hotspot fähige Geräte zum Beispiel mit einem Gäste WLAN verbindet, dann ein GUI (website) öffnet und dort die Geräte welche sich innerhalb der letzten Stunde am Gäste WLAN angemeldet haben und noch verbunden sieht.
Die Anmeldung im GUI ist entweder über Kennwort oder Benutzer wird über seine IP erkannt.
In diesem GUI kann er dann die Geräte auswählen, welche seine sind.
Durch diese Aktion werden diese der in die access-list oder radius User file eingetragen und dem VLAN des Benutzer hinzugefügt. Bei der nächsten Anmeldung des Gerätes landet dies nicht im Gäste VLAN sondern im VLAN des Benutzer.

Der Benutzer ist nur in der Lage, die Geräte in seinem VLAN auszutragen und Geräte, aktiv im Gäste VLAN, auszuwählen, so dass sie seinem VLAN zugeordnet werden.

Hallo zusammen,

hat etwas gedauert, aber naja.
Ich habe mal etwas weiter getestet. Leider ohne wirklichen Erfolg 😟.

Zitat von @aqui:

Das ist ne sehr gute Frage… Bei den besseren Herstellern kann man die Reihenfolge customizen und das so setzen das nach einem positiven Hit die nachfolgende Auth nicht mehr gemacht wird oder man das mit einem Radius Attribut steuern kann.

Mein Plan war den "Schrotschuss" auf dem Radius zu machen, damit CAPsMAN die MAC-Adresse in jedem Falle übermittelt. Daher habe ich diesen durch eine Radius-Abfrage ersetzt.
Damit komme ich dahin, dass der CAPsMAN in jedem Fall den Radius fragt. Soweit so gut.

Allerdings muss ich dann alle Clients in der MAC-Auth auflisten 🤔. Das habe ich zu Testzwecken gemacht. Soweit so gut.
Frage: gibt es hier eine Möglichkeit, dass er alle akzeptiert?

Wenn ich zusätzlich einen Radius-Account für den Client mit MAC als Username und Passwort anlege bekommt er ein OK, verbindet ihn aber nicht 😖.
Das funktioniert nur bei der Übermittlung von "korrekten" EAP-Credentials durch den Client.

Übersehe ich hier etwas?
Anscheinend erkennt der Radius auch die MAC-Anfrage als EAP-Anfrage. Kann es sein, dass das ein Teil des Problems ist?
Was müsste man tun, damit der Radius die MAC-Abfrage und die EAP-Credential auseinanderhalten kann?

Ggf. Mal ein kurzes Mail an den MT Support schicken und fragen ?!

Hab ich gemacht. Bis heute keine Reaktion 😶

Bis denne Raddi

Du hast ja bei 802.1x mit WPA Enterprise schon einen Mac Filter mit

/caps-man access-list
       add mac-address=00:00:00:00:00:00 action=accept 

aktiv. Das bedeutet dann das die Macs immer schon durchrauschen.
Wenn man den Filter nicht aktiv hat macht der MT immer eine doppelte Authentisierung. Also erst Mac und dann 802.1x. Beide müssen vom Radius dann positiv beantwortet werden damit der Client authentisiert wird.
Wenn du den FreeRadius im Debugging Mode laufen lässt siehst du das bei 802.1x immer 2 Anfragen einlaufen, einmal Mac und danach dann 802.1x. Ohne den Filter müssen beide ein access permit vom Radius bekommen. Fehlt nur einer wird der Client nicht authentisiert.
Mit dem Filter ignoriert der MT die Mac Adresse generell und nur das .1x ist relevant.
Bei Premium WLAN APs hat man hier oft eine Konfig Option das man die Reihenfolge der beiden Auth Verfahren bestimmen kann und auch ob bei Success die nachfolgende ignoriert werden kann oder zwingend zusätzlich ausgeführt werden muss. Das ist so bei MT nur sehr eingeschränkt möglich.
Die Frage ist WAS genau du bei der Client Authentisierung im einzelnen erreichen willst bzw. welcher Logik Mac und .1x Auth folgen sollen ?

Zitat von @aqui:

Du hast ja bei 802.1x mit WPA Enterprise schon einen Mac Filter mit

/caps-man access-list
       add mac-address=00:00:00:00:00:00 action=accept 

Das funktioniert auch genau so.

Mit dem Filter ignoriert der MT die Mac Adresse generell und nur das .1x ist relevant.

Soweit verstanden. Auch das funktioniert. Allerdings werden dann keine Daten von Clients ohne .1x an den Radius übermittelt. Somit kann der MAC-Bypass keine Wirkung haben.

Bei Premium WLAN APs hat man hier oft eine Konfig Option das man die Reihenfolge der beiden Auth Verfahren bestimmen kann und auch ob bei Success die nachfolgende ignoriert werden kann oder zwingend zusätzlich ausgeführt werden muss. Das ist so bei MT nur sehr eingeschränkt möglich.
Die Frage ist WAS genau du bei der Client Authentisierung im einzelnen erreichen willst bzw. welcher Logik Mac und .1x Auth folgen sollen ?

Mit der Prüfung der MAC gegen den Radius will ich erreichen, dass auch bei Clients ohne .1x die MAC-Adresse an den Radius übermittelt wird. Wenn dazu 2 Anfragen nötig sind, dann auch das.

Allerdings wäre eine default-Lösung, die alle MACs akzeptiert, super, da ich diese ja nur brauche damit der MT mit dem Radius redet wenn kein .1x im Spiel ist.

Der Bypass, wie hier im freeradius wiki beschrieben geht. Die EAP-Abfrage wird übersprungen und die MAC-Adresse mit der authorized_macs-Datei abgeglichen. Der Radius sendet dann ein OK.

(90) Login OK: [Client-MAC/Client-MAC] (from client MikrotikWAP port 0 cli Client-MAC)
(90) Sent Access-Accept Id 56 from Radius-IP:1812 to CAPsMAN-IP:58196 length 20
(90) Finished request

Trotzdem kommt der Client nicht rein.

Da hast du Recht, Clients ohne .1x sind dann gekniffen. Das Problem ist das es m.E. bei MT kein Umdrehen der Logik gibt also erst .1x und dann Mac. Bzw. bei dir dann wenn .1x fehlschlägt mache Mac wenn .1x positiv, dann überspringe Mac.
Der MT macht aber immer fix zuerst Mac und dann .1x und damit hast du in einer gemischten Umgebung mit non .1x Clients dann ein Problem, denn das kann man nicht lösen.
00:00:00:00:00:00 ist ja eine Wildcard Maske. Wenn deine .1x Clients alle den gleichen Vendor Code in der Mac haben könnte man ggf. nur die passieren lassen. Ich weiss auch nicht ob mal mehrfache Mac Filter in die Access Liste packen kann, was aber letztlich sicher geht. Allerdings artet das dann auch in Frickelei aus.
Mit der einfache Umkehr der Authnetisierungs Reihenfolge wäre das sofort geklöst aber eben das geht bei MT nicht.

moin,

mögliche Lösung mit Daloradius: das Fronend hat eine Mac-Bypass-Funktion bei den Usern-Settings, wenn man die Mac-Auth des MT cAPman verhindern kann, wäre es unter Umständen möglich, muss ich nächstes Wochenende mal testen. Evtl. muss man noch "fall through"-Anweisungen bei den Reply-Attributen Usern oder Gruppen/Profilen ergänzen.

Ggf. gibts da auch einen Workaround mit dem onboard User Manager unter 7.x. Da hat MT den Radius ja gleich mit an Bord.
Wenn nur die Bugs in der 7er nicht wären.

Mikrotik - dyn-vLAN und MAC-auth in ROS 7.2

Frage Sonstige Systeme MikroTik

Mehr von raddi

Problem mit Radius-Abfrage beim Mikrotik CAPsMANraddi - 3 Kommentare

regionale Einstellungen blockiertraddi - 6 Kommentare

lokale Anmeldung funzt nichtraddi - 3 Kommentare

Heiß diskutiert