Migration von Cisco ISE zu Cloud-RADIUS: Ein phasenweiser Umstellungsplan

Sie können in fünf Phasen von Cisco ISE zu Cloud-RADIUS migrieren, ohne einen Stichtag festlegen zu müssen, sobald jedes Gerät dem neuen Serverzertifikat vertraut. Führen Sie Purple Standort für Standort parallel zu ISE aus. Belassen Sie IEEE 802.1X und EAP-TLS auf dem Client unverändert. Führen Sie die Umstellung in Wellen durch, wobei ISE bis zum Wechsel des letzten Standorts als Rollback-Pfad dient.

Was ändert sich bei der Migration von Cisco ISE und was bleibt gleich?

Der Zielzustand lässt sich kurz beschreiben. Ihre Access Points senden Authentifizierungsanfragen an die Cloud-RADIUS von Purple statt an ISE-Knoten in Ihrem Rechenzentrum. Purple prüft die Identität gegen Microsoft Entra ID, Okta oder Google Workspace. Anschließend wird das VLAN zurückgegeben, zu dem diese Identität gehört. ISE wird heruntergefahren, die Lizenzen laufen aus und es müssen keine neuen Patches mehr eingespielt werden.

Zunächst einige Begriffe. RADIUS (RFC 2865) ist das Authentifizierungsprotokoll, das Ihre Controller bereits verwenden. IEEE 802.1X ist der portbasierte Zugangssteuerungsstandard, der die Anmeldung über WiFi überträgt. EAP-TLS (RFC 5216) authentifiziert jedes Gerät mit einem Zertifikat. PEAP verpackt einen Kennwortaustausch in einen verschlüsselten TLS-Tunnel. Ein VLAN (Virtual LAN) ist das Netzwerksegment, auf dem ein Gerät nach der Authentifizierung landet.

Vier Dinge ändern sich:

• RADIUS-Serveradressen und Shared Secrets auf jedem Netzwerkzugangsgerät (NAD) - also dem Controller, AP oder Cloud-Dashboard, das Anfragen sendet.
• Das Serverzertifikat, das Geräten während IEEE 802.1X angezeigt wird.
• Der Speicherort der Richtlinien. ISE-Richtliniensätze und Autorisierungsprofile werden zu Identitätsgruppen, die VLANs zugewiesen sind.
• Die Quelle der Identitäten. Ein Cloud-Verzeichnis ersetzt die mit dem lokalen Active Directory verbundene ISE.

Ihre SSIDs, Access Points, VLANs, das Switching und alle Client-Zertifikate Ihrer eigenen Zertifizierungsstelle (CA) bleiben unverändert. Das ist die Voraussetzung für eine phasenweise Migration. Die ISE-Funktionen selbst benötigen ein Ziel, und nicht alle landen im sicheren Netzwerk.

Was ISE heute tut	Wo es hingeht	Purple-Netzwerk
802.1X für Mitarbeiter und Unternehmensgeräte	Purple Cloud-RADIUS mit EAP-TLS und Ihrem Identitätsanbieter	Sicher
MAB (MAC Authentication Bypass) für Scanner, Drucker und Sensoren	Ein Schlüssel pro Gerät oder Gerätegruppe (iPSK oder PPSK, zusammen xPSK)	xPSK
Gast- und gesponserte Portale	Ein Captive Portal, die Anmeldeseite vor dem Zugriff	Offen
BYOD-Onboarding mit der internen ISE-CA	Zertifikate von Ihrem MDM oder Ihrer eigenen CA	Sicher
TACACS+, kabelgebundenes 802.1X, Posture, TrustSec	Außerhalb des Umfangs dieses Plans; weisen Sie jeweils einen Verantwortlichen zu	Keines

Dieser Plan deckt die WiFi Authentifizierung auf Ihren Access Points ab. Falls ISE auch die Geräteverwaltung, kabelgebundene Ports oder Posture ausführt, listen Sie jeden einzelnen Bereich vor Phase 1 auf und weisen Sie ihm einen eigenen Verantwortlichen zu. Falls ISE ein für das Marketing genutztes Gastportal hostet, wird dieses auf das offene Netzwerk und Purple Engage übertragen. Der Leitfaden für sichere Netzwerke zu Zertifikaten, Identität und Passpoint behandelt das Ziel-Design im Detail.

Was muss vor Phase 1 erfüllt sein?

Sechs Bedingungen, jeweils eine Ja- oder Nein-Frage. Beginnen Sie mit dem Aufbau erst, wenn alle sechs mit Ja beantwortet sind.

