Cloud RADIUS vs. On-Premise RADIUS: Entscheidungsleitfaden für IT-Teams

Dieser Leitfaden bietet IT-Leitern, Netzwerkarchitekten und Standort-Betriebsteams einen definitiven Rahmen für die Entscheidung zwischen Cloud-gehosteten RADIUS-Diensten und herkömmlichen On-Premise RADIUS-Servern. Er behandelt die technische Architektur, Latenz- und Zuverlässigkeitskompromisse, die Gesamtbetriebskosten sowie Compliance-Überlegungen für standortübergreifende Implementierungen im Gastgewerbe, im Einzelhandel und im öffentlichen Sektor. Am Ende verfügen die Leser über ein klares Entscheidungsmodell, das auf ihre spezifischen Infrastrukturbeschränkungen und die Risikobereitschaft ihres Unternehmens abgestimmt ist.

📖 10 Min. Lesezeit📝 2,487 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

TEIL 1 — EINFÜHRUNG & KONTEXT

Willkommen zum technischen Briefing von Purple. Ich bin Ihr Gastgeber, und heute befassen wir uns mit einer entscheidenden Infrastrukturentscheidung für Multi-Site-Standorte: Cloud RADIUS versus On-Premise RADIUS. Wenn Sie als IT-Leiter oder Netzwerkarchitekt die Authentifizierung für eine Hotelgruppe, eine Einzelhandelskette oder einen großen öffentlichen Veranstaltungsort verwalten, liefert Ihnen dieses Briefing den praktischen Leitfaden, den Sie für die richtige Entscheidung benötigen.

Legen wir den Kontext fest. RADIUS — Remote Authentication Dial-In User Service — ist der Gatekeeper für Ihr Netzwerk. Jedes Mal, wenn sich ein Gast in Ihr WiFi einloggt oder ein Mitarbeiter über 802.1X eine Verbindung zur Unternehmens-SSID herstellt, ist RADIUS die Engine, die die Anmeldedaten mit Ihrem Verzeichnis abgleicht und den Zugriff autorisiert. Traditionell bedeutete dies, physische Server in Ihrem Rechenzentrum zu installieren, FreeRADIUS oder einen proprietären Network Policy Server einzurichten und den gesamten Stack selbst zu verwalten. Heute bieten Cloud RADIUS-Dienste eine verwaltete, global verteilte Alternative. Aber was ist das Richtige für Ihre spezifische Bereitstellung? Lassen Sie uns in die technischen Vor- und Nachteile eintauchen.

TEIL 2 — TECHNISCHE DETAILS

Sprechen wir zunächst über Architektur und Latenz. Bei einer On-Premise-Bereitstellung kommunizieren Ihre Access Points direkt mit einem lokalen RADIUS-Server. Für ein einzelnes großes Stadion oder ein eigenständiges Krankenhaus bietet dies eine unglaublich niedrige Latenz. Authentifizierungsanfragen laufen über das lokale LAN — wir sprechen hier von Roundtrips im Sub-Millisekundenbereich. Wenn Sie jedoch eine Einzelhandelskette mit mehreren Standorten sind, führt das Routing des gesamten Authentifizierungsverkehrs zurück zu einem zentralen Rechenzentrum zu WAN-Latenzen und einem Single Point of Failure. Wenn diese WAN-Verbindung ausfällt, können Ihre Remote-Standorte überhaupt keine Benutzer mehr authentifizieren.

Cloud RADIUS stellt dieses Modell komplett auf den Kopf. Die RADIUS-Infrastruktur wird global über mehrere Verfügbarkeitszonen hinweg gehostet. Wenn sich ein Benutzer an einem Filialstandort verbindet, wird die Anfrage an den nächstgelegenen Cloud-Edge-Knoten weitergeleitet. Dies reduziert die Latenzzeit bei verteilten Bereitstellungen im Vergleich zum Backhauling an einen zentralen On-Premise-Server erheblich. Darüber hinaus integrieren Cloud-Anbieter standardmäßig eine hohe Verfügbarkeit. Wenn ein Knoten ausfällt, wird der Datenverkehr automatisch auf den nächstgelegenen Knoten umgeleitet. Um dieses Maß an Redundanz On-Premise zu erreichen, müssten Sie Active-Active-Cluster über mehrere geografisch verstreute Rechenzentren hinweg bereitstellen — was einen erheblichen Entwicklungsaufwand und hohe Investitionskosten erfordert.
Betrachten wir nun den Wartungsaufwand und die Skalierbarkeit. Ein On-Premise-RADIUS erfordert, dass Ihr Team das Betriebssystem verwaltet, Sicherheitspatches einspielt, SSL-Zertifikate verwaltet und den Serverzustand rund um die Uhr überwacht. Wenn Sie für ein Großereignis hochskalieren müssen – beispielsweise ein Stadion, das ein Konzert mit 70.000 Besuchern ausrichtet –, müssen Sie im Vorfeld neue Hardware oder virtuelle Maschinen bereitstellen. Es gibt keine elastische Skalierung. Cloud-RADIUS wird als SaaS bereitgestellt. Der Anbieter kümmert sich automatisch um die zugrunde liegende Infrastruktur, das Patching und die Skalierung. Sie verwalten lediglich die Richtlinien und Integrationen über ein Web-Dashboard oder eine API. Dies entlastet Ihre erfahrenen Ingenieure von der Routine-Wartung, sodass sie sich auf strategische Initiativen konzentrieren können, anstatt nur den Betrieb aufrechtzuerhalten.

Kommen wir zur Integration mit Identity Providers. Wenn sich Ihr Benutzerverzeichnis bereits in der Cloud befindet – unter Verwendung von Azure Active Directory, Google Workspace oder Okta –, ist eine Cloud-RADIUS-Lösung die natürliche Wahl. Sie lässt sich nahtlos über APIs oder sichere Konnektoren integrieren. Wenn Sie hingegen ein veraltetes On-Premise Active Directory nutzen, das aus Sicherheits- oder Compliance-Gründen nicht für das Internet freigegeben werden darf, ist ein On-Premise-RADIUS-Server möglicherweise Ihre einzige praktikable Option. Er kann das lokale AD direkt abfragen, ohne die Firewall zu passieren, was insbesondere im Gesundheitswesen oder in Regierungseinrichtungen, in denen Datensouveränität eine strikte Vorgabe ist, von Bedeutung ist.

Sprechen wir nun über Compliance. PCI DSS erfordert, dass Umgebungen mit Karteninhaberdaten eine starke Authentifizierung nutzen. Die GDPR verlangt, dass personenbezogene Daten – einschließlich der Authentifizierungsprotokolle – angemessen verarbeitet werden. Cloud-RADIUS-Anbieter bieten in der Regel SOC 2 Type II-Zertifizierungen, GDPR-Datenverarbeitungsvereinbarungen und Optionen für regionale Datenresidenz an. On-Premise bietet Ihnen die volle Kontrolle darüber, wo Ihre Daten liegen, was in stark regulierten Sektoren von Vorteil sein kann. Allerdings bedeutet dies auch, dass die gesamte Compliance-Last auf Ihr Team fällt.

Lassen Sie uns einen tieferen Blick auf die technische Architektur der beiden Ansätze werfen, da das Verständnis der Funktionsweise Ihnen helfen wird, eine fundiertere Entscheidung zu treffen.

Bei einer traditionellen On-Premise-RADIUS-Bereitstellung verfügen Sie in der Regel über einen oder mehrere Server, auf denen entweder der Network Policy Server von Microsoft – allgemein bekannt als NPS – oder die Open-Source-Plattform FreeRADIUS läuft. Diese Server befinden sich innerhalb Ihres Netzwerkperimeters und kommunizieren mit Ihren Access Points über UDP, in der Regel auf Port 1812 für die Authentifizierung und Port 1813 für das Accounting. Das Shared Secret zwischen dem Access Point und dem RADIUS-Server ist ein kritisches Sicherheitselement – es muss lang und zufällig sein sowie regelmäßig rotiert werden.

FreeRADIUS ist der weltweit am häufigsten eingesetzte RADIUS-Server, der die Authentifizierung für Hunderte von Millionen Nutzern weltweit steuert. Er ist hochgradig konfigurierbar, unterstützt eine enorme Bandbreite an EAP-Methoden und lässt sich in praktisch jedes Backend-Verzeichnis integrieren. Diese Flexibilität hat jedoch ihren Preis: Sie erfordert eine qualifizierte Administration. Fehlkonfigurationen sind eine häufige Ursache für Authentifizierungsfehler, und das Debuggen von FreeRADIUS-Protokollen erfordert Erfahrung.

Cloud-RADIUS-Plattformen abstrahieren all diese Komplexität. Unter der Haube betreiben sie eine verteilte RADIUS-Infrastruktur über mehrere Cloud-Regionen hinweg, aber Sie interagieren mit ihnen über eine übersichtliche Weboberfläche oder API. Sie definieren Ihre Authentifizierungsrichtlinien – welche SSIDs welchen Benutzergruppen zugeordnet sind, welche EAP-Methoden zulässig sind, wie mit unbekannten Geräten verfahren werden soll – und die Plattform kümmert sich um den Rest.

