Zum Hauptinhalt springen

Einrichten eines RADIUS-Servers für die WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung für 802.1X

Konfigurieren Sie FreeRADIUS, Windows Server NPS und Cloud RADIUS für die 802.1X WiFi-Authentifizierung in Unternehmen. Eine Schritt-für-Schritt-Anleitung zu Shared Secrets, EAP-TLS-Zertifikaten, dynamischer VLAN-Zuweisung und der Integration von Microsoft Entra ID.

Von Iain JewittVeröffentlicht
📖 8 Min. Lesezeit1,531 Wörter2 ausgearbeitete Beispiele3 Übungsfragen5 Schlüsseldefinitionen

Video overview

Diesen Leitfaden anhören

Podcast-Transkript ansehen
Willkommen zum Technical Briefing von Purple. Heute befassen wir uns mit einer kritischen Infrastrukturentscheidung für jeden IT-Leiter im Unternehmen: der Einrichtung eines RADIUS-Servers für die WiFi-Authentifizierung. Wenn Sie ein Großprojekt verwalten - sei es eine Hotelkette, ein Einzelhandelsnetzwerk oder ein weitläufiger Universitätscampus - ist die Nutzung eines einfachen Pre-Shared Keys ein erhebliches Sicherheitsrisiko. Wir benötigen 802.1X, und das bedeutet, wir benötigen RADIUS. Beginnen wir mit dem Kontext. RADIUS, oder Remote Authentication Dial-In User Service, fungiert als Torwächter für Ihr Netzwerk. Wenn ein Gerät versucht, sich mit einem WiFi-Access-Point zu verbinden, fungiert der Access-Point als Authentifikator und leitet die Anmeldedaten an den RADIUS-Server weiter. Der Server gleicht diese Anmeldedaten mit einem Verzeichnis ab - wie dem Active Directory oder einer LDAP-Datenbank - und gibt dann eine Bestätigungs- oder Ablehnungsnachricht zurück. Er ist das Fundament der WiFi-Sicherheit in Unternehmen und der Mechanismus, mit dem Sie granulare Zugriffsrichtlinien in großem Umfang durchsetzen können. Kommen wir nun zu den technischen Details. Die erste große Architekturentscheidung, vor der Sie stehen, ist die Wahl zwischen einem On-Premise-RADIUS-Server und einer Cloud-gehosteten Lösung. Historisch gesehen waren On-Premise-Lösungen wie der Network Policy Server von Microsoft (NPS) oder das Open-Source-System FreeRADIUS der Standard. Sie bieten die vollständige Kontrolle über die Infrastruktur und benötigen für die Authentifizierung keine externe Internetverbindung. Sie erfordern jedoch dedizierte Hardware, laufende Wartung und die manuelle Konfiguration von Redundanz. Wenn Sie über ein einziges Rechenzentrum und ein gut ausgestattetes IT-Team verfügen, ist dies ein absolut solider Ansatz. Auf der anderen Seite erfreuen sich Cloud-RADIUS-Lösungen immer größerer Beliebtheit, insbesondere in verteilten Umgebungen wie Einzelhandelsketten oder Hotelanlagen. Cloud RADIUS übernimmt das Hardware-Management vollständig, bietet integrierte Hochverfügbarkeit und lässt sich nahtlos in Cloud-Identitätsanbieter wie Azure Active Directory oder Okta integrieren. Der Nachteil ist, dass die Authentifizierung eine zuverlässige Internetverbindung erfordert und laufende Abonnementkosten anfallen. Für einen Betreiber mit fünfzig oder einhundert Standorten werden die betrieblichen Einsparungen, die sich daraus ergeben, dass an keinem Standort On-Premise-Server bereitgestellt und gewartet werden müssen, diese Kosten mit Sicherheit aufwiegen. Bei der Bereitstellung von RADIUS ist das Extensible Authentication Protocol - EAP - die entscheidende Komponente. Es definiert, wie Client und Server die Authentifizierung verhandeln und durchführen. EAP-TLS ist der Goldstandard für Sicherheit, da digitale Zertifikate sowohl auf dem Client als auch auf dem Server verwendet werden, wodurch Passwörter komplett überflüssig werden. Das bedeutet: Selbst wenn ein Angreifer den Authentifizierungsprozess abfängt, gibt es keine Anmeldedaten, die gestohlen werden könnten. Die Bereitstellung von Client-Zertifikaten kann jedoch administrativ aufwendig sein. Sie benötigen eine Public-Key-Infrastruktur und eine MDM-Lösung, um die Zertifikate auf jedes Gerät zu übertragen. PEAP-MSCHAPv2 ist die am häufigsten genutzte Alternative. Es verwendet ein serverseitiges Zertifikat, um einen verschlüsselten TLS-Tunnel aufzubauen, in dem sich der Benutzer mit einem Benutzernamen und einem Passwort authentifiziert. Dies ist erheblich einfacher bereitzustellen als EAP-TLS, da Sie nur ein einziges Zertifikat verwalten müssen - das des Servers. Es gibt jedoch einen kritischen Punkt: Wenn Clients nicht strikt so konfiguriert sind, dass sie das Zertifikat des Servers validieren, sind sie anfällig für gefälschte Access Points. Ein Angreifer kann einen gefälschten Access Point einrichten, ein gefälschtes Zertifikat vorlegen und Anmeldedaten abfangen. Dies ist kein theoretischer Angriff. Es handelt sich um eine gut dokumentierte, reale Bedrohung. Lassen Sie uns über Implementierungsempfehlungen und Fallstricke sprechen. Die erste Empfehlung besteht darin, eine strikte Zertifikatsvalidierung auf jedem Client-Gerät zu erzwingen. Verwenden Sie Group Policy Objects für Windows-Geräte und MDM-Profile - sei es Intune, Jamf oder eine andere Lösung - für macOS und mobile Geräte. Das Profil muss genau festlegen, welcher Certificate Authority vertraut werden soll und wie der erwartete Servername lautet. Überlassen Sie diese Konfiguration nicht dem Endbenutzer zur manuellen Einrichtung. Die zweite Empfehlung ist die Implementierung einer dynamischen VLAN-Zuweisung. Anstatt alle authentifizierten Benutzer in dasselbe flache Netzwerk zu leiten, konfigurieren Sie den RADIUS-Server so, dass er den Access Point anweist, den Benutzer basierend auf seiner Gruppenmitgliedschaft im Verzeichnis in ein bestimmtes VLAN einzustufen. Dies ist unerlässlich, um Unternehmensgeräte von BYOD- oder Gastgeräten zu segmentieren. Ein Mitarbeiter im Finanzteam sollte sich in einem anderen Netzwerksegment befinden als ein Auftragnehmer, der für einen Tag zu Besuch ist. Die dritte Empfehlung betrifft den Gastzugang. Für Veranstaltungsorte, die Besuchern WiFi anbieten müssen - Hotels, Einzelhandelsgeschäfte, Konferenzzentren -, ist die Integration Ihrer RADIUS-Infrastruktur mit einer Captive Portal-Lösung wie der Guest WiFi-Plattform von Purple eine leistungsstarke Kombination. Mitarbeiter und Unternehmensgeräte authentifizieren sich geräuschlos über 802.1X, während Gäste zur Authentifizierung auf ein gebrandetes Portal geleitet werden. Die Plattform von Purple erfasst dann First-Party-Daten und liefert Analysen zum Besucherverhalten, wodurch sich Ihr Netzwerk von einem Kostenfaktor in ein Business-Intelligence-Asset verwandelt. Nun zu einer kurzen Fragerunde. Erste Frage: Benötige ich einen dedizierten Server für RADIUS? Für On-Premise-Bereitstellungen lautet die Antwort: Ja, es wird dringend empfohlen, diesen auf einer dedizierten virtuellen Maschine auszuführen, anstatt Ressourcen mit einem Domain-Controller zu teilen. Die Authentifizierung ist ein latenzempfindlicher Prozess, und Ressourcenkonflikte können zu sporadischen Ausfällen führen, die nur sehr schwer zu diagnostizieren sind. Zweite Frage: Kann RADIUS die Authentifizierung für bildschirmlosen Geräte wie Drucker oder IoT-Sensoren übernehmen? Ja, über MAC Authentication Bypass, auch bekannt als MAB. Dadurch können Geräte ohne 802.1X-Funktionen basierend auf ihrer MAC-Adresse authentifiziert werden. Da MAC-Adressen jedoch leicht manipuliert werden können, sollten über MAB authentifizierte Geräte immer in einem streng eingeschränkten VLAN platziert werden. Dritte Frage: Wie richte ich eine RADIUS-Server-Redundanz ein? Stellen Sie immer mindestens zwei RADIUS-Server bereit - einen primären und einen sekundären. Konfigurieren Sie alle Access Points so, dass sie auf den sekundären Server ausweichen, falls der primäre nicht erreichbar ist. Bei Cloud RADIUS ist diese Redundanz in der Regel bereits integriert und wird vom Anbieter verwaltet. Zusammenfassend die wichtigsten Kernpunkte unseres heutigen Briefings. Pre-shared Keys sind für Enterprise WiFi ungeeignet. Implementieren Sie 802.1X. Wählen Sie Ihr Bereitstellungsmodell - On-Premise oder Cloud - basierend auf Ihren IT-Ressourcen, der Anzahl der zu verwaltenden Standorte und Ihrer bestehenden Identitätsinfrastruktur. Wenn Ihr Unternehmen verteilt arbeitet und auf Cloud-First setzt, ist Cloud RADIUS fast immer die richtige Wahl. Erzwingen Sie eine strenge Zertifikatsvalidierung auf den Clients. Dies ist nicht verhandelbar. Nutzen Sie die dynamische VLAN-Zuweisung, um Ihr Netzwerk zu segmentieren. Und schließlich sollten Sie darüber nachdenken, wie sich Ihre Authentifizierungsinfrastruktur in umfassendere Plattformen integrieren lässt, um einen geschäftlichen Mehrwert zu bieten, der über die reine Zugriffskontrolle hinausgeht. Für weitere Informationen empfehlen wir Ihnen die Leitfäden von Purple zur Konfiguration der 802.1X WiFi-Authentifizierung und zur Absicherung Ihres Netzwerks mit strengen DNS-Richtlinien. Vielen Dank fürs Zuhören.

