Egna VPN-identiteter för ett litet team, utan katalog

Sex personer delar en VPN-inloggning, en av dem slutar, och det enda sättet att ta bort den personens åtkomst är att byta hemligheten som alla andra använder. Det är det egentliga problemet, och det kräver ingen Active Directory för att lösas. Ett litet kontor kan hålla separata identiteter i den lokala lagring som gatewayen stöder och ändå behandla avgångar som rutin. Arbetet ligger i att välja lagringen och skriva ned stegen för borttagning innan de behövs.

Börja med inloggningsuppgiften som varje person har

Lista vad varje person ansluter med innan du väljer en backend. En bärbar dator, en telefon, kanske en stationär dator hemma, och var och en av dem är en egen inloggningsuppgift eller ett eget enhetscertifikat. Om du inte kan namnge inloggningsuppgiften en person har, kan du inte ta bort den senare.

Två personer som delar en profil är fallet som gör varje nästa steg svårare. Åtgärda det först, för ingen katalog löser en delad hemlighet.

Välj den lagring som gatewayen faktiskt stöder

Välj den identitetslagring som gatewayen redan stöder, inte den du helst vill driva. En gateway med lokal användardatabas kan hålla enskilda konton med policy per användare. En IKEv2-utrullning kan koppla en EAP-identitet till en viss hemlighet, förutsatt att klientmetoden och verifieraren stämmer överens. Certifikatbaserade uppsättningar kan utfärda ett certifikat per enhet från en gemensam myndighet, vilket håller förtroendeankaret delat medan inloggningsuppgifterna förblir separata.

Lagringens placering spelar mindre roll än dess operationer: registrering, säkerhetskopiering, förnyelse och återkallning. Om någon av dem saknar svar är valet inte klart.

Om gatewayen erbjuder både lokala konton och certifikat, föredra det som ditt team kan driva klockan två på natten utan leverantören i telefonen. Den preferensen handlar om återställningstid, inte om vilket alternativ som är tekniskt starkare.

Skilj personen från enheterna

Bestäm vad en inloggningsuppgift representerar: en person, en enhet eller båda. En bärbar dator och en telefon som tillhör en anställd är två enheter och en person, och att tappa telefonen bör inte nödvändigtvis inaktivera den bärbara datorn. Skriv ned den modellen, för den avgör vad borttagning betyder.

Anteckna ägaren, enheten, utfärdandedatumet och återkallningsvägen för varje inloggningsuppgift. Förvara den förteckningen någonstans där kontoret kan läsa den utan personen som satte upp den. En tabell med de fyra kolumnerna räcker för sex personer och skalar fortfarande till sextio.

Gör borttagning till en vanlig operation

Skriv avgångsproceduren innan den första avgången. Inaktivera identiteten, avsluta alla aktiva sessioner och bekräfta att tunneln faktiskt faller i stället för att vänta på en timer för omautentisering. Kontrollera sedan att den tidigare inloggningsuppgiften misslyckas från en maskin utanför kontorets nätverk. Hela sekvensen bör ta minuter och inte kräva ny utfärdning för någon annan.

sudo swanctl --terminate --ike alice-laptop

Behåll en återställningsväg för administratören som inte beror på det inaktiverade kontot, och stäm av lokala konton som senare flyttar till en katalog. Målet är enkelt: att ta bort en person är en rutinuppgift, inte ett projekt som rör allas profiler. Lokal autentisering i Access Server är ett dokumenterat exempel på en lagring som passar den här formen.