Миграция серверной части аутентификации VPN без повторного использования старых хешей

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

Симптом: учётные записи есть, сеансов нет

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

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

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

Составьте карту цепочки, прежде чем кого-то переносить

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

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

Хеши не переносятся между методами

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

Разница в том, кто вычисляет доказательство. Метод, который проверяет через привязку к каталогу, позволяет каталогу проверить то, что тот умеет. Метод, который проверяет пересчётом ответа на вызов, требует самого секрета, потому что сервер должен выполнить то же вычисление.

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

Пилотная группа, затем изменения жизненного цикла

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

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

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

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

Откат не может восстановить учётные данные

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

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

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