1. Das Inventar ist vollständig. Jede SSID, jedes NAD mit seinem Shared Secret, jedes Policy Set und Authorisation Profile sowie jede Endpunktgruppe, die auf MAB angewiesen ist.
2. Sie verfügen über eine ISE Baseline. Erfassen Sie mindestens zwei Wochen lang die Authentifizierungen pro Stunde und die Erfolgsquote pro SSID und Standort. Die Live-Logs und Berichte von ISE liefern Ihnen diese Daten. Ohne eine Baseline können Sie nicht beurteilen, ob eine Phase erfolgreich war.
3. Der Zertifikatsplan steht. Notieren Sie, welche CA Ihre Client-Zertifikate ausgestellt hat und welches Zertifikat ISE für EAP vorweist. Notieren Sie, ob Geräte Zertifikate von der internen ISE CA besitzen.
4. Identitätsgruppen existieren in Ihrem Verzeichnis. Jede ISE Autorisierungsregel benötigt eine passende Gruppe in Microsoft Entra ID, Okta oder Google Workspace, und jede Gruppe benötigt ein VLAN.
5. Standorte können die Cloud erreichen. Firewalls an jedem Standort lassen RADIUS-Datenverkehr vom Controller oder den APs zu den RADIUS-Servern von Purple zu.
6. ISE bleibt unterstützt. Halten Sie ISE lizenziert, gepatcht und betreut, bis Phase 5 abgeschlossen ist. Es dient als Ihr Rollback-Pfad.

Eine Designentscheidung gehört ebenfalls hierher. PEAP-MSCHAPv2 prüft einen Passwort-Hash, den Cloud-Verzeichnisse wie Microsoft Entra ID gegenüber RADIUS-Servern nicht offenlegen. Wenn ISE PEAP gegen ein lokales Active Directory validiert, verschieben Sie diese Geräte zuerst auf EAP-TLS, während ISE sie noch authentifiziert. Ändern Sie nur eine Sache pro Phase: zuerst die EAP-Methode, dann den RADIUS-Server.

{"tone":"warning","title":"Das Risiko, das schmerzt: Serverzertifikats-Trust","text":"Jedes Gerät prüft während 802.1X das RADIUS-Serverzertifikat. Profile, die nur dem ISE EAP-Zertifikat oder dessen CA vertrauen, lehnen Purple ab, bis Ihr MDM die neue Vertrauensstellung verteilt. Rollen Sie diese daher in Phase 2 aus, nicht in der Nacht der Umstellung."}

Welche Phasen hat eine ISE Migration in welcher Reihenfolge?

Fünf Phasen, jede mit einem Verantwortlichen und einem Abschlusstest. Die folgenden Dauern gelten für ein Umfeld mit 40 Standorten - passen Sie diese an Ihre Gegebenheiten an. Die Umstellung an einem einzelnen Standort ist in der Regel eine Wochenendaufgabe. Die Wochen davor sorgen dafür, dass sie auch als solche verläuft.

{"kind":"timeline","direction":"lr","caption":"Fünf Phasen für eine Umgebung mit 40 Standorten bei der Migration von Cisco ISE zu Purple Cloud-RADIUS. ISE bleibt aktiv, bis Phase 5 abgeschlossen ist.","alt":"Eine Zeitleiste von fünf Migrationsphasen, von der Ermittlung in den Wochen 1 bis 2 bis zur ISE-Außerbetriebnahme ab Woche 10.","nodes":[{"id":"p1","label":"Phase 1: Ermittlung und Design","sub":"Bestandsaufnahme von NADs, Richtliniensätzen, Zertifikaten und MAB-Geräten","tone":"neutral","when":"Wochen 1-2"},{"id":"p2","label":"Phase 2: Paralleler Aufbau","sub":"Cloud-RADIUS, IdP-Gruppen, VLAN-Regeln, Zertifikatsvertrauen","tone":"brand","when":"Woche 3"},{"id":"p3","label":"Phase 3: Pilotbetrieb an einem Standort","sub":"Jede Geräteklasse authentifiziert sich im richtigen VLAN","tone":"brand","when":"Wochen 4-5"},{"id":"p4","label":"Phase 4: Schrittweise Umstellung","sub":"Wochenend-Wartungsfenster, ISE als Rollback-Option behalten","tone":"brand","when":"Wochen 6-9"},{"id":"p5","label":"Phase 5: ISE außer Betrieb nehmen","sub":"Null ISE-Authentifizierungen, Knoten heruntergefahren","tone":"success","when":"Woche 10+"}],"edges":[{"from":"p1","to":"p2"},{"from":"p2","to":"p3"},{"from":"p3","to":"p4"},{"from":"p4","to":"p5"}]}