Executive Summary

Einrichten eines RADIUS-Servers für die WiFi-Authentifizierung: Eine Schritt-für-Schritt-Anleitung für 802.1X

Drahtlose Unternehmensnetzwerke erfordern eine zentrale Identitätsverwaltung, rollenbasierte Segmentierung und starken kryptografischen Schutz. Die Verwendung gemeinsamer Pre-Shared Keys (PSKs) setzt Unternehmen dem Risiko von Anmeldedatenlecks, unbefugtem Gerätezugriff und administrativen Problemen aus, sobald ein Mitarbeiter das Unternehmen verlässt.

Die Einrichtung eines RADIUS-Servers (Remote Authentication Dial-In User Service) ermöglicht die IEEE 802.1X Enterprise-Authentifizierung. Jedes verbundene Gerät und jeder Benutzer authentifiziert sich individuell gegenüber einem zentralen Verzeichnis - wie Microsoft Entra ID, Google Workspace, Okta oder dem lokalen Active Directory.

Dieser technische Leitfaden bietet Schritt-für-Schritt-Anleitungen zur Konfiguration eines RADIUS-Servers für Enterprise WiFi. Wir behandeln die Konfiguration von Linux FreeRADIUS, die Einrichtung des Windows Server Network Policy Server (NPS), moderne Cloud-RADIUS-Architekturen, dynamische VLAN-Zuweisung und die Sicherheits-Härtung gegen BlastRADIUS.

