Reconnect a Windows VPN without putting the password in the task

Every unattended reconnect recipe eventually meets the same question: where does the password live. The popular answer is the task action itself, which is also the worst place for it. Two other designs exist. Which one fits depends on whether the machine can authenticate without a person and whether the server accepts certificates.

What a task action leaves readable

Arguments in a scheduled task are part of its definition, not a hidden runtime value. Anyone who can read the task, restore a backup of it, or export its XML sees the string exactly as you typed it. During a run the same string appears in the process list. A monitoring agent may copy it into a log you never review.

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

Check before you assume otherwise. The first command prints the full definition, including the action and its arguments. The second shows which credentials the current account has cached, which matters for the alternative designs below. If the password appears in the task XML, rotating it is only half the repair, because the task still holds the old value.

What a stored pre-shared key really buys

Add-VpnConnection -L2tpPsk writes the key into the connection's phonebook entry rather than into a task. That is a smaller exposure surface than a task action. It is still a recoverable secret, because an administrator on the machine can read the phonebook.

For a lab link between two machines you control, that trade may be acceptable. For a user credential on a shared endpoint it is not. Calling it encrypted storage does not change who can read it. The phonebook is a configuration file. Plan for the person who can open it, not only for the person who can log in as the user.

Winlogon credentials remove the secret and add a dependency

-UseWinlogonCredential takes a different route. The connection authenticates with MSCHAPv2 against the credentials of the logged-on user. Nothing extra is stored for that account.

The dependency it adds is significant. There must be an interactive logon to borrow from, which rules out a service account and a pre-logon task. The connection also inherits whatever that user's credentials can reach on the server. Read the switch as a statement about where the credential comes from, not as a security setting. It changes the source, and nothing about how the server authorizes the session afterwards.

Certificate authentication scales because nothing is stored

Where the server supports EAP-TLS, a machine certificate removes the shared secret entirely, and revocation happens at the certificate layer. A task running as SYSTEM can present that certificate without an interactive logon. Confirm that the server accepts certificate authentication before building around it. A design that depends on an unsupported method is a plan rather than a solution. Then decide where the private key lives: the machine store for a device identity, the user store for a person.

Where a username and password cannot be avoided, store them in Credential Manager scoped to the task's own account. Let the client read them from there instead of from an argument. A secret the task can retrieve without printing it is a smaller problem than one written into its definition.

Review the artifacts before the next rotation

Look at what is stored rather than at what you intended. Check the per-user phonebook, the all-user copy, the task XML and any script that calls the dial command. Then confirm the certificate or cached credential is scoped to the account the task uses, because a credential stored for your interactive account is invisible to SYSTEM.

Record the authentication method and the account in the task's own notes. The next person to change the server's policy needs to know which design is in play. That answer is not visible from the reconnect behaviour alone. Write it where the next rotation will look first.