Das Ersetzen eines funktionierenden VPN-Passworts sieht wie eine Änderung in zwei Zeilen aus, bis das neu aufgebaute Konto mit Standardberechtigungen zurückkommt und die einzige Verwaltungssitzung weg ist. Das sichere Verfahren hängt davon ab, wo die Anmeldeinformation gespeichert ist und welches Protokoll sie verwendet, nicht davon, welcher Befehl am kürzesten ist. Vergleichen Sie die beiden Ansätze, bevor Sie das Gerät anfassen. Die Rotation an Ort und Stelle erhält das Kontoobjekt; Löschen und Neuanlegen ersetzt es, und alles, was darauf zeigte, geht mit ihm.

Finden Sie heraus, welcher Speicher die Sitzung tatsächlich authentifiziert

Beginnen Sie beim Tunnel- oder Verbindungsprofil, nicht bei der Benutzerdatenbank. Das Profil nennt eine Authentifizierungsmethode und oft eine Servergruppe, und wenn diese Gruppe auf RADIUS oder TACACS+ zeigt, ist der lokale Benutzername auf dem Gerät reine Dekoration. Lesen Sie die Authentifizierungsliste des Profils und die AAA-Gruppe, auf die es verweist, bevor Sie irgendetwas planen. Nur wenn das Profil lokal sagt, zählt das Konto auf dem Gerät. Machen Sie das falsch, rotieren Sie eine Anmeldeinformation, die niemand nutzt, während der echte Verzeichniseintrag genau so bleibt, wie er war.

Dasselbe Gerät beherbergt normalerweise zwei Populationen: Administratoren, die sich anmelden, und VPN-Benutzer, die einen Tunnel beenden. Sie können einen Speicher teilen, und man sollte nicht annehmen, dass sie es tun.

Aktualisierung an Ort und Stelle versus Löschen und Neuanlegen

Die Rotation an Ort und Stelle ändert ein Attribut eines vorhandenen Objekts. Privilegienstufe, Gruppenmitgliedschaft, Autorisierungsattribute und jede Richtlinie, die auf das Konto verweist, bleiben erhalten, weil nichts entfernt wurde. Löschen und Neuanlegen baut das Objekt von einer Befehlszeile aus neu auf, sodass jedes Feld, das Sie nicht wiederholten, mit seinem Standardwert zurückkommt. Auf einem Gerät, auf dem benutzerspezifische Attribute Split-Tunnel- oder Adresspoolzuweisungen tragen, ist dieser Unterschied das gesamte Risiko.

Der Neuaufbau hat einen legitimen Nutzen: wenn das gespeicherte Format selbst geändert werden muss und die Plattform keine Konvertierung bietet. Selbst dann erfassen Sie zuerst den vorhandenen Eintrag, denn die laufende Konfiguration ist die einzige genaue Bestandsaufnahme dessen, was das Konto trug. Eine vor der Änderung genommene Kopie dieser Konfiguration schlägt einen aus dem Gedächtnis geschriebenen Rollback-Plan.

Warum der Hash, den Sie haben, vielleicht nicht das Geheimnis ist, das er braucht

Speicherformate unterscheiden sich auf eine Weise, die die Antwort entscheidet. Ein Einweg-Hash kann ein Passwort verifizieren, wenn der Server es im Klartext innerhalb des Tunnels empfängt, aber ein Challenge-Response-Verfahren benötigt das gemeinsame Geheimnis selbst, um den Digest zu berechnen. Daher kann die Umstellung jedes Kontos auf das stärkste Einwegformat CHAP oder MS-CHAP genau für die Benutzer brechen, die darauf angewiesen sind.

Entscheiden Sie nach Protokoll, nicht nach Slogan. Wo die Methode ein wiederherstellbares Geheimnis benötigt, ist diese Anforderung eine Einschränkung des Designs und kein Versehen, das bereinigt werden müsste.

Sitzungen, die die Anmeldeinformation überleben

Das Ändern einer Anmeldeinformation beendet keine Sitzungen, die sich bereits authentifiziert haben. Ein Peer mit einem aufgebauten Tunnel arbeitet weiter bis zur Schlüsselerneuerung, erneuten Authentifizierung oder einer ausdrücklichen Trennung.

Planen Sie diesen Teil separat, und planen Sie ihn vor der Änderung. Wenn die Anmeldeinformation kompromittiert wurde, macht das Weiterlaufen aktiver Sitzungen die Rotation zunichte. Wenn sie nur abgelaufen ist, ist das Offlinezwingen jedes Peers eine Ausfallzeit, die Sie nicht brauchten. Halten Sie während der Arbeit einen zweiten Verwaltungsweg offen, vorzugsweise einen, der nicht vom bearbeiteten Konto abhängt, denn der Fehlermodus hier entzieht Ihnen den Zugang genau dann, wenn Sie ihn brauchen. Verifizieren Sie dann eine neue Anmeldung und die Ressourcen, die sie erreichen kann.

Beweisen Sie, dass die Berechtigungen überlebt haben

Melden Sie sich als der rotierte Benutzer an und prüfen Sie, was die Sitzung gewährt, nicht nur, dass sie sich geöffnet hat. Erreichen Sie eine Ressource, die die Autorisierung erfordert, die das Konto tragen soll, und versuchen Sie eine, die es nicht erreichen sollte. Eine erfolgreiche Anmeldung mit verengtem oder erweitertem Zugriff ist eine gescheiterte Änderung.

Vergleichen Sie die Autorisierungsattribute in der laufenden Konfiguration mit der Kopie, die Sie zu Beginn genommen haben. Prüfen Sie Gruppenmitgliedschaft, Adresspool, DNS- und Split-Tunnel-Einstellungen und jedes Richtlinienobjekt, das das Konto nannte. Aktualisieren Sie dann den Vermerk, wo diese Anmeldeinformation lebt, denn die nächste Rotation beginnt bei dieser Notiz. Eine Rotation, die niemand anhand der Dokumentation wiederholen kann, wurde nur einmal überlebt.

Ähnliche Artikel