Ein Bereich, in dem On-Premise-RADIUS immer noch einen klaren Vorteil hat, sind Umgebungen mit sehr hohen Anforderungen an den Authentifizierungsdurchsatz in Kombination mit strengen Latenzvorgaben. Denken Sie an einen großen Verkehrsknotenpunkt – einen Flughafen oder Bahnhof –, an dem Tausende von Geräten gleichzeitig versuchen, sich zu authentifizieren, während Passagiere ankommen. In diesem Szenario kann ein lokaler RADIUS-Cluster Authentifizierungsanfragen in weniger als einer Millisekunde verarbeiten, während eine Cloud-RADIUS-Anfrage das Internet hin und zurück durchqueren muss, was je nach dem nächstgelegenen Edge-Knoten des Anbieters zwischen 5 und 50 Millisekunden zusätzlich bedeutet.

TEIL 3 — IMPLEMENTIERUNGSEMPFEHLUNGEN & FALLSTRICKE

Lassen Sie mich Ihnen zwei reale Szenarien vorstellen, um dies zu verdeutlichen.

Szenario eins: Eine europäische Hotelgruppe mit 45 Hotels in sechs Ländern. Das IT-Team ist zentralisiert und besteht aus nur drei Netzwerktechnikern, die den gesamten Bestand verwalten. Sie betrieben FreeRADIUS auf virtuellen Maschinen in jedem Hotel – 45 separate Instanzen, die gepatcht, überwacht und gewartet werden mussten. Als in einem Hotel ein Zertifikat ablief, führte dies während einer großen Konferenz zu einem kompletten Ausfall des Gäste-WiFi. Sie migrierten zu einem Cloud-RADIUS-Dienst, wodurch die Richtlinienverwaltung zentralisiert und die Wartung pro Standort überflüssig wurde. Das dreiköpfige Ingenieurteam gewann rund 40 Prozent seiner Zeit zurück, die zuvor für die RADIUS-Wartung aufgewendet wurde.

Szenario zwei: Ein nationales Sportstadion mit 68.000 Sitzplätzen. Das IT-Team hat strenge Anforderungen an die Datensouveränität – alle Authentifizierungsprotokolle müssen auf britischem Boden verbleiben. Sie implementierten einen dualen On-Premise-RADIUS-Cluster in einer Active-Active-Konfiguration mit einem sekundären Cluster in einer Co-Location-Einrichtung in 20 Meilen Entfernung. Dies gab ihnen die lokale Kontrolle, eine Authentifizierung im Sub-Millisekundenbereich und die Fähigkeit, Datenverkehrsspitzen zu bewältigen, ohne auf eine Internetverbindung angewiesen zu sein.

Bei der Bereitstellung von Cloud-RADIUS besteht der häufigste Fehler darin, die lokale Internetverbindung am Veranstaltungsort zu ignorieren. Cloud-RADIUS verlässt sich vollständig auf die WAN-Verbindung. Um dieses Risiko zu mindern, sollten Sie eine lokale Ausfallsicherheitsstrategie implementieren – z. B. das Zwischenspeichern von Anmeldedaten auf dem lokalen Netzwerk-Controller für geschäftskritische Mitarbeiter oder die Nutzung von SD-WAN, um eine hohe Verfügbarkeit der Internetverbindung zu gewährleisten.

Bei On-Premise-Bereitstellungen ist das größte betriebliche Risiko das Zertifikatsmanagement. Wenn das Zertifikat auf Ihrem On-Premise-RADIUS-Server abläuft, lehnt jedes einzelne Client-Gerät die Verbindung ab, was zu einem vollständigen Authentifizierungsausfall führt. Cloud-RADIUS-Anbieter automatisieren die Zertifikatsrotation und eliminieren dieses Risiko vollständig.

TEIL 4 — SCHNELLE FRAGEN & ANTWORTEN

Frage eins: Unterstützt Cloud RADIUS den MAC Authentication Bypass für kopflose Geräte wie Drucker und IoT-Sensoren? Antwort: Ja. Die meisten Enterprise-Cloud-RADIUS-Plattformen unterstützen MAB. Sie können die MAC-Adressen-Allowlists über deren Dashboard oder API verwalten, was die Handhabung von IoT-Geräten an Hunderten von Standorten erheblich erleichtert.

Frage zwei: Wie verhält sich die Gesamtkostenentwicklung (TCO) über fünf Jahre? Antwort: On-Premise ist CapEx-intensiv — Hardware, Lizenzen, Strom, Kühlung und Entwicklungszeit. Cloud RADIUS ist OpEx — in der Regel jährlich pro Benutzer oder pro Gerät abgerechnet. Für schnell wachsende Bereitstellungen an mehreren Standorten ist das planbare OpEx der Cloud meist kosteneffizienter. Organisationen mit mehr als 10 Standorten und weniger als 5 Netzwerkingenieuren verzeichnen fast immer innerhalb von 18 Monaten einen positiven ROI durch die Cloud.

Frage drei: Kann man ein Hybrid-Modell betreiben? Antwort: Absolut. Cloud RADIUS für Gäste- und IoT-SSIDs, On-Premise für die Unternehmens-SSID zur Authentifizierung gegenüber dem internen Active Directory. Purple WiFi unterstützt dieses Hybrid-Modell nativ.

Frage vier: Was passiert bei einem Ausfall des Cloud-Anbieters? Antwort: Seriöse Cloud-RADIUS-Anbieter garantieren SLAs von 99,99 Prozent Verfügbarkeit, abgesichert durch Multi-Regionen-Redundanz. Konfigurieren Sie Ihre Access Points immer mit einer Fallback-Richtlinie — entweder offener Zugriff auf ein eingeschränktes VLAN oder lokal zwischengespeicherte Anmeldedaten —, um dieses Szenario reibungslos zu bewältigen.

TEIL 5 — ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE

Zusammenfassend lässt sich das wichtigste Entscheidungsraster wie folgt darstellen: Wählen Sie On-Premise RADIUS, wenn Sie einen einzigen großen Standort mit strengen Anforderungen an die Datensouveränität, eine physisch isolierte Sicherheitsumgebung (Air-Gapped) oder veraltete On-Premise-Verzeichnisse haben, die nicht mit der Cloud verbunden werden können. Wählen Sie Cloud RADIUS, wenn Sie eine verteilte Struktur mit mehreren Standorten, Cloud-native Identity Provider wie Okta oder Azure AD, ein kleines zentrales IT-Team haben oder wenn Sie eine schnelle Bereitstellung an neuen Standorten ohne Vorlaufzeiten für die Hardwarebeschaffung benötigen.

Fazit: Für die meisten Betreiber von Multi-Site-Standorten ist Cloud RADIUS heute die betrieblich überlegene Wahl. Das Latenzargument für On-Premise wurde durch global verteilte Cloud-Infrastrukturen weitgehend entkräftet. Bevor Sie Ihre Entscheidung treffen, prüfen Sie drei Dinge: Ihren aktuellen Identity Provider und ob dieser Cloud-nativ ist, Ihre WAN-Ausfallsicherheit an jedem Standort und die Kapazität Ihres Teams für die laufende Wartung. Diese drei Faktoren zeigen Ihnen, welcher Weg für Ihr Unternehmen der richtige ist.

Vielen Dank, dass Sie an diesem technischen Briefing von Purple teilgenommen haben. Weitere vertiefende Informationen zur WiFi-Architektur in Unternehmen finden Sie in unserer Leitfaden-Bibliothek unter Purple.ai.

Wichtigste Erkenntnisse

✓Cloud RADIUS bietet integrierte Hochverfügbarkeit, automatische Zertifikatsrotation und elastische Skalierbarkeit – was es für Multi-Site-Bereitstellungen mit verteilten Standorten und kleinen zentralen IT-Teams betrieblich überlegen macht.
✓On-Premise-RADIUS bleibt die richtige Wahl für Air-Gapped-Umgebungen, Bereitstellungen mit strengen Anforderungen an die Datensouveränität, die kein Cloud-Anbieter erfüllen kann, und sehr große Einzelstandorte, an denen eine lokale LAN-Authentifizierung im Sub-Millisekundenbereich betriebskritisch ist.
✓Die 10-Standorte-Regel: Organisationen mit mehr als 10 Standorten und weniger als 5 Netzwerktechnikern erzielen mit Cloud RADIUS fast immer innerhalb von 18 Monaten einen positiven ROI, was in erster Linie auf den Wegfall des Wartungsaufwands pro Standort zurückzuführen ist.
✓WAN-Resilienz ist die unverzichtbare Voraussetzung für die Bereitstellung von Cloud RADIUS. Implementieren Sie eine Dual-ISP-Konnektivität oder ein SD-WAN-Failover und konfigurieren Sie das Zwischenspeichern von Anmeldedaten auf Wireless-Controllern, bevor Sie den produktiven Authentifizierungsverkehr in die Cloud migrieren.
✓Das Ablaufen von Zertifikaten ist die Hauptursache für Ausfälle von On-Premise-RADIUS und lässt sich vollständig verhindern – entweder durch Cloud RADIUS (automatische Rotation) oder durch einen ordnungsgemäß implementierten Zertifikatslebenszyklus-Managementprozess mit proaktiver Überwachung in Intervallen von 90/60/30 Tagen.
✓Das Hybrid-Modell – Cloud RADIUS für Gäste- und IoT-Netzwerke, On-Premise-RADIUS für Unternehmensnetzwerke – ist eine gängige und pragmatische Architektur, die für jeden Anwendungsfall das richtige Tool einsetzt, ohne eine binäre Entscheidung zu erzwingen.
✓Die Plattform von Purple lässt sich sowohl in Cloud- als auch in On-Premise-RADIUS-Backends integrieren. Die über die Analyseebene von Purple bereitgestellten Authentifizierungsereignisdaten verwandeln RADIUS-Accounting-Datensätze in verwertbare Besucherdaten für Standortbetreiber.

