FortiClient Save Password Box Missing? The Gateway Decides

You finish the FortiClient install, connect to the office SSL VPN, and look for a Save Password control that simply is not there. Reinstalling the client does not bring it back, and neither does deleting the tunnel and adding it again. On an SSL VPN profile the firewall decides whether the client may persist credentials at all. A missing checkbox therefore usually means a policy arrived from the gateway, not that the installer failed.

That distinction matters before you start editing files: one of these paths is a conversation with the firewall owner, and the other is lab work that will be overwritten.

Check the portal before you touch the endpoint

Ask whoever runs the FortiGate to open the SSL VPN portal your tunnel points at and read its save-password setting. When the option is disabled, FortiClient is expected to hide the control and refuse to store the credential. The endpoint is obeying the rule rather than malfunctioning.

One quick test separates policy from a broken profile: sign in to a portal that still permits saving, then return to yours. If the control appears on the permissive portal and vanishes on the locked-down one, stop here and ask for the gateway change. Everything below is field work for a lab tenant or a test profile, and none of it outranks the server decision. A profile refresh or a client upgrade will rewrite the local edit.

Windows keeps the flag inside the tunnel key

Saved tunnels live under the current user, one key per connection, and the visibility flag sits beside the connection details:

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

Set the value to 1, quit the client from the tray instead of closing its window, and reopen it. On 5.x builds the same flag could sit under the Wow6432Node branch of HKEY_LOCAL_MACHINE, so look there when the per-user key is absent. Some 6.x builds rewrite the value after a successful connection, which explains a checkbox that survives one login and disappears on the next. If your key has no such value at all, create it as a string instead of guessing at other names.

Treat the registry as a debug step. Live registry state is invisible to the next administrator, and no inventory refresh will preserve it.

On macOS, trace the client to find its file

The macOS client keeps per-connection settings under /Library/Application Support/Fortinet/FortiClient/conf, in a dictionary for each tunnel. The key to set is AllowSavePassword, and it needs to read 1 while the auto-connect keys in that same dictionary stay intact. Restart the client when you are done.

Guessing the exact file wastes time on an unfamiliar build. Run opensnoop while you add the tunnel, then read the paths the client touched; the file it wrote is the one carrying the flag. Edit that file with the client closed and the job is finished. Five minutes of tracing beats a filesystem-wide search every time.

Prefer an export, edit and restore cycle

Newer clients let you round-trip the whole configuration through a file, which is easier to repeat and to hand to another machine than live registry surgery:

• Export from the client settings, include user settings, and set an export password.
• Open the file and set show_remember_password to 1.
• Unlock the padlock in the client; Restore does nothing while it is locked.
• Restore the edited file and supply the export password.

The control should appear on the next sign-in. Keep the exported file away from shared folders and ticket attachments, because it describes your tunnels and may carry an encrypted secret.

If the restore works but the box hides again after connecting, the gateway is reasserting policy at every login and no local file will hold the setting for long.

Clear the secret before it turns into a lockout

The Linux command-line client has no checkbox at all, so a wrapper that feeds the password on stdin is the usual answer and it stores nothing. On any platform the reliable removal is switching the connection back to prompting at login, or deleting the tunnel outright.

A saved credential outlives the password change that invalidates it, and the resulting failures look like a VPN outage: rejects, retries, then an account lockout. Clear the stored value before you rotate a password, and look through the tunnel list for stale entries that still carry one. The secret sits encrypted in the client store, so editing it by hand is pointless. Deleting the tunnel is faster and leaves nothing behind.

Work through it in order: confirm the portal setting with the firewall owner, prove the source with a permissive profile, keep registry or plist edits inside a lab, and know which file holds the secret so you can remove it. A checkbox missing on a portal that permits saving is an endpoint problem, and the client logs are the next place to look.