OpenVPN username-as-common-name: zašto vam je provjera CN prazna

Dodajete client-connect skriptu koja odbija svaku vezu u kojoj se common_name razlikuje od username, i to izgleda kao veza između certifikata i računa. Na serveru na kojem je uključen username-as-common-name, ta je usporedba već izgubila smisao do trenutka kada skripta krene. Obje vrijednosti su isti niz znakova, pa test prolazi i za certifikat izdat sasvim drugoj osobi.

Provjera nije pogrešna zato što je skripta loše napisana. Pogrešna je zato što je vrijednost koju čita već ranije zamijenjena u istoj vezi.

Šta usporedba navodno dokazuje

Autentifikacija certifikatom i autentifikacija lozinkom dva su odvojena dokaza, a server može tražiti oba, a da pritom ne traži da pripadaju istoj osobi. Praznina je stvarna: važeći certifikat uređaja plus bilo koji važeći račun različita je tvrdnja od tog certifikata plus jednog imenovanog računa. Skripta koja poredi common_name sa username čita se kao karika koja nedostaje između njih. I bila bi to, da common_name još uvijek znači ono što je pisalo u certifikatu.

Da li je tako zavisi od jedne serverske opcije, a ta se opcija obično uključuje iz nepovezanog razloga, kao što je lakše imenovanje konfiguracijskih datoteka po korisniku.

Šta username-as-common-name radi s imenom

Kada je username-as-common-name uključen, OpenVPN zamjenjuje zajedničko ime certifikata autentifikovanim korisničkim imenom nakon što se korisničko ime i lozinka provjere. Kuka za provjeru koja se izvršava tokom te provjere još uvijek dobija zajedničko ime certifikata, jer zamjena još nije nastupila. Sve nakon toga, uključujući client-connect, vidi korisničko ime. Zato kasniji poziv dobija jedan identitet dva puta i ne može ga uporediti sa certifikatom koji je predstavljen.

Pratite jednu ilustrativnu vezu: certifikat izdat za bob-device, uspješna prijava u direktorij kao alice i uključena opcija. Faza provjere još uvijek može vidjeti dva različita niza. Faza povezivanja vidi alice i alice.

Taj primjer pokazuje zašto je usporedba prazna. On ne pokazuje da bi veza inače bila prihvaćena, jer validacija certifikata i provjera lozinke i dalje rade samostalno.

Postavite vezu tamo gdje oba identiteta još postoje

Pravilo se mora provoditi u fazi koja vidi identitet iz certifikata i račun istovremeno, što u praksi znači kuku za provjeru korisničkog imena i lozinke ili dodatak učitan tamo. Podržani dodatak koji već obavlja provjeru lozinke obično je pravo mjesto za dodavanje pravila uparivanja, jer bi njegova zamjena poređenjem imena u potpunosti uklonila provjeru lozinke.

Definišite mapiranje prije pisanja koda, jer jednakost je rijetko prava politika. Certifikat često identifikuje uređaj, dok prijava identifikuje osobu, a jedan uređaj može legitimno služiti više osoba. Čuvajte odnos u obliku čije izdavanje kontrolišete i odlučite šta se dešava pri preimenovanju, pri ponovnom izdavanju i kod imena s domenom. Prevođenje domenskog prefiksa u mala slova ili njegovo uklanjanje bez razumijevanja direktorija može spojiti dva računa koja su trebala ostati odvojena.

Zapamtite da opcija također mijenja koja konfiguracija po klijentu važi, jer client-config-dir se indeksira po zajedničkom imenu.

Testirajte uparivanje s dva važeća akreditiva

Počnite s parom koji vaša politika dopušta i potvrdite da se povezuje. Zatim predstavite isti važeći certifikat s drugim, ali inače važećim računom: taj pokušaj mora propasti, i mora propasti zbog pravila uparivanja, a ne zbog pogrešno otkucane lozinke. Pogrešna lozinka dokazuje da provjera lozinke radi i ne govori ništa o pravilu veze certifikata i računa.

Provjerite i putanje nedostajućeg i nevažećeg certifikata i potvrdite koji identitet server koristi za postavke po klijentu. Ako je jedini način da usporedba proradi isključivanje username-as-common-name, prvo izračunajte cijenu te promjene, jer ona vraća traženje konfiguracije svakog klijenta natrag na ime iz certifikata.