Executive Summary

Die RADIUS-Authentifizierung ist das Herzstück jeder WiFi-Bereitstellung in Unternehmen. Unabhängig davon, ob Sie den Mitarbeiterzugriff über IEEE 802.1X sichern oder das Onboarding von Gästen in einem standortübergreifenden Immobilienportfolio verwalten: Die Entscheidung, wo Sie Ihre RADIUS-Infrastruktur hosten, hat direkte Auswirkungen auf die Betriebszeit, den betrieblichen Aufwand und die Gesamtbetriebskosten.

Cloud RADIUS-Dienste bieten eine verwaltete, global verteilte Authentifizierungsinfrastruktur mit integrierter Hochverfügbarkeit, automatischer Zertifikatsrotation und elastischer Skalierbarkeit. Dadurch entfällt der Wartungsaufwand pro Standort, der verteilte On-Premise-Bereitstellungen häufig belastet. On-Premise RADIUS – ob mit FreeRADIUS oder Microsoft NPS betrieben – bietet lokale Authentifizierung im Sub-Millisekundenbereich, vollständige Datensouveränität und Unabhängigkeit von der WAN-Konnektivität. Diese Vorteile sind in bestimmten hochdichten oder regulierten Umgebungen nach wie vor ausschlaggebend.

Für die meisten Betreiber von Multi-Site-Umgebungen – wie Hotelgruppen, Einzelhandelsketten oder Konferenzzentren – bietet Cloud RADIUS ein besseres betriebliches Ergebnis bei niedrigeren Gesamtbetriebskosten über fünf Jahre. Die Ausnahmen sind klar definiert: Air-Gapped-Umgebungen, strenge Vorgaben zur Datenresidenz und sehr große Einzelstandort-Bereitstellungen, bei denen die lokale LAN-Leistung im Vordergrund steht. Dieser Leitfaden bietet Ihnen den Rahmen, um zu bestimmen, in welche Kategorie Ihre Bereitstellung fällt und wie Sie auf Basis dieser Entscheidung handeln sollten.

Technischer Deep-Dive

Das RADIUS-Protokoll und seine Rolle in der 802.1X-Infrastruktur

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) fungiert als Authentifizierungs-Broker zwischen Ihrer Netzwerkzugriffsebene und Ihrem Identitätsverzeichnis. Bei einer 802.1X -Bereitstellung fungiert der Access Point oder Switch als Network Access Server (NAS) und leitet EAP-Authentifizierungs-Frames über UDP (Port 1812 für Authentifizierung, Port 1813 für Accounting) an den RADIUS-Server weiter. Der RADIUS-Server validiert die Anmeldedaten des Supplicants mit einem Backend-Verzeichnis – wie Active Directory, LDAP oder einem Cloud-Identitätsanbieter – und gibt eine Access-Accept- oder Access-Reject-Antwort zurück, optional inklusive Attributen zur VLAN-Zuweisung.

Diese Architektur ist im Grunde dieselbe, unabhängig davon, ob Ihr RADIUS-Server eine im Serverraum montierte Rack-Appliance oder ein global verteilter Cloud-Dienst ist. Der Unterschied liegt darin, wo dieser Server betrieben wird, wer ihn wartet und wie er skaliert.

On-Premise RADIUS: Architektur und Abwägungen

Die beiden dominierenden On-Premise-RADIUS-Plattformen sind FreeRADIUS und Microsoft Network Policy Server (NPS). FreeRADIUS ist der weltweit am häufigsten eingesetzte RADIUS-Server und unterstützt eine breite Palette von EAP-Methoden, darunter EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS und EAP-PWD. Er lässt sich über LDAP, SQL oder REST in praktisch jedes Backend-Verzeichnis integrieren und ist ohne Lizenzkosten erhältlich. Er erfordert jedoch eine qualifizierte Administration: Die Konfiguration ist dateibasiert, das Debugging erfordert Fachwissen in der Protokollanalyse und die Skalierung über Dutzende von Standorten hinweg erfordert eine sorgfältige Replikations- und Failover-Planung.

Microsoft NPS lässt sich nativ in Active Directory integrieren und ist die Standardwahl für Windows-zentrierte Umgebungen. Es unterstützt PEAP-MSCHAPv2 und EAP-TLS standardmäßig und wird über die vertraute Windows Server-Benutzeroberfläche verwaltet. Der Nachteil ist die enge Kopplung an die Windows Server-Lizenzierung und eine im Vergleich zu FreeRADIUS eingeschränktere Auswahl an EAP-Methoden.

Für hochverfügbare On-Premise-Bereitstellungen implementieren Unternehmen in der Regel Active-Active- oder Active-Passive-RADIUS-Cluster. Access Points werden mit einer primären und einer sekundären RADIUS-Serveradresse konfiguriert; antwortet der primäre Server nicht innerhalb des konfigurierten Timeouts (typischerweise 3–5 Sekunden), führt das NAS ein Failover auf den sekundären Server durch. Diese Architektur erfordert entweder geografisch verteilte Server – was eine eigene Komplexität mit sich bringt – oder ein Serverpaar in derselben Einrichtung, was jedoch nicht vor einem Ausfall auf Standortebene schützt.

Latenzprofil: On-Premise RADIUS bietet Authentifizierungs-Roundtrips von unter 1 Millisekunde über ein lokales LAN. Für Umgebungen mit hoher Dichte, in denen Tausende von gleichzeitigen Authentifizierungen verarbeitet werden – beispielsweise ein Stadion mit 68.000 Plätzen während einer ausverkauften Veranstaltung –, ist diese lokale Verarbeitungsfunktion ein echter betrieblicher Vorteil.

Cloud RADIUS: Architektur und Abwägungen

Cloud-RADIUS-Plattformen hosten die RADIUS-Infrastruktur über mehrere geografisch verteilte Verfügbarkeitszonen hinweg. Wenn ein Access Point eine Authentifizierungsanfrage sendet, wird diese an den nächstgelegenen Cloud-Edge-Knoten weitergeleitet, was in der Regel eine Roundtrip-Latenz von 5–50 Millisekunden verursacht, je nachdem, wie nah der Point-of-Presence des Anbieters am Standort liegt. Für die weitaus größte Mehrheit der Authentifizierungs-Anwendungsfälle ist diese Latenz für Endbenutzer nicht wahrnehmbar.

Das Hochverfügbarkeitsmodell unterscheidet sich grundlegend von On-Premise-Lösungen. Anstatt ein Primär-/Sekundär-Paar zu konfigurieren, leitet der Load Balancer der Cloud-Plattform Anfragen automatisch von ausgefallenen Nodes ab. Enterprise Cloud RADIUS-Anbieter garantieren in der Regel SLAs von 99,99 % Betriebszeit, gestützt auf eine Multi-Regionen-Redundanz. Um eine gleichwertige Redundanz On-Premise zu erreichen, müssen Active-Active-Cluster über mehrere geografisch verteilte Rechenzentren hinweg bereitgestellt werden – eine erhebliche technische und finanzielle Investition.

Cloud RADIUS-Plattformen lassen sich nativ in Cloud-Identity-Provider integrieren. Wenn Ihr Unternehmen Okta, Azure Active Directory oder Google Workspace nutzt, stellt ein Cloud RADIUS-Dienst die Verbindung über SAML, LDAP-over-TLS oder proprietäre API-Konnektoren her. Eine detaillierte Anleitung speziell zur Okta-Integration finden Sie in unserem Leitfaden: Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication .

Das Zertifikatsmanagement ist eines der überzeugendsten betrieblichen Argumente für Cloud RADIUS. Sowohl EAP-TLS als auch PEAP basieren auf serverseitigen digitalen Zertifikaten. Bei On-Premise-Lösungen ist der Ablauf von Zertifikaten eine der Hauptursachen für Authentifizierungsausfälle – ein abgelaufenes Zertifikat auf einem FreeRADIUS-Server führt dazu, dass jeder verbundene Client die Identität des Servers ablehnt, was zu einem vollständigen WiFi-Ausfall führt, bis das Zertifikat erneuert und bereitgestellt wird. Cloud RADIUS-Anbieter automatisieren die Zertifikatsrotation vollständig und eliminieren diese Fehlerquelle.