Übersicht über die 802.1X & RADIUS-Architektur

Das IEEE 802.1X-Framework unterteilt den Netzwerkzugriff in drei verschiedene Instanzen:

  1. Der Supplicant: Das Client-Endgerät (Laptop, Smartphone oder Tablet), auf dem eine 802.1X-Client-Software ausgeführt wird und das die Identitätsdaten bereitstellt.
  2. Der Authenticator: Der Wireless Access Point (AP) oder Wireless LAN Controller (WLC), der den physischen Zugriff auf das Netzwerk steuert und Authentifizierungsnachrichten weiterleitet.
  3. Der Authentication Server: Der RADIUS-Server, der die Anmeldedaten mit einem Identitätsverzeichnis abgleicht und Netzwerkautorisierungsrichtlinien zurückgibt.
+---------------+        EAP over LAN (EAPoL)        +-------------------+
|  Supplicant   | <================================> |   Authenticator   |
| (Client-Gerät)|                                    | (AP / Controller) |
+---------------+                                    +-------------------+
                                                               ||
                                                               || RADIUS-Protokoll
                                                               || (UDP 1812 / TCP 2083)
                                                               \/
                                                     +-------------------+
                                                     |   RADIUS-Server   |
                                                     |  (FreeRADIUS/NPS) |
                                                     +-------------------+
                                                               ||
                                                               || Identitätsprüfung
                                                               \/
                                                     +-------------------+
                                                     | Identity Provider |
                                                     | (Entra ID / LDAP) |
                                                     +-------------------+

