Миграция на VPN backend за удостоверяване без повторно използване на стари хешове

Потребителските имена се появяват в новия каталог, миграцията е обявена за завършена, а влизанията все още се провалят. Шлюзът все още се нуждае от поддържан път за удостоверяване и правилен резултат от оторизация и нито едно от двете не следва от каталог, който сега съдържа акаунтите. Преместването на backend е преход с жизнен цикъл, а не копиране. Симптомът по-долу е този, който обикновено разкрива разликата.

Симптомът: акаунти има, сесии не

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

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

Разделянето им, преди да се пипнат акаунтите, спестява седмица. Едното е въпрос на маршрутизация и доверие, другото е решение за нулиране на идентификационните данни, а смесването им създава промени, които никой не може да припише.

Картографирайте веригата, преди някой да бъде преместен

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

Обикновеното влизане в каталога не преминава почти нищо от тази верига. То доказва, че акаунтът съществува и паролата работи, което е именно частта, която никога не е била под съмнение.

Хешовете не пътуват между методите

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

Разликата е в това кой изчислява доказателството. Метод, който проверява чрез обвързване с каталога, оставя каталога да провери каквото може. Метод, който проверява чрез преизчисляване на отговор на предизвикателство, се нуждае от самата тайна, защото сървърът трябва да извърши същото изчисление.

Където материалът липсва, честните опции са поддържано нулиране, повторна регистрация, външна услуга за проверка или промяна на метода. Временен износ на възстановими пароли не е в този списък. Той създава хранилище на идентификационни данни в чист текст в най-хаотичната седмица на проекта и обикновено надживява миграцията.

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

Преместете малка група одобрени идентичности с истинския клиент и изпробвайте четири неща: свежо влизане, умишлено грешни идентификационни данни, ресурсите, които сесията може да достигне, и ресурсите, които не може. Проверете и идентичността на сървъра, която клиентът е приел, защото несъответствие в името на сертификата е невидимо, докато някой не прочете клиентския дневник.

След това изпробвайте промените, от които внедряването действително зависи. Сменете парола, подновете или регистрирайте отново сертификат и отнемете достъпа на един пилотен акаунт. След всяка от тях потвърдете кой верификатор е обработил опита, защото сесия, създадена преди прехода, може да продължи да работи и не доказва нищо за следващото влизане.

Отделете доставката на профила от превключването на идентичността. Всяка група се нуждае от предвидения си профил, състоянието си на идентификационни данни или регистрация, услугата за удостоверяване, която трябва да използва, и контакт за поддръжка, а нито един от тези записи не трябва да съдържа тайна.

Ако старият и новият път съществуват паралелно, ограничете ги с крайна дата. Автоматичен fallback може да пропусне акаунт през стари идентификационни данни, след като новият собственик е премахнал достъпа, а това е регресия в сигурността, представена като наличност.

Връщането назад не може да възстанови идентификационни данни

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

Пазете административен път, който не използва връзката, която се мигрира. Когато новото удостоверяване се провали, спрете групата и използвайте документирания ѝ път за възстановяване, вместо да отслабите удостоверяването за всички, за да спазите срок.

След като групите са покрити, изведете старите backend идентификационни данни, профили и отношения на доверие чрез техните собственици. Потвърдете, че старият път вече не допуска потребители, и запазете преобразуването на идентичност в политика без тайни, което поддръжката все още има нужда. Миграцията е завършена, когато новият жизнен цикъл работи и никой не влиза повече по стария път, а не когато списъкът с акаунти изглежда пълен.