WPA3-Enterprise und Protokoll-Überlegungen

Die WPA3-Enterprise-Spezifikation der WiFi Alliance führt einen 192-Bit-Sicherheitsmodus ein, der EAP-TLS mit Suite-B-Kryptografie (ECDHE, ECDSA, AES-256-GCM) vorschreibt. Dies wird für Implementierungen im Gesundheitswesen, im Finanzsektor und im öffentlichen Dienst immer relevanter. Die meisten modernen Cloud RADIUS-Plattformen unterstützen WPA3-Enterprise nativ. On-Premise-Bereitstellungen, auf denen ältere FreeRADIUS-Versionen (vor 3.0.x) oder veraltete NPS-Konfigurationen laufen, erfordern möglicherweise Upgrades, bevor WPA3-Enterprise bereitgestellt werden kann. Wenn WPA3-Enterprise auf Ihrer Roadmap steht, validieren Sie die Unterstützung Ihrer RADIUS-Plattform, bevor Sie sich auf einen Infrastrukturpfad festlegen.

Für Unternehmen, die die SD-WAN-Ebene in Betracht ziehen, die Multi-Site-Cloud-RADIUS-Bereitstellungen unterstützt, bietet unser Leitfaden über The Core SD-WAN Benefits for Modern Businesses ergänzenden Kontext zur WAN-Resilienz-Architektur.

Implementierungsleitfaden

Schritt 1: Auditieren Sie Ihre aktuellen Authentifizierungs-Abhängigkeiten

Bevor Sie ein Bereitstellungsmodell auswählen, dokumentieren Sie jede SSID, jedes VLAN, jede EAP-Methode und jedes Backend-Verzeichnis, mit dem Ihre aktuelle Authentifizierungsinfrastruktur interagiert. Beziehen Sie auch MAC Authentication Bypass (MAB)-Richtlinien für gerätelose Systeme – Drucker, IoT-Sensoren, Point-of-Sale-Terminals – mit ein, da diese bei Migrationen häufig übersehen werden und nach der Umstellung erhebliche Probleme verursachen können.

Schritt 2: Bereitschaft des Identity Providers bewerten

Wenn sich Ihr Benutzerverzeichnis in einem On-Premise Active Directory befindet und nicht mit einem Cloud-IdP synchronisiert werden kann, sind Ihre Cloud RADIUS-Optionen auf Plattformen beschränkt, die LDAP-Proxying zu On-Premise-Verzeichnissen unterstützen. Wenn Sie Azure AD Connect oder ein ähnliches Synchronisationstool bereitstellen können, steht Ihnen die gesamte Palette der Cloud RADIUS-Plattformen zur Verfügung. Diese einzige Entscheidung – Cloud-IdP versus On-Premise-Verzeichnis – ist oft der ausschlaggebende Faktor bei der Wahl zwischen Cloud und On-Premise RADIUS.

Schritt 3: WAN-Resilienz an jedem Standort bewerten

Cloud RADIUS ist nur so zuverlässig wie die Internetverbindung an jedem Standort. Überprüfen Sie vor der Migration die WAN-Konnektivität an jedem Standort. Standorte mit einer einzigen ISP-Verbindung und ohne Failover stellen ein erhebliches Risiko dar. Implementieren Sie eine Dual-ISP-Konnektivität oder ein SD-WAN-Failover, bevor Sie Cloud RADIUS als Ihre primäre Authentifizierungsinfrastruktur bereitstellen. Für Einzelhandels- Umgebungen, in denen Point-of-Sale-Systeme von der Netzwerkauthentifizierung abhängen, ist WAN-Resilienz unverzichtbar.

Schritt 4: Zertifikatsmigration planen (On-Premise-Bereitstellungen)

Wenn Sie On-Premise RADIUS mit EAP-TLS bereitstellen oder verwalten, richten Sie einen Prozess für das Zertifikats-Lifecycle-Management ein. Implementieren Sie Überwachungswarnungen 90, 60 und 30 Tage vor dem Ablauf des Zertifikats. Erwägen Sie die Bereitstellung einer internen PKI (wie Microsoft ADCS oder HashiCorp Vault), um die Ausstellung und Erneuerung von Zertifikaten zu automatisieren. Verlassen Sie sich in Produktionsumgebungen beim Zertifikatsmanagement niemals ausschließlich auf Kalendererinnerungen.

Schritt 5: Ausfallsicherheitsrichtlinien konfigurieren

Konfigurieren Sie bei Cloud RADIUS-Bereitstellungen eine lokale Ausfallsicherheitsrichtlinie auf Ihren Wireless-Controllern oder Access Points. Zu den Optionen gehören: Zwischenspeichern des letzten bekannten Authentifizierungsstatus für einen konfigurierbaren Zeitraum, Zurückgreifen auf MAC Authentication Bypass für vorab genehmigte Gerätelisten oder Routing kritischer Mitarbeiter-SSIDs über einen sekundären Authentifizierungspfad. Stellen Sie für Hotellerie- Betreiber sicher, dass das Onboarding von Gästen im WiFi über Plattformen wie das Guest WiFi von Purple ein definiertes Fallback-Verhalten bei Nichtverfügbarkeit von RADIUS aufweist.

Schritt 6: Eine parallele Bereitstellung durchführen

Stellen Sie die neue RADIUS-Plattform parallel zur bestehenden Infrastruktur bereit. Erstellen Sie eine dedizierte Test-SSID, die dem neuen RADIUS-Server zugewiesen ist, und validieren Sie alle EAP-Methoden, VLAN-Zuweisungen und Richtliniendurchsetzungen, bevor Sie die Produktions-SSIDs migrieren. Diese Phase des Parallelbetriebs sollte bei einer Bereitstellung an einem einzelnen Standort mindestens zwei Wochen und bei einer Migration über mehrere Standorte vier bis sechs Wochen betragen.

Schritt 7: Eine schrittweise Migration Standort für Standort durchführen

Migrieren Sie bei Bereitstellungen an mehreren Standorten die Standorte nacheinander und nicht gleichzeitig. Beginnen Sie mit Standorten mit geringerem Risiko – kleineren Standorten mit weniger Datenverkehr und toleranteren Benutzern –, bevor Sie Standorte mit hoher Priorität wie Flagship-Stores oder Hotelanlagen mit hohem Konferenzaufkommen migrieren. Dokumentieren Sie das Rollback-Verfahren für jeden Standort, bevor Sie mit der Umstellung beginnen.

Best Practices

Shared-Secret-Hygiene: RADIUS Shared Secrets zwischen Access Points und dem RADIUS-Server müssen mindestens 32 Zeichen lang, zufällig generiert und pro NAS-Gerät eindeutig sein. Die Wiederverwendung von Shared Secrets über alle Access Points hinweg bedeutet, dass die Kompromittierung eines einzelnen Geräts die gesamte Authentifizierungsinfrastruktur gefährdet. Rotieren Sie Shared Secrets jährlich oder nach jedem vermuteten Sicherheitsvorfall.

VLAN-Segmentierung: Verwenden Sie RADIUS-zugewiesene VLANs (über die Attribute Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private-Group-ID), um den Datenverkehr dynamisch nach Benutzerrolle zu segmentieren. Gastgeräte sollten in einem isolierten VLAN mit reinem Internetzugang landen, Unternehmensgeräte im Produktions-VLAN und IoT-Geräte in einem dedizierten, eingeschränkten VLAN. Diese Segmentierung ist eine PCI-DSS-Anforderung für jedes Netzwerk, das Karteninhaberdaten verarbeitet.

Accounting und Audit-Protokollierung: Aktivieren Sie RADIUS-Accounting (Port 1813) und bewahren Sie die Accounting-Protokolle mindestens 12 Monate lang auf. Diese Protokolle erfassen Start- und Stoppzeiten von Sitzungen, Datenvolumina und zugewiesene IP-Adressen – unerlässlich für die Untersuchung von Sicherheitsvorfällen und die GDPR-Compliance. Cloud-RADIUS-Plattformen exportieren Accounting-Daten in der Regel über Syslog oder API in SIEM-Systeme; On-Premise-Bereitstellungen sollten Accounting-Daten an eine zentralisierte Protokollverwaltungsplattform weiterleiten.

Auswahl der EAP-Methode: Für Unternehmensnetzwerke bietet EAP-TLS (zertifikatsbasiert) das stärkste Sicherheitsniveau und wird für PCI-DSS- und Gesundheitsumgebungen empfohlen. PEAP-MSCHAPv2 ist für Umgebungen mit geringerem Risiko akzeptabel, ist jedoch anfällig für Angriffe zum Diebstahl von Anmeldedaten, wenn das Serverzertifikat von den Supplicants nicht ordnungsgemäß validiert wird. Vermeiden Sie EAP-MD5 vollständig – es ist veraltet und bietet keine gegenseitige Authentifizierung.

