Standortübergreifende RADIUS-Migration: Sequenzierung von Standorten, Access Points und Richtlinien

Sie können einen Standortverbund mit mehreren Standorten in vier Phasen auf Cloud-RADIUS umstellen, ohne dass ein Stichtag erforderlich ist, an dem alte und neue Server parallel laufen. Jede SSID führt beide auf, und jedes Gerät vertraut dem neuen Serverzertifikat. Jeder Standort wechselt unter 802.1X mit einem schriftlichen Abnahmetest. Bei Purple ist die Umstellung selbst meist eine Aufgabe für ein Wochenende.

Was ändert sich bei einer RADIUS-Migration über mehrere Standorte hinweg und was bleibt gleich?

Der Endzustand ist eine einzige Cloud-RADIUS-Richtlinie, die jeden Standort bedient, wobei die Identität das VLAN festlegt. RADIUS, definiert in RFC 2865, ist das Protokoll, mit dem Ihre Access Points einen Server fragen, ob ein Gerät beitreten darf. Der Server akzeptiert oder lehnt das Gerät ab. Er kann auch Attribute wie das VLAN zurückgeben, also das Netzwerksegment, auf dem das Gerät landet.

In einem sicheren Netzwerk läuft dieser Austausch innerhalb von 802.1X, dem Standard für die portbasierte Netzwerkzugriffskontrolle. 802.1X überträgt EAP (Extensible Authentication Protocol) zwischen dem Gerät, dem Access Point und dem Server. EAP-TLS, definiert in RFC 5216, authentifiziert beide Seiten mit Zertifikaten. PEAP hüllt einen Kennwortaustausch in einen TLS-Tunnel ein.

Vier Dinge ändern sich:

• Jeder Access Point oder Controller verweist auf eine neue Serveradresse und ein neues Shared Secret. RADIUS bezeichnet dieses Gerät als NAS (Network Access Server).
• Geräte sehen während des EAP-Handshakes ein neues Serverzertifikat.
• Die Richtlinie liest Gruppen aus Microsoft Entra ID, Okta oder Google Workspace statt aus einem lokalen Verzeichnis.
• Protokolle werden in eine neue Konsole verschoben.

Die Dinge, die gleich bleiben, sind wichtiger. Sie behalten Ihre Access Points, SSID-Namen, VLAN-IDs, Switch-Trunks und Firewall-Zonen. Niemand ändert ein Kennwort oder tritt einem neuen Netzwerk bei.

Der gleiche Ansatz gilt für alle drei Netzwerke auf Purple Access. In offenen Netzwerken autorisieren viele Captive Portals Geräte über RADIUS. Sichere Netzwerke verwenden EAP-TLS oder PEAP. In xPSK-Netzwerken weist RADIUS jedem Gerät oder Bewohner seinen eigenen Pre-Shared Key zu. Dieser Leitfaden folgt dem sicheren Netzwerk, da es das größte Risiko birgt.

{"tone":"warning","title":"Das Risiko, das schmerzt: Serverzertifikatsvertrauen","text":"Geräte mit EAP-TLS oder PEAP überprüfen das RADIUS-Serverzertifikat, und viele vertrauen nur der Zertifizierungsstelle des alten Servers. Übertragen Sie die neue CA auf jedes Geräteprofil, bevor der erste Standort umzieht, da diese Geräte sonst die Verbindung verweigern und es kontinuierlich erneut versuchen."}

Sobald Sie das Zertifikatsvertrauen geregelt haben, besteht der Rest der Migration aus Konfigurationsarbeit und Haltefristen.

Was muss vor Phase 1 erfüllt sein?

Fünf Bedingungen müssen erfüllt sein, bevor eine Richtlinie erstellt wird. Wenn eine fehlt, führt dies in einer späteren Phase zu Problemen.

Ein vollständiges NAS-Inventar

Erfassen Sie jedes Gerät, das Anfragen an den alten Server sendet. Dazu gehören Access Points, Wireless-Controller, Switches mit kabelgebundenem 802.1X und VPN-Gateways. Erstellen Sie die Liste anhand der RADIUS-Client-Liste des alten Servers, nicht anhand des Netzwerkdiagramms. Wenn ein NAS im Inventar fehlt, können Sie den alten Server in Phase 4 nicht abschalten.

Eine Richtlinien-Map, Zeile für Zeile

