802.1X-Projekte: Implementierung der identitätsbasierten Architektur in der Praxis

802.1X-Projekte sehen von außen wie ein Network-Job aus; weil die Kontaktpunkte Switch-Ports, SSIDs und RADIUS sind. Aber im echten Leben wird der Erfolg von 802.1X oft nicht an den Netzwerkgeräten entschieden, sondern in der Active Directory-Struktur, der Zertifikatsinfrastruktur (PKI) und dem Endpoint-Management. Der Grund ist einfach: 802.1X zwingt die Organisation dazu, über ihr „Identitätsmodell" zu sprechen, anstatt nur über das VLAN des Ports. Mit anderen Worten: Man wechselt von „welcher Port gehört zu welchem VLAN" zu einem System von „welche Identität tritt mit welcher Berechtigung in das Netzwerk ein".

802.1X NAC Architektur-Übersicht

Dieser Übergang ändert die Gewohnheiten einer Organisation. Denn wenn 802.1X implementiert ist, ist das Netzwerk nicht mehr etwas, das „einfach funktioniert, wenn man ein Kabel einsteckt"; es produziert Ergebnisse wie Quarantäne für Geräte, die die Validierung nicht bestehen, ein Portal für Gäste oder das falsche VLAN für einen Computer, der in der falschen OU sitzt. Deshalb sehe ich 802.1X nicht als Feature, sondern als eine organisatorische Kompetenz: eine Kompetenz, bei der Identität, Inventar, Richtlinien und Betrieb am selben Tisch sitzen.

Zusammenfassung (nur Kernpunkte):

  • 802.1X ist eine Identitätsarchitektur, nicht nur Port-Sicherheit.
  • Der Erfolg hängt mehr von der AD/PKI/Endpoint-Disziplin ab als vom Netzwerk selbst.

Für die Zero-Trust-Denkweise hinter identitätsbasiertem Zugang: Die Zero-Trust-Denkweise: Sicherheit als Architektur, nicht als Produkt

1) Planung: Ohne VLAN-Plan wird 802.1X zu einer „Chaos-Maschine" statt einer „Policy-Maschine"

Beim Start von 802.1X ist der erste Reflex von jedem: „Wir richten RADIUS ein, schreiben es auf den Switch und fertig." In der Praxis endet dies meist mit dem allerersten Pilotbenutzer. Denn der Pilotbenutzer verbindet sich, und plötzlich taucht diese Frage auf: „In welches VLAN soll dieser Benutzer?"

Wenn es in der Organisation keinen sinnvollen VLAN/Segmentierungsplan gibt, werden bei der Implementierung von 802.1X alle Mängel sichtbar. Daher müssen Benutzer und Geräte vor Projektbeginn in „Klassen" eingeteilt werden: Abteilungen (Buchhaltung, Finanzen, HR…), Gerätetypen (Drucker, IP-Telefon, Kamera, Badge-Reader…), Server-Segmente (AD/DC, File, Mail, Web/DMZ), Gast-Segment, Quarantäne-Segment.

Zusammenfassung:

  • VLAN-Plan = Policy-Plan.
  • 802.1X macht die Segmentierungsentscheidung „unaufschiebbar".

2) Netzwerk-Bereitschaft: Jedes VLAN muss manuell funktionieren, bevor 802.1X implementiert wird

Vor dem Wechsel zu 802.1X reicht es nicht aus, dass VLANs auf dem Switch und der Firewall definiert sind; sie müssen manuell getestet werden. Der Workflow, den ich in der Praxis am meisten empfehle: Erstellen Sie die VLANs, richten Sie die Routing- und Firewall-Regeln ein, verschieben Sie dann einen Test-Port in ein statisches VLAN und führen Sie „erwartete Zugriffs-Tests" durch.

In dieser Phase ist auch das Thema Management-Netzwerk kritisch. Die Management-IPs von Switches, WLCs und APs sollten in einem separaten Management-VLAN liegen. Wenn es kein „Management-VLAN" gibt, geht selbst während des 802.1X-Piloten der Zugriff auf das Gerätemanagement verloren.

Zusammenfassung:

  • Sie können nicht fortfahren, ohne VLAN + FW-Regeln vor 802.1X manuell zu testen.
  • Wenn das Management-Netzwerk nicht getrennt ist, birgt das Projekt unnötige Risiken.