RadSec (RADIUS über TLS): Das traditionelle RADIUS-Protokoll überträgt Daten über UDP, wobei nur das Attribut User-Password verschlüsselt ist. RadSec (RFC 6614) verpackt RADIUS in TLS und bietet eine vollständige Transportverschlüsselung sowie gegenseitige Authentifizierung zwischen NAS und RADIUS-Server. Die meisten modernen Cloud-RADIUS-Plattformen unterstützen RadSec. Bei Neuinstallationen sollte RadSec die Standard-Transportoption sein.

Für Bereitstellungen im Gesundheitswesen und im Transportsektor , wo die Verpflichtungen zur Datenverarbeitung gemäß GDPR und branchenspezifischen Vorschriften besonders streng sind, sollten Sie sicherstellen, dass Ihre RADIUS-Plattform einen Auftragsverarbeitungsvertrag (AVV) bereitstellt und die regionale Datenresidenz unterstützt.

Fehlerbehebung & Risikominderung

Häufiges Fehlerszenario 1: Ablauf des Zertifikats (On-Premise)

Symptom: Bei allen Clients schlägt plötzlich die Authentifizierung fehl; RADIUS-Protokolle zeigen TLS-Handshake-Fehler.

Fehlerursache: Das serverseitige Zertifikat auf dem RADIUS-Server ist abgelaufen. Client-Supplicants weisen die Identität des Servers zurück.

Minderung: Implementieren Sie eine automatisierte Zertifikatsüberwachung mit Warnmeldungen bei 90/60/30 Tagen. Verwenden Sie eine interne CA mit automatischer Verlängerung. Cloud-RADIUS eliminiert dieses Fehlerszenario durch automatisierte Zertifikatsrotation vollständig.

Häufiges Fehlerszenario 2: WAN-Ausfall blockiert Cloud RADIUS

Symptom: Die Authentifizierung schlägt an einem bestimmten Standort fehl; andere Standorte sind nicht betroffen. Das lokale Netzwerk ist betriebsbereit.

Ursache: Die Internetverbindung des Standorts ist ausgefallen, was verhindert, dass Access Points den Cloud RADIUS-Dienst erreichen.

Abhilfe: Implementieren Sie eine duale ISP-Konnektivität oder SD-WAN mit automatischem Failover. Konfigurieren Sie Ausfallsicherheitsrichtlinien für Access Points, um Anmeldedaten zu cachen oder bei kritischen Geräten auf MAB auszuweichen.

Häufiges Fehlerszenario 3: Abweichender Shared Secret

Symptom: Authentifizierungsanfragen werden stillschweigend verworfen; RADIUS-Protokolle zeigen Fehler wie „invalid authenticator“ oder „message authenticator“.

Ursache: Der auf dem Access Point konfigurierte Shared Secret stimmt nicht mit dem auf dem RADIUS-Server konfigurierten Secret überein.

Abhilfe: Nutzen Sie ein zentralisiertes Secret-Management-System (HashiCorp Vault, AWS Secrets Manager), um Konsistenz zu gewährleisten. Validieren Sie Shared Secrets nach jeder Konfigurationsänderung am NAS oder RADIUS-Server.

Häufiges Fehlerszenario 4: Fehlkonfiguration des Supplicants

Symptom: Einzelne Geräte können sich nicht authentifizieren, während andere auf derselben SSID erfolgreich sind.

Ursache: Der 802.1X-Supplicant auf dem fehlerhaften Gerät ist nicht so konfiguriert, dass er dem Zertifikat des RADIUS-Servers vertraut, oder er ist für eine inkompatible EAP-Methode konfiguriert.

Abhilfe: Verteilen Sie die Supplicant-Konfiguration über MDM oder Gruppenrichtlinien, um Konsistenz zu gewährleisten. Stellen Sie für BYOD-Umgebungen eine klare Onboarding-Anleitung bereit. Die WiFi Analytics -Plattform von Purple kann dabei helfen, Muster bei Authentifizierungsfehlern über Ihren gesamten Gerätebestand hinweg zu identifizieren.

Häufiges Fehlerszenario 5: RADIUS-Timeout unter Last

Symptom: Authentifizierungsverzögerungen oder -fehlschläge während Spitzenzeiten (Veranstaltungsbeginn, Schichtwechsel).

Ursache: Der RADIUS-Server ist durch gleichzeitige Authentifizierungsanfragen überlastet; das NAS-Timeout wird überschritten, bevor eine Antwort empfangen wird.

Abhilfe: On-Premise: Skalieren Sie die RADIUS-Serverkapazität vor bekannten Spitzenereignissen; implementieren Sie Verbindungsratenbegrenzungen auf den Access Points. Cloud RADIUS: Überprüfen Sie, ob Ihr Abonnement-Tarif Ihren maximalen Authentifizierungsdurchsatz unterstützt; die meisten Enterprise-Cloud-Plattformen skalieren automatisch.

ROI & geschäftliche Auswirkungen

Total Cost of Ownership: Fünfjahresvergleich

Die folgende Analyse basiert auf einer repräsentativen Einzelhandelskette mit 20 Standorten, ca. 50 Access Points pro Standort und 200 gleichzeitig authentifizierten Geräten pro Standort in Spitzenzeiten.

Kostenkomponente	On-Premise RADIUS (20 Standorte)	Cloud RADIUS (20 Standorte)
Hardware (Server, HA-Paare)	£80.000–£120.000	£0
OS- & Software-Lizenzierung	£10.000–£30.000	£0
Jährliches Abonnement	£0	£18.000–£40.000/Jahr
Strom & Kühlung (5 Jahre)	£15.000–£25.000	£0
Engineering-Zeit (5 Jahre)	£60.000–£100.000	£10.000–£20.000
Gesamtsumme (5 Jahre)	£165.000–£275.000	£100.000–£220.000
Der Unterschied bei der Entwicklungszeit ist der wichtigste Faktor. Ein On-Premise-RADIUS an 20 Standorten erfordert fortlaufendes Patching, Zertifikatsmanagement, Monitoring und Incident Response. Cloud RADIUS reduziert dies auf Richtlinienmanagement und Integrationswartung – ein Bruchteil des Aufwands.

Erfolg messen

Zu den wichtigsten Leistungsindikatoren für Ihr RADIUS-Deployment sollten gehören: Authentifizierungserfolgsrate (Ziel: >99,5 % für Produktionsumgebungen), durchschnittliche Authentifizierungslatenz (Ziel: <100 ms für Cloud, <5 ms für On-Premise-LAN), mittlere Wiederherstellungszeit bei Authentifizierungsausfällen (Ziel: <15 Minuten) und Zertifikatsablauf-Vorfälle (Ziel: Null, erreichbar durch entsprechende Automatisierung).

Für Gastronomie- und Hotelleriebetreiber , die die Guest WiFi -Plattform von Purple nutzen, wirkt sich die Zuverlässigkeit der Authentifizierungsinfrastruktur direkt auf die Zufriedenheitswerte der Gäste aus. Eine Authentifizierungsverzögerung von 2 Sekunden während der Haupt-Check-in-Zeiten ist im Feedback der Gäste messbar. Cloud RADIUS mit korrekt konfigurierten Ausfallsicherheitsrichtlinien übertrifft bei dieser Kennzahl ad-hoc On-Premise-Deployments konsistent.

Unternehmen, die von verteilten On-Premise-FreeRADIUS-Deployments zu Cloud RADIUS migriert sind, berichten konsistent von einer Reduzierung der authentifizierungsbezogenen IT-Vorfälle um 30–50 % und einer erheblichen Verringerung der für die RADIUS-Wartung aufgewendeten Entwicklungsstunden – Stunden, die für strategische Netzwerkverbesserungsprojekte freigesetzt werden. Die Plattform von Purple, die sich in beide Deployment-Modelle integrieren lässt, liefert die WiFi Analytics - und Sensors -Daten, um diese Verbesserungen im Vergleich zu den vor der Migration erfassten Baseline-Metriken zu quantifizieren.

Für Standortbetreiber, die den breiteren Kontext der Netzwerkmodernisierung betrachten, stellen die Wayfinding -Funktionen von Purple und die Integration von Authentifizierungsdaten mit Besucherstrom-Analysen die nächste Wertschöpfungsstufe dar, die eine gut strukturierte RADIUS-Infrastruktur ermöglicht. Authentifizierungsereignisse sind im Kern Präsenzdaten – und wenn sie über die Analyseebene von Purple bereitgestellt werden, werden sie zu einem leistungsstarken Werkzeug, um das Besucherverhalten, die Verweildauer und die Wiederkehrraten an Ihren Standorten zu verstehen.

Schlüsseldefinitionen

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll (RFC 2865), das eine zentrale Authentifizierung, Autorisierung und Kontoführung (AAA) für Benutzer bietet, die sich mit einem Netzwerk verbinden. RADIUS arbeitet über UDP und fungiert als Vermittler zwischen Netzwerkzugriffsgeräten (Access Points, Switches) und dem Identitätsverzeichnis (Active Directory, LDAP, Cloud-IdP).

