Mikrotik: 802.1X Port basierte Authentifizierung mit Zertifikaten unter RouterOS 7 mit User-Manager als Radius-Server
Inhaltsverzeichnis
Einleitung
Die folgende Anleitung soll als eine zusätzliche Ergänzung zu der schon bestehenden hervorragenden Übersicht von @aqui in der Anleitung Dynamische VLAN Zuweisung für WLAN (u. LAN) Clients mit Mikrotik dienen, und die Möglichkeiten des User-Managers vorstellen der als bislang in RouterOS 6 als "abgespeckter" Radius-Server sein Dasein pflichtete. Mit den neuen Möglichkeiten wird der User-Manager endlich auch zu einem echten Radius-Server den man auch zur Authentifizierung zusätzlich zu PAP, CHAP, MS-CHAP, MS-CHAPv2 über die gängigen EAP-Methoden EAP-TLS, EAP-TTLS and EAP-PEAP nutzen kann, damit wächst der User-Manager zu einem, zwar nicht einem freeradius ebenbürtigen Kandidaten heran, aber in Zukunft kann man auch für einige Setups auf einen separaten Radius-Server verzichten.
Ich greife hier schon etwas der aktuellen Entwicklung von RouterOS im produktiven 6er Zweig voraus und möchte den neuen User-Manger im aktuellen Release von RouterOS 7 im Zusammenspiel mit 802.1X Port basierter Authentifizierung vorstellen. Da in @aqui 's Anleitung schon die dynamische VLAN Zuweisung für WLAN-Clients behandelt wurde, greife ich hier die in RouterOS enthaltene 802.1x Port basierte Authentifizierung auf.
Die Anleitung funktioniert ausdrücklich nicht auf dem 6er Zweig von RouterOS.
Hinweise
Für den User-Manager wird es in Zukunft auch kein extra Web-Administrationsportal mehr geben und die Verwaltung wird in Winbox und in das reguläre Konfigurationswebinterface eingepflegt. Da es zum Zeitpunkt des Verfassens dieser Anleitung noch keine User-Manager GUI gab beschränke ich mich hier vornehmlich auf die Konfiguration über die Konsole.
Das User-Manager Paket ist ein separates Package zu finden unter "Extra packages" unter https://mikrotik.com/download. Das *.npk extrahiert man und zieht es entweder per Drag n' Drop in Winbox auf den Router, oder überträgt es per (S)-FTP in das Root Verzeichnis des Mikrotik. Nach einem obligatorischen Reboot steht der User-Manager zur Verfügung.
1. Radius Client erstellen
Damit der Mikrotik Radius-Anfragen an den User-Manager schicken und empfangen kann legen wir einen entsprechenden Eintrag wie folgt an:
/radius add address=127.0.0.1 secret=Passw0rd service=dot1x src-address=127.0.0.1
2. Interface für 802.1X Authentifizierung vorbereiten
/interface dot1x server add interface=ether2 disabled=yes
Hinter interface= geben wir den Port an welchen wir mit 802.1x schützen möchten. Vorerst deaktivieren wir den Eintrag noch (disabled=yes) da sonst die Verbindung zum Client gekappt wird. Zum späteren Zeitpunkt aktivieren wir den Eintrag dann (Punkt 6).
3. Zertifikate erstellen
Die Anleitung soll jetzt nicht erneut die Grundlagen über die Erstellung von Zertifikaten behandeln, dafür existieren genügend ausführliche Anleitungen im Netz. Für das Beispiel generieren wir hier der Einfachheit halber eine Zertifizierungsstelle,Server- und Client-Zertifikat direkt auf dem Mikrotik.
Unsere CA nennen wir im Beispiel DOT1X_CA, den Common-Name des Server-Zertifikats DOT1X_SERVER und den des Clients DOT1X_CLIENT1.
3.1 CA Zertifikat erstellen und signieren
/certificate add name=DOT1X_CA common-name=DOT1X_CA days-valid=7300 trusted=yes country=DE
/certificate sign DOT1X_CA
3.2 Server Zertifikat erstellen und signieren
/certificate add common-name=DOT1X_SERVER days-valid=730 country=DE key-usage=tls-server,tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_SERVER ca=DOT1X_CA
3.3 Client Zertifikat erstellen und signieren
/certificate add common-name=DOT1X_CLIENT1 days-valid=730 country=DE key-usage=tls-client,digital-signature,key-encipherment
/certificate sign DOT1X_CLIENT1 ca=DOT1X_CA
4. Zertifikate für die Verwendung am Client exportieren
Das Zertifikat der Zertifizierungsstelle (CA) exportieren wir als *.crt
/certificate export-certificate DOT1X_CA
Und das Client Zertifikat mit dessen privatem Schlüssel als *.p12 pkcs12 Container
/certificate export-certificate DOT1X_CLIENT1 export-passphrase=Passw0rd type=pkcs12
5. User-Manager einrichten
Dieser Schritt besteht hauptsächlich aus folgenden Schritten:
- Router-Objekt anlegen (Authenticator festlegen)
- Zu nutzendes Server Zertifikat festlegen
- Profil anlegen(definieren von Limits usw.)
- Authentifizierungs-Variante für EAP-TLS erstellen
- User anlegen
- User dem Profil zuweisen.
Die Schritte fasse ich hier als Konsolenbefehle zusammen, Passwort und Namen der Zertifikate müssen angepasst werden wenn oben dafür andere Werte verwendet wurden:
/user-manager router add address=127.0.0.1 name=localrouter shared-secret=Passw0rd
/user-manager set certificate=DOT1X_SERVER enabled=yes
/user-manager user group add name=dot1x-tls-auth outer-auths=eap-tls
/user-manager user add name=DOT1X_CLIENT1 group=dot1x-tls-auth
6. 802.1X am Mikrotik für das Interface aktivieren
Achtung: Nach Aktivierung der 802.1X auf dem Port verliert der dort angeschlossene Client seine LAN-Verbindung zum Mikrotik so lange er sich noch nicht authentifiziert hat! Das bitte berücksichtigen.
/interface dot1x server enable [find interface=ether2]
7. Client-Computer einrichten
7.1 Linux
Für einen Test von 802.1x am Client nehme ich hier als Beispiel eine Arch-Linux Distribution. Das Aufbauen der Verbindung gelingt über mehrere Varianten, ich greife hier beispielhaft die gebräuchlich Methoden von wpa_supplicant und NetworkManager auf. Ihr müsst also wählen welche Variante ihr nutzen wollt.
7.1.1 WPA_SUPPLICANT
Falls
wpa_supplicant
noch nicht installiert sein sollte installieren wir dieses als erstessudo pacman -S wpa_supplicant
Dann legen wir unter /etc/wpa_supplicant/wpa_supplicant.conf eine Konfigurationsdatei an und fügen folgenden Inhalt ein:
(eigene Werte und Pfade anpassen):
eapol_version=2
ap_scan=0
network={
key_mgmt=IEEE8021X
eap=TLS
identity="DOT1X_CLIENT1"
private_key="/path/to/DOT1X_CLIENT1.p12"
private_key_passwd="Passw0rd"
eapol_flags=0
}
Die identity muss dem Common-Name im Client-Zertifikat und den Namen des Users im User-Manager entsprechen.
Für den ersten Test starten wir wpa_supplicant unter Angabe des Pfades zur oben erstellten Konfigurationsdatei, dem Parameter -D der den Driver auf "wired" (kabelgebunden) festlegt und dem Interface (-i) welches wir freischalten möchten:
wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired -i eth0
Nach Authentifizierung kann der Befehl mit
CTRL+C
abgebrochen werden.Auf dem Mikrotik sollte dann die entsprechende Freigabe für das Interface zu sehen sein und das Interface auf "authorized" stehen:
Die Zähler am Radius-Client des Mikrotiks sollten das ebenfalls bestätigen
Und der User-Manager eine aktive Session anzeigen
Für das dauerhafte Einrichten von wpa_supplicant als systemd Dienst macht ihr dann folgendes:
Als erstes benennt ihr die Konfiguration nach diesem Schema um: wpa_supplicant-<INTERFACENAME>.conf und platziert diese Datei dann im Verzeichnis
/etc/wpa_supplicant
. Ist der Interface-Name also z.B. eth0 sollte die Konfigurationsdatei als /etc/wpa_supplicant/wpa_supplicant-eth0.conf
abgelegt werden.Dann aktiviert ihr die passende systemd-unit mit diesem Befehl (das eth0 wieder durch euer Interface ersetzen)
sudo systemctl enable wpa_supplicant@eth0 --now
Damit wird der Dienst aktiviert und sofort als auch beim nächsten Boot automatisch gestartet, und schaltet den Port automatisch frei.
7.1.2 Network-Manager
Wenn ihr den Network-Manager benutzen wollt benötigt ihr ebenfalls das CA Zertifikat und den *.p12/*.pfx Zertifikats-Container und legt sie in einem Verzeichnis eurer Wahl ab.
Auf der grafischen Oberfläche des NetworkManager wählen wir nun unsere Ethernet-Verbindung für die wir 802.1x aktiveren wollen aus und öffnen die Einstellungen auf dem Tab 802.1X-Sicherheit, dort tragen wir unsere Daten wie folgt ein.
Wer es lieber mit der Konsole hält der kann auch die CLI des NetworkManager nutzen (Interface,Pfade und Passwort anpassen)
sudo nmcli conn modify eth0 802-1x.eap tls 802-1x.identity DOT1X_CLIENT 802-1x.client-cert /home/user/DOT1X_CLIENT.p12 802-1x.ca-cert /home/user/DOT1X_CA.crt 802-1x.private-key /home/user/DOT1X_CLIENT.p12 802-1x.private-key-password Passw0rd
sudo nmcli conn up eth0
oder die Verbindung direkt unter
/etc/NetworkManager/system-connections/*.nmconnection
bearbeiten und danach mittels nmcli conn reload
aktualisieren.Nach dem Speichern der Eigenschaften wird der NetworkManager die Verbindung erfolgreich aktiveren sofern alle Daten korrekt sind. Sollte es nicht auf Anhieb klappen, als erstes den Adapter de- und wieder aktivieren und überprüfen ob das Interface eine IP erhält.
7.2 Windows
Für Windows gibt es bei der Nutzung des Mikrotik User-Managers zur Zeit noch eine Einschränkung für die Computer-Authentifizierung die damit leider noch nicht möglich ist da Windows dem Computernamen automatisch immer das Prefix host/ voranstellt. Das ist im Normalfall kein Problem jedoch hat der User-Manager die Eigenheit das in Benutzernamen keine Slashes möglich sind und somit der Name für EAP-TLS nicht korrekt im User-Manager hinterlegt werden kann.
Bei der Benutzerauthentifizierung hingegen gibt es diesbezüglich keine Einschränkung.
Unter Windows 11 geht ihr für die Benutzerauthentifizierung exemplarisch folgendermaßen vor:
7.2.1 CA- und Benutzerzertifikat ins System importieren
Als erstes importiert ihr das CA Zertifikat in die vertrauenswürdigen Stammzertifizierungsstellen des Computers. Und den *.p12/*.pfx Container in den User-Zertifikats-Store.
CA importieren
User-Zertifikat importieren
7.2.2 Aktivieren von 802.1x
Dann öffnet die Systemeinstellungen mittels
WIN+I
und wählt Netzwerk und InternetDort aktiviert ihr die 802.1x Authentifizierung mit EAP-TLS
Nun wechseln wir zurück in die klassische Systemsteuerung und nehmen noch ein paar Detaileinstellungen vor, dazu tippen wir im Windows-Startmenü
ncpa.cpl
ein und öffnen damit die Netzwerkverbindungen, dort wählen wir unsere Netzwerkverbindung aus und wählen im Kontextmenü Eigenschaften und stellen die Eigenschaften wie folgt ein:Nach dem Speichern wird Windows den Anmeldedialog präsentieren falls wir das Häkchen für die Nutzung eines alternativen Benutzernamens gewählt haben:
War der Vorgang erfolgreich bestätigt das der Dialog
8. Dynamische VLAN-Zuweisung für den Port
Es lässt sich auch statt einer statischen VLAN-Zuweisung des Ports über die PVID auch eine dynamische VLAN-Zuweisung für den Port über den User-Manager vornehmen.
Wie bei den gängigen Radius-Servern wird dies auch hier über Radius-Attribute geregelt die der Radius-Server an den Authenticator im "Access-Accept" Paket übermittelt und dieser dann den Port in das jeweilige VLAN legt.
Die Attribute die wir für die port basierte Authentifizierung benötigen sind bei Mikrotik und 802.1x im generellen mindestens folgende:
Attribut | Wert | Beschreibung |
---|---|---|
Tunnel-Type | 13 | 13 steht für "VLAN" siehe https://tools.ietf.org/html/rfc2868#section-3.1) |
Tunnel-Medium-Type | 6 | 6 steht für "IEEE-802" siehe https://tools.ietf.org/html/rfc2868#section-3.2 |
Tunnel-Private-Group-ID | 10 | Das ist unsere VLAN ID |
Damit der Usermanager diese Attribute bei einer "Access-Accept" Antwort mitsendet, müssen wir die Attribute dem User-Manager erst einmal bekannt machen und anlegen (nur falls sie noch nicht existieren):
/user-manager attribute
add name=Tunnel-Type type-id=64 value-type=uint32
add name=Tunnel-Medium-Type type-id=65 value-type=uint32
add name=Tunnel-Private-Group-ID type-id=81 value-type=string
Eine Liste der im Usermanager möglichen Attribute findet sich hier:
https://help.mikrotik.com/docs/display/ROS/User+Manager#UserManager-Attr ...
Jetzt kann man die Attribute beim Anlegen oder Ändern eines Users oder einer Benutzergruppe mit individuellen Werten belegen.
Hier exemplarisch für einen User den man dynamisch dem VLAN 10 zuordnet:
Auf der Konsole lässt sich das so nutzen
/user-manager user add name=DOT1X_CLIENT1 attributes=Tunnel-Private-Group-ID:10,Tunnel-Type:13,Tunnel-Medium-Type:6
Wenn sich der User nun wie oben gezeigt am Port authentifiziert, wird der mit 802.1x geschützte Port in der Bridge des Mikrotik für dieses VLAN automatisch als untagged in dem VLAN hinzugefügt und wird damit Mitglied des angegebenen VLANs. Geht der Port wieder in den Status "un-authorized" wird der Port auch automatisch wieder als untagged Port aus dem VLAN entfernt.
Damit die dynamische Zuweisung auch funktioniert muss der Port natürlich vorher der Bridge schon einmal als Port zugewiesen werden da ansonsten die dynamische Port-Zuweisung fehl schlägt.
Hier sieht man im LOG des Mikrotik wie der User-Manager unsere hinzugefügten Attribute an den Mikrotik verschickt:
Ebenfalls wird nun das zugewiesene VLAN für den Port aufgeführt:
9. Troubleshooting am Mikrotik
Sollte es wieder erwarten zu Problemen kommen, sollte man als erstes das LOG um die radius und manager Topcs ergänzen, dann erhält man im LOG detaillierte Informationen über die versendeten Radius-Pakete und die User-Manager Meldungen.
Wünsche euch nun viel Erfolg bei der Umsetzung
@colinardo
Please also mark the comments that contributed to the solution of the article
Content-ID: 577655
Url: https://administrator.de/contentid/577655
Printed on: October 7, 2024 at 01:10 o'clock
21 Comments
Latest comment
Das sind ja mal gute News von Mikrotik. Interessant und auch löblich das MT sich nun auch an die Standard Radius Attribute für VLANs hält und die Vendor spezifischen Attribute wohl nicht mehr zwingend sind.
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.
Offizielle MT Doku hier.
Dein Einverständnis vorausgesetzt hab ich es mit dem o.a. Tutorial verlinkt.
Offizielle MT Doku hier.
Hallo @colinardo,
Danke für das vorzügliche Tutorial! Ich finde die Geräte und Router OS klasse.
Zu 802.1x bei MT aber zwei Fragen:
1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?
Wenn ich das richtig verstanden habe, hat erst die Anpassung von 802.1x (2010) dies (u.a.) berücksichtigt, indem MACSec (802.1AE) eingeführt wurde. Darüber hinaus gibt es (kenne da nur Cisco) herstellerspezifische Umsetzungen. Cisco unterstützt z.B. MACSec nur oberhalb der SG/CBS-Serie, hat für die KMU-Switche aber immerhin eine Lösung namens "Multi-Sessions" geschaffen, mit der sich, wenn ich das richtig verstehe, jeder am Port angeschlossene Client individuell authentifizieren muss.
2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?
Ich hätte dann zwar immerhin dynamische VLAN-Zuweisung aber keine echte Sicherheit und könnte einen MT-Switch dann doch wohl nur in bereits sicheren Umgebungen einsetzen.
Danke und viele Grüße, commodity
Edit: Da ist offenbar was in der Pipeline: https://forum.mikrotik.com/viewtopic.php?t=164427
Danke für das vorzügliche Tutorial! Ich finde die Geräte und Router OS klasse.
Zu 802.1x bei MT aber zwei Fragen:
1. Sehe ich das richtig, dass es sich bei der Mikrotik-Umsetzung faktisch um den alten 802.1x (2004) Standard handelt, der mittels zwischen einen authorisierten Client und MT-Port geschalteten Simpel-Switch umgangen werden kann?
Wenn ich das richtig verstanden habe, hat erst die Anpassung von 802.1x (2010) dies (u.a.) berücksichtigt, indem MACSec (802.1AE) eingeführt wurde. Darüber hinaus gibt es (kenne da nur Cisco) herstellerspezifische Umsetzungen. Cisco unterstützt z.B. MACSec nur oberhalb der SG/CBS-Serie, hat für die KMU-Switche aber immerhin eine Lösung namens "Multi-Sessions" geschaffen, mit der sich, wenn ich das richtig verstehe, jeder am Port angeschlossene Client individuell authentifizieren muss.
2. Wenn das bei Router OS fehlt, ist dort dann die (aufwändige) Radius-Implementierung von 802.1x im LAN mit Blick auf die Sicherheit des Netzes überhaupt noch sinnvoll?
Ich hätte dann zwar immerhin dynamische VLAN-Zuweisung aber keine echte Sicherheit und könnte einen MT-Switch dann doch wohl nur in bereits sicheren Umgebungen einsetzen.
Danke und viele Grüße, commodity
Edit: Da ist offenbar was in der Pipeline: https://forum.mikrotik.com/viewtopic.php?t=164427
Zumindestens bei anderen aktuellen Switches ist das schon lange nicht mehr so das man es per Switch davor aushebeln kann, denn das Forwarding ist immer Mac abhängig und wird nur auf Basis der Mac gemacht. Auch wenn einer den Port öffnet können andere Macs am gleichen Port NICHT durch.
Stichwort Multi- oder single Host Port Authentication. Beherrschen mittlerweile alle besseren Switches.
Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute, wie bereits gesagt, eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.
Stichwort Multi- oder single Host Port Authentication. Beherrschen mittlerweile alle besseren Switches.
Wurde früher auch mal als Mac based VLANs bezeichnet und ist heute, wie bereits gesagt, eigentlich mittlerweile überall Standard... Wenn MT noch nicht so weit ist, ist das natürlich schade.
Danke Euch für die Anmerkungen. Ja, ich war auch etwas irritiert, als ich die Doku gelesen habe. Bei Mikrotik (oder generell) darf man 802.1x eben nicht als Sicherheitsfeature sehen.
Das schöne an den MTs ist aber, dass sie sich entwickeln, wo bei anderen gar nichts passiert. Und es gibt ja andere Lösungswege - oder halt Cisco
Viele Grüße, commodity
Das schöne an den MTs ist aber, dass sie sich entwickeln, wo bei anderen gar nichts passiert. Und es gibt ja andere Lösungswege - oder halt Cisco
Viele Grüße, commodity
Uhhh, das ist böse. OK, dann heisst es auch hier wohl warten auf die nächsten Patch Releases...
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
Müsst ich gleich mal checken ob das auch mit einem externen Radius Server in der 7.1.1 passiert.
👍
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet.
Mit externem Radius auch fehlerfrei. Obwohl ja jetzt im Mikrotik Umfeld mit dem onboard Radius in 7.3 obsolet.
hab das gerade mit 7.14.3 durch-exerziert, klappt ganz hervorragend!
Offenbar hat sich aber die Syntax am CLI bissl geändert. Zwei Dinge sind mir aufgefallen:
/interface dot1x server add interface=ether2 enabled=no
aus enabled wurde jetzt disabled. Es heißt jetzt also:
/interface dot1x server add interface=ether2 disabled=yes
/user-manager profile add name=dot1x name-for-users=dot1x
hier scheint der Parameter validity neuerdings mandatory zu sein. Gibt man ihn nicht an, erscheint ein entsprechender Prompt. Da hab ich einfach <return> gedrückt, was dazu führt, dass validity=unlimited gesetzt wird.
Offenbar hat sich aber die Syntax am CLI bissl geändert. Zwei Dinge sind mir aufgefallen:
/interface dot1x server add interface=ether2 enabled=no
aus enabled wurde jetzt disabled. Es heißt jetzt also:
/interface dot1x server add interface=ether2 disabled=yes
/user-manager profile add name=dot1x name-for-users=dot1x
hier scheint der Parameter validity neuerdings mandatory zu sein. Gibt man ihn nicht an, erscheint ein entsprechender Prompt. Da hab ich einfach <return> gedrückt, was dazu führt, dass validity=unlimited gesetzt wird.
Für die CLI affine Linux Fraktion hier nochmal ein Network Manager Connection Profil ohne GUI:
(Beispiel Raspberry Pi Zero2W mit USB Ethernet Adapter)
Wie man die Zertifikate mit OpenSSL z.B. auf dem RasPi selber generiert ist HIER genau beschrieben!
Die grafische WinBox GUI Variante für die einfache Erstellung des Client Zertifikats geht so:
(Der Common Name (CN) entspricht dabei der "Identity")
(Beispiel Raspberry Pi Zero2W mit USB Ethernet Adapter)
[connection]
id=USB-Adapter
uuid=538c2100-2175-319a-a857-a3bcce31890f
type=ethernet
interface-name=eth1
[ethernet]
[802-1x]
eap=tls;
identity=DOT1X_CLIENT
ca-cert=/home/user/.certs/DOT1X_CA.crt
client-cert=/home/user/.certs/DOT1X_CLIENT.p12
private-key=/home/user/.certs/DOT1X_CLIENT.p12
private-key-password=Passw0rd
[ipv4]
method=auto
[ipv6]
addr-gen-mode=default
method=auto
[proxy]
Wie man die Zertifikate mit OpenSSL z.B. auf dem RasPi selber generiert ist HIER genau beschrieben!
Die grafische WinBox GUI Variante für die einfache Erstellung des Client Zertifikats geht so:
(Der Common Name (CN) entspricht dabei der "Identity")