3) AD-Seite: Wo keine OU-Struktur existiert, wird 802.1X immer zum „Ausnahme-Management"

Bei 802.1X-Projekten ist einer der kritischsten Punkte, „wo" die Klassifizierung von Benutzern und Computern erfolgt. Die Struktur, die ich in der Praxis als „Best Practice" ansehe: Erstellen einer OU-Struktur für jede Abteilung und das Belassen sowohl des Benutzers als auch des Computers unter dieser OU.

Das Verschieben einer OU ist „nicht nur Drag-and-Drop" — es kann die auf den Benutzer angewendeten GPOs ändern. Meine empfohlene Methode: Wählen Sie zunächst einen einzelnen Pilotbenutzer aus. Führen Sie den OU-Umzug durch. Beobachten Sie dies für 1 Woche bis 10 Tage.

Zusammenfassung:

  • Die OU-Struktur ist das unsichtbare Rückgrat von 802.1X.
  • Wenn der OU-Umzug nicht kontrolliert erfolgt, treten GPO/Zugriffs-Nebenwirkungen auf.

4) Group Policy: Eine „manuelle Einstellung nach der anderen" lässt sich in 802.1X-Projekten nicht skalieren

Sie können 802.1X im Piloten manuell einrichten; in der Produktion können Sie ohne GPO nicht überleben. Auf der GPO-Seite werden normalerweise drei Dinge getan: Verteilung von kabelgebundenen 802.1X-Profilen, drahtlosen 802.1X-Profilen und Zertifikats-Auto-Enrollment.

Ein kleines, aber sehr kritisches Detail: Wenn „benutzerbasiertes 802.1X" und „computerbasiertes 802.1X" gleichzeitig aktiv sind, ist die Reihenfolge wichtig. In den meisten Designs ist „zuerst Computer-Auth, dann Benutzer-Auth" erwünscht.

Zusammenfassung:

  • 802.1X kann nicht ohne GPO in die Produktion überführt werden.
  • Die Authentifizierungsreihenfolge (Machine vs. User) macht in der Praxis einen Unterschied.

5) RADIUS / NPS / NAC: „Sprechen" allein reicht nicht; wichtig ist, welche Antwort gegeben wird

Die RADIUS-Seite wird von den meisten Teams als „Wir haben den Switch eingeführt, das Secret vergeben, fertig" angesehen. Das eigentliche Thema ist: Welches VLAN / welche ACL / welche Richtlinie gibt RADIUS als Antwort an den Switch zurück?

  • In der einfachen Welt gibt RADIUS nur „Accept/Reject" zurück, das VLAN bleibt statisch.
  • In der reifen Welt gibt RADIUS „Accept" zusammen mit einer dynamischen VLAN-Zuweisung zurück, pusht dACL/ACL.

Ein häufiger Fehler: Verwendung anderer IPs anstelle der Management-IP, Unfähigkeit, RADIUS aufgrund der falschen VRF/Route zu erreichen, Source-Interface-Fehler… Deshalb beginne ich in jedem Projekt mit dem einfachsten Test: Erreichbarkeit vom Switch zum RADIUS, Logs im RADIUS, dann ein Test-Port.

Zusammenfassung:

  • Das Projekt endet nicht nur, weil RADIUS „kommuniziert" hat; wichtig ist, „welche Richtlinien-Antwort zurückgegeben wird".
  • Erreichbarkeits-/Source-Interface-/VRF-Fehler sind die klassischsten Ursachen.
NAC Posture Assessment und VLAN-Zuweisungs-Workflow

6) EAP-Methoden: PEAP oder EAP-TLS, Computer oder Benutzer?

Warum PEAP praktisch, aber riskant ist: Ein Benutzer kann sich mit demselben Benutzernamen/Passwort auch von seinem privaten Laptop aus ins Netzwerk einwählen. In der Zero Trust-Logik ist es das Ziel, nicht nur den Benutzer, sondern auch das Gerät zu validieren.

Warum Computer-Authentifizierung gut ist, aber in einigen Organisationen schmerzt: An Orten, an denen gemeinsam genutzte Computer verwendet werden, reicht dies allein nicht aus, wenn Sie eine benutzerbasierte Segmentierung wünschen.

