AnyConnect overschrijft je profiel? Het is een naamconflict
Twee gateways, één bestandsnaam: de client bewaart het laatste profiel in jouw map terwijl de bibliotheek machinebreed is. Hernoem de kopieën om beide te behouden.
Het verhaal dat rondgaat, is dat AnyConnect je tweede gateway kwijt is, of dat de client te oud is om twee profielen te houden. Geen van beide is gebeurd. Wat er gebeurde, is dat de client elk profiel dat hij heeft gezien opslaat als een bestand dat is genoemd naar wat de server stuurde, en je twee gateways noemen hun bestand hetzelfde. Er is één plek op schijf voor die naam, dus de tweede download neemt de plek van de eerste in.
Twee mappen, en slechts één is van jou
De kopie die verandert, is de werkkopie onder je eigen gebruikersprofiel, meestal %LOCALAPPDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml. Dat bestand legt de laatste verbinding vast die je maakte en welk profiel daarbij werd gebruikt. Omdat het in jouw map staat, herschrijft de client het bij elke verbinding zonder om verhoogde rechten te vragen.
De lijst in het vervolgmenu is iets anders. Elk profiel dat de machine ooit heeft ontvangen, wordt naar %PROGRAMDATA%\Cisco\Cisco AnyConnect Secure Mobility Client\Profile gekopieerd, en de client toont welke bestanden daar staan. Schrijven naar die map vereist beheerdersrechten, wat een symptoom verklaart dat mensen verkeerd lezen: een profiel handmatig toevoegen als gewone gebruiker lijkt te werken, en dan verdwijnt de vermelding.
Het bestand per gebruiker is dus een aanwijzer en de map voor de hele machine is de bibliotheek. Een ontbrekende vermelding betekent dat de bibliotheek is veranderd, niet de aanwijzer.
De client koppelt bestanden op naam, niet op gateway
De profielidentiteit in deze client is de bestandsnaam. Twee apparaten die beide company.xml pushen, zijn vanuit de lokale profielopslag hetzelfde profiel, twee keer gepubliceerd. De tweede download overschrijft de eerste, en de vermelding in het venster wijst nog steeds naar één bestand dat nu de andere locatie beschrijft.
Daarom ziet de storing er zo vreemd uit. De naam in de lijst leest nog steeds als de plek die je verwacht, de authenticatie slaagt nog steeds tegen de gateway die werkelijk is geconfigureerd, en niets meldt een fout. Wat veranderde, is de inhoud achter een label dat je vertrouwde.
Lees HostAddress, niet het label
Open het bestand in een teksteditor en bekijk de serverlijst. Een profiel bevat een HostName-element, dat een weergavelabel is, en een HostAddress-element, dat de gateway is die de client werkelijk benadert. Het label is vrije tekst die iedereen kan bewerken, en het adres bepaalt waar je terechtkomt.
Vergelijk die twee met de gateway die je wilde bereiken voordat je concludeert dat de client stuk is.
Beide gateways behouden, in volgorde
Haal het geaccepteerde profiel voor elke locatie op, of van de locatie of van een machine die al verbindt. Hernoem elk bestand zodat de twee namen verschillen, bijvoorbeeld site-a.xml en site-b.xml. Plaats beide als beheerder in de profielmap van de hele machine en bewaar de originelen die je ontving. Start daarna de client opnieuw en bevestig dat beide vermeldingen in het vervolgmenu verschijnen.
Open na het verbinden met elk daarvan preferences.xml opnieuw en controleer welke profielnaam hij nu als laatst gebruikt vastlegt. Als de naam overeenkomt met de vermelding waarop je klikte, gedraagt de lokale toewijzing zich correct. Zo niet, dan duwt er nog iets een bestand over je hernoemde kopie.
Wat hernoemen niet oplost
Een nieuwe bestandsnaam verandert een lokaal label en niets anders. Het gatewayadres, de authenticatiemethode, het certificaat dat de server toont en elke groepsselectie in het profiel blijven zoals ze waren. Een hernoemde kopie van het verkeerde profiel is nog steeds het verkeerde profiel, en het verbindt je onder een overtuigende naam met de verkeerde locatie.
Hij overleeft ook geen beheerpush die op de oorspronkelijke bestandsnaam is gericht.
Wanneer de volgende push het ongedaan maakt
Als je organisatie profielen op naam verspreidt, vervangt een update elk bestand dat die naam deelt. Beschouw de hernoemde kopieën als lokaal gemak en herhaal de verbindingstest na elke clientupdate, waarbij je het adres controleert en niet het label.
Vraag voor een blijvende oplossing een ondersteunde multi-gateway-opstelling aan in plaats van bestanden handmatig te onderhouden. Wijzigingen in de programmamap zijn het eerste dat een upgrade verwijdert, en het voorkeurenbestand per gebruiker wordt volgens ontwerp herschreven.
Houd één regel per gateway: bestandsnaam, HostAddress en in welke map die staat. Die notitie beantwoordt het volgende verkeerde-locatie-rapport sneller dan een herinstallatie.