Hinweis: Dies ist ein Demo-Beitrag als Platzhalter für den Blog-Aufbau. Er kann jederzeit gelöscht werden.
IEEE 802.1X ist die etablierte Norm für portbasierte Netzzugangskontrolle – und in den meisten Mittelstandsnetzen nach wie vor eine Baustelle. Wer die Technik falsch einführt, provoziert Support-Tickets, blockierte Arbeitsplätze und im schlimmsten Fall einen Produktionsausfall. Dieser Beitrag zeigt, wie ein NAC-Rollout in der Praxis abläuft und wo die typischen Fallstricke liegen.
Ausgangslage: Warum 802.1X zur Pflicht wird
802.1X regelt die Authentifizierung an der Schnittstelle zwischen Endgerät (Supplicant), Switch beziehungsweise Access Point (Authenticator) und Authentifizierungsserver (RADIUS). Ohne 802.1X reicht ein freies Patchkabel oder eine ungesicherte Dose im Besprechungsraum, um sich Zugang zum internen Netz zu verschaffen – unabhängig von Firewall- oder VLAN-Konzepten dahinter. Mit NIS2, ISO 27001 und wachsendem Zero-Trust-Anspruch wird genau diese Lücke zunehmend geprüft und adressiert.
Hinzu kommt die schiere Menge an Geräten: Drucker, Kameras, Access Points, Smart-TVs und Sensorik landen heute an denselben Switchports wie Notebooks. Ein sauberes NAC-Konzept muss all diese Gerätetypen ohne pauschale Ausnahmen abbilden – hier entscheidet sich, ob ein Rollout trägt oder in Ad-hoc-Freischaltungen endet.
Rollout in Phasen: Monitor-Mode, Low-Impact, Closed Mode
Der größte Fehler bei 802.1X-Projekten ist der Versuch, Closed Mode – also die harte Durchsetzung mit Portsperre bei fehlgeschlagener Authentifizierung – von Tag eins an netzweit zu aktivieren. In der Praxis hat sich ein dreistufiges Vorgehen bewährt, das Risiko und Sichtbarkeit sauber trennt.
Monitor-Mode: Sichtbarkeit vor Durchsetzung
Im Monitor-Mode läuft die Authentifizierung bereits vollständig mit, ein Scheitern hat aber keine Konsequenz für den Port – der Zugriff bleibt offen. Diese Phase dient ausschließlich dazu, über mehrere Wochen ein belastbares Bild zu bekommen: Welche Geräte scheitern an EAP, welche Supplicants sind falsch konfiguriert, welche Legacy-Geräte benötigen zwingend MAB. Zeigen die RADIUS-Accounting-Logs eine saubere Erfolgsquote, folgt der Low-Impact-Mode: Gescheiterte Authentifizierungen landen in einem eingeschränkten VLAN mit reduzierten ACLs statt komplett gesperrt zu werden. Erst danach wird pro Standort in den Closed Mode umgeschaltet.
RADIUS-Infrastruktur: ClearPass als Policy-Engine
Der Switch trifft keine Entscheidung selbst, er reicht die Anfrage als RADIUS-Client (NAS) an den Authentifizierungsserver weiter. In vielen Mittelstandsumgebungen übernimmt eine Policy-Engine wie Aruba ClearPass oder Cisco ISE diese Rolle und verknüpft dabei Active-Directory-Gruppen, Zertifikatsattribute und Endpoint-Profiling zu einer Zugriffsentscheidung. Wichtig: mindestens zwei RADIUS-Server im Verbund, mit korrekt dimensionierten Dead-Time- und Retransmit-Werten auf dem Switch – sonst wechselt der Authenticator bei einem kurzen Hänger schon mitten im DHCP-Handshake auf den Fallback-Server.
EAP-Methoden im Vergleich: EAP-TLS vs. PEAP
Die Wahl der EAP-Methode entscheidet über Sicherheitsniveau und Rollout-Aufwand gleichermaßen. EAP-TLS authentifiziert Client und Server gegenseitig über Zertifikate und gilt als Referenz für sichere 802.1X-Umgebungen, verlangt aber eine funktionierende PKI samt Lifecycle-Management für Ausstellung, Verteilung und Sperrung der Zertifikate. PEAP (meist in Kombination mit MSCHAPv2) tunnelt stattdessen Benutzername und Passwort durch einen serverseitig zertifikatsgesicherten TLS-Kanal und lässt sich ohne Client-Zertifikate deutlich schneller ausrollen – bleibt aber von der Passwortqualität und einer korrekt konfigurierten Server-Zertifikatsprüfung im Supplicant abhängig.
- Sicherheitsniveau: EAP-TLS deutlich höher, da keine Zugangsdaten übertragen werden
- Rollout-Aufwand: PEAP schneller einsatzbereit, EAP-TLS erfordert PKI-Vorarbeit
- Zertifikatsverwaltung: nur bei EAP-TLS clientseitig notwendig, dafür planbar automatisierbar über SCEP oder Intune
- Kompatibilität: PEAP häufig die pragmatische Wahl bei heterogenen Alt-Geräten ohne Zertifikatsunterstützung
MAC Authentication Bypass für Drucker und IoT-Geräte
Nicht jedes Gerät kann einen 802.1X-Supplicant sprechen. Für Netzwerkdrucker, Kameras, Badge-Reader oder Sensorik greift nach Ablauf des EAP-Timeouts MAC Authentication Bypass: Der Switch authentifiziert das Gerät anhand seiner MAC-Adresse gegen eine Whitelist oder ein Profiling in der Policy-Engine. MAB ist bewusst eine Notlösung – MAC-Adressen lassen sich fälschen –, weshalb MAB-Geräte grundsätzlich in ein eigenes, restriktiv per ACL beschränktes VLAN gehören und über Endpoint-Profiling (DHCP-Fingerprinting, Hersteller-OUI, Verhaltensmuster) zusätzlich verifiziert werden sollten.
Dynamic VLAN Assignment: Automatische Netzsegmentierung
Statt jedem Switchport ein festes VLAN zuzuweisen, liefert die Policy-Engine im RADIUS Access-Accept die passenden Tunnel-Attribute (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) mit – der Port wird dynamisch dem VLAN zugeordnet, das zur Identität des jeweiligen Geräts passt. Derselbe physische Port bedient so je nach Anmeldung ein Notebook im Unternehmens-VLAN, einen Gast im isolierten Gäste-VLAN oder einen per MAB erkannten Drucker im IoT-VLAN. Das reduziert manuelle Portkonfiguration erheblich und setzt die identitätsbasierte Mikrosegmentierung um, die ein Zero-Trust-Ansatz voraussetzt.
Häufige Fehlerquellen, Fallback und Monitoring
Supplicant-Konfiguration, Zertifikate und Timeouts
Die meisten Störungen im Praxisbetrieb entstehen nicht am RADIUS-Server, sondern am Endgerät oder in der Zeitachse der Authentifizierung. Typisch sind eine falsch eingestellte Auth-Reihenfolge (Computer-Only statt „Benutzer oder Computer“), wodurch Gruppenrichtlinien vor dem Login nicht greifen, fehlende Root- oder Intermediate-Zertifikate im Trust Store des Clients sowie zu knapp bemessene Timeout- und Retry-Werte, die Geräte mitten im Handshake in den Fallback drängen.
- Uhrzeit-Drift zwischen Client und CA führt zu ungültigen Zertifikatsprüfungen
- Fehlende Intermediate-CA in der Zertifikatskette bricht die TLS-Validierung ab
- Zu kurze Dead-Time zwischen primärem und sekundärem RADIUS-Server erzeugt Flapping
- Nicht überwachte Zertifikatslaufzeiten führen zu Massenausfällen bei Ablauf
Ein belastbares Fallback-Konzept ist daher Pflicht: eine definierte Critical-Auth-VLAN-Regel öffnet Ports kontrolliert, falls sämtliche RADIUS-Server nicht erreichbar sind, statt den Standort komplett lahmzulegen. Parallel gehört die RADIUS-Accounting-Auswertung ins zentrale Monitoring, mit Alarmierung bei auffälligen Häufungen fehlgeschlagener Authentifizierungen – so werden Supplicant- oder Zertifikatsprobleme erkannt, bevor der Helpdesk sie meldet.
Fazit
Ein 802.1X-Rollout ist kein Schalter, den man umlegt, sondern ein mehrwöchiger Prozess aus Monitor-Mode, Low-Impact-Phase und erst danach Closed Mode. Wer EAP-TLS und PEAP je nach Gerätetyp bewusst kombiniert, IoT-Geräte sauber per MAB und Profiling absichert, VLANs dynamisch statt statisch zuweist und von Anfang an ein Fallback- und Monitoring-Konzept mitplant, vermeidet die typischen Stolperfallen – und bekommt am Ende eine Netzzugangskontrolle, die trägt statt zu stören.