On Thu, 13 Jan 2005, Didier Conchaudron wrote: > Hi all, > > I'm still working on a renewed openvpn service wrapper( which's heading > to allow a non-admin user to start/stop pre-defined tunnels via a tcp > socket) and I see some big troubles in a near future. > > The *great* actual cryptoapi patch allow a user to access local machine > and local user certs. It's quite good right now because most of the > openvpn users are using it with admin rights or non-interactive > processing( like autostart at windows boot). > > I'm worrying about those features when our aim will be to do let > non-admin users start their tunnel and authenticate themselves on the > openvpn server with their own certificate. In the actual openvpn it's > not possible, because the SYSTEM account can only access to his own > certs and the local machine certs, but not "Foo Bar User" certs. > > We can ask ourselves few questions: > > - is it possible to make SYSTEM access user certs? > - if not, how can we make openvpn access to those users data? > > A friend of mine said an answer could be to let the GUI(or a user only > component) manage the access to such user-related data, and let openvpn > deal with this component in order to use the certs. > > Of course, this problem is only windows-related. > > What do you think of this problem?
First of all, the current impediments to running OpenVPN on Windows in non-admin user mode is: (1a) The openvpn.exe process needs to open a device handle to the TAP-Win32 adapter. Windows does not provide a convenient way for the TAP-Win32 adapter to allow itself to be opened by non-admin apps. (2a) OpenVPN needs to be able to modify the routing table. Most OSes (Windows & Linux included) require admin/root privileges for this. Now it appears that we have another obstacle, this time going the other way. (1b) The SYSTEM account (sort of like "Windows" root, the user under which services/daemons run) can't read a specific user's key from the Crypto API store. Either we need to run openvpn.exe in user mode and solve (1a) and (2a) or run openvpn.exe in service mode and solve (1b). (1a) and (2a) seem relatively difficult to solve, so probably it's worthwhile to attempt to solve (1b) -- or at least study its difficulty in relation to (1a) and (2a). James
