802.1X auf Cisco Switch konfigurieren: Netzwerkzugang absichern

Ein offener Switchport ist in vielen Netzwerken ein unterschätztes Risiko: Wer ein Gerät ansteckt, bekommt oft sofort Zugriff auf interne VLANs, Dienste und möglicherweise sogar auf sensible Systeme. Genau hier setzt 802.1X auf Cisco Switch konfigurieren an. 802.1X ist ein Standard für portbasierte Netzwerkzugangskontrolle: Ein Endgerät erhält erst dann Zugriff auf das Netzwerk, wenn es sich erfolgreich authentifiziert hat. In der Praxis geschieht das meist über einen RADIUS-Server (z. B. Cisco ISE, Microsoft NPS oder FreeRADIUS). Der Switch fungiert dabei als „Authenticator“, das Endgerät als „Supplicant“ (z. B. Windows/macOS/Linux, IP-Telefon, Drucker) und der RADIUS-Server als „Authentication Server“. Der Vorteil: Sie steuern nicht nur, ob ein Gerät Zugang bekommt, sondern auch welchen Zugang – etwa per dynamischem VLAN, dACL (Downloadable ACL) oder Rollenprofil. Damit lässt sich der Netzwerkzugang deutlich besser absichern als mit reinem Port Security oder statischen VLAN-Zuweisungen. Gleichzeitig ist 802.1X eine Funktion, die sorgfältig eingeführt werden sollte: Ohne saubere Fallback-Strategie (z. B. MAB für nicht-802.1X-fähige Geräte), geeignete VLANs für Gäste oder Quarantäne und klare Troubleshooting-Prozesse kann es schnell zu Supportfällen kommen. Dieser Leitfaden zeigt Ihnen Schritt für Schritt, wie Sie 802.1X auf Cisco Switches praxisnah konfigurieren, typische Designentscheidungen treffen und den Betrieb stabil halten.

802.1X Grundlagen: Rollen und Ablauf im Überblick

802.1X besteht aus drei Rollen, die in jeder Implementierung gleich sind:

• Supplicant: Das Endgerät, das sich authentifiziert (z. B. Windows-Client, macOS, Linux, IP-Telefon).
• Authenticator: Der Switchport, der den Zugriff kontrolliert (Cisco Switch).
• Authentication Server: Der RADIUS-Server, der Credentials prüft und Policies liefert (Cisco ISE, Microsoft NPS, FreeRADIUS).

Der Ablauf ist vereinfacht: Ein Gerät steckt an, der Switch setzt den Port in einen kontrollierten Zustand, EAPOL (EAP over LAN) startet die Authentifizierung, der Switch kapselt EAP in RADIUS und fragt den RADIUS-Server. Bei Erfolg wird der Port freigeschaltet und es werden optional Parameter angewendet (VLAN, dACL, SGT/TrustSec – je nach Architektur).

Für normativen Hintergrund zu 802.1X eignet sich der Anchor-Text IEEE 802.1X. Für Cisco-spezifische Konfigurationsdetails sind die Plattformdokumentationen und Konfigurationsguides je Switchserie sinnvoll, z. B. über den Anchor-Text Cisco Catalyst 9000 Dokumentation.

Voraussetzungen: Was Sie vor der Konfiguration klären sollten

Bevor Sie 802.1X aktivieren, sollten Sie die wichtigsten Rahmenbedingungen festlegen. Das vermeidet Lockouts und unnötige Komplexität:

• RADIUS-Server: Welcher Server authentifiziert? (Cisco ISE, NPS, FreeRADIUS) Welche IPs/Secrets?
• Authentifizierungsmethode: EAP-TLS (Zertifikate), PEAP (User/Passwort), TEAP/PEAPv2 (modernere Varianten) – abhängig von Endpoint-Management und Sicherheitsniveau.
• Gerätetypen: Welche Endgeräte können 802.1X (Clients, Telefone) und welche nicht (viele Drucker/IoT)?
• Fallback: Nutzen Sie MAB (MAC Authentication Bypass) für nicht-802.1X-fähige Geräte?
• VLAN-Design: Auth-VLAN, Guest-VLAN, Quarantine/VLAN für Fail-Open/Fail-Closed, Voice VLAN.
• Betriebsmodell: Monitoring, Logging, Supportprozess (wie entsperrt man Ports, wie erkennt man Fehler?).

Best Practice: Starten Sie mit einem Pilotbereich (z. B. ein Access-Switch oder ein Etagenbereich), sammeln Sie Erfahrung und rollen Sie anschließend schrittweise aus.

