Міграція серверної частини автентифікації VPN без повторного використання старих хешів

Імена користувачів з'являються в новому каталозі, міграцію оголошено завершеною, а входи все одно не проходять. Шлюзу досі потрібен підтримуваний шлях автентифікації та коректний результат авторизації, і жодне з цього не випливає з каталогу, який тепер містить облікові записи. Перенесення серверної частини — це перемикання з життєвим циклом, а не копіювання. Симптом нижче — той, що зазвичай і виявляє різницю.

Симптом: облікові записи є, сеансів немає

Новий каталог містить кожне ім'я користувача, тестове зв'язування проходить, а клієнт VPN усе одно повертає помилку автентифікації. Таке поєднання означає, що ідентичність існує, але шлях перевірки, який використовує шлюз, до неї не доходить або доходить методом, який вона не може задовольнити. І те, й інше — конфігурація, і це різні проблеми.

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

Розділити ці два випадки до того, як чіпати облікові записи, економить тиждень. Один — питання маршрутизації та довіри, другий — рішення про скидання облікових даних, а їх змішування породжує зміни, які ніхто не може пояснити.

Складіть карту ланцюга, перш ніж когось переносити

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

Звичайний вхід у каталог не проходить майже нічого з цього ланцюга. Він доводить, що обліковий запис існує і пароль працює, — саме ту частину, у якій ніколи не було сумнівів.

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

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

Різниця в тому, хто обчислює доказ. Метод, який перевіряє через прив'язку до каталогу, дозволяє каталогу перевірити те, що той уміє. Метод, який перевіряє перерахунком відповіді на виклик, потребує самого секрету, бо сервер має виконати те саме обчислення.

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

Пілотна група, потім зміни життєвого циклу

Перенесіть невелику групу схвалених ідентичностей із справжнім клієнтом і перевірте чотири речі: свіжий вхід, навмисно неправильні облікові дані, ресурси, яких сеанс може досягти, і ресурси, яких він не повинен досягати. Перевірте також ідентичність сервера, яку прийняв клієнт, бо невідповідність імені сертифіката непомітна, доки хтось не прочитає журнал клієнта.

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

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

Якщо старий і новий шляхи існують одночасно, обмежте їх датою завершення. Автоматичний відкат може пропустити обліковий запис за старими обліковими даними після того, як новий власник зняв доступ, і це регресія безпеки під виглядом доступності.

Відкат не може відновити облікові дані

Зворотне перевертання перемикання залишає каталог точно таким, яким він є зараз. Скинутий пароль залишається скинутим, відкликаний сертифікат залишається відкликаним, а змінений формат облікових даних залишається зміненим. Це події в каталозі, і шлюз ніколи не був їхнім джерелом. Відновлення треба визначити для кожної події, і ніщо з цього не може залежати від реконструкції секрету з несумісного хешу.

Тримайте адміністративний шлях, який не використовує з'єднання, що мігрує. Коли нова автентифікація не працює, зупиніть групу і використайте її задокументований шлях відновлення, замість того щоб послаблювати автентифікацію для всіх заради дотримання терміну.

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