RADIUS-Kommunikationsfluss

  1. Assoziierung: Der Client assoziiert sich mit der Enterprise SSID (WPA2-Enterprise oder WPA3-Enterprise).
  2. EAP-Initiierung: Der AP blockiert den gesamten Datenverkehr und sendet einen EAP-Request/Identity-Frame an den Client.
  3. Identitätsantwort: Der Client antwortet mit einem EAP-Response/Identity-Frame.
  4. RADIUS-Kapselung: Der AP kapselt die EAP-Nutzlast in ein RADIUS Access-Request-Paket und leitet es an den RADIUS-Server weiter.
  5. EAP-Aushandlung: Der Client und der RADIUS-Server handeln die kryptografische Authentifizierungsmethode (wie EAP-TLS oder PEAP) aus.
  6. Autorisierung & Access-Accept: Nach erfolgreicher Validierung stellt der RADIUS-Server ein RADIUS Access-Accept-Paket aus, das den Pairwise Master Key (PMK) und optionale Attribute für die dynamische VLAN-Zuweisung enthält.
  7. Portfreigabe: Der AP gibt den virtuellen Port frei und initiiert den 4-Wege-Handshake, um den drahtlosen Datenverkehr über die Luft zu verschlüsseln.

Für tiefere architektonische Konzepte lesen Sie unseren Enterprise WiFi Security Guide und Captive Portal Guide.

Schritt-für-Schritt-Einrichtung: FreeRADIUS auf Linux

FreeRADIUS ist der weltweite Open-Source-Standard für RADIUS-Suites. Unten finden Sie die Konfigurationsreihenfolge für Ubuntu 24.04 LTS / Debian 12.

Schritt 1: FreeRADIUS-Pakete installieren

sudo apt update
sudo apt install -y freeradius freeradius-utils freeradius-ldap ssl-cert

Schritt 2: Network Access Server (NAS) Clients definieren

Bearbeiten Sie /etc/freeradius/3.0/clients.conf, um Ihre drahtlosen Access Points zu autorisieren und ein Shared Secret zu konfigurieren:

client enterprise_wlan {
  ipaddr: 192.168.10.0/24
  secret: Str0ngSh@redSecr3t2026!
  shortname: branch-aps
  nas_type: other
  require_message_authenticator: yes
}

Hinweis: Erzwingen Sie immer RFC 2869 Message-Authenticator-Attribute, um sich gegen BlastRADIUS-Fälschungsangriffe zu schützen.

Schritt 3: EAP-Authentifizierungsmodule konfigurieren

Öffnen Sie /etc/freeradius/3.0/mods-available/eap und konfigurieren Sie die Standard-EAP-Methode:

eap {
  default_eap_type: tls
  timer_expire: 60
  ignore_unknown_eap_types: no
  cisco_accounting_username_bug: no
  max_sessions: 4096

  tls-config tls-common {
    certdir: ${confdir}/certs
    cadir: ${confdir}/certs
    private_key_file: ${certdir}/radius-server.key
    certificate_file: ${certdir}/radius-server.crt
    ca_file: ${cadir}/ca.crt
    cipher_list: HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH
    tls_min_version: 1.2
  }
}

Schritt 4: Im Debug-Modus testen

Bevor Sie den Dienst als Systemdienst ausführen, stoppen Sie den Daemon und starten Sie ihn im Vordergrund-Debug-Modus:

sudo systemctl stop freeradius
sudo freeradius -X

Testen Sie die lokale Authentifizierung mit radtest:

radtest testuser Password123 127.0.0.1 0 testing123

Eine erfolgreiche Antwort gibt Received Access-Accept Id 1 zurück.

Schritt-für-Schritt-Einrichtung: Windows Server NPS

Microsoft Network Policy Server (NPS) ist die integrierte RADIUS-Server-Rolle für Windows Server-Umgebungen, die mit Active Directory Domain Services (AD DS) verbunden sind.

+-------------------------------------------------------------------------+
|                  Windows Server Network Policy Server                   |
|                                                                         |
|  [RADIUS-Clients (AP / WLC)] ---> [Verbindungsanforderungsrichtlinien]   |
|                                                  |                      |
|                                                  v                      |
|  [Active Directory DS / PKI] <--- [Netzwerkrichtlinien (VLAN / EAP-TLS)]|
+-------------------------------------------------------------------------+