Begriffe, die Sie in Cisco-Konfigurationen ständig sehen

• AAA: Authentication, Authorization, Accounting – Cisco-Rahmen für RADIUS.
• dot1x: Schaltet 802.1X-Funktionalität auf dem Switch frei.
• authentication port-control: Steuert den Portmodus (auto/force-authorized/force-unauthorized).
• MAB: MAC Authentication Bypass – authentifiziert Geräte per MAC über RADIUS.
• Host Modes: single-host, multi-host, multi-auth, multi-domain (wichtig für Telefon+PC).
• Critical VLAN / Guest VLAN: VLANs für Sonderfälle (RADIUS down, keine Authentifizierung möglich).

RADIUS/AAA auf dem Cisco Switch einrichten

Der Switch muss RADIUS sprechen und AAA aktiv haben. Je nach IOS/IOS XE-Version gibt es unterschiedliche Syntax (klassisch radius-server host vs. moderne radius server-Blöcke). Das folgende Beispiel zeigt ein gängiges, modernes Muster.

RADIUS-Server definieren

configure terminal
aaa new-model
radius server ISE-1
address ipv4 10.10.99.10 auth-port 1812 acct-port 1813
key <SHARED_SECRET>
radius server ISE-2
address ipv4 10.10.99.11 auth-port 1812 acct-port 1813
key <SHARED_SECRET>
aaa group server radius ISE-GROUP
server name ISE-1
server name ISE-2
end

AAA-Methodenlisten für 802.1X erstellen

configure terminal
aaa authentication dot1x DOT1X-AUTH group ISE-GROUP
aaa authorization network DOT1X-AUTHZ group ISE-GROUP
aaa accounting dot1x DOT1X-ACCT start-stop group ISE-GROUP
end

Hinweis: In vielen Designs werden Auth und Authorize getrennt, damit der RADIUS-Server nicht nur „Ja/Nein“ liefert, sondern auch Rollenparameter (z. B. VLAN, dACL). Für RADIUS-Grundlagen eignet sich der Anchor-Text RFC 2865 (RADIUS).

802.1X global aktivieren und Systemverhalten festlegen

Auf Cisco Switches muss 802.1X global aktiviert werden, bevor Ports im auto-Modus authentifizieren können.

dot1x global aktivieren

configure terminal
dot1x system-auth-control
end

Je nach Umgebung empfiehlt es sich, zusätzlich Zeitouts und Reauth zu planen. Viele Unternehmen nutzen Reauth, um Policy-Änderungen durchzusetzen, ohne Ports neu zu stecken.

VLANs für Auth, Guest und Quarantäne vorbereiten

Ein stabiler Betrieb braucht definierte VLANs für Sonderfälle. Typische VLAN-Rollen:

• Data VLAN: normales Client-VLAN, wenn Auth erfolgreich ist.
• Voice VLAN: IP-Telefone, getrennt vom Client-Traffic.
• Guest VLAN: Wenn ein Gerät nicht 802.1X-fähig ist oder keine Antwort liefert (abhängig vom Design).
• Quarantine VLAN: Wenn ein Gerät zwar authentifiziert, aber nicht compliant ist (z. B. fehlender Patch, falsche Rolle).
• Critical VLAN: Wenn RADIUS nicht erreichbar ist und Sie „Fail-Open“ betreiben möchten (betriebsabhängig).

Best Practice: Entscheiden Sie bewusst, ob Ihr Netz Fail-Closed (bei RADIUS-Problemen kein Zugang) oder Fail-Open (Fallback in ein restriktives VLAN) sein soll. Für produktive Büroumgebungen ist ein restriktives Critical VLAN oft der bessere Kompromiss als kompletter Zugangsausfall.

Access-Port Schritt-für-Schritt: 802.1X im Standardmodus

Das folgende Beispiel zeigt einen typischen Office-Port (PC), an dem 802.1X priorisiert ist und MAB als Fallback dient. Der Port bleibt im auto-Modus und wird erst nach erfolgreicher Authentifizierung freigeschaltet.

Beispiel: Single-Host Port mit 802.1X + MAB

configure terminal
interface GigabitEthernet1/0/10
description Office-Client 802.1X
switchport mode access
switchport access vlan 10
spanning-tree portfast
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
mab
dot1x pae authenticator
dot1x timeout tx-period 10
authentication event fail action next-method
authentication event server dead action authorize vlan 999
authentication event server alive action reinitialize
end

Was passiert hier praktisch?

