Rotate a local VPN account without losing its permissions

Replacing a working VPN password looks like a two-line change until the rebuilt account returns with default permissions and the only management session is gone. The safe procedure depends on where the credential is stored and which protocol consumes it, not on which command is shortest. Compare the two approaches before touching the device. In-place rotation preserves the account object; delete-and-recreate replaces it, and everything that pointed at it goes with it.

Find which store actually authenticates the session

Start at the tunnel or connection profile, not at the user database. The profile names an authentication method and often a server group, and if that group points at RADIUS or TACACS+, the local username on the box is decoration. Read the profile's authentication list and the AAA group it references before planning anything. Only when the profile says local does the on-box account matter. Get this wrong and you rotate a credential nobody uses while the real directory entry stays exactly as it was.

The same device usually holds two populations: administrators who log in to it, and VPN users who terminate a tunnel. They can share a store, and they should not be assumed to.

In-place update versus delete and recreate

In-place rotation changes one attribute of an existing object. Privilege level, group membership, authorization attributes and any policy that references the account survive, because nothing was removed. Delete-and-recreate rebuilds the object from a command line, so every field you did not repeat comes back at its default. On a device where per-user attributes carry split-tunnel or address-pool assignments, that difference is the entire risk.

Rebuilding has one legitimate use: when the stored format itself has to change and the platform offers no conversion. Even then, capture the existing entry first, because the running configuration is the only accurate inventory of what the account carried. A copy of that config taken before the change beats a rollback plan written from memory.

Why the hash you have may not be the secret it needs

Storage formats differ in a way that decides the answer. A one-way hash can verify a password when the server receives it in the clear inside the tunnel, but a challenge-response method needs the shared secret itself in order to compute the digest. Converting every account to the strongest one-way format can therefore break CHAP or MS-CHAP for exactly the users who depend on it.

Decide by protocol rather than by slogan. Where the method needs a recoverable secret, that requirement is a constraint on the design and not an oversight to be cleaned up.

Sessions that outlive the credential

Changing a credential does not terminate sessions that already authenticated. A peer with an established tunnel keeps working until rekey, re-authentication or an explicit disconnect.

Plan that part separately, and plan it before the change. If the credential leaked, leaving live sessions running defeats the rotation. If it merely aged out, forcing every peer offline is an outage you did not need. Keep a second administration path open while you work, preferably one that does not depend on the account being edited, because the failure mode here removes your access precisely when you need it. Then verify a fresh sign-in and the resources it can reach.

Prove the permissions survived

Sign in as the rotated user and check what the session grants, not merely that it opened. Reach a resource that requires the authorization the account is supposed to carry, and try one it should not reach. A successful login with narrowed or widened access is a failed change.

Compare the authorization attributes in the running configuration against the copy you took at the start. Look at group membership, address pool, DNS and split-tunnel settings, and any policy object that named the account. Then update the record of where that credential lives, since the next rotation begins from that note. A rotation nobody can repeat from documentation has only been survived once.