AnyConnect überschreibt Ihr Profil? Es ist eine Namenskollision

Die Geschichte, die herumgeht, lautet, AnyConnect habe Ihr zweites Gateway verloren, oder der Client sei zu alt, um zwei Profile zu halten. Nichts davon ist passiert. Passiert ist, dass der Client jedes Profil, das er gesehen hat, als Datei speichert, die nach dem benannt ist, was der Server geschickt hat, und Ihre beiden Gateways ihre Datei gleich nennen. Auf der Platte gibt es für diesen Namen einen Platz, also nimmt der zweite Download den Platz des ersten ein.

Zwei Ordner, und nur einer gehört Ihnen

Die Kopie, die sich ständig ändert, ist die Arbeitskopie unter Ihrem eigenen Benutzerprofil, normalerweise %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Diese Datei hält die letzte Verbindung fest, die Sie aufgebaut haben, und welches Profil dabei verwendet wurde. Weil sie in Ihrem Ordner liegt, schreibt der Client sie bei jeder Verbindung neu, ohne eine Rechteerhöhung zu verlangen.

Die Liste im Dropdown-Menü ist etwas anderes. Jedes Profil, das die Maschine je empfangen hat, wird nach %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile kopiert, und der Client listet, welche Dateien dort liegen. In diesen Ordner zu schreiben erfordert Administratorrechte, was ein Symptom erklärt, das viele falsch deuten: Ein Profil als normaler Benutzer von Hand hinzuzufügen scheint zu funktionieren, dann verschwindet der Eintrag.

Die Datei pro Benutzer ist also ein Zeiger, und der Ordner für die ganze Maschine ist die Bibliothek. Ein fehlender Eintrag bedeutet, dass sich die Bibliothek geändert hat, nicht der Zeiger.

Der Client gleicht Dateien nach Namen ab, nicht nach Gateway

Die Profilidentität ist in diesem Client der Dateiname. Zwei Appliances, die beide company.xml ausliefern, sind aus Sicht des lokalen Profilspeichers dasselbe Profil, zweimal veröffentlicht. Der zweite Download überschreibt den ersten, und der Eintrag im Fenster zeigt weiter auf eine Datei, die jetzt den anderen Standort beschreibt.

Deshalb wirkt der Fehler so seltsam. Der Name in der Liste liest sich weiter wie der Ort, den Sie erwarten, die Authentifizierung gelingt weiter gegen das Gateway, das tatsächlich konfiguriert ist, und nichts meldet einen Fehler. Geändert hat sich der Inhalt hinter einem Etikett, dem Sie vertraut haben.

Lesen Sie HostAddress, nicht das Etikett

Öffnen Sie die Datei in einem Texteditor und sehen Sie sich die Serverliste an. Ein Profil trägt ein HostName-Element, das ein Anzeige-Etikett ist, und ein HostAddress-Element, das das Gateway ist, das der Client tatsächlich kontaktiert. Das Etikett ist freier Text, den jeder bearbeiten kann, und die Adresse entscheidet, wo Sie landen.

Vergleichen Sie beides mit dem Gateway, das Sie erreichen wollten, bevor Sie schließen, dass der Client defekt ist.

Beide Gateways behalten, der Reihe nach

Besorgen Sie sich das akzeptierte Profil für jeden Standort, entweder vom Standort oder von einer Maschine, die sich bereits verbindet. Benennen Sie jede Datei so um, dass sich die beiden Namen unterscheiden, zum Beispiel site-a.xml und site-b.xml. Legen Sie beide als Administrator in den maschinenweiten Profilordner und heben Sie die Originale auf, die Sie erhalten haben. Starten Sie dann den Client neu und prüfen Sie, ob beide Einträge im Dropdown-Menü erscheinen.

Öffnen Sie nach dem Verbinden mit jedem von beiden preferences.xml erneut und sehen Sie nach, welchen Profilnamen er jetzt als zuletzt verwendet festhält. Stimmt der Name mit dem Eintrag überein, auf den Sie geklickt haben, verhält sich die lokale Zuordnung korrekt. Wenn nicht, schiebt noch etwas eine Datei über Ihre umbenannte Kopie.

Was Umbenennen nicht behebt

Ein neuer Dateiname ändert ein lokales Etikett und sonst nichts. Die Gateway-Adresse, die Authentifizierungsmethode, das Zertifikat, das der Server vorzeigt, und jede Gruppenauswahl im Profil bleiben, wie sie waren. Eine umbenannte Kopie des falschen Profils ist weiterhin das falsche Profil, und sie verbindet Sie unter einem überzeugenden Namen mit dem falschen Standort.

Sie übersteht auch keinen Verwaltungs-Push, der auf den ursprünglichen Dateinamen zielt.

Wenn der nächste Push das rückgängig macht

Wenn Ihre Organisation Profile nach Namen verteilt, ersetzt ein Update jede Datei, die diesen Namen trägt. Betrachten Sie die umbenannten Kopien als lokale Bequemlichkeit und wiederholen Sie den Verbindungstest nach jedem Client-Update, wobei Sie die Adresse prüfen und nicht das Etikett.

Für eine dauerhafte Lösung bitten Sie um eine unterstützte Multi-Gateway-Einrichtung, statt Dateien von Hand zu pflegen. Änderungen im Programmverzeichnis sind das Erste, was ein Upgrade entfernt, und die Benutzereinstellungsdatei wird konstruktionsbedingt neu geschrieben.

Führen Sie eine Zeile pro Gateway: Dateiname, HostAddress und in welchem Ordner sie liegt. Diese Notiz beantwortet den nächsten Falscher-Standort-Bericht schneller als eine Neuinstallation.