{"caption":"ISE zu Cloud-RADIUS Phasenplan","asOf":"2026-06-10","columns":[{"key":"phase","label":"Phase"},{"key":"scope","label":"Umfang"},{"key":"owner","label":"Verantwortlicher"},{"key":"exit","label":"Abschlusstest"}],"rows":[["1. Ermittlung und Design","Jeder SSID, NAD, Richtliniensatz, Autorisierungsprofil, Zertifikat und MAB-Gerät","Netzwerkarchitekt","Unterzeichnete Zuordnung jeder ISE-Regel zu einer Identitätsgruppe und einem VLAN"],["2. Paralleler Aufbau","Cloud-RADIUS, IdP-Anbindung, VLAN-Regeln, xPSK-Schlüssel, Serverzertifikatsvertrauen","Identity and Access Lead","Testgeräte authentifizieren sich über eine Labor-SSID bei Purple"],["3. Pilotbetrieb an einem Standort","Ein repräsentativer Standort, jede Geräteklasse","IT-Manager mit dem Standortleiter","Fünf Arbeitstage auf oder über dem ISE-Baseline-Niveau, korrektes VLAN für jede Klasse"],["4. Schrittweise Umstellung","Standorte in Gruppen, jeweils ein Wartungsfenster","Netzwerkbetrieb","Jede Welle hält die Baseline für 48 Stunden ohne Rollback"],["5. ISE außer Betrieb nehmen","ISE-Knoten, NAD-Einträge, Lizenzen, interne CA","IT-Director","Null ISE-Authentifizierungen für den festgelegten Zeitraum, Nachweise archiviert"]],"footnote":"Dauern und Schwellenwerte sind Standard-Planungswerte für eine Umgebung mit 40 Standorten. Legen Sie Ihre eigenen Werte auf Basis der ISE-Baseline fest, die Sie vor Phase 1 erfassen.","download":{"filename":"ise-to-cloud-radius-phase-plan.csv"}}

Was passiert in jeder Phase der ISE-Migration?

Phase 1: Ermittlung und Design

Exportieren Sie die vorhandenen ISE-Daten, bevor Sie Änderungen vornehmen. Listen Sie jeden Richtliniensatz, seine Bedingungen und das zurückgegebene Autorisierungsprofil auf. In den meisten Umgebungen zeigt sich, dass jahrelang gewachsene Regeln in eine Handvoll realer Ergebnisse münden: Mitarbeiter-VLAN, Auftragnehmer-VLAN, IoT-VLAN, Ablehnung.

Schreiben Sie jedes Ergebnis als Identitätsgruppe und als VLAN. Die VLAN-Zuweisung über RADIUS verwendet die in RFC 3580 beschriebenen Tunnelattribute. Einige Controller lesen auch herstellerspezifische Attribute (VSAs), wie z. B. das Rollenattribut, das HPE Aruba-Controller verwenden. Notieren Sie, welche Attribute Ihre Hardware erwartet.

Suchen Sie anschließend die Geräte, die kein 802.1X ausführen können. Die Endpunktliste von ISE zeigt, welche MAC-Adressen per MAB authentifiziert werden. Jedes dieser Geräte benötigt einen xPSK-Schlüssel und ein VLAN, bevor der Standort migriert wird.

Phase 2: Purple parallel aufbauen

Verbinden Sie Purple mit Ihrem Identitätsanbieter und erstellen Sie die Regeln für die Zuordnung von Gruppen zu VLAN aus Phase 1. Laden Sie die Zertifizierungsstelle (CA) hoch, die Ihre Client-Zertifikate ausgestellt hat, damit EAP-TLS sie validieren kann. Stellen Sie xPSK-Schlüssel für die kopflosen (headless) Gerätegruppen aus.

Übertragen Sie das Vertrauen für das Serverzertifikat von Purple über Ihr MDM auf jedes verwaltete Gerät. Dies ist die zeitintensivste Aufgabe beim Aufbau, beginnen Sie daher am ersten Tag damit. Richten Sie eine Testzugangskontrolle (SSID) ein, die auf Purple verweist, und authentifizieren Sie ein Gerät jeder Klasse.

Phase 3: Pilotprojekt an einem repräsentativen Standort

Wählen Sie einen Standort mit allen Geräteklassen aus, die Sie besitzen: Windows, macOS, iOS, Android, Scanner und außergewöhnliche Geräte. Vermeiden Sie Ihren Hauptstandort sowie Ihren einfachsten Standort. Führen Sie die Umstellung mit denselben Schritten durch, die Sie auch in den Migrationswellen verwenden werden.

Behalten Sie den Zustand für fünf Arbeitstage bei. Vergleichen Sie die Erfolgsquote von Purple mit der ISE-Baseline für diesen Standort. Überprüfen Sie, ob jede Geräteklasse auf dem richtigen VLAN landet. Beheben Sie Fehler an dieser Stelle und nicht erst während einer Migrationswelle.