• order/priority legt fest, dass zuerst 802.1X versucht wird, dann MAB.
• mab erlaubt die MAC-basierte Authentifizierung als Fallback (z. B. für Drucker/IoT).
• server dead schaltet bei RADIUS-Ausfall in ein definiertes VLAN (hier 999 als Beispiel für ein restriktives Notfall-VLAN).
• server alive initiiert neu, sobald RADIUS wieder da ist.

Hinweis: Die exakten Optionen und Defaultwerte können je Plattform variieren. Prüfen Sie für Ihre Switchserie die passende Kommandoreferenz oder Konfigurationsanleitung.

Telefon + PC am gleichen Port: Multi-Domain oder Multi-Auth

Sehr häufig hängen ein IP-Telefon und ein PC am gleichen Switchport. In solchen Fällen ist die Host-Mode-Wahl entscheidend. Typische Modelle:

• multi-domain: getrennte Authentifizierung für Voice und Data (häufig klassisch für Telefon+PC).
• multi-auth: mehrere Geräte können unabhängig authentifizieren; geeignet, wenn mehr als zwei MACs möglich sind oder flexiblere Szenarien bestehen.
• multi-host: ein Gerät authentifiziert, danach dürfen alle hinter dem Port; meist weniger sicher.

Beispiel: Voice VLAN + 802.1X/MAB mit multi-domain

configure terminal
interface GigabitEthernet1/0/15
description Telefon+PC 802.1X
switchport mode access
switchport access vlan 10
switchport voice vlan 40
spanning-tree portfast
authentication host-mode multi-domain
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
mab
dot1x pae authenticator
end

Praxis-Tipp: In VoIP-Umgebungen ist es wichtig, dass Telefone entweder 802.1X beherrschen oder zuverlässig über MAB erkannt werden und eine passende Policy erhalten (Voice VLAN, QoS Trust, ggf. ACLs). Viele Unternehmen nutzen für Telefone MAB plus Profiling/Policy im RADIUS-Server, weil das in gemischten Endgeräteflotten pragmatisch ist.

MAB sinnvoll einsetzen: Für Drucker, IoT und Legacy-Geräte

Nicht jedes Gerät unterstützt 802.1X. Drucker, Kameras, Gebäudetechnik oder ältere Spezialgeräte sind typische Kandidaten für MAB. Dabei authentifiziert der Switch das Gerät über dessen MAC-Adresse beim RADIUS-Server. Wichtig ist: MAB ist weniger sicher als 802.1X, weil MAC-Adressen fälschbar sind. Deshalb sollten MAB-Geräte möglichst in restriktive VLANs oder mit dACLs arbeiten.

• Nutzen Sie MAB als Fallback, nicht als Standard für alle.
• Segmentieren Sie MAB-Geräte (z. B. IoT-VLAN) und erlauben Sie nur notwendige Dienste.
• Dokumentieren Sie MAB-Ausnahmen (Owner, Zweck, Standort), damit der Wildwuchs begrenzt bleibt.

Dynamische VLAN-Zuweisung und dACL: Zugriff feiner steuern

Ein großer Mehrwert von 802.1X ist die zentrale Policy-Steuerung. Je nach RADIUS-Server können Sie:

• Dynamisches VLAN zuweisen (z. B. Mitarbeiter vs. Gäste vs. Quarantäne).
• dACL (Downloadable ACL) anwenden, um Traffic pro Rolle zu filtern.
• Rollen/Tags nutzen (z. B. SGT/TrustSec in Cisco-Architekturen), wenn Ihr Design das vorsieht.

Das ist häufig der Schritt, der aus „Port-Auth“ echte Zugangskontrolle macht: Ein Endgerät ist nicht nur „drin“, sondern hat den passenden Zugriff.

Fail-Open, Fail-Closed und Critical VLAN: Betriebsentscheidung mit Folgen

Bei RADIUS-Ausfall müssen Sie entscheiden, wie sich der Switchport verhält. Die beiden Extrempunkte:

• Fail-Closed: Ohne RADIUS kein Zugang. Hohe Sicherheit, aber bei RADIUS-Problemen drohen flächige Ausfälle.
• Fail-Open: Bei RADIUS-Ausfall wird Zugang gewährt. Besser für Verfügbarkeit, aber riskanter.

In der Praxis ist ein Critical VLAN oft die beste Balance: Bei RADIUS-Ausfall landen Geräte in einem restriktiven VLAN, das nur Basisdienste erlaubt (z. B. DNS, DHCP, Zugang zu Patch-/Management-Services). Sobald RADIUS wieder verfügbar ist, wird reinitialisiert und die normale Policy greift.

