Смените локальную учётную запись VPN, не потеряв её права

Замена работающего пароля VPN выглядит как изменение в две строки, пока пересобранная учётная запись не вернётся с правами по умолчанию и единственная сессия управления не исчезнет. Безопасная процедура зависит от того, где хранятся учётные данные и какой протокол их использует, а не от того, какая команда короче. Сравните оба подхода, прежде чем трогать устройство. Ротация на месте сохраняет объект учётной записи; удаление и повторное создание заменяет его, и всё, что на него указывало, уходит вместе с ним.

Определите, какое хранилище действительно аутентифицирует сессию

Начните с профиля туннеля или подключения, а не с базы данных пользователей. Профиль называет метод аутентификации и часто группу серверов, и если эта группа указывает на RADIUS или TACACS+, локальное имя пользователя на устройстве — просто украшение. Прочитайте список аутентификации профиля и группу AAA, на которую он ссылается, прежде чем что-либо планировать. Только когда профиль говорит «локально», учётная запись на устройстве имеет значение. Ошибётесь — и вы смените учётные данные, которыми никто не пользуется, а настоящая запись в каталоге останется точно такой, какой была.

Одно и то же устройство обычно держит две популяции: администраторов, которые входят в него, и пользователей VPN, которые завершают туннель. Они могут делить хранилище, и не следует предполагать, что так и есть.

Обновление на месте против удаления и повторного создания

Ротация на месте меняет один атрибут существующего объекта. Уровень привилегий, членство в группах, атрибуты авторизации и любая политика, которая ссылается на учётную запись, сохраняются, потому что ничего не было удалено. Удаление и повторное создание пересобирают объект из командной строки, поэтому каждое поле, которое вы не повторили, возвращается к значению по умолчанию. На устройстве, где атрибуты для каждого пользователя несут назначения раздельного туннеля или пула адресов, эта разница и есть весь риск.

У пересборки есть одно законное применение: когда нужно изменить сам хранимый формат, а платформа не предлагает преобразования. Даже тогда сначала зафиксируйте существующую запись, потому что работающая конфигурация — единственная точная опись того, что несла учётная запись. Копия этой конфигурации, снятая до изменения, лучше плана отката, написанного по памяти.

Почему имеющийся у вас хеш может быть не тем секретом, который нужен

Форматы хранения различаются так, что это решает ответ. Односторонний хеш может проверить пароль, когда сервер получает его в открытом виде внутри туннеля, но методу запрос-ответ нужен сам общий секрет, чтобы вычислить дайджест. Поэтому перевод каждой учётной записи в самый стойкий односторонний формат может сломать CHAP или MS-CHAP именно тем пользователям, которые от него зависят.

Решайте по протоколу, а не по лозунгу. Там, где метод требует восстановимого секрета, это требование является ограничением проекта, а не недосмотром, который надо вычистить.

Сессии, которые переживают учётные данные

Смена учётных данных не завершает сессии, которые уже аутентифицировались. Партнёр с установленным туннелем продолжает работать до обновления ключа, повторной аутентификации или явного отключения.

Планируйте эту часть отдельно и планируйте её до изменения. Если учётные данные утекли, оставленные живыми сессии сводят ротацию на нет. Если они просто устарели, принудительное отключение каждого партнёра — это простой, которого вам не нужно. Держите открытым второй путь администрирования, пока работаете, желательно такой, который не зависит от редактируемой учётной записи, потому что здешний режим отказа отнимает доступ именно тогда, когда он нужен. Затем проверьте новый вход и ресурсы, до которых он может добраться.

Докажите, что права сохранились

Войдите как сменённый пользователь и проверьте, что даёт сессия, а не только что она открылась. Доберитесь до ресурса, который требует авторизации, полагающейся учётной записи, и попробуйте тот, до которого она добираться не должна. Успешный вход с суженным или расширенным доступом — это неудачная смена.

Сравните атрибуты авторизации в работающей конфигурации с копией, снятой в начале. Посмотрите на членство в группах, пул адресов, параметры DNS и раздельного туннеля, а также на любой объект политики, который называл учётную запись. Затем обновите запись о том, где живут эти учётные данные, потому что следующая ротация начинается с этой заметки. Ротация, которую никто не может повторить по документации, была пережита только один раз.