Schritt 1: Netzwerkrichtlinien- und Zugriffsdienste installieren

Öffnen Sie die PowerShell als Administrator:

Install-WindowsFeature NPAS -IncludeManagementTools
Register-ActiveDirectoryServer -Server nps01.corp.local

Schritt 2: RADIUS-Clients registrieren (Access Points)

  1. Öffnen Sie den Netzwerkrichtlinienserver (nps.msc).
  2. Erweitern Sie RADIUS-Clients und -Server > Rechtsklick auf RADIUS-Clients > Neu.
  3. Geben Sie einen Anzeigenamen ein: Cisco-Catalyst-AP-Cluster.
  4. Geben Sie die IP-Adresse oder das Subnetz CIDR ein (z. B. 10.50.0.0/24).
  5. Generieren und hinterlegen Sie ein starkes Shared Secret (mindestens 24 alphanumerische Zeichen).

Schritt 3: Netzwerkrichtlinie für WiFi-Authentifizierung erstellen

  1. Klicken Sie unter Richtlinien > Netzwerkrichtlinien mit der rechten Maustaste und wählen Sie Neu.
  2. Richtlinienname: Staff-WiFi-802.1X-Policy. Typ des Netzwerkzugriffsservers: Nicht angegeben.
  3. Bedingungen:
    • Windows-Gruppen hinzufügen: CORP\WiFi-Authorised-Users
    • NAS-Porttyp hinzufügen: Drahtlos - IEEE 802.11 oder Drahtlos - Sonstige
  4. Zugriffsberechtigung: Wählen Sie Zugriff gewähren.
  5. Authentifizierungsmethoden:
    • Wählen Sie weniger sichere Methoden ab.
    • Fügen Sie unter EAP-Typen Microsoft: Smartcard- oder anderes Zertifikat (EAP-TLS) hinzu.
    • Bearbeiten Sie die Methode und wählen Sie das ausgestellte RADIUS-Serverzertifikat Ihrer Active Directory-Zertifikatsdienste (AD CS) Enterprise-Zertifizierungsstelle aus.
  6. Einschränkungen: Setzen Sie das Leerlauf-Timeout auf 30 Minuten und das Sitzungs-Timeout auf 8 Stunden.

Haben Sie Fragen zu Ihrem spezifischen Setup?

Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.

Cloud RADIUS: Moderne Zero-Trust-Architektur

Herkömmliche lokale RADIUS-Server bringen erhebliche betriebliche Herausforderungen mit sich:

  • Hoher Aufwand für Server-Lizenzierung und Patch-Verwaltung.
  • Keine nativen Authentifizierungs-APIs für Cloud-Identitätsverzeichnisse wie Microsoft Entra ID oder Google Workspace.
  • Anfälligkeit für WAN-Ausfälle an Standorten und in Filialen.

Moderne Unternehmensnetzwerke setzen auf Cloud RADIUS, um die Authentifizierung ohne lokale Server-Infrastruktur zu zentralisieren.

Funktion Klassischer Windows NPS / FreeRADIUS Cloud RADIUS-Architektur
Verzeichnis-Integration Lokales LDAP / Kerberos Natives Microsoft Entra ID, Google Workspace, Okta
Transportsicherheit Unverschlüsseltes UDP 1812/1813 RadSec (RFC 6614) TLS über TCP 2083
Hochverfügbarkeit Manueller Aktiv-Passiv Failover Regionenübergreifende globale Anycast Redundanz
Wartung Betriebssystem-Patches & OS-Lizenzierung Managed Cloud Service mit kontinuierlichen Updates

Um Ihre Architektur zu modellieren, lesen Sie unseren Multi-Tenant WiFi Guide und unsere Staff WiFi Solutions.

Dynamische VLAN Zuweisungskonfiguration

Die dynamische VLAN Zuweisung (definiert unter RFC 2868 und RFC 3580) ermöglicht es einer einzigen Enterprise SSID, Benutzer basierend auf ihrer Verzeichnisgruppenmitgliedschaft dynamisch in verschiedene Netzwerk-Subnetze zu segmentieren.

                          [Enterprise Staff SSID]
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
        [VLAN 10: Exec]       [VLAN 20: Engineering]  [VLAN 30: Contractors]
        (10.10.10.0/24)        (10.10.20.0/24)        (10.10.30.0/24)

Erforderliche Standard RADIUS Attribute

