Een VPN-gebruiker registreren: vind eerst de eigenaar van de identiteit

Iemand vraagt om VPN-toegang, en de eerste reflex is adduser op de server uitvoeren. Die reflex is alleen juist in een smalle set implementaties. Voordat je iets aanmaakt, open je de configuratie van de server en zoek je uit welk product daar draait en waar het inloggegevens valideert, want het account kan in een productdatabase, bij een identiteitsprovider of in de eigen authenticatiestack van de host staan. Het verkeerde soort account aanmaken laat de persoon achter met een werkende login en zonder tunnel.

Een cliëntprofiel dat OpenVPN vermeldt, beschrijft het protocol, niet het identiteitssysteem erachter.

Begin bij de server, niet bij adduser

Identificeer eerst het product. Community OpenVPN is de daemon plus alle authenticatie die je eraan hebt gekoppeld, terwijl Access Server een product is met een eigen gebruikerslaag. Vraag om de configuratie, de unitnaam en de pakketlijst, en controleer of er een webinterface voor gebruikersbeheer is. Kijk daarna hoe het uitgerolde profiel verwacht dat cliënten bewijzen wie ze zijn: een certificaat, een gebruikersnaam en wachtwoord, of beide. Dat antwoord noemt het systeem dat het account bezit.

Pas daarna betekent de uitdrukking de gebruiker aanmaken iets. In een implementatie met alleen certificaten betekent het een apparaatidentiteit uitgeven via het goedgekeurde proces, en een Unix-login verandert niets. In een wachtwoordimplementatie betekent het de backend die het wachtwoord werkelijk valideert.

Vier backends, vier plaatsen om het account aan te maken

De lokale authenticatie van Access Server houdt accounts in zijn eigen database, dus de interface om ze aan te maken hoort bij het product en niet bij de host. PAM delegeert de validatie aan de stack van het besturingssysteem, en daarom kan een lokaal Unix-account deel uitmaken van de registratie wanneer de dienst precies die stack heeft gekozen. LDAP, RADIUS en SAML verplaatsen de validatie naar een externe dienst, waar provisioning, wachtwoordbeleid en MFA leven. Access Server kan in alle vier gevallen nog steeds certificaten en rechten per gebruiker vasthouden, en dat is wat de splitsing verwarrend maakt.

Controleer de effectieve methode voor deze specifieke gebruiker in plaats van de globale standaard. Access Server 2.10 en later kunnen verschillende authenticatiemethoden per groep of per gebruiker toepassen, dus een lokale standaard bewijst niet dat het account voor je lokaal wordt gevalideerd.

Het recht is een aparte beslissing

Authenticatie beantwoordt wie de persoon is; het recht beantwoordt wat hij mag bereiken. Houd ze als twee stappen, want een geslaagde login is geen toekenning. Wijs de bedoelde routes, resourcerechten en beheerrechten bewust toe, en bevestig dat niet-gerelateerde toegang geweigerd blijft. Waar de implementatie individuele identiteiten ondersteunt, geef er één per persoon uit in plaats van het profiel van iemand anders door te sturen, want een gedeeld profiel kan niet voor één persoon worden ingetrokken.

Het cliëntmateriaal doet er ook toe. Een auto-loginprofiel en een interactieve gebruikerslogin vertegenwoordigen verschillende authenticatierelaties, en het ene door het andere vervangen verandert wat de server werkelijk verifieert.

Toegang intrekken hoort bij de registratie

Noteer drie eigenaren terwijl de gebruiker wordt aangemaakt: wie het account valideert, wie de VPN-toegang autoriseert en welk apparaat of profiel de verbinding vertegenwoordigt. Dat kunnen drie verschillende systemen zijn, en een intrekkingsplan dat er maar één noemt, laat een pad open. Wanneer de persoon vertrekt, verwijder je het recht bij de eigenaar en trek je elk uitgegeven credential bij de eigenaar in. Een gedownload bestand verwijderen is geen intrekking, en een lokale vermelding verwijderen ook niet als een externe identiteit zich nog authenticeert.

Test de registratie daarna zoals een aanvaller dat zou doen: verbind één keer met de nieuwe identiteit, bevestig toegang tot de bedoelde resource en bevestig dat een niet-gerelateerde resource nog steeds weigert. Een eerste werkende verbinding plus een negatieve test is een voltooide registratie.

Bewaar het record bij het profiel waartoe het behoort. De volgende auditor vraagt wie zich in een bepaalde maand kon verbinden, en het antwoord ligt bij die drie eigenaren.