So richten Sie einen RADIUS-Server für die WiFi-Authentifizierung ein
Dieser maßgebliche Leitfaden bietet IT-Leitern und Netzwerkarchitekten einen umfassenden Entwurf für die Bereitstellung eines RADIUS-Servers für die WiFi-Authentifizierung in Unternehmen. Er behandelt die architektonischen Abwägungen zwischen On-Premise- und Cloud-gehosteten Bereitstellungen, die Auswahl der EAP-Methode, die Active Directory-Integration und die dynamische VLAN-Zuweisung. Betreiber von Veranstaltungsorten und IT-Teams finden hier umsetzbare Implementierungsschritte, reale Fallstudien und Strategien zur Risikominderung, um noch in diesem Quartal von einer unsicheren PSK-Umgebung zu einer robusten 802.1X-Infrastruktur überzugehen.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
Executive Summary
In Enterprise-Umgebungen – ob auf einem weitläufigen Universitätsgelände, in einem hochfrequentierten Stadion oder in einer verteilten Einzelhandelskette – stellt die Nutzung eines Pre-Shared Key (PSK) für den WiFi-Zugang ein erhebliches Sicherheitsrisiko dar. Ein einziger kompromittierter Zugangsschlüssel gefährdet das gesamte Netzwerk, und der Entzug des Zugangs erfordert die Änderung des Passworts auf jedem einzelnen Gerät im gesamten Bestand. Die Implementierung der 802.1X-Authentifizierung über einen RADIUS-Server (Remote Authentication Dial-In User Service) löst dieses Problem vollständig: Jeder Benutzer authentifiziert sich individuell, Zugriffsrechte können sofort entzogen werden und die Netzwerksegmentierung wird dynamisch erzwungen.
Dieser Leitfaden bietet IT-Managern und Netzwerkarchitekten einen klaren Fahrplan für die Bereitstellung der RADIUS-Authentifizierung. Wir behandeln die architektonischen Abwägungen zwischen On-Premise- und Cloud-basierten Implementierungen, die Konfiguration von EAP-Methoden (Extensible Authentication Protocol) und die Integration mit Verzeichnisdiensten wie Active Directory. Zudem zeigen wir, wie sich eine robuste Authentifizierungsebene in Guest WiFi -Lösungen integrieren lässt, um Besuchern einen nahtlosen Zugang zu bieten, während gleichzeitig WiFi Analytics erfasst werden, die Ihr Netzwerk in ein Business-Intelligence-Asset verwandeln.
Technische Vertiefung
Die 802.1X-Architektur
Der Standard IEEE 802.1X definiert die portbasierte Netzwerkzugriffskontrolle (PNAC). Im Wireless-Kontext sind daran drei Hauptrollen beteiligt, die zusammenarbeiten:
| Rolle | Komponente | Aufgabe |
|---|---|---|
| Supplicant | Client-Gerät (Laptop, Smartphone) | Übermittelt Anmeldedaten, um Netzwerkzugriff anzufordern |
| Authenticator | WiFi Access Point oder Controller | Erzwingt die Zugriffskontrolle; leitet EAP-Nachrichten weiter |
| Authentication Server | RADIUS-Server | Validiert Anmeldedaten; gibt Accept/Reject-Antworten und Richtlinienattribute zurück |
Wenn sich ein Supplicant mit einem Access Point verbindet, blockiert der AP den gesamten Datenverkehr mit Ausnahme von EAP-Nachrichten (Extensible Authentication Protocol). Der AP kapselt diese EAP-Nachrichten in RADIUS-Pakete und leitet sie an den RADIUS-Server weiter. Der Server überprüft die Anmeldedaten anhand einer Backend-Datenbank – in der Regel LDAP oder Active Directory – und gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Bei erfolgreicher Authentifizierung gibt der AP den Port frei und der Datenverkehr des Clients kann ungehindert fließen.
Auswahl einer EAP-Methode
Die Sicherheit Ihrer RADIUS-Bereitstellung hängt stark von der gewählten EAP-Methode ab. Die beiden am häufigsten in Enterprise-Umgebungen eingesetzten Methoden sind:
EAP-TLS (Transport Layer Security) ist der Goldstandard. Sie erfordert digitale Zertifikate sowohl auf dem RADIUS-Server als auch auf jedem Client-Gerät, wodurch Passwörter vollständig überflüssig werden. Selbst wenn ein Angreifer den gesamten Authentifizierungsvorgang abfängt, gibt es keine Anmeldedaten, die extrahiert werden könnten. Der Nachteil ist der administrative Aufwand: Die Bereitstellung und Verwaltung von Client-Zertifikaten erfordert eine funktionierende Public-Key-Infrastruktur (PKI) und eine MDM-Lösung (z. B. Microsoft Intune, Jamf), um die Zertifikate auf den Endgeräten zu verteilen.
PEAP-MSCHAPv2 (Protected EAP) ist in der Praxis die am weitesten verbreitete Methode. Sie verwendet ein serverseitiges Zertifikat, um einen verschlüsselten TLS-Tunnel aufzubauen, in dem sich der Client mit Benutzername und Passwort authentifiziert. Dies ist wesentlich einfacher zu implementieren als EAP-TLS, da nur ein einziges Zertifikat – das des Servers – verwaltet werden muss. Dies birgt jedoch ein kritisches Risiko: Wenn Client-Geräte nicht explizit so konfiguriert sind, dass sie das Zertifikat des RADIUS-Servers validieren, sind sie anfällig für Man-in-the-Middle-Angriffe (MitM) über gefälschte Access Points.
> Wichtiger Sicherheitshinweis: Wenn auf den Client-Geräten keine strikte Zertifikatsvalidierung erzwungen wird, werden die Sicherheitsvorteile von PEAP-MSCHAPv2 praktisch hinfällig. Ein Angreifer kann einen gefälschten AP betreiben, ein betrügerisches Zertifikat vorlegen und die Benutzerdaten im Klartext abfangen. Dies ist kein theoretisches Risiko, sondern ein gut dokumentierter Angriffsvektor, der in der Praxis bereits ausgenutzt wurde.
Implementierungsleitfaden
Schritt 1: Architektonische Entscheidung – On-Premise vs. Cloud RADIUS
Die erste Entscheidung betrifft den Hosting-Ort der RADIUS-Infrastruktur. Dies ist in erster Linie eine Frage des Betriebs und der Kosten, nicht der Sicherheit – beide Modelle können sicher implementiert werden.
On-Premise RADIUS (z. B. Microsoft NPS, FreeRADIUS, Cisco ISE) eignet sich für Unternehmen mit eigener IT-Abteilung, bestehender On-Premise-Verzeichnisinfrastruktur und strengen Anforderungen an Datensouveränität oder Compliance. Die Authentifizierung ist nicht von einer Internetverbindung abhängig, was in Umgebungen, in denen die Internet-Verfügbarkeit nicht garantiert werden kann, ein bedeutender Vorteil ist.
Cloud RADIUS wird zunehmend zum bevorzugten Modell für verteilte Umgebungen – wie Einzelhandelsketten , Hotel- und Gastronomiegruppen und Transportknotenpunkte , bei denen die Bereitstellung von Servern an jedem Standort betrieblich unpraktisch ist. Cloud RADIUS lässt sich nativ in Cloud-Identitätsanbieter (Azure AD, Google Workspace, Okta) integrieren und bietet integrierte Hochverfügbarkeit sowie globale Skalierbarkeit.
Schritt 2: Installation und Konfiguration des RADIUS-Servers
Für eine On-Premise-Bereitstellung mit Microsoft NPS (die häufigste Wahl in Windows-zentrierten Umgebungen):
- Installieren Sie die Rolle „Netzwerkrichtlinienserver“ über den Server-Manager.
- Registrieren Sie den NPS-Server in Active Directory, damit er die Einwahleigenschaften von Benutzern lesen kann.
- Erstellen Sie einen RADIUS-Client-Eintrag für jeden Access Point oder Wireless Controller und geben Sie die IP-Adresse des APs sowied ein starkes, eindeutiges Shared Secret.
- Konfigurieren Sie eine Netzwerkrichtlinie, die die Bedingungen (z. B. Mitgliedschaft in einer Benutzergruppe) und Einschränkungen (z. B. EAP-Methode, Sitzungstimeout) für den Zugriff definiert.
- Konfigurieren Sie die Verbindungsanforderungsrichtlinie so, dass Anforderungen lokal verarbeitet werden.
Für FreeRADIUS unter Linux:
- Über den Paketmanager installieren:
sudo apt-get install freeradius freeradius-ldap. - Konfigurieren Sie
/etc/freeradius/3.0/clients.conf, um RADIUS-Clients (APs) und deren Shared Secrets zu definieren. - Konfigurieren Sie das LDAP-Modul in
/etc/freeradius/3.0/mods-available/ldapso, dass es auf Ihr Active Directory oder Ihren LDAP-Server verweist. - Aktivieren Sie das LDAP-Modul:
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/. - Definieren Sie EAP-Methoden in
/etc/freeradius/3.0/mods-available/eap.
Schritt 3: Access Points konfigurieren
Auf Ihrem Wireless-Controller oder den einzelnen Access Points:
- Definieren Sie die IP-Adresse(n) des RADIUS-Servers und den Authentifizierungsport (Standard: UDP 1812).
- Konfigurieren Sie das Shared Secret – verwenden Sie mindestens 22 Zeichen, bestehend aus alphanumerischen Zeichen und Sonderzeichen. Verwenden Sie ein eindeutiges Secret pro Standort oder AP-Gruppe.
- Konfigurieren Sie die SSID so, dass der Sicherheitsmodus WPA2-Enterprise oder WPA3-Enterprise mit 802.1X-Schlüsselverwaltung verwendet wird.
- Konfigurieren Sie einen sekundären RADIUS-Server für das Failover.
Schritt 4: Verzeichnisintegration
Für die lokale AD-Integration muss der RADIUS-Server der Domäne beigetreten sein oder über LDAP-Lesezugriff verfügen. Stellen Sie sicher, dass die für die LDAP-Bindung verwendeten Dienstkonten über die minimal erforderlichen Berechtigungen verfügen. Konfigurieren Sie für Cloud-RADIUS die API-basierte Synchronisierung oder die SAML/OIDC-Integration mit Ihrem IdP.
Definieren Sie klare Benutzergruppen in Ihrem Verzeichnis, da diese die Autorisierungsrichtlinien steuern. Empfohlene Gruppenstruktur:
| Gruppe | VLAN | Zugriffsebene |
|---|---|---|
Corp_Staff |
VLAN 10 | Vollständiges internes Netzwerk |
Corp_Contractors |
VLAN 20 | Internet + spezifische interne Ressourcen |
Corp_IoT |
VLAN 30 | Isoliert, nur gerätespezifische Ports |
Corp_Guests |
VLAN 100 | Nur Internet über Captive Portal |
Schritt 5: Client-Konfiguration und Zertifikatsvalidierung
Dies ist der betrieblich kritischste Schritt. Verwenden Sie Gruppenrichtlinien (GPO) für Windows und MDM-Profile für macOS/iOS/Android, um WiFi-Konfigurationen geräuschlos an verwaltete Geräte zu verteilen. Das Profil muss Folgendes angeben:
- Die Root-CA, die das Zertifikat des RADIUS-Servers ausgestellt hat.
- Den erwarteten Servernamen (CN oder SAN des Serverzertifikats).
- Die EAP-Methode und das innere Authentifizierungsprotokoll.
Stellen Sie für nicht verwaltete BYOD-Geräte klare Anleitungen zur Selbstbedienung bei der Einrichtung bereit, idealerweise über ein Network Access Control (NAC)-Portal.
Schritt 6: Dynamische VLAN-Zuweisung implementieren
Konfigurieren Sie den RADIUS-Server so, dass er Attribute für die VLAN-Zuweisung in der Access-Accept-Antwort zurückgibt:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id= ``
Der Access Point liest diese Attribute und weist den authentifizierten Client dem angegebenen VLAN zu – keine manuelle Neukonfiguration erforderlich, wenn Benutzer ihre Rollen oder Standorte wechseln.
Best Practices
Redundanz ist nicht verhandelbar. Stellen Sie mindestens zwei RADIUS-Server (primär und sekundär) bereit und konfigurieren Sie alle Access Points so, dass sie automatisch ein Failover durchführen. Bei lokalen Bereitstellungen sollten Sie den sekundären Server an einem anderen physischen Standort oder in einer anderen Verfügbarkeitszone platzieren. Ein RADIUS-Ausfall bedeutet, dass sich niemand authentifizieren kann, was einen vollständigen Netzwerkausfall für durch 802.1X geschützte SSIDs bedeutet.
Überwachen Sie den Ablauf von Zertifikaten proaktiv. Der Ablauf eines RADIUS-Serverzertifikats ist eine der häufigsten Ursachen für plötzliche, weitreichende Authentifizierungsfehler. Implementieren Sie eine Überwachung, um Administratoren mindestens 30 Tage vor dem Ablauf zu warnen. Dies gilt sowohl für das Serverzertifikat als auch für alle zwischengeschalteten CA-Zertifikate in der Kette.
Behandeln Sie das Shared Secret als kritische Anmeldeinformation. Das Shared Secret zwischen dem AP und dem RADIUS-Server verschlüsselt RADIUS-Pakete. Verwenden Sie eindeutige Secrets pro Standort oder AP-Gruppe, speichern Sie diese in einem Secrets Manager und rotieren Sie sie regelmäßig. In unserem Leitfaden Schützen Sie Ihr Netzwerk mit starkem DNS und Sicherheit finden Sie weitere Empfehlungen zur allgemeinen Netzwerksicherheit.
Richten Sie sich nach Compliance-Frameworks aus. Für Umgebungen, die PCI DSS unterliegen (z. B. Zahlungsnetzwerke im Einzelhandel), unterstützt die 802.1X-Authentifizierung direkt die Anforderungen an die Netzwerkzugriffskontrolle und die Audit-Protokollierung. Für die GDPR-Compliance bieten RADIUS-Accounting-Protokolle (Port 1813) einen detaillierten Audit-Trail darüber, wer wann und von wo aus auf das Netzwerk zugegriffen hat – wertvoll für die Reaktion auf Vorfälle. Für Umgebungen im Bereich Healthcare unterstützt die Netzwerksegmentierung über die dynamische VLAN-Zuweisung die HIPAA-Anforderungen zum Schutz elektronischer geschützter Gesundheitsinformationen (ePHI).
Fehlerbehebung & Risikominderung
| Fehlermodus | Symptom | Lösung |
|---|---|---|
| Zertifikatsablauf | Plötzliche Massenauthentifizierungsfehler | Ablauf überwachen; Zertifikat erneuern und neu bereitstellen |
| NTP-Desynchronisation | Sporadische EAP-TLS-Fehler | Sicherstellen, dass RADIUS-Server und DCs mit derselben NTP-Quelle synchronisiert sind |
| Verlust der LDAP-Verbindung | Authentifizierung schlägt fehl, wenn AD nicht erreichbar ist | Redundante DCs bereitstellen; RADIUS so konfigurieren, dass kürzliche Authentifizierungen zwischengespeichert werden |
| Ungültiges Shared Secret | AP-Protokolle zeigen RADIUS timeout oder Bad authenticator |
Überprüfen, ob das Secret auf dem AP und dem RADIUS-Server übereinstimmt |
| Client-Zertifikatskonflikt | EAP-TLS-Fehler bei bestimmten Geräten | Überprüfen, ob das Client-Zertifikat von einer vertrauenswürdigen CA ausgestellt wurde; Gültigkeitsdauer des Zertifikats prüfen |
| VLAN nicht zugewiesen | Benutzer authentifiziert, aber im falschen Netzwerksegment | Überprüfen, ob RADIUS-Attribute korrekt zurückgegeben werden; AP-VLAN-Konfiguration prüfen |
Für einen tieferen Einblick in den 802.1X-Konfigurationsprozess selbst bietet der Leitfaden Konfiguration der 802.1X-WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung detaillierte, herstellerspezifische Konfigurationsanleitungen.
ROI & geschäftliche Auswirkungen
Der Übergang von PSK zu REin RADIUS-gestütztes 802.1X erfordert eine Anfangsinvestition in die Konfiguration und potenziell in Lizenzen für Cloud-Lösungen oder Hardware für On-Premise-Bereitstellungen. Der ROI-Fall ist eindeutig:
Risikominderung: Die durchschnittlichen Kosten einer Datenpanne im Vereinigten Königreich liegen bei über 3 Millionen Pfund (IBM Cost of a Data Breach Report). Ein kompromittierter PSK kann das gesamte Netzwerk gefährden. 802.1X begrenzt den Schadensradius auf ein einziges kompromittiertes Benutzerkonto, das über das Verzeichnis in Sekundenschnelle deaktiviert werden kann.
Operative Effizienz: Die dynamische VLAN-Zuweisung macht eine manuelle Netzwerkrekonfiguration bei Rollenwechseln von Mitarbeitern überflüssig. Das Onboarding eines neuen Mitarbeiters bedeutet lediglich, ihn der richtigen AD-Gruppe hinzuzufügen – der Netzwerkzugriff folgt automatisch.
Compliance-Status: Für Unternehmen, die PCI DSS, ISO 27001 oder Cyber Essentials Plus unterliegen, ist 802.1X eine direkte Kontrollmaßnahme, die Auditoren erwarten. Die Implementierung stärkt Ihren Compliance-Status und senkt die Kosten für die Behebung von Audit-Mängeln.
Gästeerlebnis und Analysen: Für Betreiber von Veranstaltungsorten schafft die Integration von RADIUS für die Mitarbeiterauthentifizierung mit der Guest WiFi -Plattform von Purple für den Besucherzugang ein einheitliches, gestuftes Zugangsmodell. Mitarbeiter authentifizieren sich geräuschlos über 802.1X; Gäste verbinden sich über ein gebrandetes Captive Portal. Die WiFi Analytics -Plattform von Purple bietet dann Echtzeit-Einblicke in die Verweildauer der Besucher, die Rate wiederkehrender Besuche und Interaktionsmetriken – Daten, die direkt in die Marketingausgaben und operativen Entscheidungen des Veranstaltungsorts einfließen.
Für weitere Informationen lesen Sie bitte Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo für eine Implementierungsanleitung in portugiesischer Sprache und What Is a Leased Line? Dedicated Business Internet für Hinweise zur Sicherstellung, dass die zugrunde liegende Konnektivität den Anforderungen von Unternehmen entspricht.
Schlüsseldefinitionen
RADIUS (Remote Authentication Dial-In User Service)
Ein Netzwerkprotokoll, das eine zentrale Verwaltung von Authentifizierung, Autorisierung und Accounting (AAA) für Benutzer bietet, die sich mit einem Netzwerkdienst verbinden. Definiert in RFC 2865.
Die zentrale Serverkomponente, die Benutzeranmeldedaten mit einem Verzeichnis abgleicht, bevor sie WiFi-Zugriff gewährt. Jede WiFi-Bereitstellung in Unternehmen, die 802.1X nutzt, erfordert einen RADIUS-Server.
802.1X
Ein IEEE-Standard für portbasierte Netzwerkzugriffskontrolle (PNAC). Er bietet einen Authentifizierungsmechanismus für Geräte, die sich mit einem LAN oder WLAN verbinden möchten, und blockiert den gesamten Nicht-EAP-Verkehr, bis die Authentifizierung erfolgreich war.
Der übergeordnete Framework-Standard, der definiert, wie Supplicant, Authenticator und Authentication Server kommunizieren. Wenn IT-Teams von 'WiFi-Sicherheit für Unternehmen' sprechen, meinen sie in der Regel WPA2/WPA3-Enterprise mit 802.1X.
Supplicant
Das Client-Gerät – oder genauer gesagt der 802.1X-Software-Stack auf diesem Gerät –, das den Authentifizierungsprozess einleitet, indem es dem Netzwerk Anmeldedaten präsentiert.
Unter Windows ist der integrierte Supplicant der Dienst 'Automatische WLAN-Konfiguration'. Unter macOS und iOS ist er nativ im Betriebssystem integriert. Die korrekte Konfiguration des Supplicants (insbesondere für die Zertifikatsvalidierung) ist die häufigste Fehlerquelle bei Bereitstellungen.
Authenticator
Das Netzwerkgerät – in der Regel ein WiFi-Access-Point oder ein Wireless-Controller –, das als Vermittler zwischen dem Supplicant und dem RADIUS-Server fungiert und die Zugriffskontrolle basierend auf dem Authentifizierungsergebnis durchsetzt.
Der AP blockiert den gesamten Datenverkehr auf dem Port, bis er ein Access-Accept vom RADIUS-Server erhält. Er liest auch RADIUS-Attribute (z. B. VLAN-Zuweisung) aus der Access-Accept-Antwort und wendet sie auf die Sitzung an.
EAP (Extensible Authentication Protocol)
Ein in RFC 3748 definiertes Authentifizierungs-Framework, das einen standardisierten Transportmechanismus für verschiedene Authentifizierungsmethoden (TLS, PEAP, TTLS usw.) zwischen dem Supplicant und dem Authentication Server bietet.
EAP ist die 'Sprache', die zwischen dem Client und dem RADIUS-Server gesprochen wird. Die Wahl der EAP-Methode (EAP-TLS vs. PEAP) bestimmt die Sicherheitsstärke und die Komplexität der Bereitstellung des Authentifizierungssystems.
PEAP (Protected EAP)
Eine EAP-Methode, die zuerst einen TLS-Tunnel unter Verwendung des Serverzertifikats aufbaut und dann eine sekundäre Authentifizierung (in der Regel MSCHAPv2 mit Benutzername/Passwort) innerhalb dieses verschlüsselten Tunnels durchführt.
Die am häufigsten verwendete WiFi-Authentifizierungsmethode in Unternehmen aufgrund ihres ausgewogenen Verhältnisses zwischen Sicherheit und einfacher Bereitstellung. Erfordert nur ein serverseitiges Zertifikat, was die Einführung im Vergleich zu EAP-TLS erheblich erleichtert.
Dynamic VLAN Assignment
Eine RADIUS-Funktion, bei der der Server VLAN-spezifische Attribute (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) in die Access-Accept-Antwort aufnimmt und den AP anweist, den authentifizierten Client in ein bestimmtes VLAN einzubinden.
Ermöglicht es einer einzigen SSID, mehrere Benutzergruppen mit unterschiedlichen Sicherheitsanforderungen zu bedienen. Erübrigt das Ausstrahlen mehrerer SSIDs für verschiedene Benutzergruppen, was den RF-Overhead reduziert und die Benutzererfahrung vereinfacht.
Shared Secret
Eine vorkonfigurierte Textzeichenfolge, die nur dem Authenticator (AP) und dem RADIUS-Server bekannt ist und zum Signieren und Verschlüsseln von RADIUS-Paketen verwendet wird, um die Integrität und Authentizität der Kommunikation zu gewährleisten.
Ein kritisches Element der Sicherheitskonfiguration. Wenn das Shared Secret schwach oder kompromittiert ist, könnte ein Angreifer RADIUS-Access-Accept-Antworten fälschen und unbefugten Netzwerkzugriff gewähren. Verwenden Sie eindeutige Secrets pro Standort und speichern Sie diese in einem Secrets-Manager.
MAC Authentication Bypass (MAB)
Ein Fallback-Authentifizierungsmechanismus, bei dem die MAC-Adresse eines Geräts als Identitätsnachweis verwendet wird, um Geräten, die keine 802.1X-Supplicants unterstützen, den Netzwerkzugriff zu ermöglichen.
Wird für bildschirmlos arbeitende Geräte (Drucker, IoT-Sensoren, IP-Kameras) verwendet. Da MAC-Adressen öffentlich sichtbar sind und leicht gefälscht werden können, bietet MAB eher eine Geräteidentifikation als eine starke Authentifizierung. Immer mit einer restriktiven VLAN-Zuweisung kombinieren.
Ausgearbeitete Beispiele
Eine nationale Einzelhandelskette mit 500 Standorten muss sicheres WiFi für die Tablets der Filialleiter und POS-Terminals implementieren. Derzeit wird in allen Filialen ein einziger PSK verwendet, der häufig an unbefugte Mitarbeiter und externe Dienstleister weitergegeben wird. Sie nutzen Azure AD für das Identitätsmanagement und haben kein dediziertes IT-Personal an den Filialstandorten.
Stellen Sie eine Cloud-RADIUS-Lösung bereit, die direkt in Azure AD integriert ist. Dadurch entfällt die Notwendigkeit, On-Premise-RADIUS-Server an 500 Standorten bereitzustellen und zu verwalten. Das IT-Team nutzt Microsoft Intune, um ein für PEAP-MSCHAPv2 konfiguriertes WiFi-Profil auf alle Tablets der Filialleiter und POS-Terminals zu übertragen, wodurch die Validierung des Zertifikats des Cloud-RADIUS-Servers strikt erzwungen wird. Die Cloud-RADIUS-Richtlinie prüft die Azure AD-Gruppenmitgliedschaft des Benutzers, bevor sie Zugriff gewährt: Die Gruppe 'Store_Managers' erhält VLAN 10 (vollständiger POS- und Back-Office-Zugriff), die Gruppe 'Contractors' erhält VLAN 20 (nur Internet). Wenn der Einsatz eines externen Dienstleisters endet, entzieht das Entfernen aus der Azure AD-Gruppe sofort und gleichzeitig an allen 500 Standorten den WiFi-Zugriff – eine Änderung des PSK ist nicht erforderlich.
Ein Hotel mit 400 Zimmern im Stadtzentrum muss sicheres WiFi sowohl für das Personal (Rezeption, Housekeeping, Management) als auch für die Gäste bereitstellen. Das Personal benötigt Zugriff auf das Property Management System (PMS) und interne Server. Gäste benötigen ausschließlich Internetzugang. Das Hotel verfügt über eine einzige On-Premise-Windows-Server-Umgebung.
Stellen Sie Microsoft NPS auf einer dedizierten Windows Server-VM bereit. Konfigurieren Sie zwei SSIDs auf der Wireless-Infrastruktur: 'Hotel_Staff' (WPA2-Enterprise, 802.1X) und 'Hotel_Guest' (offen oder WPA2-Personal mit Weiterleitung zu einem Captive Portal). Für die Mitarbeiter-SSID validiert NPS die Anmeldedaten gegen das Active Directory und gibt dynamische VLAN-Zuweisungen zurück: AD-Gruppe 'Management' → VLAN 10 (Vollzugriff), 'FrontDesk' → VLAN 20 (PMS-Zugriff), 'Housekeeping' → VLAN 30 (nur Internet + Dienstplan-App). Integrieren Sie für Gäste das Captive Portal in die Guest WiFi-Plattform von Purple, um ein gebrandetes Login-Erlebnis zu bieten, First-Party-Daten (E-Mail, Marketing-Einwilligung) zu erfassen und Analysen zur Verweildauer und zu wiederkehrenden Besuchen zu erhalten. Das Zwei-SSID-Modell trennt den Datenverkehr von Personal und Gästen auf der Netzwerkschicht vollständig.
Übungsfragen
Q1. Ihre Organisation migriert 2.000 Windows-Laptops von einem gemeinsam genutzten PSK zu 802.1X mit PEAP-MSCHAPv2. Ihr Sicherheitsteam weist darauf hin, dass PEAP anfällig für das Abgreifen von Anmeldedaten über Rogue Access Points ist. Was ist der wichtigste Konfigurationsschritt, um dieses Risiko zu minimieren, und wie stellen Sie diesen im großen Stil bereit?
Hinweis: Überlegen Sie, was einen Client daran hindert, einem betrügerischen RADIUS-Server zu vertrauen, der ein selbstsigniertes Zertifikat vorlegt.
Musterlösung anzeigen
Der entscheidende Schritt ist die Durchsetzung einer strikten Serverzertifikatsvalidierung auf jedem Client-Gerät. Übertragen Sie mithilfe von Gruppenrichtlinienobjekten (GPO) ein WiFi-Profil auf alle 2.000 Laptops, das Folgendes festlegt: (1) das genaue Root-CA-Zertifikat, das das Zertifikat des RADIUS-Servers ausgestellt hat, (2) den erwarteten Servernamen (CN/SAN) und (3) dass der Client den Benutzer nicht auffordern darf, neuen Zertifikaten zu vertrauen. Dies stellt sicher, dass der Client den TLS-Handshake ablehnt und die Übermittlung von Anmeldedaten verweigert, selbst wenn ein Angreifer einen Rogue AP mit einem gefälschten Zertifikat bereitstellt. Ohne diese Konfiguration bietet PEAP keinen wirksamen Schutz vor Angriffen durch Rogue APs.
Q2. Der IT-Leiter eines Krankenhauses muss 300 medizinischen IoT-Geräten (Infusionspumpen, Überwachungsgeräte), die kein 802.1X unterstützen, Netzwerkzugriff gewähren. Diese Geräte befinden sich neben den Arbeitsstationen des Personals in derselben Wireless-Infrastruktur. Wie sollte die RADIUS-Infrastruktur mit diesen Geräten umgehen und welche Netzwerkkontrollen müssen eingerichtet werden?
Hinweis: Denken Sie an die Authentifizierungsmethode, die für bildschirmlose Geräte zur Verfügung steht, und wie Sie deren inhärente Schwäche ausgleichen können.
Musterlösung anzeigen
Konfigurieren Sie MAC Authentication Bypass (MAB) auf dem RADIUS-Server für diese spezifischen Geräte. Registrieren Sie die MAC-Adresse jedes Geräts in einer dedizierten Active Directory-Gruppe oder RADIUS-Datenbank. Da MAC-Adressen leicht gefälscht werden können, muss der RADIUS-Server die dynamische VLAN-Zuweisung nutzen, um alle über MAB authentifizierten Geräte in ein dediziertes, stark eingeschränktes VLAN (z. B. VLAN 30 - IoT) zu verschieben. Dieses VLAN sollte durch eine Firewall so geschützt werden, dass die Kommunikation nur mit bestimmten IP-Adressen medizinischer Server zulässig ist und der gesamte andere Datenverkehr, einschließlich des Internetzugangs und der lateralen Bewegung zu den VLANs des Personals, blockiert wird. Die Arbeitsstationen des Personals authentifizieren sich über 802.1X und befinden sich in einem separaten VLAN. Diese Architektur erfüllt die HIPAA-Anforderungen zur Netzwerksegmentierung für ePHI-nahe Geräte.
Q3. Sie sind der Netzwerkarchitekt für eine Restaurantkette mit 50 Standorten. Die Authentifizierung funktioniert an 49 Standorten ordnungsgemäß über Cloud RADIUS, aber ein bestimmter Standort meldet, dass sich alle Geräte nicht authentifizieren können. Das Cloud-RADIUS-Verwaltungsportal zeigt an, dass von diesem Standort null Authentifizierungsanfragen eingehen. Wie sieht Ihr Diagnoseansatz aus?
Hinweis: Wenn der RADIUS-Server überhaupt keine Anfragen erhält, liegt das Problem im Kommunikationspfad zwischen dem Authenticator und dem Server – nicht in der Authentifizierungslogik selbst.
Musterlösung anzeigen
Da der RADIUS-Server null Anfragen von diesem Standort erhält, liegt der Fehler zwischen den Access Points und dem Cloud-RADIUS-Server. Diagnoseschritte in dieser Reihenfolge: (1) Überprüfen Sie die IP-Adresse und den Port (UDP 1812) des RADIUS-Servers, die auf den APs oder dem Wireless-Controller des Standorts konfiguriert sind – ein Tippfehler an dieser Stelle ist die häufigste Ursache. (2) Überprüfen Sie die lokalen Firewall- oder Router-Regeln an diesem Standort, um zu bestätigen, dass ausgehender UDP-1812-Datenverkehr zum IP-Bereich des Cloud-RADIUS-Servers zulässig ist. (3) Überprüfen Sie, ob das auf den APs konfigurierte Shared Secret mit dem im Cloud-RADIUS-Portal für diesen Standort konfigurierten Secret übereinstimmt – bei einer Diskrepanz verwirft der RADIUS-Server die Pakete stillschweigend. (4) Prüfen Sie, ob die Internetverbindung des Standorts funktioniert – Cloud RADIUS erfordert eine zuverlässige Internetverbindung. Eine Paketaufzeichnung auf dem AP oder dem vorgeschalteten Router bestätigt, ob RADIUS-Pakete gesendet und Antworten empfangen werden.
Weiterlesen in dieser Reihe
Per-Device PSK nach Anbieter: iPSK, DPSK, MPSK und PPSK im Vergleich (und WPA3-Unterstützung)
Ein umfassender Vergleich von Per-Device-PSK-Implementierungen bei Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet und Ubiquiti UniFi. Erfahren Sie, wie sich WPA3-SAE auf Per-Device-Key-Strategien auswirkt und wann Übergangsmodi im Vergleich zum Wechsel zu 802.1X eingesetzt werden sollten.
Captive Portal Authentifizierungsmethoden im Vergleich
Dieser maßgebliche technische Leitfaden bewertet die architektonischen, betrieblichen und Compliance-bezogenen Vor- und Nachteile von fünf zentralen Captive Portal Authentifizierungsmethoden. Er bietet Netzwerkarchitekten, IT-Leitern und Marketingmanagern die quantitativen Daten und Entscheidungsrahmen, die erforderlich sind, um die Reibung beim Onboarding von Gästen mit den Anforderungen an die Datenerfassung in Unternehmensstandorten abzuwägen.
Was ist MAC-Adressen-Authentifizierung? Wann man sie einsetzt und wann man sie vermeidet
Dieser maßgebliche technische Leitfaden behandelt die MAC-Adressen-Authentifizierung in Enterprise-WiFi-Umgebungen – wie die RADIUS-basierte MAC-Authentifizierung auf Layer 2 funktioniert, ihre inhärenten Sicherheitsrisiken (einschließlich MAC-Spoofing und den Auswirkungen der MAC-Randomisierung auf Betriebssystemebene) und die genauen betrieblichen Kontexte, in denen sie ein legitimes Tool zur Verwaltung von IoT- und Headless-Geräten bleibt. Er bietet praxisnahe Bereitstellungsrichtlinien für IT-Manager und Netzwerkarchitekten in den Bereichen Hotellerie, Einzelhandel, Gesundheitswesen und im öffentlichen Sektor, ergänzt durch praxisnahe Fallbeispiele, Entscheidungsmatrizen und Integrationskontexte für die Guest-WiFi- und Analytics-Plattform von Purple.