Phase 4: Umstellung in Wellen

Fassen Sie die verbleibenden Standorte in Wellen zusammen, die von einem Team innerhalb eines einzigen Änderungsfensters unterstützt werden können. Führen Sie vor jeder Welle die Go/No-Go-Prüfung durch. Befolgen Sie an jedem Standort dieselben Schritte.

{"title":"Umstellung eines Standorts von ISE auf Purple Cloud RADIUS","steps":[{"title":"Basiseinstellungen aufzeichnen","body":"Erfassen Sie die ISE-Authentifizierungen des Standorts pro Stunde und die Erfolgsquote pro SSID im Migrationsprotokoll.","check":"Die Basiswerte sind vor Beginn des Zeitfensters protokolliert."},{"title":"Sichere SSID auf Purple ausrichten","body":"Ersetzen Sie die ISE RADIUS-Server durch die Server und das Shared Secret von Purple. Notieren Sie die ISE-Einträge für einen eventuellen Rollback.","check":"Das Dashboard zeigt Purple als RADIUS-Server für diese SSID an.","variants":[{"label":"Cisco Meraki","body":"Bearbeiten Sie im Meraki Dashboard die Einstellungen für die SSID-Zugriffskontrolle und aktualisieren Sie die RADIUS-Serverliste."},{"label":"HPE Aruba","body":"Aktualisieren Sie in Aruba Central oder im Controller die Servergruppe, die vom WLAN 802.1X-Profil verwendet wird."},{"label":"Ruckus","body":"Aktualisieren Sie in RUCKUS One oder SmartZone den der WLAN zugewiesenen AAA-Server."},{"label":"Juniper Mist","body":"Bearbeiten Sie im Mist-Dashboard die Enterprise-Sicherheitseinstellungen des WLANs und aktualisieren Sie die RADIUS-Server."},{"label":"Ubiquiti UniFi","body":"Aktualisieren Sie in UniFi Network das vom Enterprise-SSID verwendete RADIUS-Profil."}]},{"title":"Testgeräte erneut verbinden","body":"Verbinden Sie jeweils ein Gerät jeder Klasse am Standort erneut, einschließlich bildschirmloser Geräte (Headless Devices) über xPSK.","check":"Jedes Testgerät landet im vorgesehenen VLAN."},{"title":"Die erste Stunde überwachen","body":"Lesen Sie die Authentifizierungsprotokolle von Purple und gruppieren Sie Fehlversuche nach Ursache.","check":"Die Erfolgsquote liegt auf oder über dem Basiswert des Standorts."},{"title":"Innehalten oder Rollback durchführen","body":"Wenn die Quote am Ende des vereinbarten Zeitfensters unter dem Basiswert bleibt, stellen Sie die ISE-Server für die SSID wieder her.","check":"Die Entscheidung und der Grund sind im Migrationsprotokoll vermerkt."},{"title":"Standort abschließen","body":"Markieren Sie den Standort nach 48 Stunden als migriert. Belassen Sie dessen NAD-Eintrag in ISE bis Phase 5, damit der Rollback weiterhin funktioniert.","check":"ISE zeigt keine neuen Authentifizierungen von diesem Standort an."}]}

Phase 5: ISE außer Betrieb nehmen

Starten Sie Phase 5 erst, wenn ISE über einen von Ihnen festgelegten Zeitraum (z. B. 30 Tage) null WiFi-Authentifizierungen registriert hat. Exportieren Sie die ISE-Authentifizierungsberichte, die gemäß Ihrer Richtlinie zur Aufbewahrung von Audit-Daten erforderlich sind. Entfernen Sie die NAD-Einträge und fahren Sie die Knoten anschließend herunter. Lassen Sie die Lizenzen bei der Verlängerung auslaufen, anstatt sie vorzeitig zu kündigen.

Stellen Sie die interne ISE CA zuletzt ein. Jedes von ihr ausgestellte Zertifikat verliert die Vertrauenskette zu einer aktiven CA, sobald ISE nicht mehr vorhanden ist.

Wie laufen ISE und Purple während der Umstellung parallel?

Es gibt zwei Muster, die sich unterschiedlich verhalten.

Parallele SSID. Strahlen Sie eine zweite sichere SSID aus, die über Purple authentifiziert wird, parallel zur ISE-SSID. Ihr MDM verschiebt Gerätegruppen schrittweise auf das neue SSID-Profil. Beide Netzwerke laufen gleichzeitig, sodass es sich um einen echten Parallelbetrieb handelt. Die Kosten bestehen in der Funkzeit (Airtime) für eine weitere SSID für die Dauer der Migration.

