FortiClient: het vakje Wachtwoord opslaan ontbreekt? De gateway beslist

U rondt de installatie van FortiClient af, maakt verbinding met de SSL VPN van kantoor en zoekt een besturingselement om het wachtwoord op te slaan dat er simpelweg niet is. De client opnieuw installeren brengt het niet terug, en de tunnel verwijderen en opnieuw toevoegen ook niet. In een SSL VPN-profiel bepaalt de firewall of de client überhaupt inloggegevens mag bewaren. Een ontbrekend vakje betekent dus meestal dat er een beleid van de gateway is gekomen, niet dat het installatieprogramma heeft gefaald.

Dat onderscheid is belangrijk voordat u bestanden gaat aanpassen: een van deze routes is een gesprek met de eigenaar van de firewall, de andere is laboratoriumwerk dat wordt overschreven.

Controleer de portal voordat u het eindpunt aanraakt

Vraag degene die de FortiGate beheert de SSL VPN-portal te openen waar uw tunnel naartoe wijst en de instelling voor wachtwoordopslag te lezen. Als de optie is uitgeschakeld, wordt van FortiClient verwacht dat het het besturingselement verbergt en weigert de inloggegevens op te slaan. Het eindpunt gehoorzaamt de regel in plaats van defect te zijn.

Eén snelle test scheidt beleid van een kapot profiel: meld u aan bij een portal die opslaan nog toestaat en ga dan terug naar de uwe. Als het besturingselement op de toestemmende portal verschijnt en op de vergrendelde verdwijnt, stop dan hier en vraag de wijziging bij de gateway aan. Alles hieronder is veldwerk voor een laboratoriumhuurder of een testprofiel, en niets daarvan gaat boven het besluit van de server. Een profielvernieuwing of client-upgrade schrijft de lokale aanpassing overschreven.

Windows bewaart de vlag in de tunnelsleutel

Opgeslagen tunnels leven onder de huidige gebruiker, één sleutel per verbinding, en de zichtbaarheidsvlag staat naast de verbindingsgegevens:

HKEY_CURRENT_USER\SOFTWARE\Fortinet\FortiClient\Sslvpn\Tunnels<tunnel name>
show_remember_password = 1

Zet de waarde op 1, sluit de client af via het systeemvak in plaats van het venster te sluiten, en open hem opnieuw. In 5.x-builds kon dezelfde vlag onder de Wow6432Node-tak van HKEY_LOCAL_MACHINE staan, dus kijk daar als de sleutel per gebruiker ontbreekt. Sommige 6.x-builds schrijven de waarde na een geslaagde verbinding opnieuw, wat een vakje verklaart dat één aanmelding overleeft en bij de volgende verdwijnt. Heeft uw sleutel helemaal geen zulke waarde, maak die dan aan als tekenreeks in plaats van andere namen te raden.

Behandel het register als een foutopsporingsstap. De levende registerstatus is onzichtbaar voor de volgende beheerder, en geen enkele inventarisvernieuwing bewaart die.

Volg op macOS de client om het bestand te vinden

De macOS-client bewaart instellingen per verbinding onder /Library/Application Support/Fortinet/FortiClient/conf, in een woordenboek per tunnel. De sleutel die u moet instellen is AllowSavePassword, en die moet als 1 worden gelezen terwijl de automatische verbindingssleutels in hetzelfde woordenboek intact blijven. Start de client opnieuw wanneer u klaar bent.

Het exacte bestand raden kost tijd op een onbekende build. Voer opensnoop uit terwijl u de tunnel toevoegt en lees daarna de paden die de client heeft aangeraakt; het bestand dat hij schreef, is degene die de vlag draagt. Bewerk dat bestand met de client gesloten en het werk is klaar. Vijf minuten traceren verslaat elke keer een zoektocht door het hele bestandssysteem.

Geef de voorkeur aan een cyclus van exporteren, aanpassen en herstellen

Nieuwere clients laten u de hele configuratie via een bestand heen en weer halen, wat makkelijker te herhalen en aan een andere machine te geven is dan levende registerchirurgie:

• Exporteer vanuit de clientinstellingen, neem gebruikersinstellingen mee en stel een exportwachtwoord in.
• Open het bestand en zet show_remember_password op 1.
• Ontgrendel het hangslot in de client; Herstellen doet niets zolang het vergrendeld is.
• Herstel het bewerkte bestand en geef het exportwachtwoord op.

Het besturingselement zou bij de volgende aanmelding moeten verschijnen. Houd het geëxporteerde bestand weg van gedeelde mappen en ticketbijlagen, want het beschrijft uw tunnels en kan een versleuteld geheim bevatten.

Als het herstellen werkt maar het vakje zich na het verbinden weer verbergt, legt de gateway bij elke aanmelding het beleid opnieuw op en geen enkel lokaal bestand houdt de instelling lang vast.

Wis het geheim voordat het een accountblokkade wordt

De Linux-client op de opdrachtregel heeft helemaal geen vakje, dus een wrapper die het wachtwoord op stdin doorgeeft is het gebruikelijke antwoord en die bewaart niets. Op elk platform is de betrouwbare verwijdering de verbinding terugzetten op vragen bij het aanmelden of de tunnel helemaal verwijderen.

Opgeslagen inloggegevens overleven de wachtwoordwijziging die ze ongeldig maakt, en de daaruit volgende fouten lijken op een VPN-storing: weigeringen, nieuwe pogingen en dan een accountblokkade. Wis de opgeslagen waarde voordat u een wachtwoord wijzigt, en loop de tunnellijst na op verouderde vermeldingen die er nog een bevatten. Het geheim staat versleuteld in het clientarchief, dus het met de hand aanpassen is zinloos. De tunnel verwijderen is sneller en laat niets achter.

Werk het op volgorde af: bevestig de portalinstelling met de eigenaar van de firewall, bewijs de bron met een toestemmend profiel, houd register- of plist-aanpassingen binnen een laboratorium en weet welk bestand het geheim bevat zodat u het kunt verwijderen. Een ontbrekend vakje op een portal die opslaan toestaat is een eindpuntprobleem, en de clientlogboeken zijn de volgende plek om te kijken.