OpenVPN username-as-common-name: wêrom jo CN-kontrôle leech bliuwt
In client-connect-skript dat common_name mei username ferliket, kin in namme mei himsels ferlikje. Byn it sertifikaat oan it akkount foardat de ferfanging útfierd wurdt.
Jo foegje in client-connect-skript ta dat elke ferbining wegeret wêrby't common_name ôfwiket fan username, en it liket in bining tusken in sertifikaat en in akkount. Op in tsjinner dy't username-as-common-name draait, hat dy ferliking har betsjutting al ferlern tsjin 'e tiid dat it skript draait. Beide wearden binne deselde tekenrige, dat de test slagget foar in sertifikaat dat oan hiel immen oars útjûn is.
De kontrôle is net ferkeard om't it skript min skreaun is. Hy is ferkeard om't de wearde dy't er lêst earder yn deselde ferbining ferfongen is.
Wat de ferliking blykber bewissiget
Sertifikaatautentikaasje en wachtwurdautentikaasje binne aparte bewiizen, en in tsjinner kin beide easkje sûnder te easkjen dat se by deselde persoan hearre. De kleau is echt: in jildich apparaatsertifikaat plus in jildich akkount is in oare oanspraak as dat apparaatsertifikaat plus ien beneamd akkount. In skript dat common_name mei username ferliket, lêst as de ûntbrekkende skeakel tusken beide. Dat soe it wêze, as common_name noch betsjutte wat it sertifikaat sei.
Oft dat sa is, hinget fan ien tsjinneropsje ôf, en dy opsje wurdt meastentiids om in net besibbe reden oan set, lykas it makliker meitsjen fan nammen foar konfiguraasjebestanden per brûker.
Wat username-as-common-name mei de namme docht
Mei username-as-common-name oan set ferfangt OpenVPN de gewoane namme fan it sertifikaat troch de autentisearre brûkersnamme sadree't de brûkersnamme en it wachtwurd ferifiearre binne. De ferifikaasjehook dy't yn dat kontrôle draait, krijt noch hieltyd de gewoane namme fan it sertifikaat, om't de ferfanging noch net bard is. Alles dêrnei, client-connect ynbegrepen, sjocht de brûkersnamme. Dat de lettere callback krijt ien identiteit twa kear en kin dy net ferlikje mei it sertifikaat dat oanbean is.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Gean ien yllustrative ferbining nei: in sertifikaat útjûn foar bob-device, in slagge mapoanmelding as alice, en de opsje oan set. De ferifikaasjefaze kin noch twa ferskate tekenriegen sjen. De ferbiningfaze sjocht alice en alice.
Dat foarbyld lit sjen wêrom't de ferliking leech is. It lit net sjen dat de ferbining oars wol akseptearre wurde soe, om't sertifikaatfalidisaasje en wachtwurdferifikaasje noch op har eigen draaie.
Set de bining dêr't beide identiteiten noch besteane
De regel moat hanthavene wurde yn in faze dy't de sertifikaatidentiteit en it akkount tagelyk sjocht, wat yn 'e praktyk de hook foar brûkersnamme- en wachtwurdferifikaasje betsjut of in plugin dy't dêr laden is. In stipe plugin dy't al wachtwurdferifikaasje docht, is meastentiids it rjochte plak om in koppelingsregel ta te foegjen, om't it ferfangen troch in nammeferliking de wachtwurdkontrôle hielendal falle litte soe.
Bepaal de mapping foardat jo koade skriuwe, om't gelikensens komselden it echte belied is. In sertifikaat identifisearret faak in apparaat wylst de oanmelding in persoan identifisearret, en ien apparaat kin legitime ferskate persoanen tsjinje. Bewarje de relaasje yn in foarm wêrfan jo de útjefte kontrolearje, en beslute wat der bart by werneamen, by opnij útjaan en by domeinkwalifisearre nammen. It ferlytsjen fan letters of it strippen fan in domeinprefix sûnder it mapbegryp te begripen kin twa akkounts gearfoegje dy't apart bliuwe moasten.
Tink derom dat de opsje ek feroaret hokker konfiguraasje per kliïnt jildt, om't client-config-dir fêststeld wurdt troch de gewoane namme.
Test de koppeling mei twa jildige oanmeldingsgegevens
Begjin mei it pear dat jo belied tastiet en befêstigje dat it ferbynt. Bied dêrnei itselde jildige sertifikaat oan mei in oar, mar oars jildich akkount: dy poging moat mislearje, en it moat mislearje troch de koppelingsregel en net troch in ferkeard yntikke wachtwurd. In ferkeard wachtwurd bewiist dat de wachtwurdkontrôle wurket en seit neat oer de regel tusken sertifikaat en akkount.
Kontrolearje ek de paden sûnder sertifikaat en mei in ûnjildich sertifikaat, en befêstigje hokker identiteit de tsjinner foar ynstellingen per kliïnt brûkt. As de iennichste manier om de ferliking wurkje te litten is username-as-common-name út te setten, berekkenje dy feroaring dan earst, om't it alle konfiguraasjesykjen per kliïnt weromset nei de namme fan it sertifikaat.