Warum EAP-TLS am „korrektesten" ist, aber Disziplin erfordert: Bei EAP-TLS gilt: Selbst wenn das Passwort durchsickert, gibt es ohne das Zertifikat keinen Zugriff. Aber die PKI muss laufen, Templates müssen korrekt sein, Auto-Enrollment muss funktionieren.

Zusammenfassung:

  • PEAP ist praktisch, aber das Vertrauen in das „Unternehmensgerät" bleibt schwach.
  • Computer-Auth ist stark, aber in Szenarien mit gemeinsam genutzten PCs begrenzt.
  • EAP-TLS ist am sichersten; PKI-Disziplin ist zwingend erforderlich.

7) PKI und Zertifikatsvorlagen: Die stille Bruchstelle von 802.1X

Wenn Sie EAP-TLS entwerfen, müssen Sie an mindestens zwei Dinge bei den Windows Certificate Services (AD CS) denken:

  1. Client-Zertifikate: (Benutzerzertifikat, Computerzertifikat)
  2. Das Server-Zertifikat, das der RADIUS-Server präsentieren wird.

Ein sehr häufiger Fehler: Das Template ist vorbereitet, aber weil die Sicherheitsberechtigungen falsch sind, kann das Gerät das Zertifikat nicht erhalten; oder es erhält es, kann es aber aufgrund des falschen EKU/KeyUsage nicht in EAP-TLS verwenden.

NPS präsentiert dem Client ein Server-Zertifikat. Wenn der Client diesem nicht vertraut, nimmt er es als „Man-in-the-Middle" wahr. Daher sollte die RADIUS-Server-Zertifikatskette (CA) als vertrauenswürdig an den Client verteilt werden — via GPO in den Bereich „Trusted Root Certification Authorities".

Wenn der CRL-Zugriff unterbrochen ist, verzögert sich die Validierung oder schlägt fehl, selbst wenn das Zertifikat korrekt ist. Dies ist der klassische Grund für „verbindet sich gelegentlich nicht"-Probleme.

Zusammenfassung:

  • Wenn Template-Berechtigungen/Zwecke falsch sind, endet TLS.
  • Auto-Enrollment + CA-Vertrauensverteilung sollten mit GPO standardisiert werden.
  • Wenn der CRL-Zugriff abstürzt, denkt jeder: „802.1X ist kaputt".

8) Dot1X und MAB gemeinsam auf dem Switch-Port: Die richtige Reihenfolge rettet Leben

Das gängigste und logischste Modell in der Praxis: Zuerst dot1x versuchen; wenn dot1x fehlschlägt, auf MAB zurückfallen. Denn intelligente Endpunkte wie Laptops können 802.1X; nicht-intelligente wie Drucker/Kameras können mit MAB laufen.

Wenn Sie MAB falsch priorisieren, kann sich selbst ein in die Domäne eingebundener Laptop mit MAB verbinden und in das falsche VLAN fallen. Die beste Methode: Abteilung für Abteilung vorgehen; zuerst 1–2 Pilotbenutzer, 1 Woche Beobachtung, dann Ausweitung.

Zusammenfassung:

  • Die Reihenfolge Dot1X → MAB bei Fehler ist für die meisten Umgebungen am gesündesten.
  • Ein portbasierter, kontrollierter Rollout ist schneller fertig als ein „Ein-Tages-Übergang".

9) Profiling: Die Ära von „Nur-MAC" ist vorbei

MAC-Authentifizierung ist allein keine ausreichende Sicherheit mehr. Deshalb führen moderne NAC-Lösungen ein Profiling durch: OUI-Prüfung, DHCP-Fingerprint, CDP/LLDP, Gerätebeschreibung werden zusammen ausgewertet. So wird es für ein gefälschtes Gerät schwierig, über MAB ein VLAN zu erhalten.

Zusammenfassung:

  • MAC allein ist keine Identität; Profiling nähert sich der Identität an.
  • Die Verwendung mehrerer Signale reduziert den Missbrauch in der Praxis.

10) Quarantäne-VLAN und Gast-VLAN: Sie sind nicht dasselbe

Quarantäne: Das Unternehmen besitzt das Gerät, aber es kann die Validierung nicht bestehen. Der Zweck des Quarantäne-VLANs ist nicht, das Gerät „komplett abzuschneiden"; es geht darum, den minimalen Zugriff zu gewähren — AD/CA-Zugriff, Passwort ändern, Update erhalten.