Schreiben Sie jede Regel auf, die der alte Server anwendet, einschließlich ihrer Bedingung, ihres Ergebnisses und der von ihr zurückgegebenen Attribute. Typische Zeilen sehen wie folgt aus: Mitarbeitergruppe zu Mitarbeiter-VLAN, Auftragnehmer zu einem eingeschränkten VLAN, Unternehmens-Laptops per Zertifikat zum Unternehmens-VLAN. Notieren Sie, welche Attribute das VLAN tragen. RFC 3580 definiert das Standard-Set: Tunnel-Type, Tunnel-Medium-Type und Tunnel-Private-Group-ID. Einige Umgebungen verwenden stattdessen herstellerspezifische Attribute, die Sie exakt spiegeln müssen.

Ein Zertifikatsplan

Bestimmen Sie, welche Zertifizierungsstelle (CA) das neue Serverzertifikat ausstellt. Auf verwalteten Geräten verteilen Sie diese CA über Microsoft Intune, Jamf oder Ihre Mobile-Device-Management-Plattform (MDM), bevor Sie Standorte migrieren. Für EAP-TLS muss der neue Server auch der CA vertrauen, die Ihre Gerätezertifikate ausgestellt hat.

Eine Identitätsquelle, die der neue Server lesen kann

Verbinden Sie Ihren Identitätsanbieter und bestätigen Sie, dass jede Gruppe in der Richtlinien-Map dort vorhanden ist. Wenn eine Gruppe nur auf dem alten Server existiert, erstellen Sie diese zuerst im Identitätsanbieter neu.

Erreichbarkeit, Verantwortliche und Änderungsfenster

Jeder Standort benötigt einen Netzwerkpfad zum Cloud-Server unter Verwendung der Adressen und Ports aus der Onboarding-Dokumentation von Purple. Benennen Sie für jeden Standort einen Verantwortlichen und vereinbaren Sie Änderungsfenster mit den Standortleitern. Definieren Sie den Rollback-Auslöser, bevor Änderungen vorgenommen werden.