Gleiche SSID, gewechselter Server. Behalten Sie eine SSID bei und ändern Sie deren RADIUS-Server während des Wartungsfensters. Dies ist saubere Funkhygiene, entspricht aber einer direkten Umschaltung und keiner fließenden Überblendung.

Der Punkt, den die meisten Teams übersehen: Das RADIUS-Failover auf den meisten Controllern wird ausgelöst, wenn der primäre Server nicht mehr antwortet, nicht wenn er ein Gerät ablehnt. Wenn Sie Purple zuerst und ISE an zweiter Stelle aufführen, erfolgt bei einer Ablehnung durch Purple kein Fallback auf ISE. Verlassen Sie sich nicht auf die Serverreihenfolge als Sicherheitsnetz. Verlassen Sie sich auf den Pilotversuch.

Praxisszenario: Eine Hotelgruppe mit 40 Hotels auf Cisco Meraki

Eine Hotelgruppe betreibt Mitarbeiter-WiFi in 40 Hotels auf Cisco Meraki. Zwei ISE-Knoten in einem Rechenzentrum authentifizieren Mitarbeiter mit PEAP gegen ein lokales Active Directory. Die Gruppe möchte das Rechenzentrum stilllegen.

Das Team teilte die Umstellung in zwei Schritte auf. Erstens spielte es EAP-TLS-Zertifikate und das Vertrauen in den Purple-Server über sein MDM ein, während ISE weiterhin alles authentifizierte. ISE validierte die neuen Zertifikate, sodass sich für die Mitarbeiter nichts änderte. Zweitens führte es ein Pilotprojekt in einem mittelgroßen Hotel durch und stellte den Rest in vier Wochenendwellen von neun oder zehn Hotels um.

Das messbare Ergebnis war der Ausstiegstest selbst. Die Anzahl der Authentifizierungen für die Mitarbeiter-SSID von ISE erreichte nach der letzten Welle null. Keine Welle erforderte einen Rollback. Die ISE-Knoten wurden Ende des folgenden Monats heruntergefahren.

Wie rollen Sie eine fehlgeschlagene Welle zurück?

Ein Rollback ist das Gegenteil von Schritt zwei: Stellen Sie die ISE-Server und das Shared Secret auf den betroffenen SSIDs wieder her. Da ISE aktiv bleibt und seine NAD-Einträge bestehen bleiben, kehrt der Standort beim nächsten erneuten Verbindungsaufbau in seinen vorherigen Zustand zurück. Vereinbaren Sie im Voraus, wer die Entscheidung trifft und wie lange Sie warten, bevor Sie sie treffen.

{"title":"Go, No-Go oder Rollback für eine Umstellungswelle","start":"q1","nodes":[{"id":"q1","question":"Hat der Pilotversuch oder die vorherige Welle die ISE-Erfolgsraten-Baseline gehalten?","help":"Vergleichen Sie die Erfolgsquote von Purple pro SSID mit der ISE-Baseline für dieselben Standorte.","options":[{"label":"Ja","to":"q2"},{"label":"Nein","to":"o3"}]},{"id":"q2","question":"Vertraut jedes Gerät in dieser Welle dem Serverzertifikat von Purple?","help":"Überprüfen Sie den MDM-Bereitstellungsstatus für jede Gerätegruppe an diesen Standorten.","options":[{"label":"Ja","to":"q3"},{"label":"Nein","to":"o2"}]},{"id":"q3","question":"Kann jeder Standort in der Welle die RADIUS-Server von Purple erreichen?","help":"Testen Sie jede Standort-Firewall, bevor das Fenster geöffnet wird.","options":[{"label":"Ja","to":"q4"},{"label":"Nein","to":"o2"}]},{"id":"q4","question":"Ist ISE noch aktiv und ein benannter Rollback-Verantwortlicher auf Abruf?","options":[{"label":"Ja","to":"o1"},{"label":"Nein","to":"o2"}]},{"id":"o1","outcome":"Go","detail":"Öffnen Sie das Änderungsfenster und befolgen Sie die Schritte zur Standortumstellung."},{"id":"o2","outcome":"No-Go: Beheben und neu ansetzen","detail":"Schließen Sie die Lücke und führen Sie diese Prüfung vor dem nächsten Fenster erneut durch."},{"id":"o3","outcome":"Zurückrollen und Diagnose durchführen","detail":"Stellen Sie ISE auf den betroffenen SSIDs wieder her, finden Sie die fehlerhafte Geräteklasse oder -regel und beheben Sie sie zuerst am Pilotstandort.","link":"[ISE-Alternativen vergleichen](guide:cisco-ise-alternatives)"}]}

Praxisszenario: Ein Einzelhändler mit 300 Filialen auf HPE Aruba