Wenn der RADIUS Server die Anmeldedaten validiert, fügt er der Access-Accept Antwort diese Attribute hinzu:

Tunnel-Type = 13 (VLAN)
Tunnel-Medium-Type = 6 (802 - includes all 802 media plus Ethernet canonical format)
Tunnel-Private-Group-ID = 20 (or VLAN Name "CORP_ENG")

FreeRADIUS Beispiel für dynamisches VLAN Mapping

In /etc/freeradius/3.0/users:

DEFAULT Group == "Engineering-Team"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "20"

DEFAULT Group == "Contractors"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "30"

Netzwerk Firewall-Regeln & Port-Konfiguration

Stellen Sie sicher, dass die Netzwerk-Firewalls die Kommunikation zwischen Access Points und RADIUS Servern zulassen:

Protokoll Portnummer Beschreibung Quelle Ziel
UDP 1812 RADIUS Authentifizierung (RFC 2865) Access Points / WLC RADIUS Server
UDP 1813 RADIUS Accounting (RFC 2866) Access Points / WLC RADIUS Server
TCP 2083 RadSec - RADIUS over TLS (RFC 6614) Access Points / WLC Cloud RADIUS
UDP 1645 / 1646 Veraltete RADIUS Auth / Acct (Veraltet) Ältere NAS-Geräte RADIUS Server

Sicherheitshärtung & BlastRADIUS Eindämmung

Eindämmung von BlastRADIUS (CVE-2024-3596)

Im Juli 2024 enthüllten Forscher BlastRADIUS, eine MD5-Kollisionsschwachstelle im RADIUS Protokoll, die es einem Angreifer zwischen dem Access Point und dem RADIUS Server ermöglicht, Access-Accept Antworten zu fälschen.

So sichern Sie Ihre Bereitstellung:

  1. Message-Authenticator erzwingen: Fordern Sie das Attribut Message-Authenticator (RFC 2869) für alle Access-Request- und Access-Accept-Pakete an.
  2. Übergang zu EAP-TLS: Zertifikatsbasiertes EAP-TLS ist kryptografisch immun gegen Proxy-Fälschungen, da kryptografische TLS-Schlüssel End-to-End zwischen Client und RADIUS-Server abgeleitet werden.
  3. RadSec bereitstellen (RFC 6614): Kapseln Sie den RADIUS-Verkehr in TLS-Tunneln, um Man-in-the-Middle-Paketmanipulationen zu verhindern.

Fehlerbehebung bei Fehlern der 802.1X-Authentifizierung

Fehlersymptom Ursache Technische Behebung
Client erhält sofort einen Verbindungsfehler Gemeinsames Geheimnis (Shared Secret) stimmt zwischen AP und RADIUS-Server nicht überein Überprüfen Sie die Zeichenfolge des gemeinsamen Geheimnisses im AP-Controller und in der RADIUS-Konfiguration.
Authentifizierungs-Timeout nach 10 - 15 Sekunden Firewall blockiert UDP-Port 1812 oder fehlendes Routing Überprüfen Sie die Firewall-ACLs und stellen Sie sicher, dass der AP die IP-Adresse des RADIUS-Servers über das Management-VLAN pingen kann.
RADIUS-Protokoll: "Unknown CA" oder "Certificate Untrusted" Client oder RADIUS-Server fehlt das Root-CA-Zertifikat Installieren Sie Intermediate- und Root-CA-Zertifikate im Trust-Store des Clients und im Zertifikatsverzeichnis des RADIUS-Servers.
Client authentifiziert sich, erhält aber eine APIPA-IP (169.254.x.x) Dynamische VLAN-ID existiert nicht auf dem AP-Switch-Trunk-Port Stellen Sie sicher, dass die Switch-Trunk-Konfiguration die in Tunnel-Private-Group-ID angegebene Ziel-VLAN-ID überträgt.
RADIUS-Protokoll: "Message-Authenticator is missing" NAS-Client unterstützt RFC 2869 nicht oder es fehlt ein Firmware-Update Aktualisieren Sie die Firmware des AP-Controllers oder aktivieren Sie die Erzwingung des Message-Authenticators im NAS-Profil.

Häufig gestellte Fragen

Welchen Port verwendet ein RADIUS-Server für die WiFi-Authentifizierung?

