Nawawala ang kahon na I-save ang Password sa FortiClient? Ang gateway ang magpapasya
Ang gateway ang nagpapasya kung makakapag-imbak ng password ang FortiClient. Suriin ang setting ng portal, at mas mainam na mag-export at mag-restore kaysa mag-edit ng registry.
Tinatapos mo ang pag-install ng FortiClient, kumokonekta sa SSL VPN ng opisina at naghahanap ng kontrol para i-save ang password na talagang wala. Hindi ito ibinabalik ng muling pag-install ng client, at hindi rin nakakatulong ang pagbura ng tunnel at muling pagdagdag nito. Sa isang SSL VPN profile, ang firewall ang nagpapasya kung papayagan ang client na mag-imbak ng mga kredensyal. Kaya ang nawawalang kahon ay karaniwang ibig sabihin na may patakarang dumating mula sa gateway, hindi na nabigo ang installer.
Mahalaga ang pagkakaibang iyon bago ka magsimulang mag-edit ng mga file: ang isa sa mga landas na ito ay pakikipag-usap sa may-ari ng firewall, at ang isa ay gawaing laboratoryo na mapapatungan.
Suriin ang portal bago hawakan ang endpoint
Hilingin sa nagpapatakbo ng FortiGate na buksan ang SSL VPN portal na tinutukoy ng iyong tunnel at basahin ang setting nito sa pag-save ng password. Kapag naka-disable ang opsyon, inaasahang itatago ng FortiClient ang kontrol at tatangging i-imbak ang kredensyal. Sinusunod ng endpoint ang patakaran, hindi ito sira.
Isang mabilis na pagsubok ang naghihiwalay ng patakaran sa sirang profile: mag-sign in sa portal na pinapayagan pa ang pag-save, pagkatapos ay bumalik sa iyo. Kung lumilitaw ang kontrol sa portal na nagpapahintulot at nawawala sa naka-lock, huminto dito at hilingin ang pagbabago sa gateway. Lahat ng nasa ibaba ay gawaing field para sa laboratoriong umuupa o test profile, at wala sa mga ito ang nakakalamang sa desisyon ng server. Ang pag-refresh ng profile o pag-upgrade ng client ay mapapatungan ang lokal na edit.
Iniimbak ng Windows ang bandila sa loob ng key ng tunnel
Ang mga naka-save na tunnel ay nabubuhay sa ilalim ng kasalukuyang user, isang key bawat koneksyon, at ang bandila ng visibility ay nasa tabi ng mga detalye ng koneksyon:
HKEY_CURRENT_USER\SOFTWARE\Fortinet\FortiClient\Sslvpn\Tunnels<tunnel name> show_remember_password = 1
Itakda ang halaga sa 1, lumabas sa client mula sa tray sa halip na isara ang window nito, at buksan itong muli. Sa mga build na 5.x, ang parehong bandila ay maaaring nasa ilalim ng sangay na Wow6432Node ng HKEY_LOCAL_MACHINE, kaya tingnan doon kapag wala ang key bawat user. Ang ilang build na 6.x ay muling nagsusulat ng halaga pagkatapos ng matagumpay na koneksyon, na nagpapaliwanag ng kahon na tumatagal ng isang login at nawawala sa susunod. Kung wala talagang ganoong halaga ang iyong key, gawin ito bilang string sa halip na hulaan ang ibang pangalan.
Ituring ang registry bilang hakbang sa pag-debug. Ang buhay na estado ng registry ay hindi nakikita ng susunod na administrator, at walang pag-refresh ng imbentaryo ang makapagpapanatili nito.
Sa macOS, subaybayan ang client para mahanap ang file nito
Ang macOS client ay nag-iimbak ng mga setting bawat koneksyon sa ilalim ng /Library/Application Support/Fortinet/FortiClient/conf, sa isang diksyunaryo para sa bawat tunnel. Ang key na itatakda ay AllowSavePassword, at kailangan nitong basahin bilang 1 habang buo ang mga key ng auto-connect sa parehong diksyunaryo. I-restart ang client kapag tapos ka na.
Ang paghula sa eksaktong file ay sayang sa oras sa isang build na hindi pamilyar. Patakbuhin ang opensnoop habang idinadagdag mo ang tunnel, pagkatapos ay basahin ang mga path na hinawakan ng client; ang file na isinulat nito ang siyang may bandila. I-edit ang file na iyon habang sarado ang client at tapos na ang trabaho. Ang limang minutong pagsubaybay ay nananalo sa paghahanap sa buong filesystem sa bawat pagkakataon.
Mas mainam ang siklo ng pag-export, pag-edit at pag-restore
Pinapayagan ka ng mas bagong client na dalhin ang buong configuration sa isang file pabalik-balik, na mas madaling ulitin at ibigay sa ibang makina kaysa sa live na operasyon sa registry:
- Mag-export mula sa mga setting ng client, isama ang mga setting ng user, at magtakda ng password sa pag-export.
- Buksan ang file at itakda ang show_remember_password sa 1.
- I-unlock ang kandado sa client; Walang ginagawa ang I-restore habang naka-lock ito.
- I-restore ang na-edit na file at ibigay ang password sa pag-export.
Dapat lumitaw ang kontrol sa susunod na pag-sign in. Ilayo ang na-export na file mula sa mga shared folder at attachment ng ticket, dahil inilalarawan nito ang iyong mga tunnel at maaaring magdala ng naka-encrypt na sikreto.
Kung gumagana ang pag-restore pero nagtatago muli ang kahon pagkatapos kumonekta, ipinapatupad muli ng gateway ang patakaran sa bawat login at walang lokal na file ang makakapagpanatili ng setting nang matagal.
Burahin ang sikreto bago ito maging lock ng account
Ang Linux command-line client ay walang kahon, kaya ang wrapper na nagbabahagi ng password sa stdin ang karaniwang sagot at wala itong iniimbak. Sa anumang platform, ang maaasahang pagtanggal ay ibalik ang koneksyon sa pagtatanong sa login o burahin nang tuluyan ang tunnel.
Ang naka-save na kredensyal ay nabubuhay nang mas matagal kaysa sa pagbabago ng password na nagpapawalang-bisa nito, at ang mga sumunod na pagkabigo ay mukhang pagkaantala ng VPN: mga pagtanggi, muling pagtatangka, pagkatapos ay lock ng account. Burahin ang naka-save na halaga bago mo palitan ang password, at tingnan ang listahan ng tunnel para sa mga lumang entry na may dalang isa pa. Naka-encrypt ang sikreto sa imbakan ng client, kaya walang saysay ang manu-manong pag-edit. Ang pagbura ng tunnel ay mas mabilis at walang naiiwan.
Sundin ito sa pagkakasunod-sunod: kumpirmahin ang setting ng portal sa may-ari ng firewall, patunayan ang pinagmulan gamit ang mapagbigay na profile, itago ang mga edit sa registry o plist sa loob ng laboratoryo, at alamin kung aling file ang may sikreto para maalis mo ito. Ang nawawalang kahon sa portal na pinapayagan ang pag-save ay problema ng endpoint, at ang mga log ng client ang susunod na dapat tingnan.