{"title":"Checkliste für die RADIUS-Migration an mehreren Standorten","groups":[{"heading":"Vor Phase 1","items":[{"text":"Exportieren Sie die RADIUS-Clientliste des alten Servers und gleichen Sie diese mit dem NAS-Inventar ab","why":"Ein vergessenes NAS blockiert die Außerdienststellung"},{"text":"Erfassen Sie jede Richtlinienregel: Bedingung, Ergebnis und zurückgegebene Attribute"},{"text":"Bestätigen Sie, dass jede Richtliniengruppe in Microsoft Entra ID, Okta oder Google Workspace existiert"},{"text":"Verteilen Sie die neue Server-CA über Ihr MDM auf verwaltete Geräte"},{"text":"Öffnen Sie die Pfade in der Onboarding-Dokumentation von Purple an jedem Standort"},{"text":"Benennen Sie einen Verantwortlichen sowie ein Wartungsfenster pro Standort und vereinbaren Sie den Rollback-Auslöser schriftlich"}]},{"heading":"Phase 1: Aufbau","items":[{"text":"Frieren Sie Richtlinienänderungen auf dem alten Server ein"},{"text":"Erstellen Sie jede Richtlinienzeile auf dem neuen Server neu"},{"text":"Testen Sie eine Identität pro Zeile gegen beide Server und vergleichen Sie die Antworten"}]},{"heading":"Phase 2 und 3: Pilotprojekt und Wellen","items":[{"text":"Erfassen Sie vor der Umstellung eine Baseline der Ablehnungsrate pro Standort"},{"text":"Fügen Sie den neuen Server neben dem alten auf jedem SSID hinzu"},{"text":"Bestätigen Sie, dass sich jede Geräteklasse am neuen Server authentifiziert"},{"text":"Halten Sie jede Welle für einen vollständigen Geschäftszyklus aufrecht, bevor die nächste folgt"}]},{"heading":"Phase 4: Außerdienststellung","items":[{"text":"Entfernen Sie den alten Server von jedem SSID und NAS"},{"text":"Bestätigen Sie null Anfragen auf dem alten Server für den vereinbarten Ruhezeitraum"},{"text":"Exportieren und speichern Sie die alten Serverprotokolle gemäß Ihrer Aufbewahrungsrichtlinie"},{"text":"Ziehen Sie die mit dem alten Server verwendeten Shared Secrets zurück"},{"text":"Aktualisieren Sie das Runbook und legen Sie das Protokoll des Abschlusstests jedes Standorts ab"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

Wie lauten die 4 Phasen in Reihenfolge?

Der Plan umfasst vier Phasen. Jede Phase endet mit einem Abschlusstest, den Sie bestehen oder nicht bestehen können. Nichts wird in die nächste Phase verschoben, bis der Test bestanden ist - so vermeiden Sie eine schlagartige Big-Bang-Umstellung.

{"kind":"timeline","direction":"lr","caption":"Eine beispielhafte Umgebung mit 40 Standorten: vier Phasen, die jeweils mit einem Abschlusstest enden","alt":"Zeitstrahl mit Vorbereitung, Phase 1 Aufbau, Phase 2 Pilot, Phase 3 Wellen und Phase 4 Außerbetriebnahme über etwa 12 Wochen.","nodes":[{"id":"p0","label":"Vor Phase 1","sub":"Inventar, Richtlinien-Map, CA-Push, Identitätsquelle","tone":"neutral","when":"Wochen 1-2"},{"id":"p1","label":"Phase 1: Aufbau und Spiegelung","sub":"Richtlinie auf Cloud-RADIUS neu erstellt, Lab-Antworten stimmen überein","tone":"brand","when":"Woche 3"},{"id":"p2","label":"Phase 2: Pilotstandort","sub":"Ein Standort, alter Server bleibt als sekundärer Server bestehen","tone":"brand","when":"Wochen 4-5"},{"id":"p3","label":"Phase 3: Wellen","sub":"Fünf, dann 10, dann die restlichen 24 Standorte","tone":"brand","when":"Wochen 6-10"},{"id":"p4","label":"Phase 4: Außerbetriebnahme","sub":"Null Anfragen an den alten Server, dann Abschaltung","tone":"success","when":"Wochen 11-12"}],"edges":[{"from":"p0","to":"p1","label":"Voraussetzungen erfüllt"},{"from":"p1","to":"p2","label":"Lab-Antworten stimmen überein"},{"from":"p2","to":"p3","label":"Pilot-Abschlusstest"},{"from":"p3","to":"p4","label":"alle Standorte umgestellt"}]}

{"caption":"Phasenplan für eine RADIUS-Migration über mehrere Standorte","asOf":"2026-06-10","columns":[{"key":"phase","label":"Phase"},{"key":"scope","label":"Umfang"},{"key":"owner","label":"Verantwortlicher"},{"key":"exit","label":"Abschlusstest"}],"rows":[["Vor Phase 1","NAS-Inventar, Richtlinien-Map, CA-Push, Identitätsquelle, Standortpfade","IT-Manager mit Identity-and-Access-Leiter","Jedes NAS erfasst, jede Richtliniengruppe im Identitätsanbieter, neue CA auf verwalteten Geräten"],["Phase 1: Aufbau","Richtlinie auf Cloud-RADIUS neu erstellt, kein Live-Traffic","Identity-and-Access-Leiter","Eine Test-Identität pro Zeile erhält dieselbe Antwort und VLAN von alt und neu"],["Phase 2: Pilot","Ein repräsentativer Standort, neuer Server primär, alter sekundär","Netzwerkarchitekt","Ein Geschäftszyklus ohne unerklärliche Ablehnungen und jede Geräteklasse auf dem neuen Server gesehen"],["Phase 3: Wellen","Verbleibende Standorte in wachsenden Wellen, gruppiert nach Konsolenvorlage","Netzwerkarchitekt mit Standortverantwortlichen","Jede Welle besteht den Pilot-Abschlusstest, bevor die nächste startet"],["Phase 4: Außerbetriebnahme","Alter Server von allen SSIDs und NAS entfernt","IT-Manager","Null Anfragen an den alten Server während der Ruhephase, Protokolle aufbewahrt, Secrets ausgemustert"]],"footnote":"Verantwortliche sind Rollen, keine namentlich genannten Personen. Setzen Sie die Ruhephase auf mindestens einen Re-Authentifizierungszyklus plus eine Arbeitswoche.","download":{"filename":"radius-migration-phase-plan.csv"}}

Was passiert in den einzelnen Phasen?

Phase 1: Aufbau und Spiegelung der Richtlinie

Erstellen Sie die Richtlinien-Map auf dem neuen Server neu, bevor eine Live-Anfrage ihn erreicht. Verbinden Sie den Identitätsanbieter und erstellen Sie dann jede Zeile mit ihrer Bedingung, ihrem Ergebnis und den zurückgegebenen Attributen neu. Halten Sie die VLAN-IDs identisch, damit sich die Switch- und Firewall-Konfiguration niemals ändert.

Testen Sie jede Zeile aus einem Labor. Verwenden Sie eapol_test, ein Tool aus dem wpa_supplicant-Projekt. Es sendet einen echten EAP-Austausch an einen RADIUS-Server und gibt die Antwort aus. Führen Sie eine Identität pro Zeile gegen beide Server aus und vergleichen Sie die Antworten. Der Abschlusstest ist eine Übereinstimmung in jeder Zeile, mit derselben Annahme oder Ablehnung und demselben VLAN.

Phase 2: Pilotierung an einem Standort

Wählen Sie einen Standort, der den gesamten Bestand repräsentiert, nicht den einfachsten. Er sollte jede von Ihnen genutzte Geräteklasse enthalten, auch die schwierigen. Denken Sie an Handscanner, Zahlungsterminals im WiFi und ältere Laptops. Sie benötigen außerdem jemanden vor Ort, der ein Gerät auf Anfrage testen kann.

Fügen Sie den neuen Server neben dem alten hinzu, testen Sie ihn und machen Sie den neuen Server zum primären Server. Belassen Sie dies für einen vollständigen Geschäftszyklus. Für ein Hotel bedeutet das eine Woche voller Schichtmuster. Für ein Büro bedeutet es eine Woche lang Anmeldungen am Montagmorgen. Der Pilotversuch ist bestanden, wenn zwei Dinge zutreffen. Erstens: Jede Geräteklasse hat sich auf dem neuen Server authentifiziert. Zweitens: Die Ablehnungsrate ist nicht schlechter als Ihre Baseline.

Phase 3: Umstellung des Bestands in Wellen

Machen Sie jede Welle größer als die vorherige, sobald die früheren erfolgreich abgeschlossen sind. Ein Bestand von 40 Standorten könnte einen Piloten umstellen, dann fünf, dann 10 und schließlich die restlichen 24. Gruppieren Sie jede Welle nach Konsolenvorlage oder -gruppe, sodass eine Änderung jeden darin enthaltenen Standort erreicht. Meraki-Konfigurationsvorlagen, Juniper Mist-WLAN-Vorlagen und HPE Aruba Central-Gruppen eignen sich alle für diesen Ansatz.

Führen Sie die Umstellung durch, während das Personal vor Ort ist, nicht um 3 Uhr morgens. Eine Änderung, die niemand bis zum Morgen testet, ist eine Änderung, die Sie nicht getestet haben. Vermeiden Sie es, andere Netzwerkänderungen in dasselbe Fenster zu packen.

Phase 4: Außerbetriebnahme des alten Servers

Entfernen Sie den alten Server aus jedem SSID und jedem NAS im Inventar und beobachten Sie dann dessen Protokolle. Die Anfragen sollten auf null sinken. Alles, was noch eingeht, stammt von einem NAS, das Sie übersehen haben. Halten Sie die Ruhephase mindestens für einen Re-Authentifizierungszyklus plus eine Arbeitswoche aufrecht. Exportieren Sie dann die Protokolle gemäß Ihrer Aufbewahrungsrichtlinie, fahren Sie den Server herunter und ziehen Sie seine Shared Secrets zurück.

Praxisbeispiel: Eine Gruppe von 40 Hotels auf Cisco Meraki

Nehmen wir eine Gruppe von 40 Hotels, die Mitarbeiter-WiFi auf Cisco Meraki betreibt. Sie nutzt PEAP gegen einen On-Premises-RADIUS-Server in der Zentrale. Jede Anfrage läuft über das WAN zu einem Gebäude, sodass ein Ausfall in der Zentrale das Mitarbeiter-WiFi in jedem Hotel lahmlegt.

Die Gruppe spielt das neue CA in Woche eins über ihr MDM aus. Sie baut fünf Richtlinienzeilen auf dem Cloud-RADIUS gegen Microsoft Entra ID neu auf und führt dann einen Pilotversuch in einem Stadthotel mit 120 Zimmern durch. Es folgen Wellen von fünf, 10 und 24 Hotels, von denen jede eine Meraki-Konfigurationsvorlage ist. Ein Hotel führt für einen Nachmittag einen Rollback durch, weil ein Tablet des Etagendienstes nur dem alten CA vertraut. Eine Woche später wird es erneut umgestellt.

Das Ergebnis:

• Alle 40 Hotels werden in sechs Änderungsfenstern umgestellt.
• Ein Standort führt einmal einen Rollback durch.
• Die Zentrale befindet sich nicht mehr im Authentifizierungspfad.

Wie laufen die alten und neuen RADIUS-Server nebeneinander?

Der Parallelbetrieb hängt davon ab, wie Access Points ein Failover durchführen. Ein NAS sendet jede Anfrage an den ersten Server in seiner Liste. Er versucht den nächsten Server erst, wenn der erste nicht innerhalb des Timeouts antwortet.

Ein Access-Reject gilt als Antwort, nicht als Fehler, sodass das NAS die Anfrage nicht an anderer Stelle erneut versucht. Das hat zwei Konsequenzen:

• Beide Server müssen dieselbe Antwort geben. Wenn sie sich unterscheiden, hängt das Nutzererlebnis eines Geräts davon ab, welcher Server zufällig geantwortet hat.
• Der Parallelbetrieb ist ein Sicherheitsnetz, kein Test. Testen Sie Richtlinien in Phase 1 und beim Pilotprojekt. Testen Sie nicht, indem Sie abwarten, wie sich das Failover verhält.

Überprüfen Sie Timeouts vor der Migration des ersten Standorts. Ein Cloud-Server ist weiter entfernt als ein Server in Ihrem Serverraum. Vergleichen Sie die NAS-Timeout- und Wiederholungseinstellungen jedes Standorts mit dessen Paketumlaufzeit (Round-Trip Time). Wenn die Einstellungen zu knapp bemessen sind, wird ohne tatsächlichen Grund ein Failover der Anfragen auf den alten Server durchgeführt, was Probleme verschleiert. Stellen Sie RADIUS Accounting im selben Moment wie die Authentifizierung auf den neuen Server um, damit Sitzungsdatensätze an einem zentralen Ort liegen.

Die Umstellung an jedem Standort besteht einfach darin, die Reihenfolge der beiden Server zu tauschen. Diese Schritte gelten für jeden Standort, wobei die Herstellerunterschiede in Schritt 2 dargestellt sind.

{"title":"Einen Standort ohne Stichtagsumstellung umstellen","steps":[{"title":"Bereitschaft des Standorts bestätigen","body":"Prüfen Sie den Standort anhand der Migrations-Checkliste: NAS aufgeführt, neue CA auf verwalteten Geräten, Pfad zu Purple offen, Verantwortlicher vor Ort.","check":"Jede Voraussetzung für den Standort ist abgehakt."},{"title":"Den neuen Server neben dem alten hinzufügen","body":"Fügen Sie Purple Cloud RADIUS zur RADIUS-Serverliste der SSID hinzu. Verwenden Sie dabei das von Purple für den Standort ausgegebene Shared Secret. Belassen Sie den alten Server vorerst an erster Stelle.","check":"Die Konsole zeigt beide Server für die SSID an.","variants":[{"label":"Meraki","body":"Fügen Sie den Server im Meraki Dashboard in den Zugriffskontrolleinstellungen der SSID hinzu, idealerweise in der Konfigurationsvorlage."},{"label":"Aruba","body":"Fügen Sie den Server in HPE Aruba Central der vom WLAN verwendeten Authentifizierungsserver-Gruppe hinzu."},{"label":"Ruckus","body":"Fügen Sie den Server dem vom WLAN verwendeten AAA-Serverprofil als sekundären Server hinzu."},{"label":"Mist","body":"Fügen Sie den Server im Juniper Mist Portal den RADIUS-Authentifizierungsserver des WLANs hinzu, idealerweise in der WLAN-Vorlage."},{"label":"UniFi","body":"Fügen Sie den Server in der UniFi Network Anwendung dem RADIUS-Profil hinzu, das dem WiFi Netzwerk zugewiesen ist."}]},{"title":"Vor dem Wechsel testen","body":"Senden Sie von einem als RADIUS-Client registrierten Test-Host eine Identität pro Richtlinienzeile an den neuen Server.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Jede Identität erhält Access-Accept oder Access-Reject gemäß der Richtlinienzuordnung mit dem erwarteten VLAN."},{"title":"Reihenfolge tauschen","body":"Machen Sie den neuen Server zum primären Server und behalten Sie den alten Server als sekundären Server bei. Das ist die Umstellung.","check":"Die Protokolle des neuen Servers zeigen Anfragen von jedem Access Point am Standort."},{"title":"Einen Geschäftszyklus lang beobachten","body":"Vergleichen Sie die Ablehnungsrate mit Ihrer Baseline und bestätigen Sie, dass sich jede Geräteklasse authentifiziert hat.","check":"Keine unerklärlichen Ablehnungen und der Standort besteht seinen Abschlusstest."}]}

Wie führen Sie einen Rollback für einen Standort oder eine Welle durch?

Ein Rollback ist die Umstellung in umgekehrter Reihenfolge: Sie setzen den alten Server wieder an die erste Stelle. Auf jeder oben genannten Konsole ist dies eine einzige Konfigurationsänderung. Dies funktioniert nur, wenn der alte Server weiterhin unverändert läuft und seine Shared Secrets intakt sind. Aus diesem Grund erfolgt die Außerdienststellung ganz zum Schluss. Das ist auch der Grund, warum Sie die Richtlinie auf dem alten Server zu Beginn von Phase 1 einfrieren.

Vereinbaren Sie die Auslöser, bevor Sie beginnen. Typische Auslöser sind:

• Eine Geräteklasse, die sich nicht verbinden kann und für die es am selben Tag keine Lösung gibt.
• VLAN-Zuweisungen, die von der Richtlinienzuordnung abweichen.
• Eine Ablehnungsrate über der Baseline, die Sie innerhalb des Änderungsfensters nicht erklären können.

{"title":"Fortfahren, pausieren oder eine Welle zurückrollen","start":"q1","nodes":[{"id":"q1","question":"Schlägt eine Geräteklasse auf dem neuen Server fehl, die auf dem alten erfolgreich war?","help":"Vergleichen Sie Ablehnungen nach Gerätetyp mit der vor der Umstellung erfassten Baseline.","options":[{"label":"Ja","to":"q2"},{"label":"Nein","to":"q3"}]},{"id":"q2","question":"Beschränkt sich der Fehler auf eine Geräteklasse mit einer bekannten Lösung?","help":"Eine fehlende Zertifizierungsstelle (CA) in einem Profil ist eine bekannte Lösung. Ablehnungen über mehrere Klassen hinweg sind es nicht.","options":[{"label":"Ja","to":"o2"},{"label":"Nein","to":"o3"}]},{"id":"q3","question":"Landet jede Testidentität an jedem Standort der Welle im erwarteten VLAN?","options":[{"label":"Ja","to":"q4"},{"label":"Nein","to":"o3"}]},{"id":"q4","question":"Hat die Welle einen vollständigen Geschäftszyklus ohne unerklärte Ablehnungen durchlaufen?","options":[{"label":"Ja","to":"o1"},{"label":"Nein","to":"o2"}]},{"id":"o1","outcome":"Fortfahren: Nächste Welle starten","detail":"Erfassen Sie das Abschlusstestergebnis pro Standort und planen Sie die nächste Welle.","link":"[Eine Richtlinie für jeden Standort](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Pausieren: Beheben, dann erneut testen","detail":"Setzen Sie den alten Server nur auf der betroffenen SSID an erste Stelle, beheben Sie das Profil oder die Regel und führen Sie den Abschlusstest erneut aus."},{"id":"o3","outcome":"Die Welle zurückrollen","detail":"Setzen Sie den alten Server auf jeder SSID in der Welle an erste Stelle, erfassen Sie Protokolle von beiden Servern und finden Sie die Ursache, bevor Sie es erneut versuchen.","link":"[Wenn RADIUS nicht erreichbar ist](guide:radius-server-down-wifi)"}]}

Exportieren Sie nach jedem Rollback die Protokolle beider Server für das fehlerhafte Zeitfenster. Finden Sie die Ursache und beheben Sie sie in der neuen Richtlinie. Führen Sie dann den Labortest aus Phase 1 für die betroffene Zeile erneut durch, bevor der Standort erneut verschoben wird.

Woran erkennen Sie, dass die Migration abgeschlossen ist?

Die Migration ist abgeschlossen, wenn die Nachweise dies bestätigen - nicht, wenn der letzte Standort verschoben wird. Fünf Tests schließen sie ab:

1. Der alte Server hat für den vereinbarten Ruhezeitraum null Anfragen protokolliert.
2. Jedes NAS im Inventar erscheint in den Protokollen des neuen Servers.
3. Ein reales Gerät hat jede Richtlinienzeile durchlaufen und ist im erwarteten VLAN gelandet.
4. Die Ablehnungsrate liegt auf oder unter der Baseline, die Sie vor Phase 2 erfasst haben.
5. Der alte Server ist ausgeschaltet, seine Protokolle werden aufbewahrt, seine Secrets sind außer Betrieb genommen und das Runbook wurde aktualisiert.

Bewahren Sie eine einseitige Dokumentation für jeden Standort mit dem Datum, dem Abschlusstestergebnis und jedem Rollback auf. Zusammen mit den neuen Authentifizierungsprotokollen dienen diese Aufzeichnungen als Nachweis für die ISO 27001-Zugriffskontrollen und die PCI DSS-Protokollierungskontrollen. Sie dienen auch als Nachweis für die Änderungssteuerung im nächsten Audit-Zyklus.

Fehlerbilder aus der Praxis

Geräte, die nur dem alten Zertifikat vertrauen

Dies ist der häufigste Fehler. Nicht verwaltete PEAP-Geräte fordern möglicherweise das neue Zertifikat an oder verweigern es direkt. Einige verwaltete Profile pinnen sowohl den Servernamen als auch die CA. Überprüfen Sie beides vor dem Pilotprojekt.

Ein NAS, das niemand aufgeführt hat

Vergessene Controller, kabelgebundene 802.1X-Switches und VPN-Gateways halten den alten Server noch lange auf Trab, nachdem das WiFi bereits umgezogen ist. In der Ruhephase von Phase 4 spüren Sie diese Geräte auf.

Richtlinien, die auf dem alten Server lagen

Lokale Gruppen, hartcodierte MAC-Listen und tageszeitabhängige Regeln existieren oft nur auf dem alten Server. Wenn sie nicht in der Policy-Map enthalten sind, verschwinden sie beim Cutover.

Mismatches bei Shared Secrets und Attributen

Ein Tippfehler beim Shared Secret führt auf einigen Konsolen zu einem lautlosen Fehlschlagen. Wenn ein VLAN nach Namen statt nach ID zurückgegeben wird, können Geräte im Standard-VLAN landen. Beide Fehler sollten in Phase 1 beim Testen auffallen und beim Pilotprojekt erneut überprüft werden.

Auf einen Server im Gebäude abgestimmte Timeouts

Zu kurze Timeouts auf einem NAS führen zu fehlerhaften Failovern auf den alten Server. Alles scheint zu funktionieren, bis der alte Server entfernt wird.

Praxisbeispiel: Ein Einzelhändler mit 120 Filialen auf zwei Konsolen

Nehmen wir einen Einzelhändler mit 120 Filialen: Ältere Standorte nutzen HPE Aruba, neuere Juniper Mist. Die Handhelds und Laptops in den Filialen nutzen EAP-TLS gegenüber einem Paar lokaler RADIUS-Server. Das Pilotprojekt und die Migrationswellen verlaufen reibungslos, gruppiert nach Aruba Central-Gruppe und Mist-WLAN-Vorlage.

In Phase 4 protokollieren die alten Server weiterhin Anfragen von drei Adressen, nachdem jede SSID bereits umgezogen ist. Zwei davon sind Controller in Verteilzentren außerhalb des Filialnetzes. Die dritte ist ein VPN-Gateway für Laptops der Zentrale. Das Team nimmt alle drei in das Inventar auf, verschiebt sie in einem zusätzlichen Zeitfenster und startet die Ruhephase erneut. Die Außerbetriebnahme wird zwei Wochen später ohne Ausfall in irgendeiner Filiale abgeschlossen.

Wo Purple ins Spiel kommt

Purple Access betreibt offene, sichere und xPSK-Netzwerke auf einer Plattform und nutzt dafür die Access Points, die Sie bereits besitzen. Das sichere Netzwerk trägt diese Migration. Es bietet Cloud-RADIUS, EAP-TLS und Identitätsverwaltung über Microsoft Entra ID, Okta oder Google Workspace. Es unterstützt auch Passpoint, auch bekannt als Hotspot 2.0, wodurch Geräte automatisch mit den passenden Zugangsdaten einem sicheren Netzwerk beitreten können. Purple ist hardwareunabhängig, sodass eine einzige Richtlinie Standorte auf folgenden Plattformen abdeckt:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme
• Fortinet

Das bedeutet, dass eine gemischte Infrastruktur nach einem einzigen Plan migriert werden kann.

Purple betreibt den größten Cloud-RADIUS der Welt. Er bietet ein RADIUS-Uptime-SLA von 99,9 % auf einer Plattform, die mit 99,999 % Verfügbarkeit läuft. Da die Purple-Seite vor Beginn von Phase 2 eingerichtet wird, ist der Cutover für jeden Standort meist eine Aufgabe fürs Wochenende. Die Phaseneinteilung dient dazu, das Risiko in Ihrer Infrastruktur zu steuern, nicht auf unserer Plattform.

{"items":[{"value":"80,000+","label":"aktive Standorte","note":"Eigene Daten von Purple"},{"value":"90","label":"Länder"},{"value":"99.9%","label":"RADIUS Uptime-SLA","note":"Auf einer Plattform mit 99,999 % Verfügbarkeit"}]}

{"tone":"proof","title":"Mitarbeiter-WiFi in großem Filialmaßstab","text":"JPMorgan betreibt Mitarbeiter-WiFi mit Purple in 5.000 Filialen."}

Produktdetails finden Sie unter Cloud-RADIUS auf Purple Access. Das erweiterte Steuerungssortiment entnehmen Sie dem Enterprise-WiFi-Sicherheitsleitfaden. Guest Marketing ist in Engage enthalten, DNS-Filtering in Shield. Beide ändern sich bei einer RADIUS-Migration nicht.

Häufig gestellte Fragen

Wie lange dauert eine standortübergreifende RADIUS-Migration?

Planen Sie einige Wochen für den gesamten Bestand und ein Wochenende pro Standort ein. Auf Purple ist die Umstellung eines Standorts meist eine Übung für ein einziges Wochenende. Der gesamte Bestand dauert länger, da jede Welle für einen Geschäftszyklus pausiert, bevor die nächste beginnt. Ein exemplarischer Bestand von 40 Standorten benötigt von der Bestandsaufnahme bis zur Außerbetriebnahme etwa 12 Wochen. Der Großteil dieser Zeit entfällt auf Vorbereitungs- und Haltephasen, nicht auf die eigentlichen Änderungsarbeiten.

Benötige ich neue Access Points für den Wechsel zu Cloud-RADIUS?

Nein. Cloud-RADIUS ändert den Server, den Ihre Access Points abfragen, nicht die Access Points selbst. Purple funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Sie fügen den neuen Server in der Konsole, die Sie bereits nutzen, zur RADIUS-Serverliste jedes SSIDs hinzu. Ihre SSIDs, VLAN-IDs und die Switch-Konfiguration bleiben unverändert.

Wie sollte ich die Kosten von Cloud-RADIUS über mehrere Standorte hinweg kalkulieren?

Basieren Sie Ihr Modell auf zwei Zahlen: Standorte und Identitäten. Zählen Sie jeden Standort, der authentifiziert, und jede Identität, die sich verbindet, einschließlich der Geräte auf EAP-TLS. Vergleichen Sie dies anschließend mit den Gesamtkosten des alten Servers: Hardware, Lizenzen, Patching, Hochverfügbarkeit und der WAN-Pfad zur Zentrale. Unser Leitfaden zur Kostenmodellierung von Cloud-RADIUS pro Standort führt Sie durch die Berechnung.

Kann ich den alten RADIUS-Server nach dem Wechsel als Fallback behalten?

Behalten Sie ihn während des Parallelbetriebs bei und schalten Sie ihn anschließend aus. Solange er als sekundärer Server gelistet ist, deckt er Zeitüberschreitungen an Standorten ab, die sich noch in den Migrationswellen befinden. Nach Phase 4 wird ein Server, der eine eingefrorene Kopie der alten Richtlinie enthält, zu einem Risiko, da jede von ihm erteilte Antwort veraltete Regeln nutzt. Von da an ergibt sich die Ausfallsicherheit aus dem SLA von 99,9 % RADIUS-Betriebszeit und einem Wiederherstellungsplan für Ausfälle.

Müssen Mitarbeiter ihre Geräte erneut registrieren?

Nicht, wenn dem neuen Serverzertifikat vor der Umstellung vertraut wird. Übertragen Sie die neue CA während der Erstellungsphase über Ihr MDM auf verwaltete Geräte. EAP-TLS-Geräte behalten ihre vorhandenen Clientzertifikate, sofern der neue Server der ausstellenden CA vertraut. Nicht verwaltete PEAP-Geräte bilden die Ausnahme, da einige einmalig zur Bestätigung des neuen Zertifikats auffordern. Senden Sie diesen Mitarbeitern eine kurze Benachrichtigung, bevor ihr Standort umgezogen wird.

Wirkt sich die Migration auf unsere ISO 27001- oder PCI-DSS-Nachweise aus?

Es ändert sich, woher Ihre Nachweise stammen. Planen Sie dies daher von Anfang an ein. Authentifizierungsprotokolle, Richtliniendefinitionen und Änderungsprotokolle werden auf die neue Plattform übertragen. Bewahren Sie die Protokolle des alten Servers gemäß Ihrer Aufbewahrungsrichtlinie auf und legen Sie den Nachweis des Abschlusstests für jeden Standort ab. Purple ist nach ISO 27001 zertifiziert, was Ihren Auditoren Nachweise für die Plattformseite liefert. Ihre eigenen Kontrollen benötigen weiterhin eigene Nachweise.

Wie unterscheidet sich dies für einen MSP, der mehrere Umgebungen verwaltet?

Die Phasen sind dieselben. Was sich unterscheidet, ist die Isolierung zwischen den Umgebungen. Ein MSP durchläuft dieselben vier Phasen für jede Umgebung, aber jede benötigt ihre eigene Richtlinie, Identitätsquelle und Protokolle auf einer gemeinsamen Plattform. Wellen folgen in der Regel den Vertragsgrenzen statt den Konsolenvorlagen. Unser Leitfaden zu Mandantenfähigem RADIUS für MSPs beschreibt, wie Sie jede Umgebung während und nach dem Wechsel getrennt halten.