IT-Teams stoßen immer dann auf RADIUS, wenn sie eine 802.1X-Authentifizierung für WiFi oder kabelgebundene Netzwerke implementieren. Es ist das grundlegende Protokoll für die Netzwerkzugriffskontrolle in Unternehmen und wird für WPA2-Enterprise- und WPA3-Enterprise-Bereitstellungen benötigt.

802.1X

Ein IEEE-Standard für portbasierte Netzwerkzugriffskontrolle, der das Framework für EAP-basierte Authentifizierung definiert. Im WiFi-Kontext erfordert 802.1X drei Komponenten: den Supplicant (Client-Gerät), den Authenticator (Access Point) und den Authentifizierungsserver (RADIUS). Der Access Point blockiert den gesamten Datenverkehr des Clients, bis RADIUS ein Access-Accept zurückgibt.

802.1X ist der Authentifizierungsmechanismus für WPA2-Enterprise- und WPA3-Enterprise-Netzwerke. IT-Teams nutzen ihn, um sicherzustellen, dass sich nur autorisierte Geräte und Benutzer mit dem Unternehmens-WiFi verbinden können, mit dynamischer VLAN-Zuweisung basierend auf der Benutzeridentität.

EAP (Extensible Authentication Protocol)

Ein flexibles Authentifizierungs-Framework, das innerhalb von 802.1X verwendet wird und mehrere Authentifizierungsmethoden unterstützt. Zu den gängigen EAP-Methoden gehören EAP-TLS (zertifikatsbasiert, höchste Sicherheit), PEAP-MSCHAPv2 (passwortbasiert mit Serverzertifikatsvalidierung) und EAP-TTLS (getunnelte Passwortauthentifizierung).

Die Wahl der EAP-Methode hat direkten Einfluss auf das Sicherheitsniveau und die Komplexität der Bereitstellung. EAP-TLS erfordert Client-Zertifikate auf jedem Gerät, was die Bereitstellung komplexer macht, aber die Resistenz gegen Angriffe auf Anmeldedaten erheblich erhöht. IT-Teams in regulierten Branchen (Gesundheitswesen, Finanzwesen) sollten standardmäßig EAP-TLS verwenden.

FreeRADIUS

Der weltweit am häufigsten eingesetzte Open-Source-RADIUS-Server, der die Authentifizierung für Hunderte von Millionen Nutzern weltweit steuert. FreeRADIUS unterstützt eine breite Palette von EAP-Methoden und Backend-Integrationen, ist lizenzkostenfrei erhältlich und läuft auf Linux. Es erfordert eine qualifizierte Administration und dateibasierte Konfiguration.

FreeRADIUS ist die Standardwahl für On-Premise-RADIUS-Bereitstellungen in Nicht-Microsoft-Umgebungen. IT-Teams, die die Entscheidung zwischen Cloud und On-Premise abwägen, sollten prüfen, ob sie über das interne Fachwissen verfügen, um FreeRADIUS effektiv zu betreiben, da Fehlkonfigurationen eine Hauptursache für Authentifizierungsprobleme sind.

NPS (Network Policy Server)

Der integrierte RADIUS-Server von Microsoft, der im Lieferumfang von Windows Server enthalten ist. NPS lässt sich nativ in Active Directory integrieren und unterstützt PEAP-MSCHAPv2 sowie EAP-TLS. Er wird über die Windows Server-GUI verwaltet und ist die Standard-RADIUS-Wahl für Microsoft-zentrierte Umgebungen.

IT-Teams, die eine Windows Server-Infrastruktur betreiben, setzen NPS in der Regel als ihren On-Premise-RADIUS-Server ein. NPS ist eng an die Windows Server-Lizenzierung und das Active Directory gekoppelt, was die Bereitstellung in Microsoft-Umgebungen vereinfacht, aber die Flexibilität in heterogenen oder Cloud-nativen Umgebungen einschränkt.

MAC Authentication Bypass (MAB)

Eine Authentifizierungsmethode, die die MAC-Adresse eines Geräts als Anmeldedaten verwendet. Dies ermöglicht es gerätelosen Systemen (Druckern, IoT-Sensoren, Point-of-Sale-Terminals), die keinen 802.1X-Supplicant ausführen können, sich am Netzwerk zu authentifizieren. Die MAC-Adresse wird mit einer Freigabeliste auf dem RADIUS-Server abgeglichen.

MAB ist für jedes Netzwerk mit IoT-Geräten oder Legacy-Systemen unerlässlich. IT-Teams müssen genaue MAC-Adressbestände pflegen und Prozesse für das Hinzufügen neuer Geräte implementieren. Cloud-RADIUS-Plattformen bieten in der Regel ein zentrales Dashboard für die Verwaltung von MAB-Listen über alle Standorte hinweg, was wesentlich effizienter ist als die standortbezogene Verwaltung von Konfigurationsdateien auf FreeRADIUS.

RadSec (RADIUS over TLS)

Eine Erweiterung des RADIUS-Protokolls (RFC 6614), die RADIUS-Pakete über TLS anstelle von UDP transportiert. RadSec bietet eine vollständige Transportverschlüsselung und gegenseitige Authentifizierung zwischen dem NAS und dem RADIUS-Server, wodurch mehrere gut dokumentierte Sicherheitslücken im traditionellen UDP-basierten RADIUS-Protokoll behoben werden.

Herkömmliches RADIUS verschlüsselt nur das User-Password-Attribut; alle anderen Attribute, einschließlich Benutzernamen und Sitzungsdaten, werden im Klartext übertragen. RadSec ist der moderne, sichere Transportmechanismus für RADIUS und wird von den meisten Enterprise Cloud-RADIUS-Plattformen und modernen Access-Point-Anbietern unterstützt. IT-Teams, die eine neue RADIUS-Infrastruktur aufbauen, sollten RadSec als Standardtransport evaluieren.

VLAN Assignment (RADIUS-assigned VLAN)

Eine RADIUS-Funktion, die ein sich verbindendes Gerät basierend auf dem Authentifizierungsergebnis dynamisch einem bestimmten VLAN zuweist. Der RADIUS-Server gibt die Attribute Tunnel-Type (13=VLAN), Tunnel-Medium-Type (6=802) und Tunnel-Private-Group-ID (VLAN-ID) in der Access-Accept-Antwort zurück, und der Access Point platziert das Gerät im angegebenen VLAN.

Die dynamische VLAN-Zuweisung ist der Mechanismus, mit dem IT-Teams eine Netzwerksegmentierung basierend auf der Benutzeridentität implementieren. Eine einzige SSID kann für mehrere Benutzertypen genutzt werden – Gäste, Mitarbeiter, Auftragnehmer, IoT-Geräte –, wobei jeder Typ basierend auf seinem RADIUS-Authentifizierungsergebnis automatisch im entsprechenden VLAN platziert wird. Dies ist eine PCI-DSS-Anforderung für Netzwerke, die Karteninhaberdaten verarbeiten.

High Availability (HA) RADIUS

Eine RADIUS-Bereitstellungsarchitektur, die sicherstellt, dass Authentifizierungsdienste trotz einzelner Serverausfälle verfügbar bleiben. Zu den gängigen HA-Mustern gehören Active-Active-Clustering (beide Server verarbeiten den Datenverkehr gleichzeitig mit Lastverteilung), Active-Passive-Failover (der sekundäre Server übernimmt, wenn der primäre ausfällt) und geografisch verteilte Redundanz (Server an verschiedenen physischen Standorten).

Hochverfügbarkeit (HA) ist ein kritischer Designfaktor für jede produktive RADIUS-Bereitstellung. IT-Teams müssen ihre Wiederherstellungszeit (Recovery Time Objective, RTO) definieren – also wie schnell die Authentifizierung nach einem Ausfall wiederhergestellt sein muss – und ihre HA-Architektur entsprechend auslegen. Cloud-RADIUS-Anbieter stellen HA als integrierten Service bereit; On-Premise-HA erfordert ein explizites Architekturdesign und laufende Wartung.

Ausgearbeitete Beispiele

Eine europäische Hotelgruppe betreibt 45 Hotels in sechs Ländern. Jedes Hotel verfügt über 150–400 Gästezimmer sowie Konferenzräume. Das zentrale IT-Team besteht aus drei Netzwerktechnikern. Sie betreiben derzeit FreeRADIUS auf virtuellen Maschinen in jedem Hotel – 45 separate Instanzen. Der Ablauf eines Zertifikats in einem Hotel führte während einer großen Konferenz zu einem kompletten Ausfall des Gäste-WiFi. Der CTO möchte diese Art von Vorfällen eliminieren und den Wartungsaufwand reduzieren. Welche Architektur wird empfohlen?

Empfohlene Architektur: Cloud RADIUS mit Purple Gäste-WiFi-Integration