Die Standard-RADIUS-Authentifizierung erfolgt über den UDP-Port 1812, die Abrechnung (Accounting) über den UDP-Port 1813. Ältere Implementierungen verwendeten die UDP-Ports 1645 und 1646. Moderne Cloud-RADIUS-Bereitstellungen nutzen RadSec über TCP-Port 2083 mit TLS-Verschlüsselung.

Sollte ich mich für FreeRADIUS oder Windows Server NPS entscheiden?

Wählen Sie Windows Server NPS, wenn Ihr Unternehmen ausschließlich auf On-Premise Active Directory Domain Services setzt. Wählen Sie FreeRADIUS für hohe Leistung, Open-Source-Flexibilität und Linux-Umgebungen. Wenn Ihr Unternehmen Cloud-Identitätsanbieter wie Microsoft Entra ID oder Google Workspace nutzt, wählen Sie Cloud RADIUS.

Wie verbinde ich Microsoft Entra ID (Azure AD) mit einem RADIUS-Server?

Microsoft Entra ID unterstützt standardmäßig keine älteren On-Premise-LDAP- oder NTLM-Authentifizierungsprotokolle. Um Entra ID mit Enterprise-WiFi zu verbinden, stellen Sie Cloud RADIUS in Kombination mit der Microsoft Intune SCEP-Zertifikatsbereitstellung bereit, um Endpunkte mithilfe von EAP-TLS zu authentifizieren.

Warum wird EAP-TLS gegenüber PEAP-MSCHAPv2 bevorzugt?

EAP-TLS nutzt die gegenseitige X.509-Zertifikatsauthentifizierung, bei der sowohl der Client als auch der Server kryptografische Identitäten validieren. PEAP-MSCHAPv2 basiert auf Benutzerkennwörtern innerhalb eines TLS-Tunnels, wodurch Netzwerke anfällig für Password-Spraying, Phishing und den Diebstahl von Anmeldedaten über gefälschte APs werden.


Für eine maßgeschneiderte Enterprise WiFi Sicherheitsarchitektur lesen Sie unseren WiFi Analytics Guide oder sprechen Sie mit einem Experten für Unternehmensnetzwerke.

Schlüsseldefinitionen

RADIUS (RFC 2865)

Remote Authentication Dial-In User Service. Ein Client-Server-Netzwerkprotokoll, das eine zentrale Verwaltung von Authentifizierung, Autorisierung und Accounting (AAA) ermöglicht.

Fungiert als Authentifizierungsserver, der die über drahtlose Access Points übermittelten Geräte- und Benutzerdaten überprüft.

IEEE 802.1X

Ein IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle (PNAC), der eine geschützte Authentifizierung für Geräte bietet, die eine Verbindung zu einem LAN oder WLAN herstellen möchten.

Definiert die Kapselung von EAP-Frames zwischen dem Supplicant (Endgerät) und dem Authenticator (Access Point).

EAP-TLS (RFC 5216)

Extensible Authentication Protocol - Transport Layer Security. Ein Protokoll zur gegenseitigen zertifikatsbasierten Authentifizierung, bei dem sowohl der RADIUS-Server als auch der Client digitale Zertifikate validieren.

Der branchenübliche Authentifizierungsstandard für passwortloses Zero-Trust WiFi in Unternehmen.

RadSec (RFC 6614)

RADIUS über TLS. Ein Standard, der herkömmliche UDP-RADIUS-Pakete in sicheren TCP-Port 2083 TLS-Tunneln kapselt.

Sichert den RADIUS-Authentifizierungsverkehr über ungesicherte öffentliche WAN-Verbindungen zwischen lokalen Access Points und Cloud RADIUS-Servern.

Dynamische VLAN-Zuweisung (RFC 3580)

Ein RADIUS-Mechanismus, der basierend auf der Benutzerrolle oder dem Sicherheitsstatus des Geräts VLAN-IDs in Access-Accept-Antworten zurückgibt.

Ermöglicht es einer einzigen SSID im Unternehmen, Benutzer dynamisch in isolierte Netzwerksegmente zu verschieben.

Ausgearbeitete Beispiele

Ein Netzwerkingenieur muss FreeRADIUS konfigurieren, um drahtlose Clients zu authentifizieren, die über 12 Cisco Catalyst Access Points im Subnetz 10.20.0.0/24 mit dem Shared Secret SecretAuthKey2026 verbunden sind. Welche Konfiguration muss in clients.conf eingetragen werden?

client branch_aps { ipaddr = 10.20.0.0/24 secret = SecretAuthKey2026 nas_type = cisco require_message_authenticator = yes }

