SSL-VPN Benutzereinstellung in Kombination mit AD-Anbindung

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Albzundy
Beiträge: 34
Registriert: Mo 26.02.2018, 15:40

SSL-VPN Benutzereinstellung in Kombination mit AD-Anbindung

Beitrag von Albzundy »

Ich bin dabei unsere UTM ans AD anzubinden. Bisher vergessen manche Mitarbeiter gerne ihr Kennwort, da sie den Zugang zu selten verwenden und dann muss das Kennwort neu vergeben werden. Mit der AD-Anbindung würde das zusätzliche Kennwort entfallen und jeder MA kann das gewohnte Kennwort für die Windows Domäne Anmeldung verwenden. (So ist der Plan ;-)

Zu der Einrichtung bzw Umstellung der UTM VPN-User habe ich eine Frage:
Da ich ja jedem Benutzer ein eigenes Zertifikat zuweisen muss/sollte, muss ich also trotz AD Anbindung jeden VPN User auf der UTM anlegen?
Bisher existiert der Benutzer nur lokal auf der UTM, dort ist ihm zugeordnet:
  • Benutzername
  • Passwort
  • Client-Zertikat
  • One-Time Password Token
Jetzt habe ich die UTM mit dem AD verbunden und entsprechende Gruppen angelegt.
Für den Webzugriff (Administration oder Zugriff auf Mailfilter) ist das ja ganz einfach, dafür braucht man nur einen Benutzernamen und ein Passwort.
Für OpenSSL VPN reicht ja aber alleine die Gruppe im AD nicht, weil dort nur der Benutzername und Passwort hinterlegt ist.
Die Einstellung für das Client-Zertifikat und bei uns noch zusätzlich den OTP-Hardware Token kann ja nur direkt auf der Firewall erfolgen.

Also muss man zwingend auf der Firewall einen Benutzer anlegen, der dann exakt den gleichen Anmeldenamen haben muss wie der AD-User?
Ich muss auf der UTM beim Benutzer Anlegen außerdem zwingend ein Kennwort vergebeben. Mit AD Anbindung wird bei gleichen Username immer das Passwort vom AD User gefordert habe ich ausprobiert?.(Habe ich eben nochmal getstet,ich bin mir nicht mehr sicher)
Kann/Muss ich das lokale Kennwort auf der UTM somit als Rückfallebene ansehen? Normalerweise brauche und kann ich es ja gar nicht verwenden (?).



Ich habe eben gesehen, dass man doch alle Informationen im AD speichern kann und warscheinlich auch MUSS:
https://wiki.securepoint.de/UTM/AUTH/AD_Anbindung
https://wiki.securepoint.de/UTM/AUTH/OTP
https://wiki.securepoint.de/UTM/AUTH/OTP-AD

Dann gibts keine Verwirrung mehr wegen mehrfach angelegten Usern mit gleichen Benutzernamen.

Auf lokale Benutzer kann also komplett verzichtet werden denke ich (außer natürlich min. 1 Admin Konto für den Notfall etc)

Albzundy
Beiträge: 34
Registriert: Mo 26.02.2018, 15:40

Beitrag von Albzundy »

Die Umsetzung der AD Anbindung ist leider etwas umständlich.
Die Philosphie von Securepoint hat Vor- und Nachteile.
Der Vorteil ist, dass wirklich alle Informationen im AD gepflegt werden.
Das ist gleichzeitig auch der Nachteil, denn das AD beinhaltet von Haus aus nicht passend vordefinierte Felder für einige der benötigten Informationen. Man muss mit extra Attributen arbeiten (extensionAttributexx) oder eben neue Attribute erstellen (nicht empfehlenswert).
Von diversen anderen Anwendungsfällen wo ich etwas ans AD anbinde, sind derart spezifische Informationen (hier zB die VPN IP-Adresse, das Zertifikat oder das OTP) in der jeweiligen Anwendung/dem Server/dem Gerät direkt vorhanden und das ganze ist lediglich verknüpft mit dem AD-User.
Das Vorgehen bei der Securepoint FIrewall verlagert jedoch ALLE Einstellungen ins AD, ohne weitere Daten des Benutzers lokal auf der UTM vorzunehmen.
Wie gesagt, es hat Vor- und Nachteile.
In unserer Umgebung wäre der Vorteil, dass die Passwörter nicht mehr lokal sondern aus dem AD kommen, leider nur relativ klein im Gegensatz zu der aufwendigeren Konfiguration im AD mit exra Attributen etc. Die Einrichtung eines Users in der Weboberfläche wo man alle benötigten Informationen sieht und teils in Auswahlfeldern selektieren kann fällt deutlich leichter. In kleinen Umgebungen wo nur auch selten etwas an der Konfiguration geändert wird ist es angenehmer, man hat diesen Luxus . Auch im Interesse meiner Kollegen die ebenfalls damit arbeiten müssten, werde ich daher erst noch warten die VPN User komplett im AD abzubilden.

Antworten