Ein Einzelhändler betreibt 300 Filialen auf HPE Aruba. ISE authentifiziert Mitarbeiter-Laptops mit EAP-TLS und Handscanner für die Bestandsaufnahme mit MAB. Die Pilotfiliale verlief erfolgreich, sodass das Team die erste Welle von 30 Filialen umstellte.

Bei vier Filialen der zweiten Welle schlugen die Scanner fehl. Diese Filialen nutzten ein neueres Scannermodell, dessen MAC-Adressen in der Inventarliste von Phase 1 fehlten. Der Verantwortliche für den Rollback stellte die ISE-Servergruppe auf den betroffenen WLANs innerhalb des Änderungsfensters wieder her, und der Scanbetrieb wurde fortgesetzt.

Das Team zog die Adressen des neuen Modells aus der Endgeräte-Liste von ISE und wies ihm xPSK-Schlüssel zu. Ein Scanner wurde in der Pilotfiliale getestet, anschließend wurde die Welle erneut durchgeführt. Alle 300 Filialen wurden erfolgreich auf Purple umgestellt. Jede MAB-Regel wurde außer Betrieb genommen, und die Kartenterminals befinden sich nun in einem eigenen VLAN. Diese Segmentierung diente als Nachweis für die Abgrenzung des PCI-DSS-Geltungsbereichs des Einzelhändlers.

Wie weisen Sie nach, dass die Migration von ISE abgeschlossen ist?

"Abgeschlossen" ist eine Reihe von Fakten, kein Gefühl. Sie sind fertig, wenn alle folgenden Punkte zutreffen:

• ISE hat für den von Ihnen festgelegten Zeitraum null WiFi-Authentifizierungen protokolliert.
• Die Erfolgsquote von Purple an jedem Standort liegt auf oder über dem ISE-Referenzwert.
• Jede Identitätsgruppe landet auf ihrem vorgesehenen VLAN, geprüft mit einem Testgerät pro Klasse.
• Kein Gerät besitzt ein Zertifikat, das auf die interne CA von ISE zurückgeht.
• ISE-Berichte für Ihren Aufbewahrungszeitraum sind exportiert und gespeichert.
• Die ISE-Knoten sind heruntergefahren und die Verlängerung ist gekündigt.

Führen Sie ein einziges Protokoll für das gesamte Programm. Die folgende Checkliste ist dieses Protokoll.

{"title":"Protokoll zur Migration von ISE zu Cloud-RADIUS","groups":[{"heading":"Vor Phase 1","items":[{"text":"Jede SSID, jedes NAD und jedes Shared Secret aufgeführt"},{"text":"Jedes Richtlinienset einer Identitätsgruppe und einem VLAN zugeordnet"},{"text":"Zwei Wochen ISE-Referenzwerte pro Standort und SSID erfasst","why":"Ohne diese Daten kann keine Welle als erfolgreich oder fehlgeschlagen bewertet werden"},{"text":"PEAP-Geräte identifiziert und ein EAP-TLS-Plan vereinbart"},{"text":"MAB-Geräte aus der ISE-Endgeräte-Liste erfasst"},{"text":"Verkabelte Geräte, TACACS+ und Posture-Bereiche separaten Verantwortlichen zugewiesen"}]},{"heading":"Aufbau und Pilotbetrieb","items":[{"text":"Identitätsanbieter verbunden und Gruppen VLANs zugeordnet"},{"text":"Client-Zertifikats-CA für EAP-TLS als vertrauenswürdig eingestuft"},{"text":"Vertrauen in das Purple-Serverzertifikat über MDM verteilt","why":"Das Risiko, das am Umschaltabend Probleme verursacht"},{"text":"xPSK-Schlüssel für gerätelose Gruppen ausgestellt"},{"text":"Standort-Firewalls lassen RADIUS-Datenverkehr zu Purple zu"},{"text":"Pilotstandort hielt den Referenzwert für fünf Arbeitstage"}]},{"heading":"Wellen","items":[{"text":"Go- oder No-Go-Prüfung für jede Welle protokolliert"},{"text":"Rollback-Verantwortlicher für jedes Zeitfenster benannt"},{"text":"Jede Welle hielt den Referenzwert für 48 Stunden"}]},{"heading":"Abgeschlossen","items":[{"text":"Zero ISE WiFi-Authentifizierungen für den vereinbarten Zeitraum"},{"text":"Keine Zertifikate gehen auf die interne CA von ISE zurück"},{"text":"ISE-Berichte für die Auditantwort exportiert"},{"text":"NAD-Einträge entfernt und ISE-Knoten heruntergefahren"},{"text":"ISE-Lizenzverlängerung gekündigt"}]}],"download":{"filename":"ise-migration-log.csv"}}

Welche Fehlerbeispiele treten im Feld auf?

