So richten Sie einen RADIUS-Server für die WiFi-Authentifizierung ein
Dieser maßgebliche Leitfaden bietet IT-Leitern und Netzwerkarchitekten ein umfassendes Konzept für die Bereitstellung eines RADIUS-Servers zur WiFi-Authentifizierung in Unternehmen. Er behandelt die architektonischen Vor- und Nachteile von On-Premise- und Cloud-basierten Bereitstellungen, die Auswahl von EAP-Methoden, die Active Directory-Integration und die dynamische VLAN-Zuweisung. Betreiber von Standorten und IT-Teams finden hier praxisnahe Implementierungsschritte, reale Fallstudien und Strategien zur Risikominderung, um noch in diesem Quartal von einer unsicheren PSK-Umgebung auf eine robuste 802.1X-Infrastruktur umzustellen.
Diesen Leitfaden anhören
Podcast-Transkript ansehen
📚 Teil unserer Kernserie: Enterprise WiFi Security Guide →
Executive Summary
In Unternehmensumgebungen – ob auf einem weitläufigen Universitätscampus, in einem stark besuchten Stadion oder in einer verteilten Einzelhandelskette – ist die Nutzung eines Pre-Shared Key (PSK) für den WiFi-Zugang ein erhebliches Sicherheitsrisiko. Ein einziger kompromittierter Anmeldedaten-Satz gefährdet das gesamte Netzwerk. Um den Zugriff zu entziehen, muss das Passwort für jedes einzelne Gerät im Unternehmen geändert werden. 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 Vor- und Nachteile von On-Premise- und Cloud-basierten Bereitstellungen, die Konfiguration von EAP-Methoden (Extensible Authentication Protocol) und die Integration in Verzeichnisdienste wie Active Directory. Zudem zeigen wir, wie sich eine robuste Authentifizierungsebene in Gäste-WiFi -Lösungen integrieren lässt. So bieten Sie Besuchern nahtlosen Zugang und erfassen gleichzeitig WiFi Analytics , die Ihr Netzwerk in ein wertvolles Business-Intelligence-Tool verwandeln.
Technischer Deep-Dive
Die 802.1X-Architektur
Der Standard IEEE 802.1X definiert die portbasierte Netzwerkzugriffskontrolle (PNAC). Im drahtlosen Kontext arbeiten drei Hauptrollen zusammen:
| Rolle | Komponente | Verantwortung |
|---|---|---|
| Supplicant | Client-Gerät (Laptop, Smartphone) | Präsentiert Anmeldedaten, um Netzwerkzugriff anzufordern |
| Authenticator | WiFi-Access-Point oder Controller | Erzwingt die Zugriffskontrolle; leitet EAP-Nachrichten weiter |
| Authentifizierungsserver | RADIUS-Server | Validiert Anmeldedaten; gibt Annahme/Ablehnung 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 gleicht die Anmeldedaten mit einer Backend-Datenbank ab – typischerweise LDAP oder Active Directory – und gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Bei Annahme 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 genutzten Methoden in Unternehmen sind:
EAP-TLS (Transport Layer Security) ist der Goldstandard. Es 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 Authentifizierungsaustausch abfängt, gibt es keine Anmeldedaten, die er extrahieren könnte. 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 Zertifikate auf den Endgeräten zu verteilen.
PEAP-MSCHAPv2 (Protected EAP) ist in der Praxis die am weitesten verbreitete Methode. Sie nutzt ein serverseitiges Zertifikat, um einen verschlüsselten TLS-Tunnel aufzubauen, in dem sich der Client mit Benutzername und Passwort authentifiziert. Dies ist deutlich einfacher bereitzustellen als EAP-TLS, da nur ein einziges Zertifikat – das des Servers – verwaltet werden muss. Es gibt jedoch eine kritische Einschränkung: 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 manipulierte Access Points (Rogue APs).
Wichtiger Sicherheitshinweis: Wenn Sie keine strikte Zertifikatsvalidierung auf den Client-Geräten erzwingen, heben Sie die Sicherheitsvorteile von PEAP-MSCHAPv2 praktisch auf. Ein Angreifer kann einen manipulierten AP aufstellen, ein gefälschtes Zertifikat präsentieren und Benutzerdaten im Klartext abfangen. Dies ist kein theoretisches Risiko, sondern ein gut dokumentierter Angriffsvektor, der in der Praxis bereits ausgenutzt wurde.
Implementierungsleitfaden
Schritt 1: Architekturentscheidung – On-Premise vs. Cloud-RADIUS
Die erste Entscheidung betrifft den Hosting-Ort der RADIUS-Infrastruktur. Dies ist in erster Linie eine Betriebs- und Kostenfrage, keine Sicherheitsfrage – beide Modelle können sicher bereitgestellt werden.
On-Premise-RADIUS (z. B. Microsoft NPS, FreeRADIUS, Cisco ISE) eignet sich für Organisationen mit eigener IT-Abteilung, bestehender On-Premise-Verzeichnisinfrastruktur und strengen Anforderungen an Datensouveränität oder Compliance. Die Authentifizierung hängt nicht von einer Internetverbindung ab, was in Umgebungen, in denen die Internet-Verfügbarkeit nicht garantiert werden kann, ein entscheidender Vorteil ist.
Cloud-RADIUS wird zunehmend zum bevorzugten Modell für verteilte Umgebungen – Einzelhandelsketten , Gastronomie- und Hotelgruppen sowie 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: Installieren und Konfigurieren 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 der Benutzer lesen kann.
- Erstellen Sie für jeden Access Point oder Wireless Controller einen RADIUS-Client-Eintrag und geben Sie die IP-Adresse des APs sowie ein starkes, eindeutiges Shared Secret an.
- 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, um Anforderungen lokal zu verarbeiten.
Für FreeRADIUS auf 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 die 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 mit einer Mischung aus alphanumerischen Zeichen und Sonderzeichen. Nutzen Sie ein eindeutiges Secret pro Standort oder AP-Gruppe.
- Konfigurieren Sie die SSID so, dass sie den Sicherheitsmodus WPA2-Enterprise oder WPA3-Enterprise mit 802.1X-Schlüsselverwaltung verwendet.
- Konfigurieren Sie einen sekundären RADIUS-Server für das Failover.
Schritt 4: Verzeichnisintegration
Für die On-Premise-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-Anbindung verwendeten Dienstkonten nur die minimal erforderlichen Berechtigungen besitzen. 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 im Hintergrund auf verwaltete Geräte zu übertragen. 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 interne Authentifizierungsprotokoll.
Stellen Sie für nicht verwaltete BYOD-Geräte klare Anleitungen zur Selbstregistrierung bereit, idealerweise über ein Network-Access-Control-Portal (NAC).
Schritt 6: Dynamische VLAN-Zuweisung implementieren
Konfigurieren Sie den RADIUS-Server so, dass er Attribute zur VLAN-Zuweisung in der Access-Accept-Antwort zurückgibt:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id=<VLAN-ID>
Der Access Point liest diese Attribute aus und weist den authentifizierten Client dem angegebenen VLAN zu – es ist keine manuelle Neukonfiguration erforderlich, wenn Benutzer ihre Rolle oder ihren Standort wechseln.
Best Practices
Redundancy is non-negotiable. Deploy a minimum of two RADIUS servers (primary and secondary) and configure all access points to fail over automatically. For on-premise deployments, consider placing the secondary server in a different physical location or availability zone. A RADIUS outage means nobody can authenticate, which is a complete network outage for 802.1X-protected SSIDs.
Überwachen Sie den Zertifikatsablauf proaktiv. Das Ablaufen eines RADIUS-Serverzertifikats ist eine der häufigsten Ursachen für plötzliche, flächendeckende Authentifizierungsfehler. Richten Sie ein Monitoring ein, das Administratoren mindestens 30 Tage vor dem Ablauf warnt. Dies gilt sowohl für das Serverzertifikat als auch für alle Intermediate-CA-Zertifikate in der Kette.
Behandeln Sie das Shared Secret als kritische Anmeldedaten. Das Shared Secret zwischen dem AP und dem RADIUS-Server verschlüsselt die RADIUS-Pakete. Verwenden Sie eindeutige Secrets pro Standort oder AP-Gruppe, speichern Sie diese in einem Secrets Manager und rotieren Sie sie regelmäßig. Weitere Empfehlungen zur allgemeinen Netzwerksicherheit finden Sie in unserem Leitfaden Schützen Sie Ihr Netzwerk mit starkem DNS und Sicherheit .
Orientieren Sie sich an Compliance-Frameworks. In Umgebungen, die dem PCI-DSS unterliegen (z. B. Zahlungsnetzwerke im Einzelhandel), unterstützt die 802.1X-Authentifizierung direkt die Anforderungen an die Netzwerkzugriffskontrolle und die Audit-Protokollierung. Zur Einhaltung der GDPR bieten RADIUS-Accounting-Protokolle (Port 1813) einen detaillierten Audit-Trail darüber, wer wann von wo aus auf das Netzwerk zugegriffen hat – wertvoll für die Reaktion auf Vorfälle. In Healthcare -Umgebungen unterstützt die Netzwerksegmentierung über die dynamische VLAN-Zuweisung die HIPAA-Anforderungen zum Schutz elektronischer geschützter Gesundheitsdaten (ePHI).
Fehlerbehebung & Risikominderung
| Fehlermodus | Symptom | Lösung |
|---|---|---|
| Zertifikatsablauf | Plötzliche massenhafte Authentifizierungsfehler | 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 |
| Falsches 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 eigentlichen 802.1X-Konfigurationsprozess bietet der Leitfaden So konfigurieren Sie die 802.1X-WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung detaillierte, herstellerspezifische Konfigurationsanleitungen.
ROI & geschäftlicher Nutzen
Der Übergang von PSK zu RADIUS-gestütztem 802.1X erfordert eine Anfangsinvestition in die Konfiguration und potenziell in Lizenzen für Cloud-Lösungen oder Hardware für On-Premise-Bereitstellungen. Die ROI-Rechnung ist einfach:
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 in Sekundenschnelle über das Verzeichnis deaktiviert werden kann.
Betriebliche Effizienz: Die dynamische VLAN-Zuweisung macht eine manuelle Netzwerkkonfiguration bei Rollenwechseln von Mitarbeitern überflüssig. Das Onboarding eines neuen Mitarbeiters bedeutet lediglich, ihn der richtigen AD-Gruppe hinzuzufügen – der Netzwerkzugriff erfolgt automatisch.
Compliance-Status: Für Organisationen, die PCI-DSS, ISO 27001 oder Cyber Essentials Plus unterliegen, ist 802.1X eine direkte Kontrollmaßnahme, die Auditoren erwarten. Die Bereitstellung 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 und Filialen schafft die Integration von RADIUS für die Mitarbeiter-Authentifizierung mit der Gäste-WiFi -Plattform von Purple für den Besucherzugang ein einheitliches, gestaffeltes 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 Marketingausgaben und Entscheidungen zum Standortbetrieb einfließen.
Weitere Informationen finden Sie unter Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo für eine Implementierungsanleitung in portugiesischer Sprache und unter 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 zentralisierte 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 die 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-Datenverkehr, bis die Authentifizierung erfolgreich war.
Der übergeordnete Framework-Standard, der definiert, wie Supplicant, Authenticator und Authentifizierungsserver 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) sicherzustellen, ist die häufigste Ursache für Bereitstellungsprobleme.
Authenticator
Das Netzwerkgerät – typischerweise ein WiFi-Access-Point oder Wireless Controller –, das als Vermittler zwischen dem Supplicant und dem RADIUS-Server fungiert und die Zugriffskontrolle basierend auf dem Authentifizierungsergebnis erzwingt.
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 Authentifizierungsserver bereitstellt.
EAP is the 'language' spoken between the client and the RADIUS server. The choice of EAP method (EAP-TLS vs PEAP) determines the security strength and deployment complexity of the authentication system.
PEAP (Protected EAP)
Eine EAP-Methode, die zuerst einen TLS-Tunnel unter Verwendung des Serverzertifikats aufbaut und dann eine sekundäre Authentifizierung (typischerweise MSCHAPv2 mit Benutzername/Passwort) innerhalb dieses verschlüsselten Tunnels durchführt.
Die aufgrund ihres ausgewogenen Verhältnisses von Sicherheit und einfacher Bereitstellung am weitesten verbreitete WiFi-Authentifizierungsmethode in Unternehmen. 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 einfügt und den AP anweist, den authentifizierten Client in ein bestimmtes VLAN zu verschieben.
Ermöglicht es einer einzigen SSID, mehrere Benutzergruppen mit unterschiedlichen Sicherheitsanforderungen zu bedienen. Macht die Ausstrahlung mehrerer SSIDs für verschiedene Benutzergruppen überflüssig, was den HF-Overhead reduziert und die Benutzererfahrung vereinfacht.
Shared Secret
Eine vorkonfigurierte Zeichenfolge, die nur dem Authenticator (AP) und dem RADIUS-Server bekannt ist. Sie wird verwendet, um RADIUS-Pakete zu signieren und zu verschlüsseln, wodurch die Integrität und Authentizität der Kommunikation sichergestellt wird.
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 ohne Unterstützung für 802.1X-Supplicants den Netzwerkzugriff zu ermöglichen.
Wird für bildschirmlos betriebene 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 verwenden sie in allen Filialen einen einzigen PSK, der häufig an unbefugte Mitarbeiter und externe Dienstleister weitergegeben wird. Sie nutzen Azure AD für das Identitätsmanagement und haben kein eigenes IT-Personal an den Filialstandorten.
Stellen Sie eine Cloud-RADIUS-Lösung bereit, die direkt in Azure AD integrated 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, wobei 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 Backoffice-Zugriff), die Gruppe „Contractors“ erhält VLAN 20 (nur Internet). Wenn der Vertrag eines Dienstleisters endet, entzieht das Entfernen aus der Azure AD-Gruppe sofort den WiFi-Zugriff an allen 500 Standorten gleichzeitig – eine Änderung des PSK ist nicht erforderlich.
Ein Innenstadthotel mit 400 Zimmern muss sicheres WiFi sowohl für Mitarbeiter (Rezeption, Housekeeping, Management) als auch für Gäste bereitstellen. Mitarbeiter benötigen 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 mit 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 Gäste-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 hält den Datenverkehr von Mitarbeitern und Gästen auf der Netzwerkeschnittstelle vollständig getrennt.
Ü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 Abfangen von Anmeldedaten über manipulierte Access Points (Rogue APs) ist. Was ist der wichtigste Konfigurationsschritt, um dieses Risiko zu mindern, und wie stellen Sie diesen im großen Stil bereit?
Hinweis: Überlegen Sie, was einen Client daran hindert, einem gefälschten RADIUS-Server zu vertrauen, der ein selbstsigniertes Zertifikat präsentiert.
Musterlösung anzeigen
Der entscheidende Schritt besteht darin, eine strikte Serverzertifikatsvalidierung auf jedem Client-Gerät zu erzwingen. Ü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 betreibt. Ohne diese Konfiguration bietet PEAP keinen wirksamen Schutz vor Angriffen durch manipulierte Access Points.
Q2. Der IT-Leiter eines Krankenhauses muss Netzwerkzugriff für 300 medizinische IoT-Geräte (Infusionspumpen, Überwachungsgeräte) bereitstellen, die kein 802.1X unterstützen. Diese Geräte befinden sich neben den Arbeitsstationen der Mitarbeiter auf 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 verfügbar ist, 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 nur die Kommunikation mit bestimmten IP-Adressen medizinischer Server erlaubt ist und der gesamte andere Datenverkehr, einschließlich des Internetzugangs und der lateralen Bewegung zu den Mitarbeiter-VLANs, blockiert wird. Die Arbeitsstationen der Mitarbeiter authentifizieren sich über 802.1X und werden in einem separaten VLAN platziert. Diese Architektur erfüllt die HIPAA-Anforderungen zur Netzwerksegmentierung für Geräte in der Nähe von ePHI.
Q3. Sie are the network architect for a 50-venue restaurant chain. Authentication is working correctly at 49 venues using Cloud RADIUS, but one specific venue reports that all devices fail to authenticate. The Cloud RADIUS management portal shows zero authentication requests arriving from that venue. What is your diagnostic approach?
Hinweis: Wenn der RADIUS-Server überhaupt keine Anfragen erhält, liegt das Problem auf dem Kommunikationsweg 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 der Reihe nach: (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 hier ist die häufigste Ursache. (2) Überprüfen Sie die lokalen Firewall- oder Router-Regeln an diesem Standort, um sicherzustellen, dass ausgehender UDP-1812-Datenverkehr zum IP-Bereich des Cloud-RADIUS-Servers zugelassen 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 Abweichung 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
Konfigurieren von RADIUS-Authentifizierung für Gäste- und Mitarbeiter-WiFi-Netzwerke
Dieses technische Referenzhandbuch beschreibt die Architektur, Konfiguration und Bereitstellung der RADIUS-Authentifizierung für WiFi-Netzwerke von Unternehmen für Gäste und Mitarbeiter. Es bietet Netzwerkarchitekten und IT-Managern die genauen Protokolle, Sicherheitsstandards und Fehlerbehebungsmethoden, die für den Aufbau sicherer, skalierbarer drahtloser Zugriffskontrollsysteme erforderlich sind.
Passpoint und OpenRoaming: Das vollständige Handbuch
Dieses technische Referenzhandbuch bietet eine umfassende Analyse der Passpoint (Hotspot 2.0) und WBA OpenRoaming Frameworks in Enterprise WiFi Netzwerken. Es beschreibt detailliert die zugrundeliegenden Authentifizierungsprotokolle, Architekturkomponenten und Bereitstellungsstrategien, die für den Aufbau einer sicheren, reibungslosen Gastkonnektivität erforderlich sind. Netzwerkarchitekten und IT-Leiter erfahren, wie sie diese Standards entwerfen, implementieren und Fehler beheben, um manuelle Anmeldebarrieren zu beseitigen und gleichzeitig die Sicherheit auf Enterprise-Niveau aufrechtzuerhalten.
Implementierung von SCEP für sichere BYOD- und Netzwerkanmeldung im Hochschulbereich
Dieser technische Leitfaden bietet Netzwerkarchitekten und IT-Managern ein herstellerunabhängiges Konzept für die Bereitstellung von SCEP-basierten Zertifikatsanmeldungen zur Sicherung von Campusnetzwerken an Hochschulen. Er beschreibt im Detail die Migration von passwortbasiertem PEAP zu 802.1X EAP-TLS, die Automatisierung des BYOD-Onboardings und die Durchsetzung einer robusten VLAN-Segmentierung.