[snip] > > The user should not have the ability to logon to a machine with > > OpenVPN installed if they are not allowed to use OpenVPN, or that user > > should not have access to run the GUI (maybe the OpenVPN Service > > should not even be running). > > These are not the questions. The ability to access to openvpn is not a > matter of openvpn, just one of the computer admin. And even if a user > have openvpn installed, a good conf must need a USER certificate or a > user/pass to allow him to connect to the vpn server. So it's not a > matter of openvpn too, but one of the openvpn admin. > > > The certificate is authenticating the computer. > > It's the actual openvpn features. But much openvpn addicts would be very > pleased to make openvpn works like other commercial vpn, with USER > certificate. > > Btw, MSDN cryptoapi docs don't talk about a way to get userspace certs > from a SYSTEM rights. I think a way to solve this issue would be to make > openvpn deals with a userspace component which one could get the > certificate and supply desired data to openvpn at tunnel startup. This > userspace component could be openvpn-gui or another program. I really > don't know if this kind of solution is technicaly possible. Only true > openvpn hackers could ;-) >
All good points. I must add a couple of my own. 1) OpenVPN is cross platform. 2) Apparently a MS design implementation. Could possible be rectified my having the service use the user login instead of system. 3) At this stage I think changes of this magnitude, as you suggest, would most likely be post 2.0. James an the other brains behind this would know better. -- Leonard Isham, CISSP Ostendo non ostento.
