Миграција на VPN-автентикациски backend без повторна употреба на стари хешеви

Корисничките имиња се појавуваат во новиот директориум, миграцијата е прогласена за завршена, а најавите сѐ уште не успеваат. Гејтвејот сѐ уште бара поддржан пат за автентикација и точен резултат од авторизација, и ниту едно од двете не произлегува од директориум што сега ги содржи сметките. Преместувањето на backend е пресек со животен циклус, не копирање. Симптомот подолу е оној што обично ја открива разликата.

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

Новиот директориум го содржи секое корисничко име, пробното поврзување успева, а VPN-клиентот сѐ уште враќа грешка при автентикација. Таквата комбинација значи дека идентитетот постои, но патот за верификација што го користи гејтвејот не стигнува до него, или стигнува со метод што не може да го задоволи. Двете се конфигурација и тоа се различни проблеми.

Првиот е ожичување: гејтвејот покажува на backend што не одговара, користи заедничка тајна што другата страна не ја очекува, или бара атрибут што новата услуга не го враќа. Вториот е криптографски: методот бара изворната тајна, а новото складиште држи само нејзин хеш. Текстот на грешката изгледа слично во двата случаи, затоа двете се третираат како еден проблем.

Раздвојувањето на двете пред да се допрат сметките штеди една недела. Едното е прашање на рутирање и доверба, другото е одлука за ресетирање на акредитивите, а нивното мешање создава промени што никој не може да ги припише.

Мапирајте го синџирот пред некој да се премести

За секој профил на клиент запишете шест работи: надворешниот метод за автентикација, евентуален внатрешен метод, идентитетот на серверот што клиентот го очекува, интерфејсот помеѓу гејтвејот и backend, атрибутот што гејтвејот го мапира на членство во група и резултирачката политика за ресурси. Читањето по ред покажува која алка нема сопственик. Секоја ставка има сопственик, а пресекот паѓа на онаа што никој не ја проверил.

Обичната најава во директориум не поминува речиси ништо од тој синџир. Докажува дека сметката постои и дека лозинката работи, што е токму делот што никогаш не бил под прашање.

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

Компатибилноста на акредитивите мора да се провери еднаш, пред да се премести која било група. FreeRADIUS јасно ја опишува поделбата: проверката CHAP што ја изведува самиот сервер бара вистинската лозинка, а MS-CHAP ја прифаќа таа лозинка или соодветен NT-материјал. Хеш направен за друга намена не одговара на ниту еден случај, колку и да е силен.

Разликата е во тоа кој го пресметува доказот. Метод што верифицира со поврзување со директориумот му дозволува на директориумот да провери што може да провери. Метод што верифицира со пресметување на одговорот на предизвикот повторно ја бара самата тајна, бидејќи серверот мора да ја изведе истата пресметка.

Каде што материјалот недостига, чесните можности се поддржан ресет, повторна регистрација, надворешна услуга за верификација или промена на метод. Привремен извоз на обновливи лозинки не е на тој список. Создава складиште на акредитиви во чист текст во најхаотичната недела од проектот и обично ја надживува миграцијата.

Пилот-група, потоа промени во животниот циклус

Преместете мала група одобрени идентитети со вистинскиот клиент и испробајте четири работи: свежа најава, намерно погрешен акредитив, ресурсите што сесијата смее да ги достигне и ресурсите што не смее. Проверете го и идентитетот на серверот што клиентот го прифатил, бидејќи несовпаѓањето на името на сертификатот е невидливо додека некој не го прочита дневникот на клиентот.

Потоа испробајте ги промените од кои распоредувањето навистина зависи. Променете лозинка, обновете или повторно регистрирајте сертификат и отстранете пристап од една пилот-сметка. По секоја потврдете кој верификатор го обработил обидот, бидејќи сесија создадена пред пресекот може да продолжи да работи и ништо не докажува за следната најава.

Одвојте ја испораката на профилот од префрлувањето на идентитетот. Секоја група треба свој предвиден профил, својата состојба на акредитиви или регистрација, услугата за автентикација што треба да ја користи и контакт за поддршка, а ниту еден од тие записи не смее да содржи тајна.

Ако стариот и новиот пат постојат паралелно, ограничете ги со краен датум. Автоматски fallback може да пушти сметка преку стар акредитив откако новиот сопственик го отстранил пристапот, а тоа е безбедносна регресија претставена како достапност.

Враќањето назад не може да обнови акредитив

Вртењето на пресекот го остава директориумот точно во состојбата во која е сега. Ресетирана лозинка останува ресетирана, отповикан сертификат останува отповикан, а променет формат на акредитиви останува променет. Тоа се настани во директориумот и гејтвејот никогаш не бил нивни извор. Обновата мора да се дефинира по настан и ништо од тоа не смее да зависи од реконструкција на тајна од некомпатибилен хеш.

Задржете административен пат што не ја користи врската што се мигрира. Кога новата автентикација не успее, паузирајте ја групата и користете го нејзиниот документиран пат за обнова, наместо да ја ослабите автентикацијата за сите за да стигнете рок.

Откако групите се покриени, повлечете ги старите акредитиви на backend, профилите и односите на доверба преку нивните сопственици. Потврдете дека стариот пат повеќе не пушта корисници и задржете го мапирањето на идентитетот во политика без тајни што поддршката сѐ уште го бара. Миграцијата е завршена кога новиот животен циклус работи и никој повеќе не влегува по стариот пат, а не кога списокот на сметки изгледа целосен.