OpenVPN username-as-common-name: kial via CN-kontrolo estas malplena

Vi aldonas skripton client-connect, kiu rifuzas ĉiun konekton, kie common_name malsamas de username, kaj tio aspektas kiel ligo inter atestilo kaj konto. Sur servilo, kie funkcias username-as-common-name, tiu komparo jam perdis sian sencon antaŭ la momento, kiam la skripto funkcias. Ambaŭ valoroj estas la sama signoĉeno, do la testo sukcesas por atestilo eldonita al tute alia persono.

La kontrolo ne estas malĝusta ĉar la skripto estas malbone verkita. Ĝi estas malĝusta ĉar la valoro, kiun ĝi legas, estis anstataŭigita pli frue en la sama konekto.

Kion la komparo ŝajne pruvas

Atestila aŭtentikigo kaj pasvorta aŭtentikigo estas apartaj pruvoj, kaj servilo povas postuli ambaŭ, ne postulante, ke ili apartenas al la sama persono. La breĉo estas reala: valida atestilo de aparato plus iu ajn valida konto estas alia aserto ol tiu atestilo plus unu nomita konto. Skripto, kiu komparas common_name kun username, legiĝas kiel la mankanta ligilo inter la du. Kaj ĝi estus, se common_name ankoraŭ signifus tion, kion diris la atestilo.

Ĉu tiel estas, dependas de unu servila opcio, kaj tiu opcio kutime estas ŝaltita pro nerilata kialo, ekzemple por plifaciligi nomi konfigurajn dosierojn por ĉiu uzanto.

Kion username-as-common-name faras al la nomo

Kiam username-as-common-name estas ŝaltita, OpenVPN anstataŭigas la komunan nomon de la atestilo per la aŭtentikigita uzantnomo post kiam la uzantnomo kaj pasvorto estas kontrolitaj. La kontrola hoko, kiu funkcias dum tiu kontrolo, ankoraŭ ricevas la komunan nomon de la atestilo, ĉar la anstataŭigo ankoraŭ ne okazis. Ĉio poste, inkluzive de client-connect, vidas la uzantnomon. Do la posta vokado ricevas unu identecon dufoje kaj ne povas kompari ĝin kun la prezentita atestilo.

Sekvu unu ilustran konekton: atestilo eldonita por bob-device, sukcesa dosieruja ensaluto kiel alice kaj la opcio ŝaltita. La kontrola fazo ankoraŭ povas vidi du malsamajn signoĉenojn. La konekta fazo vidas alice kaj alice.

Tiu ekzemplo montras, kial la komparo estas malplena. Ĝi ne montras, ke la konekto alie estus akceptita, ĉar atestila validigo kaj pasvorta kontrolado ankoraŭ funkcias memstare.

Metu la ligon tie, kie ambaŭ identecoj ankoraŭ ekzistas

La regulo devas esti plenumata en fazo, kiu vidas la atestilan identecon kaj la konton samtempe, kio praktike signifas la kontrolan hokon por uzantnomo kaj pasvorto aŭ kromaĵon ŝarĝitan tie. Subtenata kromaĵo, kiu jam faras pasvortan kontroladon, kutime estas la ĝusta loko por aldoni parigregulon, ĉar anstataŭigi ĝin per nomkomparo tute forigus la pasvortan kontrolon.

Difinu la mapadon antaŭ ol verki kodon, ĉar egaleco malofte estas la reala politiko. Atestilo ofte identigas aparaton, dum la ensaluto identigas personon, kaj unu aparato povas laŭleĝe servi plurajn personojn. Konservu la rilaton en formo, kies eldonadon vi kontrolas, kaj decidi, kio okazas ĉe renomado, ĉe reeldonado kaj ĉe domajne kvalifikitaj nomoj. Malgrandigi aŭ forigi domajnan prefikson sen kompreni la dosierujon povas kunfandi du kontojn, kiuj devis resti apartaj.

Memoru, ke la opcio ankaŭ ŝanĝas, kiu agordo por ĉiu kliento validas, ĉar client-config-dir estas ŝlosita per la komuna nomo.

Testu la parigon per du validaj legitimiloj

Komencu per la paro, kiun via politiko permesas, kaj konfirmu, ke ĝi konektiĝas. Poste prezentu la saman validan atestilon kun malsama, sed alie valida konto: tiu provo devas malsukcesi, kaj ĝi devas malsukcesi pro la parigregulo, ne pro mistajpita pasvorto. Malĝusta pasvorto pruvas, ke la pasvorta kontrolo funkcias, kaj diras nenion pri la regulo inter atestilo kaj konto.

Kontrolu ankaŭ la vojojn de mankanta kaj nevera atestilo, kaj konfirmu, kiun identecon la servilo uzas por agordoj por ĉiu kliento. Se la sola maniero igi la komparon funkcii estas malŝalti username-as-common-name, unue kalkulu la koston de tiu ŝanĝo, ĉar ĝi movas la agordan serĉadon de ĉiu kliento reen al la atestila nomo.