Kommentar des Prüfers: Die Definition eines gesamten Subnetzbereichs in der Datei clients.conf vereinfacht das Hinzufügen von Access Points. Die Einstellung require_message_authenticator = yes mindert Fälschungsangriffe via BlastRADIUS (CVE-2024-3596).

Eine IT-Abteilung migriert 2.000 geschäftliche Windows 11 Laptops von Active Directory zu Microsoft Entra ID und Intune. Wie sollte die RADIUS-Infrastruktur aktualisiert werden, um passwortlose WiFi-Authentifizierung zu unterstützen, ohne Domain Controller vor Ort zu behalten?

  1. Bereitstellung von Cloud RADIUS mit nativer Integration für Microsoft Entra ID. 2. Konfiguration von Microsoft Intune SCEP- oder PKCS-Zertifikatsprofilen zur automatischen Ausstellung von Client-Zertifikaten an verwaltete Laptops. 3. Konfiguration des Wireless Controllers so, dass die 802.1X-Authentifizierung über RadSec (TLS-Port 2083) an den Cloud RADIUS-Server weitergeleitet wird. 4. Erzwingen von EAP-TLS als primäre Authentifizierungsmethode im Intune WiFi-Konfigurationsprofil.
Kommentar des Prüfers: Da Microsoft Entra ID keine nativen NTLM- oder Kerberos-Endpunkte für ältere PEAP-MSCHAPv2-Verfahren bereitstellt, ist das zertifikatsbasierte EAP-TLS in Kombination mit Cloud RADIUS der empfohlene Migrationspfad für Unternehmen.

Übungsfragen

Q1. Während eines drahtlosen 802.1X-Rollouts verbinden und authentifizieren sich Client-Geräte erfolgreich, erhalten jedoch eine IP-Adresse im standardmäßigen nativen VLAN anstelle des zugewiesenen Unternehmens-VLANs. Welche RADIUS-Attribute muss der Server zurückgeben?

Hinweis: Prüfen Sie die Tunnel-Attribute in RFC 2868 und RFC 3580.

Musterlösung anzeigen

Der RADIUS-Server muss in der Access-Accept-Antwort drei spezifische Attribute zurückgeben: 1. Tunnel-Type = 13 (VLAN), 2. Tunnel-Medium-Type = 6 (802), 3. Tunnel-Private-Group-ID = [VLAN_ID_oder_Name]. Der Switch-Port des Access Points muss zudem als Trunk-Port konfiguriert sein, der dieses VLAN überträgt.

Q2. Welches Sicherheitsrisiko besteht bei der Bereitstellung von PEAP-MSCHAPv2 in BYOD-Netzwerken, wenn das Root-CA-Zertifikat des RADIUS-Servers auf den Client-Geräten nicht erzwungen wird?

Hinweis: Berücksichtigen Sie Angriffe durch Rogue Access Points und Evil-Twin-Szenarien.

Musterlösung anzeigen

Wenn Client-Geräte das RADIUS-Server-Zertifikat nicht validieren, kann ein Angreifer einen betrügerischen Access Point bereitstellen, der dieselbe SSID ausstrahlt. Sobald sich der Client verbindet, fängt der manipulierte Server den MS-CHAPv2-Challenge-Response-Handshake ab, wodurch der Angreifer das Passwort offline mit Tools wie asleap knacken kann.

Q3. Welche Firewall-Ports müssen zwischen einem lokalen Wireless Access Point und einem Cloud-RADIUS-Server geöffnet sein, wenn RadSec im Vergleich zu Standard-RADIUS verwendet wird?

Hinweis: Vergleichen Sie veraltete UDP-Ports mit modernem TLS-verschlüsseltem RADIUS.

Musterlösung anzeigen

Standard-RADIUS erfordert den ausgehenden UDP-Port 1812 (Authentifizierung) und UDP-Port 1813 (Accounting). RadSec erfordert den ausgehenden TCP-Port 2083 mit TLS-Verschlüsselung, was eine gegenseitige Zertifikatsvalidierung ermöglicht und die Klartext-UDP-Übertragung über das öffentliche Internet eliminiert.

Haben Sie Fragen zu Ihrem spezifischen Setup?

Unser Team arbeitet mit Standortbetreibern, IT-Managern und Netzwerktechnikern an über 80.000 Standorten zusammen. Buchen Sie ein 20-minütiges Gespräch und wir zeigen Ihnen, wie andere diese Herausforderungen gelöst haben.