Hello Heiko, > However it was only an example and thus > didn't have to make any practical sense. =)
:-) > You forgot the GUI in this picture. If the service is connected to the > management interface the GUI can't connect anymore. ? If I understand you correctly it works this way: openvpnserv.exe spawns openvpn.exe openvpnhelperserv.exe spawns openvpnhelper.exe openvpn.exe runs with no privileges at all (local service) and openvpnhelper.exe with priviliges to modify routing (network configuration operator) openvpn.exe communicates via pipe to openvpnhelper.exe, for example "please add a route" the user client (for example perl script) uses management interface to connect to openvpn.exe (please establish connection, credentials are xyz) > Interesting, could you elaborate? The process needs to much rights. AFAIK openvpnhelper.exe would than need SE_ASSIGNPRIMARYTOKEN_NAME Why should it have so much power? Can you explain the architeture in more detail? Do you need it for smartcard auth? I don't know the details of Smartcard API ... > Not users, really. More like session. So you can connect to different server > simultaneously. Yeah, that's a point. But I think it would only need management commands like "connect vpn session 1" "disconnect vpn session 1", "supply credentials for sessions 1". Credentials could be more than username/password, for example tls key or smartcard "connection". > Of course this could be used by two different users at the > same time or different impersonations in the same session, while still running > ovpn with the credentials of the entity who started openvpn. So the point > isn't really that many user can connect, but that the running sessions will be > isolated from each other by the service. hmm, I'm unsure if you would win something. If the network communicating process is compromised (exploited from internet) than it could get all the credentials via normal interface from processes that holds them. greetings Carsten