Gast: Nicht das Gerät des Unternehmens. Hier erlauben Sie normalerweise nur Internet; interne Ressourcen wie AD/Kerberos/LDAP sind völlig unnötig.

Zusammenfassung:

  • Quarantäne ist „unseres, aber problematisch"; Gast ist „nicht unseres".
  • Beides in dasselbe VLAN zu stecken, macht die Sicherheit und den Betrieb kaputt.

11) Gast-Portal: Sponsor-Login, SMS, Social-Login und die MAC-Randomisierungs-Realität

Der Sponsor-Login-Ansatz funktioniert besonders in Unternehmensstrukturen sehr gut: Der Gast sagt „wen ich besuche"; das System findet diese Person im AD; eine Genehmigungsmail wird gesendet; nach der Genehmigung geht der Gast ins Internet.

Wenn moderne Telefone MAC-Randomisierung im Wi-Fi durchführen, kann das Gerät als „neues Gerät" erscheinen und erneut nach einer Validierung fragen. Dies beeinträchtigt das Benutzererlebnis — es regnet „Internet ist weg"-Anrufe beim Helpdesk.

Zusammenfassung:

  • Das Portal-Modell ist ebenso sehr UX-Design wie Sicherheit.
  • MAC-Randomisierung kann den Gast-Fluss unterbrechen; dies sollte entsprechend geplant werden.

12) Posture: Die „letzte Festung" von 802.1X, aber es ermüdet den Betrieb, wenn es falsch eingerichtet ist

Posture bedeutet: Den Zugriff einschränken, wenn der Sicherheitsstatus des Geräts nicht geeignet ist, selbst wenn die Identität korrekt ist. Typischerweise werden abgefragt: OS-Version, Patch-Level, Status der Festplattenverschlüsselung, ob AV vorhanden und aktuell ist, ob der EDR-Agent läuft.

Posture hat einen Preis: Oft ist ein Agent auf dem Endpunkt erforderlich. Deshalb ist es klug, wenn möglich bestehende Agenten wiederzuverwenden — in Cisco-Umgebungen AnyConnect, auf der Fortinet-Seite FortiClient, in manchen Strukturen Trellix.

Der praktische Ansatz, den ich am meisten empfehle: Starten Sie Posture in der ersten Phase als „Beobachtungs- und Berichtsmechanismus", nicht als „Ablehnungsmechanismus". Sammeln Sie zuerst die Daten, sehen Sie, wie viele Geräte als nicht-konform gemeldet werden, und verschärfen Sie dann schrittweise. Posture reift in einem Prozess, nicht an einem Tag.

Zusammenfassung:

  • Posture ist ein „Identitäts- + Gesundheits-Check"; es fängt den Drift ab.
  • Ein neuer Agent ist kostspielig; es ist klug, bestehende Agenten wiederzuverwenden.
  • Nicht am ersten Tag ablehnen; zuerst messen, dann verschärfen.

13) Basis 802.1X → Profiling/Portal → Posture: Reifegrade

  • Stufe 1: Dot1X + MAB — mit Windows NPS erreichbar. Kostengünstig, begrenzte Fähigkeiten.
  • Stufe 2: Profiling + Gast-Portal — Cisco ISE, Aruba ClearPass kommen ins Spiel. Die Arbeit wird zu „das Gerät erkennen und den Gast verwalten."
  • Stufe 3: Posture — Höchster Sicherheitsgewinn, höchste Betriebskosten. Die Endpoint-Management-Fähigkeit, Agenten-Strategie und Helpdesk-Kapazität müssen realistisch bewertet werden.

Fazit: 802.1X ist kein „Setup", es ist ein interner Vertrag

802.1X-Projekte mögen technisch wie ein paar Befehle auf einem Switch aussehen. Aber in der Realität schreibt 802.1X diesen Vertrag vor: „Wie wird Identität übertragen, wie wird das Gerät erkannt, wie wird der Gast verwaltet, wo landet das problematische Gerät, an welchem Punkt beginnt die Sicherheit?"

Der Erfolg von 802.1X ist eher die Summe aus AD-Ordnung, GPO-Disziplin, PKI-Management und einer schrittweisen Rollout-Kultur als die Leistung der Geräte. Wenn Sie 802.1X so handhaben, erhöhen Sie nicht nur die Sicherheit; Sie zentralisieren auch den Betrieb.

Verwandte Artikel

Architektur & Sicherheit

Praktisches Engineering