Зашто уређивање .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 подршке, колико год се често појављивао у форумским темама.

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

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