Міграцыя сервернай часткі аўтэнтыфікацыі VPN без паўторнага выкарыстання старых хэшаў

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

Сімптом: уліковыя запісы ёсць, сеансаў няма

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

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

Аддзяліць гэтыя два выпадкі да таго, як чапаць уліковыя запісы, эканоміць тыдзень. Адзін — пытанне маршрутызацыі і даверу, другі — рашэнне пра скід уліковых даных, а іх змешванне спараджае змены, якія ніхто не можа патлумачыць.

Складзіце карту ланцуга, перш чым кагосьці пераносіць

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

Звычайны ўваход у каталог не праходзіць амаль нічога з гэтага ланцуга. Ён даказвае, што ўліковы запіс існуе і пароль працуе, — менавіта тую частку, у якой ніколі не было сумневаў.

Хэшы не пераносяцца паміж метадамі

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

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

Там, дзе матэрыялу няма, сумленныя варыянты — скід, які падтрымліваецца, паўторная рэгістрацыя, знешні сэрвіс праверкі або змена метаду. Часовы экспарт аднаўляльных пароляў у гэты спіс не ўваходзіць. Ён стварае сховішча ўліковых даных у адкрытым выглядзе ў самы хаатычны тыдзень праекта і звычайна перажывае міграцыю.

Пілотная група, потым змены жыццёвага цыкла

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

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

Аддзяліце дастаўку профілю ад пераключэння ідэнтычнасці. Кожнай групе патрэбны яе прызначаны профіль, стан уліковых даных або рэгістрацыі, сэрвіс аўтэнтыфікацыі, якім яна павінна карыстацца, і кантакт падтрымкі, і ні адзін з гэтых запісаў не павінен змяшчаць сакрэт.

Калі стары і новы шляхі існуюць адначасова, абмяжуйце іх датай завяршэння. Аўтаматычны адкат можа прапусціць уліковы запіс па старых уліковых даных пасля таго, як новы ўласнік зняў доступ, і гэта рэгрэсія бяспекі пад выглядам даступнасці.

Адкат не можа аднавіць уліковыя даныя

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

Трымайце адміністрацыйны шлях, які не выкарыстоўвае злучэнне, што мігруе. Калі новая аўтэнтыфікацыя не працуе, спыніце групу і выкарыстайце яе задокументаваны шлях аднаўлення, замест таго каб паслабляць аўтэнтыфікацыю для ўсіх дзеля выканання тэрміну.

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