轮换本地 VPN 账号而不丢失其权限

替换一个仍在使用的 VPN 密码看起来只是改两行，直到重建后的账号带着默认权限回来，而唯一的管理会话已经消失。安全的做法取决于凭据存放在哪里、由哪个协议使用，而不取决于哪条命令最短。动手前先比较两种做法：就地轮换保留账号对象；删除重建则会替换它，所有指向它的东西都会一并丢失。

找出真正负责认证会话的存储

从隧道或连接配置文件开始，而不是从用户数据库开始。配置文件会指明认证方式，往往还指定服务器组；如果该组指向 RADIUS 或 TACACS+，设备上的本地用户名就只是装饰。制定任何方案之前，先读配置文件的认证列表以及它引用的 AAA 组。只有配置文件写明使用本地认证时，设备上的账号才重要。这里弄错，你就会轮换一个没人使用的凭据，而真正的目录条目仍原封不动。

同一台设备通常承载两类人群：登录其上的管理员，以及终止隧道的 VPN 用户。他们可能共用同一存储，但不能想当然地认为一定共用。

就地更新与删除重建的对比

就地轮换只改动现有对象的一个属性。权限级别、组成员关系、授权属性以及任何引用该账号的策略都会保留，因为没有删除任何东西。删除重建则从命令行重新构建该对象，所以你没有重复填写的每个字段都会回到默认值。在那些按用户属性承载分离隧道或地址池分配的设备上，这一差别就是全部风险。

重建只有一个正当用途：当存储格式本身必须改变，而平台又不提供转换时。即便如此，也要先记录现有条目，因为运行中的配置是账号曾经携带什么内容的唯一准确清单。变更前留存的那份配置副本，胜过凭记忆写出的回滚方案。

为什么你手上的哈希可能不是它需要的那个秘密

存储格式的差异决定了答案。单向哈希可以在服务器于隧道内收到明文口令时完成校验，但质询-响应方式需要共享密钥本身来计算摘要。因此，把所有账号都转成最强的单向格式，可能恰恰会打断依赖它的用户的 CHAP 或 MS-CHAP。

按协议决定，而不是按口号决定。方法需要可恢复密钥的地方，这一要求是设计约束，而不是需要清理的疏忽。

比凭据活得更久的会话

更改凭据不会终止已经完成认证的会话。已建立隧道的对端会一直工作到密钥更新、重新认证或显式断开。

把这部分单独规划，并在变更前规划好。如果凭据已经泄露，放任活动会话继续运行会让轮换失效。如果只是过期，强制所有对端下线就是一次本不必要的停机。工作时保留第二条管理路径，最好是不依赖正在编辑的账号的那条，因为这里的故障模式恰恰会在你最需要访问时把它拿走。随后验证一次全新登录及其可访问的资源。

证明权限确实保留了

以轮换后的用户登录，检查会话授予了什么，而不仅仅是它能打开。访问一个需要账号本应携带的授权的资源，再尝试一个它不应访问的资源。登录成功但权限被收窄或放宽，就是一次失败变更。

把运行配置中的授权属性与开始时留存的副本作比较。查看组成员关系、地址池、DNS 与分离隧道设置，以及任何点名该账号的策略对象。然后更新该凭据存放位置的记录，因为下一次轮换从这条记录开始。无人能照文档复现的轮换，只算侥幸过关一次。