Die meisten fehlgeschlagenen Wellen lassen sich auf wenige Ursachen zurückführen.

• Nicht vertrauenswürdiges Serverzertifikat. Geräte melden eine Warnung oder lehnen die Verbindung stumm ab. Beheben Sie dies in Phase 2 über Ihr MDM - bitten Sie die Mitarbeiter niemals, eine Aufforderung manuell zu akzeptieren.
• Zwei Dinge gleichzeitig ändern. Der Wechsel von PEAP zu EAP-TLS im selben Zeitfenster wie der Serverwechsel verschleiert, welche Änderung den Fehler verursacht hat.
• Vergessene headless Geräte. Scanner, Drucker und Sensoren mit MAB fallen zuerst aus, wie der Einzelhändler feststellen musste. Erstellen Sie die MAB-Liste aus ISE kurz vor jeder Welle neu.
• Nicht übereinstimmende Shared Secrets. Ein einziges falsch eingegebenes Secret auf einem Controller lehnt einen gesamten Standort ab. Kopieren Sie Secrets aus einer zentralen Quelle, niemals manuell.
• Firewall-Egress. Standorte mit lokalem Breakout oder älteren Firewall-Regeln blockieren den RADIUS-Datenverkehr zur Cloud. Testen Sie jeden Standort vor seinem Zeitfenster.
• Unterschiede bei VLAN-Attributen. ISE-Autorisierungsprofile können einen VLAN-Namen, eine VLAN-ID oder eine herstellerspezifische Rolle zurückgeben. Stimmen Sie die Erwartungen des jeweiligen Controllers am Pilotstandort ab.
• Stille nachgelagerte Verbraucher. Wenn eine Firewall Identitäten von ISE über pxGrid bezogen hat, stoppt dieser Feed bei der Umstellung. Wenn Sie sich auf Change of Authorisation (RFC 5176) verlassen, um Sitzungen zu beenden, testen Sie dies während des Pilots.
• Verlassen auf Failover. Das Eintragen von ISE als sekundären Server fängt Rejects nicht ab. Das kann nur ein getesteter Rollback.

Wo Purple ins Spiel kommt

Purple Access betreibt drei Netzwerke auf den Access Points, die Sie bereits besitzen: offen, sicher und xPSK. Eine ISE-Migration landet auf dem sicheren Netzwerk. Purple cloud RADIUS authentifiziert mit EAP-TLS gegenüber Microsoft Entra ID, Okta oder Google Workspace. Passpoint, der Hotspot 2.0-Standard für automatisches und verschlüsseltes Verbinden, erweitert dieselbe Identität über mehrere Standorte hinweg. Die Identität legt das VLAN in jedem Netzwerk fest.

Purple ist hardwareunabhängig. Es funktioniert mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet - ohne neue Hardware. Purple betreibt den größten cloud RADIUS der Welt. Er bietet eine RADIUS-Betriebszeit-SLA von 99,9 % auf einer Plattform, die mit 99,999 % Betriebszeit läuft.

{"items":[{"value":"99.9%","label":"RADIUS-Betriebszeit-SLA","note":"Vertragliche SLA von Purple"},{"value":"99.999%","label":"Plattform-Betriebszeit","note":"Eigene Daten von Purple"},{"value":"80,000+","label":"Aktive Standorte","note":"Eigene Daten von Purple"},{"value":"90","label":"Länder","note":"Eigene Daten von Purple"}]}

{"tone":"proof","title":"Mitarbeiter-WiFi in Filialnetzwerken","text":"JPMorgan betreibt Mitarbeiter-WiFi mit Purple in über 5.000 Filialen."}

Purple ist nach ISO 27001, Cyber Essentials sowie als B Corp zertifiziert und arbeitet unter GDPR und CCPA. Diese Zertifizierungen verkürzen die Lieferantenbewertung Ihres Sicherheitsteams. Für ein umfassenderes Sicherheitsbild lesen Sie den Leitfaden für Enterprise WiFi Sicherheit. Wenn Sie noch auf der Suche nach einer Zielplattform sind, lesen Sie Cisco ISE Alternativen für WiFi-Authentifizierung.

Häufig gestellte Fragen

Wie lange dauert die Migration von Cisco ISE auf Cloud-RADIUS?

Die Umstellung selbst erfolgt in der Regel an einem Wochenende; die Vorbereitung nimmt mehr Zeit in Anspruch. Für eine Infrastruktur mit 40 Standorten sollten Sie zwei Wochen für die Bestandsaufnahme, eine Woche für den Aufbau, einen zweiwöchigen Pilotbetrieb und mehrere Abschnitte an Wochenenden einplanen. Zertifikate sind dabei die größte Variable. Wenn Geräte bereits EAP-TLS mit Zertifikaten Ihrer eigenen Zertifizierungsstelle (CA) nutzen, verkürzt sich der Zeitplan. Wenn PEAP über Active Directory genutzt wird, fügen Sie eine Phase hinzu, um diese Geräte zuerst auf EAP-TLS umzustellen.