Best Practices für eine sichere und wartbare 802.1X-Einführung

• Pilotieren: Erst eine kleine Portgruppe, dann stufenweise ausrollen.
• Klare Rollen: Mitarbeiter, Gäste, IoT/Drucker, Quarantäne – mit sauberem VLAN-/ACL-Konzept.
• Prefer 802.1X: MAB nur als Fallback für Geräte, die 802.1X nicht können.
• Dokumentation: Portbeschreibungen, VLANs, Policies, Ausnahmen, Supportprozess.
• Monitoring: RADIUS-Server-Status, Auth-Fails, ungewöhnliche MAB-Spitzen.
• Starke Methoden: Wo möglich EAP-TLS (Zertifikate) bevorzugen, weil es sicherer und besser automatisierbar ist.

Als übergreifender Rahmen für Zugriffskontrolle und Betriebssicherheit ist der Anchor-Text CIS Controls hilfreich, weil er organisatorische Best Practices wie Least Privilege, Logging und Change-Disziplin adressiert.

Troubleshooting: Häufige Fehler und wie Sie sie systematisch finden

802.1X-Probleme wirken für Nutzer oft wie „Netz geht nicht“. Für Administratoren ist daher ein klarer Diagnosepfad wichtig. Typische Ursachen:

• RADIUS nicht erreichbar: Routing/ACL/Firewall blockt 1812/1813 oder falsches Shared Secret.
• Supplicant nicht konfiguriert: Client hat 802.1X nicht aktiviert oder falsche EAP-Methode.
• Zertifikatsprobleme: Bei EAP-TLS fehlen Zertifikate oder Trustchain ist nicht sauber.
• Falscher Host-Mode: Telefon+PC funktionieren nicht, weil single-host statt multi-domain/multi-auth.
• MAB greift unerwartet: 802.1X scheitert, Switch fällt auf MAB zurück und das Gerät landet im falschen Profil.

Wichtige Show-Befehle auf dem Switch

show authentication sessions interface GigabitEthernet1/0/10 details
show dot1x interface GigabitEthernet1/0/10 details
show aaa servers
show radius statistics
show logging

Praktische Interpretation:

• Wenn die Session im Status „unauthorized“ bleibt, scheitert Auth oder RADIUS ist down.
• Wenn MAB statt 802.1X genutzt wird, prüfen Sie Supplicant-Einstellungen und EAP-Policy.
• Wenn Auth erfolgreich ist, aber Zugriff falsch ist, liegt das oft an Authorization (VLAN/dACL/Policy-Set).

Debugging mit Vorsicht

Debugs können auf produktiven Switches belastend sein. Wenn Sie Debug nutzen, dann gezielt und kurzzeitig, z. B. auf einem Pilotport:

debug dot1x all
debug radius authentication
undebug all

Sicherer Betrieb: Rollback, Notfallzugang und Change-Strategie

802.1X betrifft produktive Endgeräte. Deshalb sollten Sie Änderungen kontrolliert durchführen:

• Rollback-Plan: Port zurück auf authentication port-control force-authorized oder 802.1X temporär deaktivieren, wenn Pilot scheitert.
• Out-of-Band/Console: Zugriff auf Switches auch dann sicherstellen, wenn Auth-Policies Probleme machen.
• Change-Fenster: Erst nach Büroschluss oder in Wartungsfenstern ausrollen, wenn Nutzerimpact minimiert werden muss.
• Kommunikation: Nutzer und Support informieren, wie sich 802.1X-Verhalten zeigt (z. B. „erst nach Login Netz“).

Praxis-Checkliste: 802.1X auf Cisco Switch konfigurieren

• Ist ein RADIUS-Server eingerichtet und erreichbar (1812/1813, Shared Secret, Routing)?
• Ist aaa new-model aktiv und sind dot1x AAA-Methodenlisten definiert?
• Ist dot1x system-auth-control global gesetzt?
• Gibt es definierte VLANs für Data, Voice, Guest, Quarantäne und ggf. Critical?
• Sind Access-Ports korrekt konfiguriert (mode access, portfast) und mit authentication port-control auto versehen?
• Ist MAB nur als Fallback aktiv, nicht als Standard für alles?
• Ist der passende Host-Mode gesetzt (multi-domain/multi-auth für Telefon+PC)?
• Wird die Wirkung verifiziert (show authentication sessions, RADIUS-Stats, Logs)?
• Gibt es Monitoring und einen Supportprozess für Gerätewechsel und Auth-Fails?

copy running-config startup-config

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.