Registrere ein VPN-brukar: finn identitetseigaren først

Nokon ber om VPN-tilgang, og den første refleksen er å køyre adduser på tenaren. Den refleksen er berre rett i eit smalt sett av installasjonar. Før du opprettar noko, opne konfigurasjonen til tenaren og finn ut kva produkt som køyrer der og kvar det validerer legitimasjon, fordi kontoen kan liggje i ein produktdatabase, hos ein identitetsleverandør eller i verten sin eigen autentiseringsstakk. Å opprette feil type konto lèt personen sitje att med ei fungerande innlogging og utan tunnel.

Ein klientprofil som seier OpenVPN skildrar protokollen, ikkje identitetssystemet bak han.

Start med tenaren, ikkje med adduser

Identifiser produktet først. Community OpenVPN er daemonen pluss all autentisering du kopla til han, medan Access Server er eit produkt med sitt eige brukarlag. Be om konfigurasjonen, eininga sitt namn og pakkelista, og sjekk om det finst eit webgrensesnitt for brukaradministrasjon. Sjå deretter på korleis den utrulla profilen ventar at klientar skal prova kven dei er: eit sertifikat, eit brukarnamn og passord, eller begge. Det svaret namngir systemet som eig kontoen.

Først etter det gir uttrykket å opprette brukaren meining. I ein installasjon med berre sertifikat tyder det å gje ut ein einingidentitet gjennom den godkjende prosessen, og ei Unix-innlogging endrar ingenting. I ein passordinstallasjon tyder det backend som faktisk validerer passordet.

Fire backendar, fire stader å opprette kontoen

Den lokale autentiseringa til Access Server held kontoar i sin eigen database, så grensesnittet for å opprette dei høyrer til produktet og ikkje verten. PAM delegerer valideringa til stakken til operativsystemet, og difor kan ein lokal Unix-konto vere del av registreringa når tenesta har valt nettopp den stakken. LDAP, RADIUS og SAML flyttar valideringa til ein ekstern teneste, der provisjonering, passordpolitikk og MFA ligg. Access Server kan framleis halde sertifikat og løyve per brukar i alle fire tilfella, og det er dette som gjer oppdelinga forvirrande.

Sjekk den effektive metoden for denne konkrete brukaren i staden for den globale standarden. Access Server 2.10 og nyare kan bruke ulike autentiseringsmetodar per gruppe eller brukar, så ein lokal standard provar ikkje at kontoen framfor deg blir validert lokalt.

Retten er ei eiga avgjerd

Autentisering svarar på kven personen er; retten svarar på kva personen kan nå. Hald dei som to steg, fordi ei vellukka innlogging ikkje er ei tildeling. Tildel dei tiltenkte rutene, ressurstilgangane og dei administrative rettane medvite, og stadfest at urelatert tilgang framleis blir avvist. Der installasjonen støttar individuelle identitetar, gje ut éin per person i staden for å videresende profilen til nokon andre, fordi ein delt profil ikkje kan kallast tilbake for éin person åleine.

Klientmaterialet betyr òg noko. Ein auto-innloggingsprofil og ei interaktiv brukarinnlogging representerer ulike autentiseringsforhold, og å byte den eine mot den andre endrar kva tenaren faktisk verifiserer.

Tilbakekalling av tilgang er ein del av registreringa

Skriv ned tre eigarar medan brukaren blir oppretta: kven som validerer kontoen, kven som autoriserer VPN-tilgangen, og kva eining eller profil som representerer sambandet. Det kan vere tre ulike system, og ein tilbakekallingsplan som berre nemner éin av dei, lèt ein veg stå open. Når personen sluttar, fjern retten frå eigaren og kall tilbake kvar utstedt legitimasjon hos eigaren. Å slette ei nedlasta fil er ikkje tilbakekalling, og det er heller ikkje å slette ei lokal oppføring om ein ekstern identitet framleis autentiserer seg.

Test deretter registreringa slik ein angripar ville gjort: kople til éin gong med den nye identiteten, stadfest tilgang til den tiltenkte ressursen, og stadfest at ein urelatert ressurs framleis avviser. Ein første samband som verkar pluss ein negativ test er ei fullført registrering.

Oppbevar posten saman med profilen han høyrer til. Den neste revisoren vil spørje kven som kunne kople til i ein gitt månad, og svaret ligg hos dei tre eigarane.