Wählen Sie einen Cloud RADIUS-Anbieter mit europäischer Datenresidenz (zur Erfüllung der GDPR-Vorgaben) und nativer Integration in Ihren bestehenden IdP. Wenn die Hotelgruppe Azure AD für die Mitarbeiteridentität nutzt, wählen Sie eine Plattform mit Unterstützung für den Azure AD LDAP-Connector.
Migrieren Sie zuerst die Gäste-WiFi-SSIDs. Die Gäste-Authentifizierung ist das volumenstärkste Migrationsziel mit dem geringsten Risiko. Konfigurieren Sie das Captive Portal von Purple so, dass es das Onboarding der Gäste (Datenerfassung, Einwilligung, gebrandete Splash-Page) übernimmt und authentifizierte Sitzungen an das Cloud RADIUS-Backend weiterleitet. Dies eliminiert sofort die FreeRADIUS-Wartung pro Hotel für das Gästenetzwerk.
Migrieren Sie die Mitarbeiter-SSIDs Hotel für Hotel, beginnend mit kleineren Standorten. Führen Sie für jedes Hotel eine zweiwöchige parallele Bereitstellung mit einer Test-SSID durch, bevor Sie den produktiven Datenverkehr umschalten.
Konfigurieren Sie die WAN-Überlebensfähigkeit an jedem Standort. Implementieren Sie SD-WAN oder eine duale ISP-Anbindung. Konfigurieren Sie den Wireless-Controller so, dass er Mitarbeiter-Anmeldedaten lokal für bis zu 8 Stunden zwischenspeichert, um sicherzustellen, dass das Hotelpersonal sich auch bei kurzen Internetausfällen authentifizieren kann.
Nehmen Sie die FreeRADIUS-VMs an jedem Standort nach der Migration außer Betrieb. Bewahren Sie VM-Snapshots 30 Tage lang als Rollback-Sicherheitsnetz auf.
Zentralisieren Sie das Richtlinienmanagement über das Cloud RADIUS-Dashboard. Definieren Sie VLAN-Zuweisungsrichtlinien einmal und wenden Sie sie auf alle 45 Hotels an – eine Aufgabe, die zuvor die Bearbeitung von Konfigurationsdateien pro Hotel erforderte.

Erwartete Ergebnisse: Eliminierung von Vorfällen durch abgelaufene Zertifikate (automatisierte Rotation), Reduzierung der RADIUS-bezogenen Engineering-Zeit um ca. 40 % und verbesserte Authentifizierungslatenz in Hotels in Ländern, in denen der Cloud-Anbieter über lokale Edge-Knoten verfügt.

Kommentar des Prüfers: Dieses Szenario ist der klassische Anwendungsfall für eine Cloud RADIUS-Migration. Die wichtigsten Entscheidungsfaktoren sind die verteilte Multi-Site-Struktur (45 Hotels), das kleine zentrale IT-Team (3 Techniker) und der spezifische Schwachpunkt fehlerhafter Zertifikatsverwaltung. Der phasenweise Migrationsansatz – zuerst Gäste-SSIDs, dann Mitarbeiter – entspricht der Best Practice, da er die Auswirkungen während des Übergangs begrenzt. Die Anforderung an die WAN-Überlebensfähigkeit ist im Gastgewerbe von entscheidender Bedeutung: Ein Hotel, das seine Mitarbeiter bei einem Internetausfall nicht für das VLAN des Hotelmanagementsystems authentifizieren kann, steht vor schwerwiegenden betrieblichen Problemen. Die Alternative, das FreeRADIUS vor Ort weiterzubetreiben, wurde geprüft, aber verworfen, da sie den Wartungsaufwand aufrechterhält und die Ursache der Zertifikatsverwaltung nicht behebt.

Ein nationales Sportstadion mit 68.000 Sitzplätzen veranstaltet 30 Großveranstaltungen pro Jahr. Bei ausverkauften Spielen überschreitet die Anzahl der gleichzeitigen WiFi-Nutzer 25.000. Das Stadion verfügt über eine dedizierte 10-Gbps-Internetverbindung, aber das IT-Sicherheitsteam hat eine strikte Vorgabe: Alle Authentifizierungsprotokolle müssen auf britischem Boden verbleiben und dürfen nicht über das öffentliche Internet übertragen werden. Das Stadion betreibt außerdem ein PCI DSS-konformes Point-of-Sale-Netzwerk für Verkaufsstände. Welche RADIUS-Architektur ist angemessen?

Empfohlene Architektur: On-Premise RADIUS mit Active-Active-Cluster und Co-Location DR

Stellen Sie einen primären Active-Active-RADIUS-Cluster im serverraum des Stadions vor Ort bereit. Verwenden Sie zwei physische Server, auf denen FreeRADIUS in einer Active-Active-Konfiguration läuft, mit Lastverteilung über die RADIUS-Serverliste des Wireless-Controllers. Jeder Server sollte in der Lage sein, die gesamte Authentifizierungslast unabhängig zu bewältigen – ausgelegt auf mehr als 3.000 Authentifizierungen pro Minute bei Spitzenzeiten zu Veranstaltungsbeginn.
Stellen Sie einen sekundären Cluster in einer britischen Co-Location-Einrichtung im Umkreis von 30 Meilen um das Stadion bereit, der über eine dedizierte private WAN-Verbindung (nicht über das öffentliche Internet) angebunden ist. Dies bietet ein Disaster Recovery auf Standortebene, ohne die Anforderungen an die Datensouveränität zu verletzen.
Segmentieren Sie die PCI DSS-Umgebung mit einer dedizierten RADIUS-Richtlinie für die Point-of-Sale-SSID. Weisen Sie POS-Geräte über RADIUS-Attribute einem dedizierten VLAN zu. Stellen Sie sicher, dass RADIUS-Accounting-Protokolle für die POS-Authentifizierung mindestens 12 Monate lang aufbewahrt und gemäß PCI DSS-Anforderung 10 vor Ort gespeichert werden.
Implementieren Sie EAP-TLS für die Authentifizierung aller Mitarbeiter und POS-Geräte. Stellen Sie eine interne Zertifizierungsstelle (Microsoft ADCS oder gleichwertig) bereit, um Client-Zertifikate auszustellen und zu verwalten. Konfigurieren Sie die automatische Zertifikatsverlängerung mit Warnmeldungen 90 Tage im Voraus.
Implementieren Sie RadSec (RADIUS über TLS) zwischen Access Points und dem On-Premise RADIUS-Cluster, um den Authentifizierungsverkehr im internen Netzwerk zu verschlüsseln – besonders wichtig in einer hochverdichteten öffentlichen Umgebung.
Stellen Sie Kapazitäten vor Großveranstaltungen bereit. Arbeiten Sie mit dem Veranstaltungsteam des Stadions zusammen, um 72 Stunden im Voraus bestätigte Besucherzahlen zu erhalten, und validieren Sie die RADIUS-Serverkapazität im Vergleich zu den erwarteten Spitzenauthentifizierungsraten.

Erwartete Ergebnisse: Authentifizierungslatenz im Sub-Millisekundenbereich bei Spitzenzeiten zu Veranstaltungsbeginn, vollständige Einhaltung der Datensouveränität, PCI DSS-konforme Authentifizierungsprotokollierung und eine Verfügbarkeit von über 99,99 % durch die Active-Active-Cluster-Architektur.

Kommentar des Prüfers: Dieses Szenario stellt das stärkste verbleibende Argument für On-Premise RADIUS dar. Die Kombination aus Anforderungen an die Datensouveränität, PCI DSS-Konformität, extremer Spitzenlast und einer dedizierten Breitband-Internetverbindung macht On-Premise zur richtigen Wahl. Der Co-Location-DR-Standort ist unerlässlich – eine On-Premise-Bereitstellung an einem einzigen Standort ohne Redundanz außerhalb des Standorts würde den Verfügbarkeitsstandards von Unternehmen nicht entsprechen. Die wichtigste Erkenntnis ist, dass die Anforderung des Stadions an die Datensouveränität eine harte Einschränkung darstellt, die die meisten Cloud RADIUS-Anbieter (die den Datenverkehr über eine globale Infrastruktur leiten) ausschließt. Die Empfehlung von EAP-TLS gegenüber PEAP wird durch die PCI DSS-Umgebung begründet – die zertifikatsbasierte Authentifizierung ist die sicherere Methode für Karteninhaber-Datenumgebungen.

Übungsfragen

Q1. Eine nationale Apothekenkette betreibt 320 Filialen in ganz Großbritannien. Jede Filiale verfügt über eine einzige Internetverbindung eines großen ISP ohne Failover. Die Kette nutzt Microsoft 365 und Azure Active Directory für die Identitätsverwaltung aller Mitarbeiter. Das IT-Team aus 8 Technikern verwaltet derzeit FreeRADIUS-Instanzen auf einer virtuellen Maschine in jeder Filiale. Der CISO hat darauf hingewiesen, dass 23 % der Filialen über RADIUS-Zertifikate verfügen, die innerhalb von 90 Tagen ablaufen. Der CTO möchte dieses Problem lösen und den laufenden Wartungsaufwand reduzieren. Welche RADIUS-Architektur empfehlen Sie und welches ist die wichtigste infrastrukturelle Änderung, die vor der Migration erforderlich ist?

Hinweis: Berücksichtigen Sie die Anforderungen an die WAN-Ausfallsicherheit sorgfältig – was passiert mit dem Betrieb in den Filialen, wenn die Internetverbindung nach der Bereitstellung von Cloud RADIUS ausfällt?

