VPN-Benutzer anlegen: zuerst den Identitätsinhaber finden
Einen VPN-Benutzer hinzuzufügen beginnt beim Identitätssystem, nicht bei der Shell. Finde heraus, welches Backend das Konto prüft, vergib die Berechtigung und plane die Rücknahme.
Jemand bittet um VPN-Zugang, und der erste Impuls ist, adduser auf dem Server auszuführen. Dieser Impuls stimmt nur in einem engen Satz von Installationen. Bevor du etwas erstellst, öffne die Konfiguration des Servers und finde heraus, welches Produkt dort läuft und wo es Anmeldedaten prüft, denn das Konto kann in einer Produktdatenbank, bei einem Identitätsanbieter oder im eigenen Authentifizierungs-Stack des Hosts liegen. Ein Konto der falschen Art anzulegen hinterlässt eine Person mit funktionierendem Login und ohne Tunnel.
Ein Clientprofil, das OpenVPN nennt, beschreibt das Protokoll, nicht das Identitätssystem dahinter.
Beim Server anfangen, nicht bei adduser
Identifiziere zuerst das Produkt. Community OpenVPN ist der Daemon plus jegliche Authentifizierung, die du eingebunden hast, während Access Server ein Produkt mit eigener Benutzerschicht ist. Frage nach Konfiguration, Unit-Namen und Paketliste und prüfe, ob es eine Weboberfläche für die Benutzerverwaltung gibt. Sieh dir dann an, wie das ausgerollte Profil erwartet, dass Clients beweisen, wer sie sind: ein Zertifikat, ein Benutzername und ein Passwort oder beides. Diese Antwort benennt das System, dem das Konto gehört.
Erst danach bedeutet die Formulierung den Benutzer anzulegen etwas. In einer Installation nur mit Zertifikaten bedeutet es, eine Geräteidentität über den genehmigten Prozess auszustellen, und ein Unix-Login ändert nichts. In einer Installation mit Passwort bedeutet es das Backend, das das Passwort tatsächlich prüft.
Vier Backends, vier Orte, um das Konto anzulegen
Die lokale Authentifizierung von Access Server hält Konten in seiner eigenen Datenbank, daher gehört die Oberfläche zum Anlegen dem Produkt und nicht dem Host. PAM delegiert die Prüfung an den Stack des Betriebssystems, weshalb ein lokales Unix-Konto Teil der Anmeldung sein kann, wenn der Dienst genau diesen Stack gewählt hat. LDAP, RADIUS und SAML verlagern die Prüfung in einen externen Dienst, in dem Bereitstellung, Passwortrichtlinie und MFA leben. Access Server kann in allen vier Fällen weiterhin Zertifikate und Berechtigungen pro Benutzer halten, und genau das macht die Trennung verwirrend.
Prüfe die effektive Methode für diesen konkreten Benutzer statt der globalen Vorgabe. Access Server 2.10 und später kann unterschiedliche Authentifizierungsmethoden pro Gruppe oder pro Benutzer anwenden, eine lokale Vorgabe beweist also nicht, dass das Konto vor dir lokal geprüft wird.
Berechtigung ist eine eigene Entscheidung
Authentifizierung beantwortet, wer die Person ist; Berechtigung beantwortet, was sie erreichen darf. Halte beides als zwei Schritte, denn ein erfolgreicher Login ist keine Gewährung. Vergib die vorgesehenen Routen, Ressourcenberechtigungen und Verwaltungsrechte bewusst und bestätige, dass nicht zugehöriger Zugang verweigert bleibt. Wo die Installation individuelle Identitäten unterstützt, stelle eine pro Person aus, statt das Profil von jemand anderem weiterzugeben, denn ein geteiltes Profil lässt sich nicht für eine Person allein zurückziehen.
Auch das Clientmaterial zählt. Ein Auto-Login-Profil und ein interaktiver Benutzer-Login stehen für unterschiedliche Authentifizierungsbeziehungen, und das eine gegen das andere zu tauschen ändert, was der Server tatsächlich prüft.
Zugang zurückzuziehen gehört zur Anmeldung
Notiere drei Inhaber, während der Benutzer angelegt wird: wer das Konto prüft, wer den VPN-Zugang genehmigt und welches Gerät oder Profil die Verbindung repräsentiert. Das können drei verschiedene Systeme sein, und ein Rücknahmeplan, der nur eines davon nennt, lässt einen Weg offen. Wenn die Person das Unternehmen verlässt, entferne die Berechtigung bei ihrem Inhaber und ziehe jedes ausgegebene Credential bei seinem Inhaber zurück. Eine heruntergeladene Datei zu löschen ist keine Rücknahme, und einen lokalen Eintrag zu löschen auch nicht, wenn eine externe Identität sich noch authentifiziert.
Teste die Anmeldung dann so, wie es ein Angreifer täte: verbinde dich einmal mit der neuen Identität, bestätige den Zugang zur vorgesehenen Ressource und bestätige, dass eine nicht zugehörige Ressource weiterhin abweist. Eine erste funktionierende Verbindung plus ein Negativtest ist eine abgeschlossene Anmeldung.
Bewahre den Datensatz beim Profil auf, zu dem er gehört. Der nächste Prüfer wird fragen, wer sich in einem bestimmten Monat verbinden konnte, und die Antwort liegt bei diesen drei Inhabern.