802.1X – Netzwerkzugangskontrolle (NAC) im Detail
802.1X sperrt Switch-Ports und WLAN, bis sich Geraet oder User authentisiert haben. EAP-Methoden, NPS-RADIUS, Supplicant und dynamische VLANs im Detail.
Was 802.1X eigentlich loest
Stell dir einen Konferenzraum mit freien Netzwerkdosen vor. Jeder Besucher, der ein Kabel einsteckt, bekommt per DHCP eine IP-Adresse und landet im selben Netz wie eure Fileserver und Domain Controller. Genau das ist der Normalzustand in sehr vielen Schweizer KMU-Netzwerken – Switch-Ports sind offen, WLAN-Passwoerter kursieren auf Zetteln, und “Netzwerkzugriff” bedeutet praktisch “physischer Zugriff auf eine Dose oder Kenntnis eines PSK”.
IEEE 802.1X ist der Standard, der das aendert: Port-basierte Zugangskontrolle. Ein Switch-Port oder eine WLAN-Verbindung bleibt komplett gesperrt (bis auf den Authentifizierungs-Traffic selbst), bis sich das angeschlossene Geraet oder der User erfolgreich ausgewiesen hat. Erst danach wird der Port “freigeschaltet” – und je nach Ergebnis sogar einem bestimmten VLAN zugeordnet.
802.1X ist damit die Grundlage fuer Network Access Control (NAC): Wer darf ueberhaupt rein, und in welches Segment. Es ist kein optionales Nice-to-have mehr, sondern in vielen Compliance-Rahmenwerken (NIS2, ISO 27001, Cyber-Versicherungen) implizit gefordert, sobald es um Netzwerksegmentierung geht.
Die drei Rollen im 802.1X-Modell
802.1X definiert immer exakt drei Beteiligte:
- Supplicant – die Software auf dem Endgeraet, die die Anmeldedaten liefert (bei Windows: der Dienst “Automatische Konfiguration (verkabeltes Netzwerk)” bzw. “WLAN-AutoConfig”).
- Authenticator – der Switch-Port oder Access Point. Er selbst prueft nichts, sondern leitet die Anfrage nur an den Authentifizierungsserver weiter (RADIUS-Client-Rolle).
- Authentication Server – i.d.R. ein RADIUS-Server, bei Microsoft-Umgebungen der Network Policy Server (NPS), der die eigentliche Entscheidung trifft (Zugriff ja/nein, welches VLAN).
Supplicant <--EAP über EAPoL--> Authenticator (Switch/AP) <--RADIUS (UDP 1812/1813)--> RADIUS-Server (NPS)
Client Switch-Port AD-Domaenencontroller
Wichtig fuer das Troubleshooting: Die Kommunikation Client-zu-Switch laeuft ueber EAPoL (EAP over LAN), ein Layer-2-Protokoll (Ethertype 0x888E), das ohne IP-Adresse funktioniert – der Port ist ja noch gesperrt. Erst die Kommunikation Switch-zu-RADIUS-Server nutzt echtes IP/UDP auf den Ports 1812 (Authentication) und 1813 (Accounting), frueher teils 1645/1646.
EAP-Methoden: PEAP vs. EAP-TLS im Detail
EAP (Extensible Authentication Protocol) ist selbst kein einzelnes Verfahren, sondern ein Rahmenwerk mit vielen austauschbaren Methoden. Im Unternehmensumfeld sind praktisch nur zwei relevant:
PEAP (Protected EAP), meist mit MS-CHAPv2
PEAP baut zuerst einen verschluesselten TLS-Tunnel zwischen Client und RADIUS-Server auf – dafuer braucht nur der Server ein Zertifikat. Innerhalb dieses Tunnels laeuft dann die eigentliche Authentifizierung, ueblicherweise per MS-CHAPv2 mit Benutzername/Passwort (dem AD-Konto).
- Vorteil: Kein Client-Zertifikat noetig, schneller Rollout, funktioniert mit normalem AD-Login.
- Nachteil: MS-CHAPv2 gilt kryptografisch als schwach (NTLM-basiert). Wenn der Client die Server-Zertifikatspruefung nicht korrekt validiert, sind Credential-Relay-Angriffe moeglich.
EAP-TLS
EAP-TLS nutzt beidseitige Zertifikatsauthentifizierung: Sowohl Server als auch Client legen ein Zertifikat vor, das gegenseitig gegen eine vertrauenswuerdige CA geprueft wird. Es werden nie Passwoerter uebertragen.
- Vorteil: Deutlich resistenter gegen Phishing, Credential-Diebstahl, Offline-Angriffe. Kein Passwort, das gestohlen werden kann.
- Nachteil: Erfordert eine funktionierende PKI (siehe ADCS – Zertifikatsdienste & PKI Grundlagen) und automatisierte Client-Zertifikatsverteilung, z.B. via Gruppenrichtlinien-Autoenrollment oder Intune-Zertifikatsprofile.
| Kriterium | PEAP-MSCHAPv2 | EAP-TLS |
|---|---|---|
| Benoetigt Client-Zertifikat | Nein | Ja |
| Benoetigt Server-Zertifikat | Ja | Ja |
| Authentifiziert mit | AD-Passwort | Zertifikat (privater Schluessel) |
| Schutz vor Passwort-Diebstahl | Nur indirekt (TLS-Tunnel) | Ja, es gibt kein Passwort |
| PKI-Aufwand | Gering (nur Server-Zert.) | Hoch (Client-Zert. pro Geraet/User) |
| Anfaellig fuer Offline-Bruteforce | MS-CHAPv2-Hash theoretisch angreifbar | Nein |
| Typischer Einsatz KMU | Schneller Erststart, Gastfirmen-Notebooks | Domaenengeraete, Server-Segmente, hohe Sicherheitsanforderung |
| Zertifikatsverwaltung noetig | Nein (ausser Server) | Ja, laufend (Ablauf, Sperrung, CRL) |
Es gibt daneben EAP-TTLS (aehnlich PEAP, aber herstelleroffener) und EAP-FAST (Cisco-spezifisch) – in reinen Microsoft-Umgebungen aber selten im Einsatz.
RADIUS-Server: NPS unter Windows Server konfigurieren
Der Network Policy Server (NPS) ist die Windows-Server-Rolle, die RADIUS-Funktionalitaet bereitstellt. Er ist eng mit Active Directory verzahnt: Benutzer- und Gruppenmitgliedschaften aus AD koennen direkt in NPS-Richtlinien verwendet werden.
Rolle installieren
# NPS-Rolle installieren (auf einem Mitgliedsserver, idealerweise nicht dem DC selbst)
Install-WindowsFeature NPAS -IncludeManagementTools
# NPS-Dienst im Active Directory registrieren, damit er
# die msNPAllowDialin-Attribute und Gruppen lesen darf
netsh nps add registeredserver
RADIUS-Client (den Switch) eintragen
Jeder Switch bzw. Wireless-Controller, der Authentifizierungsanfragen an den NPS schicken darf, muss als RADIUS-Client registriert werden – inklusive eines Shared Secret, das beide Seiten identisch konfigurieren:
Import-Module NPS
New-NpsRadiusClient -Name "SW-Access-01" -Address "10.10.1.5" `
-SharedSecret "Tr0ub4dor&3-langes-Secret-hier" -VendorName "RADIUS Standard"
Nutze pro Switch (oder zumindest pro Standort) ein eigenes Shared Secret – nicht ein einziges fuer den ganzen Switch-Park. Das begrenzt den Schaden, falls ein Secret geleakt wird.
Netzwerkrichtlinie (Network Policy) fuer 802.1X
Die Netzwerkrichtlinie legt fest: Wer darf rein, mit welcher EAP-Methode, und was passiert danach (VLAN-Zuweisung). Am einfachsten geht das ueber den Assistenten:
NPS-Konsole → NPS (Lokal) → RADIUS-Server fuer 802.1X-Kabelgebunden- oder Drahtlosverbindungen konfigurieren
→ Assistent wählen: "Sichere Drahtlosverbindungen" oder "Sichere kabelgebundene Verbindungen"
→ RADIUS-Clients (Switches) hinzufügen
→ EAP-Typ waehlen: Microsoft: Smartcard oder anderes Zertifikat (= EAP-TLS)
oder: Geschuetztes EAP (PEAP)
→ Gruppen festlegen, die Zugriff erhalten (z.B. AD-Gruppe "VPN-und-8021X-Clients")
Wichtig: In den Bedingungen der Richtlinie kannst du granular filtern, z.B. nach NAS-Port-Type = Ethernet fuer kabelgebundene Ports oder nach der AD-Gruppenmitgliedschaft des Computerkontos (bei EAP-TLS mit Maschinenzertifikaten) bzw. Benutzerkontos.
Logging aktivieren
Ohne aktives Accounting-Logging tappst du beim Troubleshooting im Dunkeln:
# NPS-Ereignisprotokollierung fuer erfolgreiche und fehlgeschlagene Anfragen aktivieren
Set-NpsAuditPolicy -EnableSuccessAuditing $true -EnableFailureAuditing $true
Fehlgeschlagene Auth-Versuche findest du danach in der Windows-Ereignisanzeige unter “Security” mit Event-ID 6273 (Fehler) bzw. 6272 (Erfolg) – siehe dazu auch Windows-Ereignisanzeige – Grundlagen.
Zertifikatsbasierte Authentifizierung: die PKI-Seite
Fuer EAP-TLS (und fuer PEAP als Server-Zertifikat) brauchst du eine funktionierende interne PKI, typischerweise Active Directory Certificate Services (ADCS). Die wichtigsten Zertifikatsvorlagen:
| Zertifikatstyp | Zweck | Typische Vorlage | Verteilung |
|---|---|---|---|
| NPS-Server-Zertifikat | TLS-Tunnel-Aufbau (PEAP + EAP-TLS) | “RAS and IAS Server” | Manuell oder Autoenrollment auf NPS-Server |
| Computer-Zertifikat | EAP-TLS fuer Domaenen-PCs (Boot vor User-Login) | “Workstation Authentication” (angepasst) | GPO-Autoenrollment |
| Benutzer-Zertifikat | EAP-TLS fuer User-Authentifizierung | ”User” (angepasst) | GPO-Autoenrollment oder Smartcard |
; Ausschnitt: GPO-Pfad fuer automatische Zertifikatsregistrierung
Computerkonfiguration > Richtlinien > Windows-Einstellungen >
Sicherheitseinstellungen > Richtlinien fuer oeffentliche Schluessel >
Zertifikatsdienstclient - Automatische Registrierung
= "Aktiviert, Zertifikate erneuern, alte Zertifikate entfernen, ausstehende Registrierung aktualisieren"
Supplicant-Konfiguration unter Windows
Windows bringt den 802.1X-Supplicant als Betriebssystemdienst mit. Zwei Dienste sind relevant und muessen laufen:
# Fuer kabelgebundenes 802.1X
Set-Service -Name dot3svc -StartupType Automatic
Start-Service dot3svc
# Fuer WLAN mit 802.1X (WPA2/WPA3-Enterprise)
Set-Service -Name Wlansvc -StartupType Automatic
Kabelgebundenes 802.1X per GPO ausrollen
Fuer Domaenen-PCs verteilst du das 802.1X-Profil zentral per Gruppenrichtlinie statt manuell auf jedem Client zu klicken:
Computerkonfiguration > Richtlinien > Windows-Einstellungen >
Sicherheitseinstellungen > Kabelgebundene Netzwerk (IEEE 802.3)-Richtlinien
→ Neue Richtlinie fuer verkabelte Netzwerke erstellen
→ Sicherheit: 802.1X aktivieren, Netzwerkauth.-Methode: Microsoft: Smartcard oder anderes Zertifikat (EAP-TLS)
→ Authentifizierungsmodus: "Computerauthentifizierung" (Login-Screen erreichbar, bevor User sich anmeldet)
Manuelle Konfiguration per netsh (fuer Einzelrechner/Troubleshooting)
:: Profil aus XML-Datei importieren
netsh lan add profile filename="C:\Configs\8021x-wired-profile.xml" interface="Ethernet"
:: Aktuellen Status des Supplicants am Interface pruefen
netsh lan show interfaces
Ein minimales EAP-TLS-Profil (8021x-wired-profile.xml):
<?xml version="1.0"?>
<LANProfile xmlns="http://www.microsoft.com/networking/LAN/profile/v1">
<MSM>
<security>
<OneXEnforced>true</OneXEnforced>
<OneX xmlns="http://www.microsoft.com/networking/OneX/v1">
<EAPConfig>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig">
<EapMethod>
<Type xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type>
<VendorId xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId>
</EapMethod>
</EapHostConfig>
</EAPConfig>
</OneX>
</security>
</MSM>
</LANProfile>
Type 13 steht hier fuer EAP-TLS (Type 25 waere PEAP). Fuer den WLAN-Fall gilt das Gleiche, nur ueber ein WLAN-Profil per netsh wlan add profile.
Dynamische VLAN-Zuweisung
Der eigentliche Mehrwert von 802.1X im KMU-Alltag: Ein Notebook steckt an einer x-beliebigen Netzwerkdose, und je nachdem, WER oder WAS sich authentisiert, landet der Port automatisch im richtigen VLAN – ganz ohne dass jemand am Switch etwas umkonfigurieren muss.
Technisch passiert das ueber drei RADIUS-Attribute, die der NPS im Access-Accept zurueckschickt:
| Attribut | Wert | Bedeutung |
|---|---|---|
| Tunnel-Type | 13 (VLAN) | Sagt dem Switch: Es folgt eine VLAN-Zuweisung |
| Tunnel-Medium-Type | 6 (IEEE-802) | Medientyp Ethernet |
| Tunnel-Private-Group-ID | z.B. “20” | Die eigentliche Ziel-VLAN-ID |
In der NPS-Netzwerkrichtlinie konfigurierst du das unter Einstellungen → RADIUS-Attribute → Standard:
Netzwerkrichtlinie "802.1X - Server-VLAN" Einstellungen:
Tunnel-Type = Virtual LANs (VLAN)
Tunnel-Medium-Type = 802 (Includes all 802 media plus Ethernet canonical format)
Tunnel-Pvt-Group-ID = 20
Praxisbeispiel: Du legst drei Netzwerkrichtlinien in der richtigen Reihenfolge an (NPS wertet Richtlinien der Reihe nach aus, die erste passende gewinnt):
- “IT-Admins” → VLAN 99 (Bedingung: AD-Gruppe “IT-Netzwerkadmins”)
- “Domaenen-PCs” → VLAN 10 (Bedingung: AD-Gruppe “Domain Computers”, EAP-TLS)
- “MAB-Drucker” → VLAN 60 (Bedingung: NAS-Port-Type Ethernet + MAB-Anfrage, MAC-Adresse in Gruppe “Erlaubte-Drucker-MACs”)
- Alles andere → Ablehnen (Default Deny)
Entscheidungsablauf am Switch (vereinfacht)
Geraet an Port angeschlossen
│
▼
Sendet Geraet EAPoL-Start? ──Nein──▶ Timeout ──▶ MAB versuchen? ──Ja──▶ MAC an RADIUS senden
│ Ja │ Nein
▼ ▼
802.1X-Handshake (EAP-TLS/PEAP) Port bleibt gesperrt / Gast-VLAN
│
▼
RADIUS Access-Accept mit VLAN-Attributen?
│ Ja │ Nein (nur Accept ohne VLAN)
▼ ▼
Port wird dynamisch VLAN 10/20/60 Port bleibt im statisch konfigurierten VLAN
zugewiesen, Traffic freigegeben
MAC Authentication Bypass (MAB)
Nicht jedes Geraet kann 802.1X sprechen: Netzwerkdrucker, IP-Kameras, aeltere IoT-Geraete, Multifunktionsgeraete oder manche IP-Telefone haben schlicht keinen Supplicant. Fuer diese Faelle gibt es MAB: Der Switch nutzt die MAC-Adresse des Geraets selbst als Credential.
Ablauf: Meldet sich ein Geraet nicht innert der konfigurierten Zeit per EAPoL, faellt der Switch auf MAB zurueck und schickt einen RADIUS-Request, bei dem Benutzername UND Passwort die MAC-Adresse des Geraets sind (ueblich: Format ohne Trennzeichen, klein geschrieben, z.B. aabbccddeeff).
! Cisco IOS Beispielkonfiguration: 802.1X mit MAB als Fallback
interface GigabitEthernet1/0/12
switchport mode access
switchport access vlan 10
authentication port-control auto
authentication order dot1x mab
authentication priority dot1x mab
mab
dot1x pae authenticator
dot1x timeout tx-period 5
spanning-tree portfast
In NPS legst du dafuer eine eigene Netzwerkrichtlinie an, die auf Service-Type = Call Check bzw. das Attribut NAS-Port-Type reagiert und die erlaubten MAC-Adressen entweder als AD-Objekte (ueber ein Skript gepflegt) oder in einer einfachen SQL-/CSV-Positivliste abgleicht.
Praxis-Szenario: Rollout in einem 120-Personen-KMU
Ein realistischer Migrationsplan, wie er in vielen Schweizer KMU funktioniert:
- Inventar & Pilotgruppe: Alle Switch-Ports und WLAN-SSIDs erfassen, die betroffen sind. Pilotgruppe (z.B. IT-Abteilung) zuerst.
- Monitor-Modus nutzen: Viele Enterprise-Switches (Cisco, Aruba, HP) kennen einen “Monitor Mode” oder “Open Mode”, bei dem 802.1X zwar laeuft und geloggt wird, der Port aber trotzdem offen bleibt. So siehst du VOR dem Scharfschalten, welche Geraete durchfallen wuerden.
- PKI vorbereiten: NPS-Server-Zertifikat ausstellen, Root-CA per GPO auf alle Clients verteilen, Autoenrollment fuer Computer-/User-Zertifikate aktivieren (bei EAP-TLS-Ziel).
- PEAP als Zwischenschritt (falls PKI noch nicht steht): Schnell wirksamer Basisschutz mit AD-Zugangsdaten.
- MAB-Ausnahmeliste erstellen: Drucker, Kameras, Chef-Kaffeemaschine mit Netzwerkport – alles, was kein 802.1X kann, mit MAC in eine gepflegte Gruppe.
- Schrittweiser Rollout nach VLAN/Stockwerk: Nicht das ganze Netz an einem Freitagnachmittag umstellen. Ein Stockwerk oder ein Switch-Stack nach dem anderen.
- Fallback-Notausgang einplanen: Ein physisch getrennter, nicht-802.1X-gesicherter Management-Port oder Out-of-Band-Zugang, falls sich NPS-Server oder Zertifikate verabschieden und du sonst ausgesperrt bist.
- Enforcement scharf schalten: Aus dem Monitor-Modus in den “Closed Mode” wechseln, sobald die Fehlerquote gegen null geht.
Troubleshooting: haeufige Fehlerbilder
| Symptom | Wahrscheinliche Ursache | Erste Massnahme |
|---|---|---|
| Client bleibt im “Begrenzt”-Netzwerk haengen | Kein Access-Accept vom NPS, Port faellt auf VLAN im “Restricted”-Modus | NPS-Ereignisprotokoll pruefen (Event-ID 6273), Reason Code auswerten |
| ”Es konnte keine Verbindung zum Server hergestellt werden” | Shared Secret zwischen Switch und NPS stimmt nicht ueberein | Secret auf beiden Seiten neu setzen, Tippfehler/Leerzeichen pruefen |
| EAP-TLS schlaegt fehl, Zertifikat wird abgelehnt | Root-CA fehlt im Client-Vertrauensspeicher, Zertifikat abgelaufen, falscher EKU (Client Authentication fehlt) | Zertifikat mit certutil -verify pruefen, Autoenrollment-GPO kontrollieren |
| Port authentifiziert erfolgreich, landet aber im falschen VLAN | Tunnel-Attribute fehlen oder falsche Reihenfolge der Netzwerkrichtlinien | RADIUS-Attribute in der Richtlinie und Policy-Reihenfolge pruefen |
| Drucker/IoT-Geraet ohne Netzwerkzugriff nach Rollout | MAB nicht konfiguriert oder MAC nicht in Positivliste | MAC-Adresse per show mac address-table ermitteln, Positivliste ergaenzen |
| Reauth alle paar Minuten, Verbindung “flackert” | reauth-period zu kurz konfiguriert oder Zertifikat kurz vor Ablauf | Timer anpassen, Zertifikatslaufzeit pruefen |
Fuer die Traffic-Analyse auf Layer 2 (EAPoL-Frames sichtbar machen) eignet sich Wireshark – Grundlagen hervorragend – filtere einfach nach eapol.
Entscheidungshilfe: Wann welche Kombination?
Hast du eine funktionierende interne PKI (ADCS) mit Autoenrollment?
│
Ja ──▶ Sind es primär Domaenen-Windows-Geraete?
│ │
│ Ja ──▶ EAP-TLS mit Computer-/Benutzerzertifikaten (Ziel: Best Practice)
│ │
│ Nein ──▶ EAP-TLS nur fuer verwaltbare Geraete, PEAP+MSCHAPv2
│ als Fallback fuer BYOD/Gast mit AD-Konto
│
Nein ──▶ PEAP-MSCHAPv2 als Sofortmassnahme, PKI-Aufbau parallel planen
Immer zusaetzlich: MAB fuer Drucker/IoT/Geraete ohne 802.1X-Client,
in eigenem, restriktivem VLAN mit minimalen Firewall-Regeln.
Weiterlernen
- Konfigurieren von Netzwerkrichtlinien (NPS) – offizielle Microsoft-Doku
- NPS-Übersicht – Microsoft Learn
- Cisco: MAC Authentication Bypass Deployment Guide – Cisco
- RFC 3580 – IEEE 802.1X RADIUS Usage Guidelines – IETF (Tunnel-Attribute fuer VLAN-Zuweisung)
- Cisco: VLAN RADIUS Attributes in Access Requests – Cisco
- Active Directory Certificate Services Übersicht – Microsoft Learn
Videos
Kommentare
Frage, Verbesserungsvorschlag oder eigene Erfahrung zu diesem Artikel? Schreib einen Kommentar. Neue Beiträge erscheinen nach kurzer Moderation.
- Lade Kommentare …