9
OpenVPN für Standarduser
Hallo zusammen
Wie der Titel schon sagt, ich suche möglichkeiten bei uns in der AD OpenVPN für Standarduser zur Verfügung zu stellen, auf Win7 Pro.
OpenVPN Server ist eine PFSense (V2.3.1)
Ich kenn schon dieses How To:
How To
Allerdings gefällt mir die Lösung nicht sonderlich.
Bisher habe ich mir Securepoint SSL Client angeschaut, welches zwar keine Adminrechte braucht, aber dieser hat kein Silent Install Parameter. Das würde die Verteilung extrem schwierig machen, da wir alles Manuell installieren müssten.
Dann noch den OpenVPN Management Client, allerdings fragt dieser auch nach Adminzugangsdaten (wobei in der PFSense oberfläche steht, dass er eigentlich keine will).
Ich dachte es gäbe noch eine möglichkeit über die Aufgabenplanung dies zu starten mit Adminrechten, aber das scheint nicht zu funktionieren.
Kenn ihr weitere möglichkeiten, oder wie verteilt ihr OpenVPN wenn ihr es in einer Domäne einsetzt?
Vielen Dank!
Wie der Titel schon sagt, ich suche möglichkeiten bei uns in der AD OpenVPN für Standarduser zur Verfügung zu stellen, auf Win7 Pro.
OpenVPN Server ist eine PFSense (V2.3.1)
Ich kenn schon dieses How To:
How To
Allerdings gefällt mir die Lösung nicht sonderlich.
Bisher habe ich mir Securepoint SSL Client angeschaut, welches zwar keine Adminrechte braucht, aber dieser hat kein Silent Install Parameter. Das würde die Verteilung extrem schwierig machen, da wir alles Manuell installieren müssten.
Dann noch den OpenVPN Management Client, allerdings fragt dieser auch nach Adminzugangsdaten (wobei in der PFSense oberfläche steht, dass er eigentlich keine will).
Ich dachte es gäbe noch eine möglichkeit über die Aufgabenplanung dies zu starten mit Adminrechten, aber das scheint nicht zu funktionieren.
Kenn ihr weitere möglichkeiten, oder wie verteilt ihr OpenVPN wenn ihr es in einer Domäne einsetzt?
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 310834
Url: https://administrator.de/contentid/310834
Printed on: April 28, 2024 at 18:04 o'clock
9 Comments
Latest comment
Hallo,
OpenVPN muss ab Win7 (glaube auch schon ab Vista) mit Adminrechten gestartet werden.
Ohne diese Rechte zonk können die Routen nicht gesetzt werden und der Arp nicht gelöscht werden.
Es ist möglich OpenVPN als Dienst einzurichten der automatisch oder Benutzerinteraktion startet.
Das Problem, die Logindaten müssen dann in Cleartext gepeichert werden oder bei Zertifikatseinwahl, darf das Zertifikat kein Passwort haben.
Beim automatishen Start macht das System alles, bei Benutzerstart/Stop vom VPN braucht der Benutzer in den Sicherheitsrichtliien die Erlaubnis den OpenVPN Dienst zu starten und stoppen.
Gruß
Chonta
OpenVPN muss ab Win7 (glaube auch schon ab Vista) mit Adminrechten gestartet werden.
Ohne diese Rechte zonk können die Routen nicht gesetzt werden und der Arp nicht gelöscht werden.
Es ist möglich OpenVPN als Dienst einzurichten der automatisch oder Benutzerinteraktion startet.
Das Problem, die Logindaten müssen dann in Cleartext gepeichert werden oder bei Zertifikatseinwahl, darf das Zertifikat kein Passwort haben.
Beim automatishen Start macht das System alles, bei Benutzerstart/Stop vom VPN braucht der Benutzer in den Sicherheitsrichtliien die Erlaubnis den OpenVPN Dienst zu starten und stoppen.
Gruß
Chonta
Moin,
wenn ich mich jetzt nicht ganz täusche, sollte das seit Version 2.1 oder 2.2 con OpneVPN funktionieren.
Gruß Krämer
wenn ich mich jetzt nicht ganz täusche, sollte das seit Version 2.1 oder 2.2 con OpneVPN funktionieren.
Gruß Krämer
Hm Schade... Tolle Software, aber das ist leider eine große Einschränkung
Allerdings habe ich es evtl. schon gelöst. Securepoint SSL VPN gibt es nun mit Silent install, wenn man die MSI aus dem Temp Ordner abholt. Habe es in WSUS integriert und hat problemlos installiert.
Wenn es Lösungsvorschläge für den nativen Client gibt, wäre ich trotzdem dankbar!
Allerdings habe ich es evtl. schon gelöst. Securepoint SSL VPN gibt es nun mit Silent install, wenn man die MSI aus dem Temp Ordner abholt. Habe es in WSUS integriert und hat problemlos installiert.
Wenn es Lösungsvorschläge für den nativen Client gibt, wäre ich trotzdem dankbar!
Danke Aqui, der letzten beitrag hat es mal gut erklärt. Allerdings werde ich bei Securepoint bleiben. Ist leider zu umständlich mit dem normalen VPN Client...
Danke für eure Hilfe
Danke für eure Hilfe
Du könntest folgendes machen:
Das ganze geht relativ einfach über eine GPO.
Sollte der Benutzer die VPN Login Daten hingegen nicht auslesen können, einfach Besitzer des config Ordners auf System stellen und allen außer "System" aus den ACLs löschen (+ Bitlocker mit TPM, + Benutzer ist kein Administrator).
P. S. Wenn das Thema erledigt ist, bitte auf erledigt setzen.
- OpenVPN Client verwenden
- Berechtigungen für das Verzeichnis "C:\Program Files\OpenVPN\config" ändern, so dass der Benutzer dort seine ".ovpn" + Zertifikate ablegen kann.
- Berechtigung zum Starten/Stoppen des OpenVPN Dienstes erteilen.
Das ganze geht relativ einfach über eine GPO.
Sollte der Benutzer die VPN Login Daten hingegen nicht auslesen können, einfach Besitzer des config Ordners auf System stellen und allen außer "System" aus den ACLs löschen (+ Bitlocker mit TPM, + Benutzer ist kein Administrator).
P. S. Wenn das Thema erledigt ist, bitte auf erledigt setzen.
Das ganze geht relativ einfach über eine GPO.
Ist aber nur die halbe Miete und reicht nicht.....Wenn der Client das Tunnel Interface aktiviert bei der VPN Einwahl, dann wird eine IP Route in das Windows OS gesetzt.
Ein Route Injection ist einzig nur mit Administrator Rechten derzeit möglich bei Winblows.
Dein Tip wird zwar funktionieren aber durch die dann fehlende Route auf das VPN Netz ist die Kommunikation über den Tunnel tot.
Nun kann der TO den Thread entsprechend setzen:
How can I mark a post as solved?
Ein Route Injection ist einzig nur mit Administrator Rechten derzeit möglich bei Winblows.
@aqui, soweit ich weiß, hat der Benutzer "NT Authorität\System" alle dafür erforderlichen Rechte 
. Bei OpenVPN läuft der Dienst unter diesem Benutzer, also kein Problem, funktioniert problemlos.
OK, das wäre ja dann die Lösung für den TO. Bin nicht so der Winblows Wizzard... 
