Network Access Control (NAC): 802.1X, RADIUS, Posture Assessment und Zero-Trust-Integration

Jedes Gerät das sich mit dem Unternehmensnetzwerk verbindet ist ein potentieller Einstiegspunkt für Angreifer. Ein ungemanagte Laptop, ein privates Smartphone, ein IoT-Gerät - alle können Schadcode einschleusen oder als Brückenkopf für Lateral Movement dienen. Network Access Control (NAC) verhindert, dass unkontrollierte Geräte ins Unternehmensnetz gelangen, indem es vor dem Netzwerkzutritt prüft: Wer ist das Gerät? Gehört es uns? Ist es aktuell gepatcht? Ist Antivirus aktiv?

802.1X: Port-basierte Zugangskontrolle

IEEE 802.1X hat drei Rollen: Supplicant (das Gerät, das Zugang will: Windows, Linux, iPhone), Authenticator (das Netzwerkgerät: Switch-Port oder WLAN Access Point) und Auth-Server (der RADIUS-Server, der die Identität prüft).

Der Ablauf: Das Gerät verbindet sich mit dem Switch-Port. Der Switch sperrt den Port zunächst (nur 802.1X-Traffic erlaubt) und sendet einen EAP-Request/Identity. Das Gerät antwortet mit EAP-Response/Identity (Username oder Zertifikat). Der Switch leitet an RADIUS weiter (RADIUS Access-Request). Bei Erfolg sendet RADIUS Access-Accept, der Switch öffnet den Port und weist ein VLAN zu. Bei Fehler bleibt der Port gesperrt.

Ergebnis: Auth OK + Posture OK → Normal-VLAN (produktiv). Auth OK + Posture Fail → Quarantäne-VLAN (nur Update-Server). Auth Fail → kein Zugang oder Gast-VLAN. Unbekanntes Gerät → MAB (MAC Authentication Bypass) → Gast-VLAN.

EAP-Methoden:

EAP-TLS: Beiderseitige Zertifikat-Authentifizierung (Client und Server). Stärkste Methode, kein Passwort-Angriff möglich. Voraussetzung: PKI (CA + Client-Zertifikate). Einsatz: Unternehmensgeräte mit Intune/Jamf-deployed Certificates.

PEAP-MSCHAPv2: Server-Zertifikat plus Username/Passwort (AD-Credentials). Einfacher zu deployen als EAP-TLS, aber schwächer - Passwort-Angriffe möglich wenn das Server-Zertifikat nicht validiert wird. Wichtig: Der Supplicant muss das Server-Zertifikat zwingend validieren, sonst ist Man-in-the-Middle möglich.

PEAP-EAP-TLS: PEAP-Tunnel mit EAP-TLS innen - sehr stark, sehr komplex.

EAP-TTLS: Ähnlich PEAP, bietet mehr Identitätsschutz.

RADIUS-Server-Konfiguration

# FreeRADIUS Installation (Ubuntu)
apt install freeradius freeradius-utils

# /etc/freeradius/3.0/clients.conf - Switches/APs registrieren
client switch-floor1 {
    ipaddr          = 192.168.1.10
    secret          = "StarkesRADIUSSecret123!"
    nastype         = cisco
    shortname       = sw-floor1
}

client wlan-ap-01 {
    ipaddr          = 192.168.1.20
    secret          = "AnderesSicheresSecret!"
    nastype         = cisco_aironet
}

