Registri VPN-uzanton: unue trovu la posedanton de la identeco

Iu petas VPN-aliron, kaj la unua instinkto estas ruli adduser sur la servilo. Tiu instinkto pravas nur en mallarĝa aro da enkondukoj. Antaŭ ol krei ion ajn, malfermu la agordon de la servilo kaj eltrovu, kiu produkto tie funkcias kaj kie ĝi validigas legitimilojn, ĉar la konto povas loĝi en produkta datumbazo, ĉe identeca provizanto aŭ en la propra aŭtentiga stako de la gastiganto. Krei la malĝustan specon de konto lasas la personon kun funkcianta ensaluto kaj sen tunelo.

Klienta profilo, kiu diras OpenVPN, priskribas la protokolon, ne la identecan sistemon malantaŭ ĝi.

Komencu per la servilo, ne per adduser

Unue identigu la produkton. Community OpenVPN estas la demono plus ajna aŭtentigo, kiun vi ligis al ĝi, dum Access Server estas produkto kun propra uzanta tavolo. Petu la agordon, la nomon de la unuo kaj la pakaĵliston, kaj kontrolu, ĉu ekzistas reta interfaco por administrado de uzantoj. Poste rigardu, kiel la enkondukita profilo atendas, ke klientoj pruvu, kiuj ili estas: per atestilo, per uzantnomo kaj pasvorto, aŭ per ambaŭ. Tiu respondo nomas la sistemon, kiu posedas la konton.

Nur post tio la esprimo krei la uzanton havas sencon. En enkonduko nur per atestiloj ĝi signifas eldoni identecon de aparato per la aprobita procezo, kaj Unix-ensaluto ŝanĝas nenion. En enkonduko per pasvorto ĝi signifas la backend, kiu efektive validigas la pasvorton.

Kvar backend, kvar lokoj por krei la konton

La loka aŭtentigo de Access Server tenas kontojn en sia propra datumbazo, do la interfaco por krei ilin apartenas al la produkto, ne al la gastiganto. PAM delegas validigon al la stako de la operaciumo, kaj tial loka Unix-konto povas esti parto de registro, kiam la servo elektis ĝuste tiun stakon. LDAP, RADIUS kaj SAML translokigas validigon al ekstera servo, kie loĝas provizado, pasvorta politiko kaj MFA. Access Server ankoraŭ povas teni atestilojn kaj permesojn por ĉiu uzanto en ĉiuj kvar kazoj, kaj tio estas, kio igas la dividon konfuza.

Kontrolu la efektivan metodon por ĉi tiu konkreta uzanto anstataŭ la tutmondan defaŭlton. Access Server 2.10 kaj poste povas apliki malsamajn aŭtentigajn metodojn por grupo aŭ por uzanto, do loka defaŭlto ne pruvas, ke la konto antaŭ vi estas validigata loke.

Rajto estas aparta decido

Aŭtentigo respondas, kiu estas la persono; rajto respondas, kion ĝi povas atingi. Tenu ilin kiel du paŝojn, ĉar sukcesa ensaluto ne estas donaco. Donu la celitajn vojojn, rimedpermesojn kaj administrajn rajtojn konscie, kaj konfirmu, ke nerilata aliro restas rifuzata. Kie la enkonduko subtenas individuajn identecojn, eldonu unu por persono anstataŭ plusendi la profilon de iu alia, ĉar komuna profilo ne povas esti revokita por unu persono sola.

La klienta materialo ankaŭ gravas. Aŭtomata ensaluta profilo kaj interaga uzanta ensaluto reprezentas malsamajn aŭtentigajn rilatojn, kaj interŝanĝi unu kontraŭ la alia ŝanĝas, kion la servilo efektive kontrolas.

Revoko de aliro estas parto de la registro

Notu tri posedantojn dum la uzanto estas kreata: kiu validigas la konton, kiu rajtigas la VPN-aliron, kaj kiu aparato aŭ profilo reprezentas la konekton. Tiuj povas esti tri malsamaj sistemoj, kaj revoka plano nomanta nur unu el ili lasas vojon malfermita. Kiam la persono foriras, forigu la rajton de ĝia posedanto kaj revoku ĉiun eldonitan legitimilon ĉe ĝia posedanto. Forigi elŝutitan dosieron ne estas revoko, kaj nek estas forigi lokan rikordon se ekstera identeco ankoraŭ aŭtentigas.

Poste testu la registron kiel atakanto farus: konektiĝu unufoje per la nova identeco, konfirmu aliron al la celita rimedo, kaj konfirmu, ke nerilata rimedo ankoraŭ rifuzas. Unua funkcianta konekto plus negativa testo estas finita registro.

Konservu la rikordon kun la profilo, al kiu ĝi apartenas. La sekva aŭditoro demandos, kiu povus konektiĝi dum donita monato, kaj la respondo loĝas en tiuj tri posedantoj.