Musterlösung anzeigen

Empfohlene Architektur: Cloud RADIUS integriert mit Azure Active Directory, um die 320 FreeRADIUS-Instanzen zu ersetzen. Die Azure AD-Integration ist angesichts der bestehenden Microsoft 365-Bereitstellung unkompliziert, und Cloud RADIUS beseitigt die Krise bei der Zertifikatsverwaltung sofort durch automatisierte Rotation.

Kritische Infrastrukturänderung vor der Migration: WAN-Ausfallsicherheit. Jede Filiale verfügt derzeit über eine einzige ISP-Verbindung ohne Failover. Cloud RADIUS ist vollständig von der Internetverbindung abhängig. Implementieren Sie vor der Migration einer Filiale SD-WAN mit Dual-ISP-Failover oder konfigurieren Sie zumindest den Wireless-Controller so, dass er die Anmeldedaten der Mitarbeiter lokal für 8–12 Stunden zwischenspeichert. Ohne diese Maßnahme kann eine Filiale, die die Internetverbindung verliert, die Mitarbeiter nicht am Unternehmensnetzwerk authentifizieren – was möglicherweise den Zugriff auf Point-of-Sale-Systeme, die Bestandsverwaltung und andere netzwerkabhängige Abläufe blockiert.

Migrationsreihenfolge: (1) Bereitstellung von SD-WAN oder Zwischenspeicherung von Anmeldedaten in allen 320 Filialen. (2) Migration der 23 % der Filialen mit bevorstehendem Zertifikatsablauf zuerst – dies behebt das unmittelbare Risiko. (3) Migration der verbleibenden Filialen in Chargen von 20–30 pro Woche. (4) Stilllegung der FreeRADIUS-VMs nach der Migration. Erwartetes Ergebnis: null Vorfälle mit abgelaufenen Zertifikaten, 60–70 % Reduzierung des RADIUS-bezogenen Engineering-Aufwands, zentralisierte Richtlinienverwaltung für alle 320 Filialen.

Q2. Ein Konferenzzentrum-Betreiber betreibt einen einzigen Flaggschiff-Veranstaltungsort mit einer Kapazität von 5.000 Delegierten. Der Veranstaltungsort beherbergt 200 Events pro Jahr, von kleinen Vorstandssitzungen bis hin zu großen internationalen Konferenzen. Die Spitzenzahl der gleichzeitigen WiFi-Benutzer erreicht bei Großveranstaltungen 4.500. Der Veranstaltungsort verfügt über eine dedizierte 1-Gbps-Internetverbindung mit 99,9 % SLA. Das IT-Team besteht aus zwei Netzwerktechnikern. Es gibt keine spezifischen Anforderungen an die Datensouveränität. Der aktuelle On-Premise-FreeRADIUS-Server nähert sich dem Ende seines Lebenszyklus. Sollten sie ihn durch eine neue On-Premise-Bereitstellung ersetzen oder zu Cloud RADIUS migrieren?

Hinweis: Berücksichtigen Sie sowohl das Spitzenlastprofil als auch die Teamgröße. Sind 4.500 gleichzeitige Benutzer an einem einzigen Standort ein starkes Argument für On-Premise, oder geben die Teamgröße und der Verwaltungsaufwand den Ausschlag?

Musterlösung anzeigen

Empfohlene Architektur: Cloud RADIUS. Trotz des Profils mit nur einem Standort und hoher Dichte machen die Kombination aus einem kleinen IT-Team (2 Techniker), dem Fehlen von Anforderungen an die Datensouveränität und einer zuverlässigen dedizierten Internetverbindung Cloud RADIUS zur besseren Wahl.

Begründung: Die Spitzenlast von 4.500 gleichzeitigen Benutzern liegt weit innerhalb der Durchsatzkapazität von Enterprise-Cloud-RADIUS-Plattformen, die für weitaus höhere Volumina ausgelegt sind. Die zusätzliche Latenz von 5–20 ms durch das Cloud-Routing ist in einer Konferenzumgebung nicht wahrnehmbar. Die dedizierte 1-Gbps-Internetverbindung mit einem SLA von 99,9 % bietet eine ausreichende WAN-Zuverlässigkeit für die Abhängigkeit von Cloud RADIUS.

Der entscheidende Faktor ist die Teamgröße. Zwei Techniker, die einen On-Premise-FreeRADIUS-Ersatz verwalten – einschließlich Hardwarebeschaffung, OS-Härtung, Zertifikatsverwaltung, EAP-Konfiguration und laufender Wartung –, bedeuten einen erheblichen laufenden Aufwand für ein kleines Team. Cloud RADIUS reduziert dies auf die Richtlinienverwaltung und entlastet beide Techniker für die umfassenderen Anforderungen der Netzwerkinfrastruktur des Veranstaltungsorts.

Implementierungshinweis: Konfigurieren Sie die Zwischenspeicherung von Anmeldedaten auf dem Wireless-Controller für die SSID des Betriebspersonals des Veranstaltungsorts, um die Überlebensfähigkeit bei kurzen Internetunterbrechungen zu gewährleisten. Stellen Sie sicher, dass der Cloud-RADIUS-Anbieter über einen Edge-Knoten in Großbritannien oder Europa verfügt, um die Authentifizierungslatenz für das Szenario mit hoher Veranstaltungsdichte zu minimieren.

Q3. Ein regionaler NHS-Trust betreibt 12 Krankenhausstandorte in einer Grafschaft. Zu den Authentifizierungsanforderungen gehören: (1) Mitarbeiterzugriff auf das klinische Netzwerk über 802.1X mit EAP-TLS, (2) Gast-/Patienten-WiFi über ein Captive Portal und (3) Authentifizierung medizinischer Geräte über MAC Authentication Bypass. Das Information-Governance-Team des Trusts hat vorgeschrieben, dass alle patientenbezogenen Daten, einschließlich der Authentifizierungsprotokolle, in vom NHS genehmigten Rechenzentren in England verbleiben müssen. Der Trust verwendet On-Premise Active Directory und plant derzeit keine Migration zu Azure AD. Welche Architektur empfehlen Sie?

Hinweis: Dieses Szenario weist mehrere harte Einschränkungen auf. Identifizieren Sie jede einzelne und bestimmen Sie, ob sie Cloud RADIUS vollständig oder nur teilweise ausschließt.

Musterlösung anzeigen

Empfohlene Architektur: Hybrid – On-Premise RADIUS für die Authentifizierung von klinischem Personal und medizinischen Geräten; Cloud RADIUS (NHS-konform) oder On-Premise für das Gast-/Patienten-WiFi.

Analyse der Einschränkungen:

Datensouveränität (vom NHS genehmigte englische Rechenzentren): Dies schließt die meisten kommerziellen Cloud-RADIUS-Anbieter aus, es sei denn, sie bieten eine NHS-konforme Datenresidenz. Einige Anbieter bieten NHS-spezifische Bereitstellungen an; diese sollten evaluiert werden. Wenn keine konforme Cloud-Option existiert, ist On-Premise für alle Authentifizierungen erforderlich.
On-Premise Active Directory ohne Cloud-Synchronisierung: Dies ist eine harte Einschränkung für die Cloud-RADIUS-Integration. Ohne Azure AD Connect oder ein Äquivalent kann Cloud RADIUS das Mitarbeiterverzeichnis des Trusts nicht abfragen. Für die Mitarbeiterauthentifizierung ist On-Premise RADIUS erforderlich.
EAP-TLS für klinisches Personal: Wird sowohl von On-Premise FreeRADIUS als auch von NPS unterstützt. Erfordert eine interne PKI (Microsoft ADCS wird für eine AD-integrierte Umgebung empfohlen).

Empfohlene Bereitstellung: Stellen Sie On-Premise RADIUS (NPS oder FreeRADIUS) an jedem der 12 Krankenhausstandorte in Aktiv-Passiv-Paaren bereit, integriert in das On-Premise Active Directory des Trusts. Verwenden Sie RADIUS-zugewiesene VLANs, um den Datenverkehr von klinischen, administrativen und medizinischen Geräten zu segmentieren. Stellen Sie für das Gast-/Patienten-WiFi das Captive Portal von Purple für eine GDPR-konforme Datenerfassung und Einwilligungsverwaltung bereit – dies erfordert kein RADIUS für die Gästethauthentifizierung und umgeht die Einschränkung der Datensouveränität für das Gästenetzwerk vollständig. MAB-Richtlinien für medizinische Geräte werden auf dem On-Premise-RADIUS-Server verwaltet, wobei die MAC-Adresslisten zentral über ein Konfigurationsmanagement-Tool gepflegt werden.

Wichtiges zu minimierendes Risiko: Zertifikatsverwaltung für EAP-TLS an 12 Standorten. Stellen Sie Microsoft ADCS mit automatischer Zertifikatsregistrierung über Gruppenrichtlinien bereit, um sicherzustellen, dass alle klinischen Geräte Zertifikate automatisch erhalten und erneuern.

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.