So testen Sie Schritt für Schritt die RADIUS-Authentifizierung
Published
Sie befinden sich an einem Standort mit einem Laptop, einem Access Point und einem RADIUS-Server, der "eigentlich bereits funktionieren sollte". Jemand hat einen Ping gesendet. UDP 1812 ist offen. Eine Dashboard-Prüfung war sogar erfolgreich. Nichts davon verrät Ihnen jedoch, ob ein Mitarbeitergerät im Mitarbeiter-VLAN landet oder ob ein gesperrtes Zertifikat dennoch eine Sitzung erhält.
Das Testen der RADIUS-Authentifizierung ist eine Kette von Nachweisen, nicht nur ein einzelner Anmeldevorgang. Betrachten Sie jedes Access-Accept als Hypothese. Sie müssen weiterhin die Methode, die Attribute, die Quelladresse und das Netzwerkverhalten prüfen, wenn der Server, das Verzeichnis oder das Zertifikat fehlerhaft sind.
Starten Sie mit einer kontrollierten Anfrage. Erweitern Sie dann die Fälle, bis ein falsches Positivresultat keinen Versteckplatz mehr hat.
Inhaltsverzeichnis
- Senden Sie Ihren ersten Test mit radtest
- Warum Access-Accept keinen Netzwerkzugriff beweist
- Testfälle, die jede RADIUS-Bereitstellung benötigt
- Messen Sie Last und Latenz mit radclient
- Fehlerpfade, Failover und Sicherheitsprüfungen
- Lesen Sie Protokolle, um jedes Testergebnis zu bestätigen
- Entscheiden Sie, wann RADIUS bereit für den Rollout ist
Senden Sie Ihren ersten Test mit radtest
Der Befehl, den Sie in den nächsten fünf Minuten ausführen können, lautet radtest testing password 127.0.0.1 0 testing123. Das FreeRADIUS radtest-Handbuch definiert dies als ein kontrolliertes Access-Request mit fünf Eingaben: Benutzername, Passwort, Serveradresse, NAS-Port und Shared Secret. PAP ist der Standardwert. Dasselbe Dienstprogramm kann auch CHAP, MS-CHAP oder EAP-MD5 senden.
Führen Sie die Baseline aus, bevor Sie etwas anderes ändern
- Definieren Sie ein Testkonto. Hinterlegen Sie einen bekannten Benutzernamen und ein Passwort dort, wo der Server sie finden kann. Sie benötigen Anmeldedaten, die Sie eingeben können, ohne erst ein Verzeichnis durchsuchen zu müssen.
- Listen Sie den Client auf. Der Host oder das NAS, von dem aus Sie senden, muss in der Datei
clients.confmit dem Secret eingetragen sein, das Sie eingeben werden. Eine unbekannte Quelle ist ein anderer Fehler als ein falsches Passwort. - Starten Sie den Server im Debug-Modus. Jedes Paket und jeder Ablehnungsgrund sollte im Terminal ausgegeben werden. Ein stillschweigender Fehler macht den Durchlauf nutzlos.
- Senden Sie die fünf Eingaben. Benutzername, Passwort, Server, NAS-Port, Secret. Ein NAS-Port von
0ist für diesen ersten Nachweis ausreichend. - Lesen Sie den Code und anschließend den Grund. Access-Accept bedeutet, dass der Server diese Anmeldedaten genehmigt hat. Access-Reject bedeutet, dass er sie verweigert hat. Die Debug-Ausgabe unterscheidet zwischen einem falschen Shared Secret, einem unbekannten Client, ungültigen Anmeldedaten und einem Richtlinienfehler.
- Wiederholen Sie den Vorgang vom NAS aus. Senden Sie dieselbe Anfrage von der Adresse des Access Points oder Switches und nicht nur von Localhost. Clients werden häufig über die Quelladresse und das Shared Secret gemeinsam autorisiert.
Erreichbarkeit ist nicht das Endergebnis. Das Paket muss ankommen und die Autorisierungsentscheidung muss Ihren Erwartungen entsprechen. Überprüfen Sie bei einer Annahme die zurückgegebenen Attribute wie VLAN, Diensttyp oder zugewiesene Adresse. Eine Annahme, die das falsche VLAN angibt, ist kein Erfolg - selbst wenn der Code fehlerfrei aussieht.
Nach dieser grundlegenden Annahme führt dasselbe Handbuch acht Methoden auf, die für das Beispielkonto funktionieren können: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC und EAP-MD5. Verfolgen Sie heute nicht alle acht.
Praktische Regel: Speichern Sie ein Access-Accept von der echten NAS-Adresse und ein Access-Reject für ein falsches Passwort. Diese beiden Notizen bilden die Baseline, an der jeder spätere Fall gemessen wird.
Warum Access-Accept keinen Netzwerkzugriff beweist
Ein grüner Infrastrukturtest ist das falsche Positivresultat, das ich nicht abzeichnen würde. Er zeigt oft nur, dass eine Anfrage irgendeine Antwort erhalten hat.
Im Meraki RADIUS Feherbehebungsleitfaden wird angegeben, dass der Dashboard-Test PEAP mit MS-CHAPv2 verwendet. Dieser Test schlägt fehl oder liefert keine aussagekräftige Validierung für EAP-TLS, da der Access Point über kein Client-Zertifikat verfügt. Zertifikatbasiertes WLAN muss mit einem echten Supplicant getestet werden, der das richtige Zertifikat und die richtige Trust-Chain enthält.
Vier Schichten, vier verschiedene Fragen
Transport fragt ab, ob etwas geantwortet hat. Ein Timeout ist keine Ablehnung.
Authentifizierung fragt, ob das Passwort oder Zertifikat für diese Identität gültig war.
Autorisierung fragt, ob die Antwort die VLAN, Rolle oder ACL enthielt, die Sie senden wollten.
Erreichbarkeit prüft, ob der Endpunkt die erwartete Adresse, DNS-Richtlinie und den Zugriff auf die Ressourcen erhalten hat, die dieses Segment zulassen sollte.
Ein erfolgreicher Test auf einer Ebene sagt nichts über die anderen drei Ebenen aus. Dieselben Meraki-Richtlinien beschreiben zusammen mit dem FreeRADIUS-EAP-Verhalten einen erfolgreichen EAP-TLS-Test als einen mehrstufigen Paket-Austausch von Access-Request und Access-Challenge mit anschließendem echtem Client-Netzwerkzugriff. Eine einfache Verbindungsprüfung entspricht diesem Test nicht.
Überprüfen Sie den Servernamen, dem der Supplicant vertraut, die CA-Kette, den Zertifikatsablauf und die Geräteuhrzeit. Eine Uhrenabweichung lässt ein gültiges Zertifikat fehlschlagen. Nehmen wir an, ein Mitarbeiter-Laptop authentifiziert sich und befindet sich dann auf dem Standard-VLAN statt im Mitarbeitersegment. Das „Accept“ war echt. Die Netzwerkplatzierung war falsch. Das ist der Fehler, den die meisten Checklisten nie erfassen.
Führen Sie separate Zeilen für Passwort-Benutzer, EAP-TLS-Geräte, xPSK-Identitäten und verzeichnisgesteuerte Richtlinien. Ein PAP-Accept darf nicht als Ersatz für einen Zertifikatsbeitritt stehen.
Testen Sie EAP-TLS auf einem Ersatzgerät
- Stellen Sie ein Test-Clientzertifikat von derselben CA aus, der der Server vertraut.
- Installieren Sie das Zertifikat und die CA-Kette auf einem Ersatz-Laptop oder -Telefon.
- Bestätigen Sie, dass der Supplicant den von Ihnen konfigurierten Servernamen validiert.
- Stellen Sie eine Verbindung her und erfassen Sie den Challenge-Austausch, nicht nur eine Ein-Paket-Stichprobe.
- Bestätigen Sie, dass die Sitzung auf der erwarteten VLAN mit echtem Netzwerkzugriff endet.
Eine kurze Ansicht dieses Austauschs erleichtert das Erkennen des Captures, wenn Ihr eigener Trace unübersichtlich ist.
Testfälle, die jede RADIUS-Bereitstellung benötigt
Ein gültiger Anmeldedaten-Datensatz kann ein Access-Accept erzeugen, obwohl der Benutzer im falschen Netzwerk landet. Testen Sie jede Ebene separat: Anfragenverarbeitung, Authentifizierung, Autorisierungsattribute und den tatsächlichen Zugriff des Endpunkts. Der Leistungstest-Leitfaden für FreeRADIUS deckt sowohl die Last als auch die Korrektheit ab. Beziehen Sie auch negative Fälle ein: Ungültige Anmeldedaten sollten Access-Reject zurückgeben, während fehlerhafte Anfragen, ein nicht mechatronisch erkannter NAS und ein falsches Shared Secret keinesfalls zu einer erfolgreichen Anmeldung führen dürfen.
Der radtest-Workflow ist seit Langem etabliert und nutzt weiterhin dieselben fünf Eingaben. Testen Sie bei getunnelten Methoden den inneren Authentifizierungsserver separat auf dem UDP-Port 18120. Verwenden Sie einen inneren MS-CHAP-Test, wenn PEAP die äußere Methode ist. Dies hilft zu isolieren, ob ein Fehler beim äußeren EAP-Austausch, der Zertifikats- oder TLS-Einrichtung oder der inneren Anmeldedatenprüfung liegt.
Ein Access-Accept ist eine zu überprüfende Hypothese, kein Nachweis für einen korrekten Netzwerkzugriff. Der FreeRADIUS-Implementierungsleitfaden beschreibt, wie ein NAS ein nicht unterstütztes VLAN-Attribut verwerfen oder ein fehlendes Attribut einem Standard-VLAN zuordnen kann. Überprüfen Sie die zurückgegebenen Attribute und anschließend die Adresse, das VLAN, die ACL, die DNS-Richtlinie und die Erreichbarkeit des Endpunkts. EAP-MD5 liefert nicht das von WLAN benötigte Schlüsselmaterial, daher ist ein EAP-MD5-Accept kein Nachweis für die WLAN-Bereitschaft. Verwenden Sie es nur für eingeschränkte kabelgebundene Tests.
Legen Sie die vorgesehenen Segmente fest, bevor Sie Autorisierungstests durchführen; WiFi Zugriffskontrolle erklärt, wie diese Richtlinie strukturiert wird.
Neun Zeilen, die als Minimum gelten
| Testfall | Durchführung | Erwartetes Ergebnis |
|---|---|---|
| Baseline-Bestätigung | Führen Sie radtest mit einem gültigen Testkonto über die NAS-IP aus |
Access-Accept mit dem erwarteten VLAN-Attribut; bestätigen Sie, dass der Endpunkt auf diesem VLAN landet |
| Falsches Passwort | Führen Sie radtest mit einem falschen Passwort aus |
Access-Reject mit einem protokollierten Grund |
| Falsches Shared Secret | Senden Sie die Anfrage von einem Client, der mit einem nicht übereinstimmenden Secret konfiguriert ist | Kein Access-Accept; Secret-Fehler in der Debug-Ausgabe sichtbar |
| Unbekanntes NAS | Senden Sie die Anfrage von einer IP-Adresse, die nicht als Client definiert ist | Verworfen oder abgelehnt und protokolliert |
| Gültiges EAP-TLS-Gerät | Verbinden Sie einen echten Supplicant mit einem gültigen Zertifikat und einer vertrauenswürdigen Kette | Access-Accept und das korrekte VLAN für seine Gruppe; bestätigen Sie den Netzwerkzugriff vom Gerät aus |
| Abgelaufenes oder widerrufenes Zertifikat | Verbinden Sie ein Gerät mit einem abgelaufenen oder widerrufenen Zertifikat | Access-Reject, ohne Fallback auf ein Standardnetzwerk |
| Verzeichnisgruppenänderung | Verschieben Sie den Testbenutzer in eine andere Gruppe und authentifizieren Sie ihn erneut | VLAN oder Rolle ändert sich entsprechend der neuen Gruppe, oder der Zugriff wird verweigert |
| Primärer Server nicht verfügbar | Blockieren Sie UDP 1812 zum primären Server oder stoppen Sie ihn | Failover auf den sekundären Server innerhalb der Zeitüberschreitung unter Anwendung derselben Richtlinie |
| Accounting-Start und -Stopp | Starten Sie eine Sitzung und beenden Sie sie anschließend | Start- und Stopp-Datensätze stimmen mit der Sitzung überein |
Erfassen Sie für jede Zeile den Eingang der Anfrage, den Antwortcode, die Roundtrip-Latenz, die ausgewählte Richtlinie, die zurückgegebenen Attribute sowie Accounting-Start und -Stopp. Wiederholen Sie jeden Test, um zeitweise auftretende UDP-Verluste zu erkennen. Ein einzelner fehlerfreier Durchlauf kann ein falsches VLAN oder eine inkonsistente Richtlinienentscheidung übersehen.
Eine Bestätigung, die den Client im falschen Netzwerk platziert, gilt als fehlgeschlagener Test.
Messen Sie Last und Latenz mit radclient
Ein unauffälliges Accept verbirgt Warteschlangenbildung. Lasttests erfordern ein Werkzeug, das für Batch-Verarbeitung ausgelegt ist - nicht eine weitere einzelne Anmeldung.
- Erstellen Sie eine Authentifizierungsdatei mit zufällig generierten Benutzernamen und Passwörtern. Mischen Sie gültige und ungültige Einträge, damit Ablehnungen gezählt und nicht als Rauschen behandelt werden.
- Senden Sie die Datei und messen Sie die Zeit des Batches mit dem Unix-Befehl
time, währendradclientden Server ansteuert. - Erfassen Sie die Rohdaten. Anfragen gesamt, Akzeptierungen, Ablehnungen, Zeitüberschreitungen, Fehler-Antworten und verstrichene Zeit.
- Berechnen Sie die Raten. Die Akzeptanzrate sollte dem gültigen Anteil der Datei entsprechen. Die Ablehnungsrate sollte dem ungültigen Anteil entsprechen. Ermitteln Sie zudem die durchschnittliche und perzentile Latenz.
- Wiederholen Sie den Vorgang zu Spitzenzeiten. Ein morgendlicher Check-in oder ein Schulbeginn zeigt Warteschlangenbildung auf, die bei einem Testlauf in der Mittagspause niemals sichtbar wird.
| Messwert | Berechnungsmethode | Zielwert |
|---|---|---|
| Anfragen gesamt | Anzahl der aus der Authentifizierungsdatei gesendeten Zeilen | Entspricht der Dateilänge |
| Akzeptanzrate | Anzahl der Akzeptierungen geteilt durch Anfragen gesamt | Entspricht dem gültigen Anteil der Datei |
| Ablehnungsrate | Anzahl der Ablehnungen geteilt durch Anfragen gesamt | Entspricht dem ungültigen Anteil der Datei |
| Zeitüberschreitungen und Fehler | Anzahl der Nicht-Antworten und Fehler-Antworten im Durchlauf | Null bei ordnungsgemäßem Verlauf |
| Durchschnittliche Latenz | Mittlere Antwortzeit über alle Anfragen hinweg | Zu Spitzenzeiten innerhalb Ihres Latenz-Zielwerts |
| Verstrichene Zeit | Unix-Zeitausgabe für den gesamten Batch | Stabil über wiederholte Durchläufe hinweg |
Trennen Sie den Tunnel vom Kontospeicher
Wenn die Akzeptanzrate niedriger ist als der gültige Anteil, schieben Sie die Schuld nicht auf die „Last“, bis Sie wissen, welche Hälfte fehlgeschlagen ist. Testen Sie für PEAP die innere Methode für sich allein mit einer MS-CHAP-Anfrage an den inneren Server. Eine innere Akzeptanz mit einer fehlerhaften äußeren Verbindung deutet auf Zertifikate oder TLS-Einstellungen hin. Ein äußerer Handshake, der bei der inneren Prüfung fehlschlägt, deutet auf den Account-Speicher, den Passwort-Hash oder die von der Richtlinie erwartete Gruppe hin.
Bewahren Sie diese Zeiten im selben Log wie die funktionalen Ergebnisse auf. Eine spätere Firmware- oder Verzeichnisänderung sollte mit dieser Baseline verglichen werden und nicht mit dem Gefühl, dass „es sich langsamer angefühlt hat“.
Wenn Zeitüberschreitungen nur zu Spitzenzeiten steigen, beheben Sie die Kapazität oder den Pfad, bevor Sie weitere Standorte hinzufügen. Ein Server, der korrekt und langsam ist, führt dennoch zu Fehlern bei Clients, die zuerst abbrechen.
Fehlerpfade, Failover und Sicherheitsprüfungen
Ein funktionierender Austausch kann dennoch unsicher sein. Eine Fehlersuche, die nur prüft, ob UDP 1812 eine Antwort erhalten hat, stoppt zu früh.
Junipers Sicherheitshinweis von 2025 beschreibt die anfällige Blast-RADIUS-Exposition im RFC 2865 Response Authenticator. Ein lokaler Angreifer, der den Datenverkehr verändern kann, kann möglicherweise eine gültige Antwort durch eine MD5-Chosen-Prefix-Kollision in eine andere Antwort umwandeln. „Authentifizierung erfolgreich“ ist kein Beweis dafür, dass die Bereitstellung geschützt ist.
Prüfungen, die in denselben Durchlauf wie das Failover gehören
Schützen Sie den Pfad dort, wo die Plattform es zulässt. Bestätigen Sie, dass Manipulationen auf dem Pfad blockiert werden und dass die Message-Authenticator-Validierung bei Paketen erzwungen wird, die dies erfordern.
Deaktivieren Sie schwache Methoden. Veraltete EAP-Typen sollten deaktiviert werden und nicht "für alle Fälle" aktiv bleiben. Wenn Sie sich noch zwischen Zertifikats- und Passwort-Außenmethoden entscheiden, vergleichen Sie diese in EAP-TLS vs. PEAP, bevor Sie beide aktiviert lassen.
Führen Sie den Serverabsichtlichen Ausfall herbei. Jedes der folgenden Szenarien sollte den vorgesehenen Fail-Closed-Zustand oder einen kontrollierten Fallback zeigen, zusammen mit einer Log-Zeile, einem Alarm und einer Benutzererfahrung, die Sie einem Standortleiter erklären können.
| Ausfallszenario | So lösen Sie es aus | Bestehensbedingung |
|---|---|---|
| Zeitüberschreitung | UDP 1812 zum Server blockieren | Fail-Closed oder kontrollierter Fallback, protokolliert und alarmiert |
| Access-Reject | Falsches Passwort verwenden | Zugriff verweigert ohne Fallback-Netzwerk |
| Abgelaufenes Zertifikat | Gerät mit abgelaufenem Zertifikat | Access-Reject ohne Standard-VLAN |
| Widerrufenes Zertifikat | Gerät mit widerrufenem Zertifikat | Access-Reject ohne Standard-VLAN |
| Unbekannte NAS-Quell-IP | Von einer undefinierten Adresse senden | Verworfen oder abgelehnt und protokolliert |
| Fehlerhaftes Shared Secret | Nicht übereinstimmendes Secret auf dem Client | Kein Access-Accept und Secret-Fehler in der Debug-Ausgabe |
| Nicht erreichbares Verzeichnis | Verzeichnisverbindung stoppen | Abgelehnt oder kontrollierter Fallback gemäß Richtlinie |
| Verzögerte Autorisierungsantwort | Verzögerung zur Autorisierungsantwort hinzufügen | Zeitüberschreitung ohne offenen Zugriff verarbeitet |
Was ein regionales Failover aufrechterhalten muss
Dass ein anderer Server antwortet, bedeutet nicht, dass die Richtlinien konsistent sind. Wenn Sie den primären Server stoppen, vergleichen Sie VLAN, Bandbreitenbegrenzungen, Sperrstatus und Audit-Attribute des Backup-Servers mit dem primären Server. Ein Gast, der per Failover in ein Mitarbeitersegment gelangt, stellt einen fehlgeschlagenen Test dar - selbst wenn der Beitritt schnell erfolgte.
Markieren Sie jedes Szenario, das auf einen offenen Zugriff zurückgreift, als fehlgeschlagen - unabhängig davon, ob der Benutzer online geht oder nicht. Tragen Sie jedes Ergebnis in dasselbe Test-Log wie die funktionale Baseline ein, damit eine spätere Failover-Änderung sofort ersichtlich ist.
Lesen Sie Protokolle, um jedes Testergebnis zu bestätigen
Jeder Test sollte eine Spur hinterlassen, die Sie einer Test-ID oder einem bekannten Konto zuordnen können. In einer ausgelasteten Umgebung ist dieses Label die Möglichkeit, Ihren Durchlauf zu finden, ohne durch die Daten aller anderen vom Morgen scrollen zu müssen.
Gleichen Sie für jede Authentifizierung diese Felder ab:
- Identität und Gerät: wer oder was beigetreten ist, nicht nur eine MAC-Adresse, von der Sie hoffen, dass sie Ihnen gehört.
- Methode: EAP-TLS, PEAP oder ein individueller PSK. Eine Methode, die Sie nicht bereitgestellt haben, ist ein Befund.
- Ort: Access Point, SSID und Standort.
- Entscheidung: VLAN und zurückgegebene Rolle oder der Ablehnungsgrund.
- Zeit: Zeitstempel, der innerhalb des von Ihnen getesteten Fensters liegt.
Unser Authentifizierungsprotokoll ist genau auf diesen Abgleich ausgelegt. Eine standortübergreifende Abfrage zeigt jede Annahme und Ablehnung samt Identität, Gerät, Registrierungsstatus, Methode, Access Point, SSID, Standort, VLAN, Rolle, Grund und Zeitstempeln. Nutzen Sie dies, wenn ein Standort über viele Access Points verfügt und Sie prüfen müssen, ob derselbe Fehler überall oder nur auf einem einzelnen Controller auftritt.
Drei Muster, die darauf hinweisen, dass die Notizen falsch sind
Der Grund passt nicht zum Test. Sie haben ein falsches Passwort gesendet und im Log steht „unbekannter Client“. Sie haben das Falsche getestet oder es sind zwei Fehler zusammengekommen.
Das Accept benennt die Standard-VLAN. Anmeldedaten haben funktioniert. Die Platzierung nicht. Schließen Sie das Ticket nicht.
Accounting wurde gestartet und nie gestoppt. Der Sitzungsdatensatz ist unvollständig, sodass Sie nicht belegen können, dass der Client das Netzwerk zu dem von Ihnen vermuteten Zeitpunkt verlassen hat. Vergleichen Sie Start und Stopp mit der von Ihnen ausgeführten Sitzung, nicht mit der eines Benutzers in der Nähe.
Richten Sie für das Testfenster einen Alarm für Reject-Spitzen ein, damit ein falsches Shared Secret nicht wie „Benutzer hat sich Tippfehler erlaubt“ aussieht. Bewahren Sie den Log-Auszug zusammen mit den Testnotizen auf. Dieser Auszug dient als Prüfungsnachweis, wenn Wochen später jemand nachfragt, was Sie nachgewiesen haben.
Entscheiden Sie, wann RADIUS bereit für den Rollout ist
Gehen Sie erst live, wenn die Nachweise fünf Kriterien erfüllen. Ein zuversichtlicher Techniker gehört nicht dazu.
- Jede Matrixzeile wird auf jedem NAS-Typ erfolgreich durchlaufen, den Sie bereitstellen, einschließlich aller SSID- oder Zugriffsrichtlinien, die Sie beibehalten möchten.
- Failover behält dasselbe Verhalten bei VLAN, Richtlinie und Sperrung bei wie das primäre System. Ein zweiter Server, der mit einer anderen Rolle antwortet, besteht diese Prüfung nicht.
- Kein Fehlerszenario führt zu einer unsicheren Öffnung (Fail-Open). Falsches Passwort, ausgefallenes Verzeichnis, abgelaufenes Zertifikat und eine verzögerte Antwort dürfen den Benutzer nicht in ein uneingeschränktes Netzwerk leiten.
- Die Last bleibt zu Spitzenzeiten innerhalb Ihres Latenz-Zielwerts, wobei die Akzeptanzrate dem gültigen Anteil der Testdatei entspricht.
- Protokolle zeigen den erwarteten Grund und VLAN für jeden Durchlauf, den Sie als erfolgreich eingestuft haben.
Halten Sie den umfassenderen Rollout zurück, bis diese fünf Punkte an einem echten Standort zutreffen - nicht nur im Labor VLAN.
Wir ermöglichen Ihnen, dies zuerst an einem Standort zu beweisen. Richten Sie die neuen offenen, sicheren und xPSK-Netzwerke auf den Access Points ein, die dieser Standort bereits nutzt - neben dem Netzwerk, das er heute verwendet - und beurteilen Sie das Ergebnis anhand von Tickets und Audit-Nachweisen, bevor Änderungen an anderen Standorten vorgenommen werden. Während dieses Pilots sollte das Protokoll zwei Fragen ohne ein Meeting beantworten: Welche Geräte sind über welche VLAN beigetreten und welcher Akzeptanz- oder Ablehnungsgrund trat am häufigsten auf.
Erweitern Sie erst, wenn die Tickets und der Audit-Auszug keine unerwarteten Ablehnungen und keine Geräte im falschen Segment zeigen. Halten Sie die Matrix als ständige Regressionssuite aufrecht. Führen Sie sie nach jeder Zertifikatsverlängerung, jedem Firmware-Update oder jeder Verzeichnisänderung erneut gegen dieselbe Baseline aus, bevor die Benutzer die Änderung sehen. Wie dieser Pilot-Standort konzipiert werden sollte, erfahren Sie unter WiFi Netzwerkdesign. Testen Sie das Design, das Sie beibehalten möchten, und kein temporäres SSID, das Sie nächste Woche löschen werden.
Purple Access bietet Ihnen Cloud-RADIUS, das jedes Gerät nach Identität im offenen, sicheren oder xPSK-Netzwerk platziert, wobei VLAN und der Ablehnungsgrund im Authentifizierungsprotokoll sichtbar sind. Wenn Sie möchten, dass dieser Testplan für die bereits vorhandenen Access Points ausgeführt wird, beginnen Sie mit einem Standort und lesen Sie das Ergebnis ab, bevor Sie den Rollout fortsetzen. Besuchen Sie Purple Access und bringen Sie den ersten Standort auf eine Baseline, die Sie verteidigen können.