# /etc/freeradius/3.0/mods-available/ldap - AD-Integration
ldap {
    server          = "ldap://dc01.company.local"
    identity        = "CN=radius-svc,OU=ServiceAccounts,DC=company,DC=local"
    password        = "ServiceAccountPasswort"
    base_dn         = "DC=company,DC=local"
    user {
        base_dn     = "${..base_dn}"
        filter      = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    group {
        base_dn     = "${..base_dn}"
        filter      = "(objectClass=groupOfNames)"
        membership_attribute = "memberOf"
    }
}

# VLAN-Zuweisung basierend auf AD-Gruppe
if (LDAP-Group == "CN=Corp-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Type := VLAN
    reply:Tunnel-Medium-Type := IEEE-802
    reply:Tunnel-Private-Group-Id := "10"    # VLAN 10 = Corporate
}
elsif (LDAP-Group == "CN=Guest-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Private-Group-Id := "99"    # VLAN 99 = Guest
}
else {
    reply:Tunnel-Private-Group-Id := "998"   # VLAN 998 = Quarantäne
}

Microsoft NPS (Network Policy Server) ist in Windows Server integriert (kein Extra-Produkt): Server Manager → Add Roles → Network Policy and Access Services → NPS. Connection Request Policy: Type 802.1X (Wired/Wireless), Auth-Method PEAP-MSCHAPv2 oder EAP-TLS. Network Policy: Condition Windows Groups = "CORP\Domain Computers", Permission: Grant Access, Settings: VLAN-Attribute (Tunnel-Type, Tunnel-Medium-Type, VLAN-ID).

Supplicant-Konfiguration

Windows 802.1X wird über GPO konfiguriert: Computer → Windows Settings → Security Settings → Wired Network (IEEE 802.3) Policies.

# Linux wpa_supplicant EAP-TLS (/etc/wpa_supplicant/wpa_supplicant.conf)
ctrl_interface=/run/wpa_supplicant
network={
    ssid="CORP-WLAN"
    scan_ssid=1
    key_mgmt=WPA-EAP
    eap=TLS
    identity="host/laptop01.company.local"
    ca_cert="/etc/ssl/certs/company-ca.crt"
    client_cert="/etc/ssl/certs/laptop01.crt"
    private_key="/etc/ssl/private/laptop01.key"
}

Intune WLAN-Profil (iOS/Android/Windows) für EAP-TLS: Device Configuration → Profiles → Wi-Fi → Enterprise, EAP Type TLS, Certificate server names: radius.company.local, Root certificate: Company Internal CA, Client certificate: SCEP/PKCS cert from Intune.

MAC-Address-Bypass für Legacy-Geräte

Drucker, IP-Telefone und IoT-Sensoren unterstützen kein 802.1X, müssen aber trotzdem kontrolliert ins Netz. MAB löst das: Der Switch sendet die MAC-Adresse des Geräts als RADIUS-Request. RADIUS vergleicht die MAC mit einer Whitelist und weist bei Match das entsprechende VLAN zu.

# FreeRADIUS MAB Policy - MAC-Whitelist
# Format: XX-XX-XX-XX-XX-XX in Kleinbuchstaben
aa-bb-cc-dd-ee-ff Cleartext-Password := "aa-bb-cc-dd-ee-ff"
    Tunnel-Type = VLAN,
    Tunnel-Medium-Type = IEEE-802,
    Tunnel-Private-Group-Id = "20"   # VLAN 20 = Drucker-VLAN

Sicherheitslimitation: MAC-Adressen sind leicht zu fälschen - ein Angreifer kann beliebige MACs verwenden (MAC-Spoofing). MAB sollte daher nur für Low-Trust-Geräte mit eigenem Sicherheits-VLAN und wenn möglich mit zusätzlichem Posture Assessment eingesetzt werden.

Posture Assessment - Gerätezustand prüfen

Posture-Checks (Cisco ISE) prüfen sieben Bereiche:

Betriebssystem-Konformität: Windows min. 10 22H2, macOS min. 14.x (Sonoma). Ältere Versionen → Quarantäne → Update-Seite.
Patch-Level: Alle kritischen Windows-Updates installiert? Status via WSUS/SCCM oder WMI. Nicht aktuell → Quarantäne mit Update-Server-Zugang.
Antivirus/EDR: AV-Lösung, Version, Definitionen aktuell? Defender Real-Time-Protection aktiv? Konformes EDR installiert? Fehlt AV/EDR → Quarantäne.
Disk-Encryption: BitLocker (Windows) aktiv und escrowed? FileVault (macOS) aktiv? Nicht verschlüsselt → Quarantäne.
Firewall: Windows Firewall aktiviert für alle Profile (Domain/Private/Public)?
Domänenmitgliedschaft: AD-Domain oder Entra-ID-Join (Cloud-Managed)? Nicht in Domain → BYOD-Behandlung.
Software-Inventory: Unzulässige Software (Torrent, Remote-Tools)? → Warnung oder Quarantäne.

Agent-basiert (NAC-Agent auf Gerät): ermöglicht tiefe Prüfung aller obigen Checks. Problem: Agent-Management, Updates, BYOD akzeptiert keinen Agent.

Agentless (ohne Software): prüft über MAB (MAC-Adresse), DHCP-Fingerprint und mDNS. Schwächere Checks (Gerät-Typ erkannt, aber kein Patch-Level). Für Drucker, Kameras und IoT-Geräte (kein Agent möglich) sowie BYOD (begrenzte Kontrolle).

Posture Workflow: Gerät verbindet sich → 802.1X-Authentifizierung → NAC-Agent prüft Posture → Ergebnis: Compliant → Full Access VLAN; Non-Compliant → Quarantäne-VLAN; Unknown → begrenzter Zugang (für Erstregistrierung).

VLAN-basierte Segmentierung

Ein typisches NAC-Zonenmodell arbeitet mit mehreren VLANs: VLAN 10 Corporate für gemanagte, konforme Windows/macOS-Geräte mit Domain-Join; VLAN 20 BYOD/Mobile für persönliche Geräte mit MDM-Enrollment und eingeschränktem Zugang; VLAN 30 Gast ohne Unternehmenszugang, nur Internetzugang; VLAN 40 Quarantäne für nicht konforme Geräte mit Zugang nur zu Remediation-Servern; VLAN 50 IoT für Drucker, Kameras und Sensoren, vollständig isoliert; VLAN 60 VoIP für IP-Telefone mit QoS-Priorisierung; VLAN 70 Server mit restriktivem Zugang zu Produktionsservern; und VLAN 98 Management ausschließlich für Netzwerk-Admins und Netzwerkgeräte.

Die VLAN-Zuweisung durch NAC folgt klaren Regeln: 802.1X-Authentifizierung mit bestandenem Posture-Check ergibt Corporate VLAN 10; MDM-Enrollment mit BYOD-Policy ergibt BYOD VLAN 20; kein Auth oder unbekanntes Gerät landet im Gast-VLAN 30; Posture Fail (z. B. fehlender AV) landet in Quarantäne VLAN 40; eine bekannte Drucker-MAC per MAB landet in IoT VLAN 50.

Das Quarantäne-VLAN erlaubt nur DHCP, DNS sowie HTTP/HTTPS auf interne Remediation-Server und blockiert alle übrigen Hosts im Netzwerk. Eine Remediation-Seite erklärt das erkannte Problem und führt den Nutzer zur Lösung. Nach erfolgreicher Remediation wird ein erneutes Posture-Assessment durchgeführt und das Gerät ins korrekte VLAN verschoben.

Gastnetze sind vollständig von internen Ressourcen isoliert: Internet-Zugang ist eingeschränkt (kein P2P, Bandbreiten-Limit), ein Captive Portal erfordert AGB-Akzeptanz und setzt ein Zeitlimit, die SSID "Guest" ist getrennt von der Corporate-SSID, und VPN-Tunnel vom Gast-VLAN ins Corporate-Netz sind nicht erlaubt.

BYOD-Integration und Mobile

Private Geräte stellen NAC vor drei Kernherausforderungen: Sie akzeptieren keinen vollständigen NAC-Agenten, der Arbeitgeber darf laut DSGVO keine privaten Daten auf privaten Geräten prüfen, und Compliance lässt sich ohne vollständige Kontrolle schwerer sicherstellen.

Strategie 1 - MDM-Enrollment (Hybrid): Das Gerät muss in einem MDM (Intune, Jamf) eingeschrieben sein. Das MDM-Profil erzwingt Geräteverschlüsselung, PIN-Anforderung und VPN-Profil. Der NAC prüft den MDM-Enrollment-Status via API: MDM-Compliance ergibt Zugang zum BYOD-VLAN (eingeschränkt, aber produktiv); kein MDM bedeutet Gast-VLAN oder keinen Zugang. Datenschutz-Kompromiss: Apple User Enrollment bietet MAM only ohne Device Wipe; Android Work Profile trennt privates und berufliches Profil. Der Arbeitgeber sieht ausschließlich das Work-Profil, nicht private Apps oder Daten.

Strategie 2 - Certificate-basiertes BYOD: Der Benutzer erhält nach der Registrierung ein Client-Zertifikat, das im Schlüsselspeicher des privaten Geräts abgelegt wird. 802.1X mit EAP-TLS nutzt das Zertifikat zur Authentifizierung - ohne vollständigen Posture-Check. Das Gerät erhält Zugang zum BYOD-VLAN mit begrenzten Ressourcen.

Strategie 3 - ZTNA statt LAN-Zugang: Das private Gerät erhält keinen Netzwerkzugang, sondern ausschließlich Anwendungszugang über ZTNA (Zero Trust Network Access). Eine Secure Enclave bzw. Sandbox-App stellt Firmen-Apps in isolierter Umgebung bereit. Da kein Zugang zum internen Netzwerk besteht, ist kein Lateral Movement möglich. Empfohlene Produkte: Cloudflare Access, Zscaler Private Access, Microsoft Entra ID.

Für die rechtlich sichere BYOD-Umsetzung sind folgende Punkte erforderlich:

Schriftliche Einwilligung: Das Gerät darf gemanagt werden
Klarer Scope: welche Daten und Apps auf dem privaten Gerät
Remote-Wipe-Policy: nur Work-Container, nicht das gesamte Gerät
Klare Trennung zwischen privatem und beruflichem Bereich (Work Profile)
Datenschutzerklärung: was über das Gerät gesammelt wird

NAC-Lösungen im Vergleich

Produkt	Stärken	Schwächen	Empfehlung
Cisco ISE	Marktführer, tiefe Cisco-Integration, pxGrid, TrustSec/SGT, über 7.000 Geräteprofile	Hohe Lizenzkosten, komplexe Implementierung (6-12 Monate), hohe Hardware-Anforderungen	Cisco-zentrierte Enterprises, ab ca. 50 USD/Gerät/Jahr
Aruba ClearPass (HPE)	Herstellerunabhängig, starke BYOD-Workflows, OnGuard Agent, gute API	Komplex, erfordert Expertise, beste Integration mit Aruba-Switches	Bestes BYOD-Workflow, herstellerunabhängige Umgebungen
Microsoft NPS	Kostenlos (in Windows Server enthalten), native AD-Integration	Begrenzte Posture-Fähigkeiten (nur Domain-Check), keine Zero-Trust-Features, Legacy-Architektur	Als Einstieg oder Ergänzung, nicht als primäre NAC
Portnox Cloud	Cloud-native (kein On-Prem-Server), einfachere Implementierung, BYOD-freundlich, Entra-ID-Integration	Weniger mächtig als ISE bei komplexen Szenarien, relativ junge Plattform	Cloud-First-Umgebungen, KMU
Forescout	Agentless (sieht alle Geräte ohne Agent), IoT/OT-Spezialist, keine 802.1X-Voraussetzung	Geringere Tiefe beim Posture Assessment	OT/IoT-Umgebungen und Legacy-Netzwerke

Für die Produktauswahl gelten folgende Faustregeln: Wer eine Cisco-dominierte Infrastruktur betreibt, wählt ISE; wer herstellerunabhängig bleiben will und BYOD im Fokus hat, wählt Aruba ClearPass; wer überwiegend IoT- und OT-Geräte integrieren muss, nimmt Forescout; wer cloud-first arbeitet oder ein kleines Budget hat, ist mit Portnox oder einer ZTNA-Lösung besser bedient als mit klassischem NAC.

NAC als Zero-Trust-Baustein

NAC setzt das Zero-Trust-Prinzip "Never trust, always verify" auf Netzwerkebene um. Jedes Gerät muss sich identifizieren (802.1X oder Zertifikat), Compliance nachweisen (Posture Assessment) und erhält kontextabhängigen Zugang (VLAN je Gerät und Rolle). Die Prüfung ist nicht einmalig, sondern kontinuierlich: Posture wird regelmäßig neu bewertet.

In Microsoft-Umgebungen ergänzen sich NAC und Conditional Access: Intune markiert Geräte als compliant oder non-compliant. Azure AD Conditional Access verlangt Intune-Compliance für den O365-Zugriff. Kombiniert mit NAC bedeutet ein non-compliant Gerät gleichzeitig Quarantäne-VLAN und gesperrten O365-Zugang.

Für die Implementierung gilt der Grundsatz: nie alles auf einmal. Der empfohlene Einstieg ist das WLAN (weniger Geräte, einfacheres Rollback). Danach folgt das kabelgebundene LAN (höhere Komplexität), dann IoT-Geräte per MAB und abschließend das vollständige Posture Assessment. Ein stufenweiser Rollout über mehrere Monate reduziert das Risiko produktivitätshemmender Fehlkonfigurationen erheblich.

Implementation-Roadmap

Ein NAC-Rollout dauert typischerweise 12-18 Monate und läuft in fünf Phasen.

Phase 1 (Monate 1-3): Inventory und Design. Alle Netzwerksegmente kartieren, alle Gerätekategorien identifizieren (PC, Mobile, Drucker, IoT), ein VLAN-Konzept entwerfen, Policy-Anforderungen mit HR und Legal für die BYOD-Policy klären und ein NAC-Produkt auswählen und im Proof of Concept erproben.

Phase 2 (Monate 4-6): Pilotierung. 802.1X auf Pilot-Switches konfigurieren (nicht produktiv!), 50-100 Pilot-User mit Corporate Windows-Geräten testen, Authentication und Basic Posture validieren, Helpdesk-Prozesse für NAC-Probleme definieren und den Exception-Prozess festlegen (wer erhält Ausnahmen und auf welcher Grundlage?).

Phase 3 (Monate 7-9): BYOD und Mobile. MDM-Enrollment-Workflow einrichten, BYOD-VLAN und zugehörige Richtlinien in Betrieb nehmen, Zertifikatsverteilung für EAP-TLS automatisieren und Gast-WLAN mit Captive Portal aktivieren.

Phase 4 (Monate 10-12): IoT und Legacy. MAB für Drucker, Kameras und Telefone konfigurieren, automatisches Profiling für Geräteerkennung aktivieren, IoT-VLAN mit Mikrosegmentierung einrichten und Legacy-Geräte einzeln bewerten: Ausnahme oder Ersatz.

Phase 5 (Monate 13-18): Vollrollout und Monitoring. Alle Switches und WLANs umstellen, ein NAC-Dashboard mit SIEM-Integration aufbauen, quartalsweise Policy-Reviews etablieren und Incident-Playbooks für NAC-Ausfall und False Positives erstellen.

Erfolgskennzahlen für den Betrieb: Anteil der Geräte unter NAC-Kontrolle (Ziel: über 95 %), Anzahl erkannter unmanagebarer Geräte (Ziel: unter 5 %), Quarantäne-Ereignisse pro Woche (Trend: abnehmend), Mean Time to Remediate von Quarantäne bis Konformität sowie NAC-Verfügbarkeit von mehr als 99,9 %.