Зошто уредувањето на .ovpn датотека не може да вклучи MFA на серверот

Додавате auth-user-pass на профил, повторно се поврзувате, и клиентот бара корисничко име и лозинка. Изгледа како MFA да е вклучен. Потоа внесувате код од погрешна сметка, или код што истекол пред десет минути, а тунелот сепак се крева. Тоа е симптомот: клиентот се смени, серверот не. Еднократната лозинка е фактор само кога проверувачот на серверот одлучува дали е валидна за идентитетот што ја бара.

Барањето докажува само дека клиентот прашал, ништо повеќе

.ovpn датотека е документ на страната на клиентот. Таа може да му каже на клиентот да побара акредитиви, да ги кешира или да престане да го прави тоа. Не може да регистрира корисник, да инсталира PAM модул или да го натера серверот да бара втор фактор што во моментов не го проверува.

Инсталирањето на автентикациска апликација на телефон исто така не ја создава таа врска. Проектот Google Authenticator PAM е компонента за проверка на OTP што може да стои зад OpenVPN; тоа не е начин да се залепи најавувањето на Google сметка на увезен профил.

Регистрацијата е делот што профилот не може да го направи

TOTP бара регистрациски материјал споделен меѓу автентикациската апликација и нејзиниот проверувач. Шесте цифри на телефонот се излез; семето зад нив е тајната, и тоа припаѓа на еден идентитет.

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

Дизајнот заснован на PAM не мора да создава посебна Unix сметка за секој VPN корисник. Документацијата на модулот поддржува алтернативни патеки за тајни и посветена сметка за пристап до датотеки, што е идентитет на датотечниот систем, а не идентитетот за најава што се проверува.

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

Прочитајте го PAM стекот за да видите што навистина се бара

Ред како account required pam_permit.so не ја спроведува подобноста на сметката и не додава фактор. Тој го дозволува тој степен на управување со сметки во PAM, што е изјава за степен, а не за вашите корисници.

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

Усогласете ја интеракцијата на клиентот со дизајнот на серверот

auth-user-pass

Оваа директива бара внесување корисничко име и лозинка. Таа не конфигурира PAM, не создава регистрациски запис и не му кажува на серверот дека полето за лозинка содржи TOTP вредност. Интеграцијата на серверот и клиентот мора да се договорат за интеракција што распоредувањето навистина ја поддржува: предизвик, документиран комбиниран формат на акредитиви или тек специфичен за производот.

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

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

Повторни поврзувања, токени и тестот што го решава прашањето

Планирајте што се случува по првото успешно најавување. Претходно прифатен код може да биде истечен или одбиен како повторување при следната автентикација. auth-nocache го контролира задржувањето на акредитивите и не инсталира MFA, а reneg-sec 0 не е дефиниција за поддршка на TOTP, колку и често да се појавува во форумски теми.

Некои распоредувања издаваат токени за автентикација по првичната проверка за повторните поврзувања да не прашуваат повторно. Тоа е дизајнерска одлука со сопствен прозорец на важност и сопствена историја на отповикување, а не стандардна вредност што ја наследувате.

Потоа тестирајте ја политиката за прием со клиентот што луѓето навистина го користат. Регистриран корисник со точната лозинка, сертификат и тековен код треба да се поврзе. Погрешен код, корисник без регистрација и забранета сметка треба секој да не успее, и причината треба да биде видлива во дневникот на серверот. Додека сѐ уште не ги видите тие одбивања, имате барање, не политика.