Benötige ich neue Access Points für den Wechsel von Cisco ISE?

Nein. Cloud-RADIUS funktioniert mit den Access Points und Controllern, die Sie bereits betreiben: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Die Migration erfordert lediglich eine Konfigurationsänderung an jedem SSID: neue RADIUS-Serveradressen, ein neues Shared Secret und bei Bedarf neue VLAN-Attribute. Ihre Switching-Infrastruktur, VLANs und SSIDs bleiben exakt so bestehen, wie sie sind.

Können wir die bereits ausgestellten Client-Zertifikate weiterverwenden?

Ja, sofern sie von Ihrer eigenen Zertifizierungsstelle (CA) oder Ihrem MDM ausgestellt wurden. Cloud-RADIUS validiert EAP-TLS-Zertifikate gegenüber der ausstellenden CA. Sie funktionieren also weiterhin, sobald dieser CA vertraut wird. Zertifikate der internen ISE-CA bilden die Ausnahme. Diese hängen an einem System, das Sie kurz vor der Außerbetriebnahme steht. Stellen Sie diese daher vor Beginn von Phase 5 über Ihr MDM oder Ihre CA neu aus.

Was passiert mit Geräten, die in ISE MAC Authentication Bypass nutzen?

Diese wechseln in das xPSK-Netzwerk. MAB vertraut einer MAC-Adresse, die leicht gefälscht werden kann. Ein Schlüssel pro Gerät oder Gerätegruppe weist Scannern, Druckern und Sensoren eigene Zugangsdaten zu und ordnet sie ihrem eigenen VLAN zu. Erfassen Sie diese in Phase 1 aus der Endpunktliste von ISE. Stellen Sie in Phase 2 Schlüssel aus und testen Sie anschließend jeweils ein Modell im Pilotstandort.

Wirkt sich der Wechsel von ISE auf unsere PCI DSS- oder ISO 27001-Nachweise aus?

Es ändert sich nur, woher die Nachweise stammen, nicht, ob Sie sie besitzen. Exportieren Sie ISE-Authentifizierungsberichte für Ihren Aufbewahrungszeitraum vor der Stilllegung. Ab der Umstellung liefern die Authentifizierungsprotokolle und VLAN-Zuweisungen von Purple die Nachweise für Netzwerksegmentierung und Zugriffskontrolle. Die eigene ISO 27001- und Cyber Essentials-Zertifizierung von Purple unterstützt zudem die Lieferantenbewertung, die Ihre Auditoren erwarten werden.

Wie verhält sich die Preisgestaltung von Cloud-RADIUS im Vergleich zu Cisco ISE?

Vergleichen Sie die Gesamtkosten statt einzelner Lizenzpositionen. Die Kosten für ISE umfassen Lizenzen, die ausführenden Knoten oder virtuellen Maschinen, Supportverträge sowie die Arbeitszeit von Technikern für Patching und Upgrades. Cloud-RADIUS ist ein Abonnement ohne Server, die Sie selbst betreiben müssen. Purple erstellt ein Angebot für Ihre gesamte Infrastruktur. Halten Sie dazu Ihre Standortanzahl, SSIDs und Gerätezahlen bereit. Der Leitfaden zu ISE-Alternativen zeigt auf, was Sie sonst noch vergleichen sollten.

Sollten wir verkabeltes 802.1X gleichzeitig mit WiFi migrieren?

Nein. Migrieren Sie zuerst WiFi und behandeln Sie kabelgebundenes 802.1X als separates Projekt mit einem eigenen Pilotprojekt. Kabelgebundene Ports weisen häufig MAB-Geräte, Tischtelefone und Posture-Regeln auf, die ein eigenes Inventar erfordern. Beide Änderungen in einem einzigen Fenster durchzuführen, verdoppelt die Anzahl der Fehlerquellen auf einmal. Zudem erschwert es die Entscheidung für einen Rollback unter Druck.

Unterscheidet sich die Migration von Aruba ClearPass?

Die fünf Phasen sind identisch; der Export unterscheidet sich. ClearPass speichert Richtlinien als Dienste, Durchsetzungsrichtlinien und Profile und nicht als ISE-Richtliniensätze. Diese Identitätsgruppen und VLANs zuzuordnen, ist die Hauptaufgabe in Phase 1. Das Risiko beim Zertifikatsvertrauen und das Failover-Verhalten gelten in exakt gleicher Weise. Der ClearPass-Migrationsleitfaden behandelt den Export im Detail.