Start Before Logon (SBL)?

[kq01526]

Hi,

apparently OpenVPN seems to be able to establish a VPN connection before a user logs on to Windows. Apparently this is being done by having OpenVPN running as a service:

https://openvpn.net/index.php/open-source/documentation/howto.html#startup

Establishing a VPN connection before logging on to Windows is especially useful when needing to log on to a domain joined machine (i.e. having to authenticate on a domain controller).

Is OpenVPN also able to offer a prompt for the VPN credentials before logging on to Windows?

Cisco AnyConnect does have that feature, it's called "Start Before Logon" or in short "SBL", see for example:

https://youtu.be/dkwC5lXu-HQ

Windows itself also does offer a similar feature:

https://blog.lan-tech.ca/2012/04/29/connect-to-windows-vpn-at-logon/
https://blog.lan-tech.ca/2013/03/02/windows-8-connect-to-vpn-before-logon/

So, Windows does seem to have a "native" button for this on the log on screen (which is also being utilized by Cisco AnyConnect).

So, would it also be possible to have OpenVPN prompt for the VPN credentials when clicking on that button, so that a user can enter his VPN credentials (username + password) and connect via VPN before logging on to Windows?

Regards

[selvanair]

So, would it also be possible to have OpenVPN prompt for the VPN credentials when clicking on that button, so that a user can enter his VPN credentials (username + password) and connect via VPN before logging on to Windows?

This requires writing a credential provider that implements the Pre-Logon Access Provider (PLAP) usage scenario. A very basic implementation is not hard, but integrating with service (or with the GUI, or keep it as another way of starting the connection ?), providing options to choose which config to connect etc. etc. takes some work, so may not happen anytime soon. Also such a feature is often not required for domain login: as Windows caches domain login credentials, the user can login and then start the tunnel even if the DC is not reachable before the tunnel is up.

However, this "start before logon" feature may be needed for setups where the corporate policy does not allow caching of domain login credentials.

[kq01526]

@selvanair wrote:

Also such a feature is often not required for domain login: as Windows caches domain login credentials, the user can login and then start the tunnel even if the DC is not reachable before the tunnel is up.

That's not quite correct.

For the credentials to be cached, you first need to be able to log on to the domain controller for Windows to be able to cache the credentials.

So you need to log on at least once before the credentials are being cached. In some circumstances this might not be possible without VPN though. So, a Start VPN Before Logon feature would be essential in that case.

Furthermore, the crendential cache storage of Windows is finite.

@selvanair wrote:

However, this "start before logon" feature may be needed for setups where the corporate policy does not allow caching of domain login credentials.

Not just that. As Cisco and Microsoft put it:

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/107598-sbl.html

[...] Start Before Logon lets the administrator control the use of login scripts, password caching, mapping network drives to local drives, and more. [...]

https://support.microsoft.com/en-us/kb/172931

[...] When you logon to Windows by using cached logon information, if the domain controller is unavailable to validate your account, you cannot access network resources that require domain validation. However, you can access network resources that do not require domain validation. [...]

So, it's useful for lots of other things and basically essential for a proper log on.

Furthermore, a Start VPN Before Logon feature would be even more useful now with Windows 10, because Windows 10 now even lets you connect to wireless networks before logging on to Windows.

Regards

[chipitsine]

there's similar implementation https://github.com/Amebis/GEANTLink
we can learn from it

[selvanair]

What is blocking this is lack of time not lack of interest.. The part requiring interaction with logonexec is a rather simple COM interface implementation; the rest is starting the VPN, doing user auth etc. which is tedious unless we re-use existing GUI code. I've an implementation that is not yet ready for prying eyes. Need some quality free time to make it decent, sigh...

I think the link you posted does not implement PLAP interface which is required for starting VPN --- as this will execute as a part of logonexec usual auth methods are given a limited time window to complete unless PLAP interface is implemented.

[sekamin322]

Does anyone have a definite working solution for starting OpenVPN before login? Switching to AD, our DC is connected to the VPN so if users are offsite and forget their passwords, they will be locked out. Allowing them to connect to the VPN first seems to be the easiest solution.

[chipitsine]

what kind of auth do you use ? if login/password, it will not be any usefull.

[chipitsine]

I think, computer active directory issued certificate would be perfect for such kind of setup.

[rozmansi]

We use OpenVPN to connect domain computers to organizations before user logs on.

The OpenVPN is started automatically as a service running as the Local System account. We use the NSSM as the service wrapper for this purpose. The service is configured to depend on Dhcp and tap0901 services just like the OpenVPNService. Probably, the OpenVPNService could do the job too.

For years, we have been using manually managed certificates to authenticate. But, asking employees to go get a new certificate to the Windows Server CA before the current one expires, install it to the Local System's Certificate Store, then update the --cryptoapicert hash in the ovpn file simply did not scale.

Therefore, we no longer use client certificates but --verify-client-cert none + --auth-user-pass to authenticate. The server side has a simple script (I can provide samples for Linux and Windows) with a list of approved computer names and a long secret string per each computer. On the client side the --auth-user-pass points to an ASCII file with computer name and its secret string. This file has ACL limited access only to Administrators and Local System.

Remember, by doing "start-before-logon" you are actually connecting and authenticating computers, not users.

The end result is, the remote computer is connected automatically soon enough in the Windows boot not only to allow domain logons, but it also processes the Group Policy (when the bandwidth is sufficient). This was the whole point of our setup: the employee's laptops can roam around for years without the need to come back home for maintenance. Anywhere they go, they are connected from boot.

[rozmansi]

A side note: If you use Windows provided VPN to connect before logon, you can use the domain logon - true. However, the Group Policy agent service has tried to contact AD long before that and gave up. Therefore, applying Group Policy settings over VPN is not possible.

I am not familiar with Cisco AnyConnect. Can it authenticate and connect soon enough in the boot process so the Group Policy settings can apply too?

[chipitsine]

@rozmansi, Active Directory is a combination of DNS, LDAP and kerberos working together.

As long as computer can reach DNS, AD should work. Including domain logon and group policy. I'd like to see debug of group policy service in your case

As for "logon before connect", it is intended to authenticate users, not computers (Your case with computer authentication via service is worth documenting however)

In order to use start before logon, some api should be implemented, api is available starting win8.1 (it was drastically changed in win10)

On win7 Cisco any connect emulates such api by itself

[rozmansi]

Here are the exported Group Policy and System event logs:
SR5.EventLog.boot-on-LAN.zip
SR5.EventLog.boot-on-OpenVPN.zip

Methodology used:

• Clear event logs
• Reboot
• Login
• Export event logs

One run represents laptop connected to the domain LAN. Another run was made using OpenVPN over WiFi with no direct access to domain LAN.

Comparing the event logs you shall notice they are mostly indistinguishable.

[gordonfrei]

@rozmansi I would like to try the same with openvpn connecting before logon to get software install from GPO working on remote sites. Can you provide sample script of your setup as mentioned?

[rozmansi]

Due to popular demand, I might make a wiki or blog page with step-by-step instructions. Here's something to get you going...

1. Make sure you can connect using an elevated command line:

   cd "C:\Program Files\OpenVPN\config"
   "C:\Program Files\OpenVPN\bin\openvpn.exe" --config Contoso.ovpn
   

   Then disconnect.

2. If you are using --cryptoapicert, install the client certificate to the Local Computer's "Personal" store.

   Optional: I am using --client-cert-not-required and username/passwords instead of client certificates, because PKI is a royal pain-in-the-... = you will notice your client certificate expired when you're out on the road.

3. Download and save nssm.exe utility. No setup required. For this walkthru, I will assume you copied it to C:\Program Files\OpenVPN\bin.

4. Execute using an elevated command line:

   "C:\Program Files\OpenVPN\nssm.exe" install OpenVPN-Contoso "C:\Program Files\OpenVPN\bin\openvpn.exe"
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppDirectory "C:\Program Files\OpenVPN\config"
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppParameters "--config Contoso.ovpn"
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppStdout "C:\Program Files\OpenVPN\log\Contoso.log"
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppStderr "C:\Program Files\OpenVPN\log\Contoso.log"
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppStdoutCreationDisposition 2
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso AppStderrCreationDisposition 2
   "C:\Program Files\OpenVPN\nssm.exe" set OpenVPN-Contoso DependOnService Dhcp tap0901
   "C:\Program Files\OpenVPN\nssm.exe" start OpenVPN-Contoso
   

   This will create an OpenVPN-Contoso system service, configure it to run your OpenVPN connection and redirect the output to C:\Program Files\OpenVPN\log\Contoso.log. The ...CreationDisposition 2 tells the nssm.exe to make a new log on each service restart. The dependencies will allow correct service startup/shutdown timing. Finally, it will start the service.

You operate VPN connection by starting/stopping/disabling the OpenVPN-Contoso service. When set to start Automatically, it will connect on boot. The Group Policy Client service does wait for a while on boot to see if any DC becomes available.

Optional: For laptops, I also install and create a Stunnel connection to my VPN server to port 443 to run a secondary OpenVPN TCP connection service thru it (I set its network interface higher metric than its UDP equivalent). This OpenVPN TCP over TLS/443 penetrates the most strict DPI firewalls and brings quite some "surprise" looks when my laptop seamlessly connect to my work in any conference room. :)

[danieldjewell]

A side note: If you use Windows provided VPN to connect before logon, you can use the domain logon - true. However, the Group Policy agent service has tried to contact AD long before that and gave up. Therefore, applying Group Policy settings over VPN is not possible.

I am not familiar with Cisco AnyConnect. Can it authenticate and connect soon enough in the boot process so the Group Policy settings can apply too?

I can confirm that at least with AnyConnect, connecting the VPN before logon does indeed provide "live" AD logon (i.e. not using cached credentials) and normal group policy processing - as if you were locally connected. If memory serves, there are a few GP settings that can both positively and negatively affect GP processing when using VPN before Logon -- I vaguely remember having to set something like "wait for group policy processing to finish on slow links" or something like that. (It was one of those one-time set it and forget it fixes, so I don't remember the exact steps... if you're experiencing GP processing problems, check those settings )

But, in general, without a doubt: AnyConnect definitely has the capability of doing full 100% "normal" logins without cached credentials and with full group policy processing (including the tricky ones that will only run during a logon.) Likewise, the built-in Windows VPN client also has this ability.

That said, and without sounding "complain-y", I would stress that the capability of doing this is huge -- especially for roadwarrior users or users who are 99-100% remote but use domain joined laptops. There are certain policies and settings that will never be applied unless they run during an interactive logon (e.g. not using cached credentials). Likewise, as noted elsewhere, the cached credentials have a finite expiration time (as I recall, that's configurable in Group Policy - Security Settings? - somewhere near where one configures password complexity) ... performing an interactive logon refreshes these credentials.

Unless something has changed with newer releases of Windows 10, logging on to a VPN connection after logging into Windows does not perform all of the same actions as logging in before. Yes, some group policies will background refresh and some other things will still work, but if you have a user that is 100% remote, working from home, doesn't have say a hardware VPN router, eventually, that computer will eventually require an interactive "online" logon. In one of the worst cases, an employee had to ship their laptop across the country overnight so it could be plugged into the network and updated (because no VPN before logon).

From experience, the AnyConnect client has a setting you enable in the client config to enable the VPN option before logon. Then, in the Windows logon GUI, it would launch the normal client software window "on top of" the logon screen where the user could then interact with it with 100% normal functionality.

Presumably, since OpenVPN now uses a system service and the client essentially communicates with that service, a similar setup could be used?

[danieldjewell]

You operate VPN connection by starting/stopping/disabling the OpenVPN-Contoso service. When set to start Automatically, it will connect on boot. The Group Policy Client service does wait for a while on boot to see if any DC becomes available.

But this doesn't provide a mechanism to allow for user authentication or say 2FA? (I mean, doing client certs on smart cards/keys with PINs could even count as 2FA.) If it's running as a service it would seemingly have to use some kind of stored authentication?

What happens if say on boot it doesn't initially connect (say someone forgot to plug in a wired ethernet cable)... is there any way to trigger a reconnect without a reboot?

Optional: For laptops, I also install and create a Stunnel connection to my VPN server to port 443 to run a secondary OpenVPN TCP connection service thru it (I set its network interface higher metric than its UDP equivalent). This OpenVPN TCP over TLS/443 penetrates the most strict DPI firewalls and brings quite some "surprise" looks when my laptop seamlessly connect to my work in any conference room. :)

Nice! How's the performance? So stunnel is doing a TCP tunnel? And then it's TCP-in-TCP? (More specifically ((TLS-in-TCP)>TLS-in-TCP) for a double tunnel?) I can definitely see the need for using TCP on 443 to fool strict DPI (trying to rack my brain, can't think of any part of HTTP/HTTPS that would use UDP, so yeah). Since you kinda need the outer tunnel to be TCP, couldn't you use UDP inside for better performance? (Trying to think, TCP-in-TCP is never ideal, but UDP-in-TCP might be worse...)

[rozmansi]

But this doesn't provide a mechanism to allow for user authentication or say 2FA? (I mean, doing client certs on smart cards/keys with PINs could even count as 2FA.) If it's running as a service it would seemingly have to use some kind of stored authentication?

True. 2FA may be performed interactively only.

What happens if say on boot it doesn't initially connect (say someone forgot to plug in a wired ethernet cable)... is there any way to trigger a reconnect without a reboot?

That's quite usual when you walk into a place you have never been before and your laptop doesn't have access to WiFi yet. GP client service will stall the boot for 30 seconds (by default). After that boot will resume offline.

It depends on your .ovpn config. Fortunately, with some persist... settings it should keep reconnecting until the network is available.

Nice! How's the performance? So stunnel is doing a TCP tunnel? And then it's TCP-in-TCP? (More specifically ((TLS-in-TCP)>TLS-in-TCP) for a double tunnel?) I can definitely see the need for using TCP on 443 to fool strict DPI (trying to rack my brain, can't think of any part of HTTP/HTTPS that would use UDP, so yeah). Since you kinda need the outer tunnel to be TCP, couldn't you use UDP inside for better performance? (Trying to think, TCP-in-TCP is never ideal, but UDP-in-TCP might be worse...)

The performance was a bit slower than direct OpenVPN UDP, but still comparable: internet links were the true bottleneck. I made sure the stunnel was up-to-date, using a strong cipher, client-side checking server cert issued by the pinned root CA, and finnaly set OpenVPN to cipher none.

However, I never tried to tunnel UDP thru the stunnel.

[Gauss23]

Is there any chance of a SBL implementation for OpenVPN? Especially the version, where a box pops up and lets the user enter username and password (+optional 2FA token).
Don´t like the autostart way for various reasons: if the user is in the office, the connection is not needed and for security reasons it´s always good to have multiple separated login factors.

[cron2]

Hi,

On Mon, Sep 07, 2020 at 07:48:53AM -0700, Gauss23 wrote: Is there any chance of a SBL implementation for OpenVPN? Especially the version, where a box pops up and lets the user enter username and password (+optional 2FA token).

"someone would have to do it"... I am willing to review and test, but have no idea how such an implementation would have to be done. gert

…

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany gert@greenie.muc.de

[smartens]

Due to popular demand, I might make a wiki or blog page with step-by-step instructions. Here's something to get you going...

@rozmansi
Your setup sounds promising. I'm about to set up a docker server for our startup. Because we will work in a co-working place but still want some central user management we will have a samba domain controller container to which every laptop needs to log in on start. But such a setup with saved credentials is quite a security risk if not properly configured I would be glad if you could provide a step-by-step instruction :).

[GutsBlack]

Hello
The Fortinet client (FortiClient 6.x) also allows to launch a VPN before the login.
If the vpn fortigate is connected to the AD you can authenticate the VPN at the same time as the user.
If this is not the case you will have to enter the VPN ID and then the AD user ID

https://www.deploymentshare.com/using-forticlient-vpn-with-hybrid-aad-logon-after-autopilot-process/

My client abandoned OpenVPN + Pfsense for this reason.

[mattock]

I wonder if OpenVPN Connect supports this feature. @lstipakov any idea?

[GutsBlack]

OpenVPN Connect and Viscosity do not support this feature either. Viscosity indicated a planning for the feature but it was in 2019...

[cron2]

Hi,

On Wed, Jun 30, 2021 at 04:56:46AM -0700, GutsBlack wrote: The Fortinet client (FortiClient 6.x) also allows to launch a VPN before the login.

Starting the VPN before login is not convenient but doable, using the OpenVPN Service (openvpnsrv2). This only works for VPNs that do not require user auth, though. We have no support for "the VPN starts before login and asks for credentials" (and I have no idea how to implement that). But indeed, that would be a truly nice feature. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany ***@***.***

[GutsBlack]

(and I have no idea how to implement that).

maybe it can help you :
Zyxel use "Gina Mode in windows 7" -> https://docs.microsoft.com/en-us/windows/win32/secauthn/winlogon-and-gina
SystoLOCK use PLAP provider -> https://www.youtube.com/watch?v=XUe1Cf6ruZE

and https://docs.microsoft.com/en-us/windows/win32/secauthn/credential-providers-in-windows

other vpn and start before logon : https://www.shrew.net/static/help-2.2.x/html/Shrew%20Soft%20VPN%20Client%20Administrators%20Guide.html?VPNAccessManager1.html

other exemple : https://kb.swivelsecure.com/w/index.php/Swivel_Windows_Credential_Provider

[gitnewcomer]

Hi,
On Wed, Jun 30, 2021 at 04:56:46AM -0700, GutsBlack wrote: The Fortinet client (FortiClient 6.x) also allows to launch a VPN before the login.
Starting the VPN before login is not convenient but doable, using the OpenVPN Service (openvpnsrv2). This only works for VPNs that do not require user auth, though. We have no support for "the VPN starts before login and asks for credentials" (and I have no idea how to implement that). But indeed, that would be a truly nice feature. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany @.***

Hi @cron2, this project should help implementing this feature: https://github.com/phaetto/windows-credentials-provider
I think all that is needed is described on Appendix C on this document: https://github.com/phaetto/windows-credentials-provider/blob/master/Credential_Provider_Technical_Reference.pdf
The credential provider in our case must use the CPUS_PLAP as the CREDENTIAL_PROVIDER_USAGE_SCENARIO (https://docs.microsoft.com/en-us/windows/win32/api/credentialprovider/ne-credentialprovider-credential_provider_usage_scenario)
Here we can find more information about the credential provider: https://github.com/DavidWeiss2/windows-Credential-Provider-library
Another project for a credential provider that can be useful: https://github.com/SteveSyfuhs/CredProvider.NET
Here another project for older Windows versions (Win7): https://github.com/naveedmurtuza/CredentialProviders
Here some samples from Microsoft: https://www.microsoft.com/en-us/download/details.aspx?id=4057 and https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/CredentialProvider
Maybe @lstipakov can help us on that... :)
It would be a great improvement for OpenVPN if this would be supported! Let's make it happen! :)

[ManZosh]

In our environment we recently ditched our Cisco ASA which we leveraged the SBL module for VPN connectivity for a Netgate pfSense+ based NGFW appliance. Although this was a real nice upgrade in terms of network performance and licensing overhead, we're now missing out on the awesome functionality and manageability that Cisco's SBL afforded us. We would configure our ASA to our Windows Server's Network Policy Server (NPS) where RADIUS authentication took place, allowing us to configure various network protections and constraints through there. Packaging the SBL module with the end-user's VPN client enabled the Network Sign-In icon at the Windows Logon which gave users an incredibly simple company VPN experience. As Admins we could also push updates and changes to the overall client config and even still the SBL module at connection time would update the client-side config with the new version hosted from the VPN server/ASA.

With SBL, we could always be absolutely sure that all laptops both on-prem and remote were remaining in contact with our Windows DC at logon time, and therefore had various security GPs applied such as refusing PC logon if the domain was unavailable and disabling cached logon credentials. Nowadays, we've had to disable these policies since we haven't been able to get the native Win10 Network Sign-In client to work with the pfSense OpenVPN server... Currently we're evaluating setting up an IPsec-based VPN solution on our firewall as an alternative that seems to probably play nicer with the Win10 native Network Sign-In.

I'd be more than happy to help test out and field feedback to anyone that needs a proper test harness for an OpenVPN version of SBL, as my company sports a full Enterprise network architecture and Windows domain!! Just let me know!! :)

[phaetto]

Hey everyone,

I am the author of https://github.com/phaetto/windows-credentials-provider, a credential provider written in C# for simple login operations. I thought that I would give my 2 cents.

Firstly, what @gitnewcomer wrote is correct. There is a special implementation of credential provider that would allow the specific scenario. I have no experience however with that specific workflow.

I am working on the background in a spinoff of that project that allows auto login operations using a credential provider in unattended VMs for automation purposes. It includes a complete and tested implementation (doing that with a company on the background) and I will open source it in the next months. I am only saying this because I can provide you with a fork of that functionality and help developing a credential provider that can orchestrate that case. I am however inexperienced with the intricate details of such a VPN setup and I would probably need help for verifying and testing.

I can only do it in C# though, so let me know what you guys think.

[gitnewcomer]

I have made a proof of concept with the CheckPoint Endpoint Security Client so I could test if we could use an OpenVPN connection before Domain Logon...

My steps on Windows 11 Pro:

1. Download and install CheckPoint Endpoint Client (I have tested with version E86.00): https://supportcenter.checkpoint.com/supportcenter/portal/user/anon/page/default.psml/media-type/html?action=portlets.DCFileAction&eventSubmit_doGetdcdetails=&fileid=118725
2. Download and install OpenVPN Connect Client (didn't succeed with OpenVPN GUI): https://openvpn.net/vpn-client/
3. Enable "Secure Domain Logon" on the CheckPoint Endpoint Client options (this will activate the PLAP Provider under HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\PLAP Providers\{a7fd389f-fac9-4772-b6af-54e09f65a2a3}).
4. Edit the registry key HKLM\SOFTWARE\Wow6432Node\CheckPoint\TRAC\5.0\PRODDIR to point to the OpenVPN Connect installation directory (ex.: C:\Program Files\OpenVPN Connect\).
5. Rename the OpenVPN Connect EXE on the installation directory to the CheckPoint GUI EXE that would be started when we do a Pre-Logon (OpenVPNConnect.exe => TrGUI.exe).
6. Restart the computer and at Logon, try to click only once on the Network Logon icon: the OpenVPN Connect Client will popup and ask you to import a profile (OpenVPN Client will be run under SYSTEM user, so it will not find any profile that you imported under another user).
7. Connect to the OpenVPN Server: should connect without problems (I also tested with OneTimePassword connection).
8. Try to logon on your domain: the CheckPoint PLAP Provider will popup saying it will try to establish a secure connection, you can cancel it and logon will take place.

This is a proof of concept and not really usable for production!

Problems found:

1. If you click more than once on the Network Logon icon, you will open every time a new instance of the OpenVPN Client and make it crash.
2. Logon screen may return back to "Hit Ctrl-Alt-Delete to Logon" while still having the OpenVPN Client open.
3. After logon you can't control the VPN connection because the OpenVPN Client is running under the SYSTEM user.
4. You can see that even CheckPoint Client isn't secure enough an let you use another EXE on Network Logon. They should check a hash from the EXE or something before loading it!
5. Maybe more I can't remember right now... :)

So this is something that is doable... but I do not have the knowledge to do it...

Hope someone can make this happend so many admins out there would jump for joy! :P

[selvanair]

@ManZosh Check whether the default value of the registry key HKEY_CLASSES_ROOT\CLSID\4fbb8b67-cf02-4982-a7a8-3dd06a2c2ebd}\inprocserver32readsC:\Program Files\OpenVPN\bin\libopenvpn_plap.dll` If not fix it. I found a bug in the reg file that could have caused this not to be set.

[bjoernv]

I am working on a "Start Before Logon" setup where an OpenVPN client should be started before Windows login, but only if a Smart card is inserted.

Currently the problem is, that the Smart card needs a PIN, which can't be entered before Windows login.

I wrote a feature request for an option to save the PIN. See https://community.openvpn.net/openvpn/ticket/1485

An alternative solution would be to extend the Windows service for OpenVPN so that the service uses the OpenVPN management interface to enter the PIN from a configuration file. The current version of the OpenVPN Windows service probably can not do this.

[selvanair]

Currently the problem is, that the Smart card needs a PIN, which can't be entered before Windows login.

Starting verion 11.30 PLAP module is available and interatcive connection of OpenVPN tunnel with password/PIN/challenge response input from login screen is now possible. See #518

[bjoernv]

Could you please give a HOWTO for testing? I have OpenVPN 2.5.8 community edition installed.

And I have the compiled the Git master version of OpenVPN-GUI. The openvpn/out/build/x64-release-ossl3/ directory now contains these *.exe and *.dll files:

libcrypto-3-x64.dll
libopenvpn_plap.dll
openvpn-gui.exe
test_plap.exe

but no openvpnserv2.exe and no installer.

How I test the OpenVPN-GUI PLAP functions?

[selvanair]

It may be easier to test this using a snapshot installer for 2.6 -- see here

Otherwise, re-install 2.5.8 by selecting to install automatic service. It's not selected by default. Set to start the service automaticlaly and then start it. Copy libopenvpn_plap.dll that you built to C:\Program Files\OpenVPN\bin. Run plap/openvpn-plap-install.reg from the GUI sources as admin to register the dll. These steps are handled by the installer in snapshot builds (eventually in 2.6 release).

Then follow instructions in README -- first get persistent connections working from the GUI and then from PLAP.
Note that you will have to restart OpenVPNService if you add or modify config files in config-auto folder.

[ManZosh]

@selvanair Hi Selva! I just had a brief question for you, picking back up on all this... I installed on a new Win10Pro laptop a fresh OpenVPN client using the openvpn-master-20221216T0629-97929d16-amd64.msi you linked. I confirmed the OpenVPN service is running, alongside the interactive service (if that's even necessary for this). My profile is the same as my above comment as well, with the management lines added. The PLAP VPN button appears on the Windows Logon screen! But for some reason the client gets hung up on waiting for the management network to come up, shown below:

I don't recall having this hung management interface previously when I compiled a client from source.

Is the management interface literally the TAP-Windows Adapter V9? Trying a variety of trial & error troubleshooting steps, but if the management lines in the config file change at all, the PLAP icon is no longer visible on the Logon screen.

[selvanair]

You can test connection to management i/f by logging in and running OpenVPN-GUI. It should show profiles in config-auto grouped under Persistent Connections and will allow you to connect it. If the GUI also fails to connect to the management interface, either the management option in the config is wrong or some other program is holding a connection to that port and thus blocking it. It can also be tested by telnet 127.0.0.1 1200 where 1200 is the port specified in the management option in your config file.

Its also possible that there is a start up error when the service is bringing up openvpn process. Check the log file -- you can open it from the GUI menu or look for it in Program Files\OpenVPN\log\ where the service creates it.

BTW, now that 2.6_beta is out testing using the latest beta release (26_beta2) may be better.

[gitnewcomer]

@selvanair I've been testing the PLAP without management interface password and all worked fine.
Now that I would like to test it on our corporate environment, I have added a password file to the management interface like this:

management 127.0.0.1 8888 passwd.txt

The passwd.txt file has one line with the management interface password. I've copied the file to the same path as the ovpn (C:\Program Files\OpenVPN\config-auto), but after this, I can see the PLAP on Windows Logon screen and when I choose the ovpn profile it doesn't ask any username/password (or any OpenVPN window) and immediately shows that the connection failed.
If I try to start the connection with the OpenVPN GUI then I see a quick window opening and closing again. Log file does not log anything.
If I remove the passwd.txt parameter from the management configuration, it works like expected.
Am I missing something or doing something wrong?
Thanks again for all you work for making this PLAP a reality! :)

[ManZosh]

@selvanair

BTW, now that 2.6_beta is out testing using the latest beta release (26_beta2) may be better.

Alrighty, please ignore my previous comment! Something was funky with that particular laptop's network stack that was preventing the management interface from being built. I tested this on a new laptop and everything works beautifully!! Here are the steps I followed...

1. Cleanly fresh install OpenVPN GUI v2.7git (beta?), ensure the Pre-Logon Access Provider (PLAP) is enabled for install.
2. Once installed, open services.msc and change the OpenVPNService's Startup Type to Automatic.
   • (is this an available directive in the .msi installer?)
3. Ensure the following new configuration lines are appended to our OVPN profile:
   • management 127.0.0.1 1200
   • management-hold
   • management-query-passwords
4. Insert the modified profile and its dependencies into ..\OpenVPN\config-auto, there should not be a profile in the regular config folder unless you have an otherwise need for it.
5. If you sign-out of the user session or reboot, via the newly implemented PLAP there's now a 4th icon available on the bottom-right of the Windows Logon screen which reads Network sign-in on mouse hover. Clicking this shows the connection the OpenVPN service built where we can simply click the connect arrow and the user can then sign-in using (atleast in our case) their LDAPS credentials.
6. Start the OpenVPNService, on startup this service checks the config-auto folder for any connections it should automatically build.

The connection is immediately visible from the OpenVPN server. With this, we can now achieve a Windows SysAdmin's dream of having a laptop asset residing on a foreign untrusted network be available to our Domain Controller and Remote Assistance software agent before the user is even signed into their Windows user profile!

Only 3 small bugs I've noticed through successively testing this...

• At the Windows Logon screen, if you proceed through to Sign-In (or Ctrl+Alt+Del) and wait for the default 2-minute timeout where it throws you back to the Lock screen wallpaper, if you proceed through to Sign-In a second or successive time the PLAP icon is no longer available and (atleast as an end-user) you can't bring it back unless you reboot.

• If you connect to the VPN via PLAP, the PLAP icon then shows an 'X' on it providing you the obvious ability to now Disconnect your VPN session. However, if you sign-in and then sign-out of the Windows user profile, end up back at the Lockscreen, and proceed through to sign-in again, the PLAP icon no longer has the 'X' anymore and appears as if you can initiate a new VPN connection. But as evident from the OpenVPN Server's client statuses, the VPN connection is still alive and active! If you attempt to click the PLAP again, and hit the connect arrow on your auto-config'd profile, it immediately shows you a Connected message again. This may have potential to confuse end-users.

• At anytime, if the user does decide to use the PLAP icon with an 'X' on it to kill the VPN connection, the icon just then disappears on-click and does not give you ability to connect to the VPN again unless you reboot the system.

So this is just incredible and I'm stupidly excited to soon use this in a production capacity in our environment. Please let me know if I can be of any assistance!! Can take GIFs of any of the bugs I mentioned as well if necessary.

[selvanair]

@ManZosh

Thanks for the feedback

Only 3 small bugs I've noticed through successively testing this...

• At the Windows Logon screen, if you proceed through to Sign-In (or Ctrl+Alt+Del) and wait for the default 2-minute timeout where it throws you back to the Lock screen wallpaper, if you proceed through to Sign-In a second or successive time the PLAP icon is no longer available and (atleast as an end-user) you can't bring it back unless you reboot.

This I cannot reproduce and should not happen. Unless the dll crashes which would be a bug. But I have not seen it.

• If you connect to the VPN via PLAP, the PLAP icon then shows an 'X' on it providing you the obvious ability to now Disconnect your VPN session. However, if you sign-in and then sign-out of the Windows user profile, end up back at the Lockscreen, and proceed through to sign-in again, the PLAP icon no longer has the 'X' anymore and appears as if you can initiate a new VPN connection. But as evident from the OpenVPN Server's client statuses, the VPN connection is still alive and active! If you attempt to click the PLAP again, and hit the connect arrow on your auto-config'd profile, it immediately shows you a Connected message again. This may have potential to confuse end-users.

I think this is a limitation of PLAP. It does not show the connected icon without going through a connect cycle and does not remember that state from session to session. Within a session (even after the 2 min timeout) it should remember it, I believe. I do not think we can do anything about it. If you have seen any other PLAP offerings (such as anyconnect) behave differently, I can take a look again. One thing we could possibly do is to show a connected checkmark on the tile but its not easy to implement, so unlikely to happen any time soon.

• At anytime, if the user does decide to use the PLAP icon with an 'X' on it to kill the VPN connection, the icon just then disappears on-click and does not give you ability to connect to the VPN again unless you reboot the system.

Looks similar/related to your first point. Again, this should not happen and I cannot reproduce. May be you can open a separate issue with details of OS and OpenVPN version etc.

[selvanair]

@gitnewcomer Have you seen this mis-behaviour on login-screen time-out or after clicking PLAP disconnect button reported by @ManZosh above? Sounds like a bug in the dll, but I cannot reproduce it.

[ManZosh]

@gitnewcomer Have you seen this mis-behaviour on login-screen time-out or after clicking PLAP disconnect button reported by @ManZosh above? Sounds like a bug in the dll, but I cannot reproduce it.

Hey @selvanair, it's worth mentioning the only difference there could be between your test system and mine is that the laptop I've been using is indeed joined to our production Windows Domain and therefore has many policies applied. Now I'd never think any of our policies could be affecting this, but if in your experience the PLAP icon indeed persists through Logon timeouts, then it could just be something deep in the bowels of our particular Group Policy that might be affecting these PLAP phenomena I'm seeing.

I have other laptops in inventory I can put a totally fresh install of Win10Pro onto, this time I won't join it to my domain at all. I'll just run through the brief setup steps and try again and see if those bugs persist. If not, then it must be something we're flicking on or off in GP on domain-joined PCs.

Lemme get to that after the holiday and I'll be sure to report back here!

[gitnewcomer]

@gitnewcomer Have you seen this mis-behaviour on login-screen time-out or after clicking PLAP disconnect button reported by @ManZosh above? Sounds like a bug in the dll, but I cannot reproduce it.

Hi @selvanair, first of all, I wish you and all here a Happy New Year! :)
Sorry for my late reply, but I was on holiday between Christmas and New Year without access to my git account.
To the problems reported by @ManZosh, I didn't remember having them, but I could test it on my test lab (computer joined to a domain) and report back as soon as I can...

[MP230]

Hello Git-OpenVPN-Developer,
I want to try the new "Pre-Logon Access Provider" Feature with the 2.6 RC "OpenVPN-2.6_rc1-I001-amd64.msi".
With a GUI customize installation it works fine when I manual checked "Pre-Logon Access Provider".
But I doesn't find any installation Parameter for an silent MSI istallation.
I tryed it with "select_service=1" without sccess.

Can anyone help me?

[lstipakov]

Can anyone help me?

This should work:

c:\Users\lev\Downloads>msiexec /i "OpenVPN-2.6_rc1-I001-arm64 (1).msi" /quiet ADDLOCAL="OpenVPN.GUI,OpenVPN.GUI.OnLogon,OpenVPN.Service,OpenVPN.PLAP.Register,OpenVPN.Documentation,OpenVPN.SampleCfg,Drivers,Drivers.OvpnDco,Drivers.TAPWindows6,OpenSSL,EasyRSA" /L*V install.log

You might want to remove Drivers.OvpnDco if you install on pre-Windows 10 system.

[gitnewcomer]

@gitnewcomer Have you seen this mis-behaviour on login-screen time-out or after clicking PLAP disconnect button reported by @ManZosh above? Sounds like a bug in the dll, but I cannot reproduce it.

Hi @selvanair and @ManZosh,

I had some time to test the PLAP again on my test lab (computer is running Windows 11 Pro with domain joined, so Windows 10 Pro could behave differently).
I have used the last OpenVPN beta version from 17/01/2023 found here OpenVPN Development Snapshots.

At the Windows Logon screen, if you proceed through to Sign-In (or Ctrl+Alt+Del) and wait for the default 2-minute timeout where it throws you back to the Lock screen wallpaper, if you proceed through to Sign-In a second or successive time the PLAP icon is no longer available and (atleast as an end-user) you can't bring it back unless you reboot.

I can not reproduce this. If I start a OpenVPN sign-in process (where it asks me username and password from OpenVPN) and wait some time, I will get to the Windows lock screen. If I try to sign-in again to OpenVPN, the PLAP shows again like expected.

If you connect to the VPN via PLAP, the PLAP icon then shows an 'X' on it providing you the obvious ability to now Disconnect your VPN session. However, if you sign-in and then sign-out of the Windows user profile, end up back at the Lockscreen, and proceed through to sign-in again, the PLAP icon no longer has the 'X' anymore and appears as if you can initiate a new VPN connection. But as evident from the OpenVPN Server's client statuses, the VPN connection is still alive and active! If you attempt to click the PLAP again, and hit the connect arrow on your auto-config'd profile, it immediately shows you a Connected message again. This may have potential to confuse end-users.

On Windows 11 I don't see any "X" on the PLAP icon after successfully connect to OpenVPN. If I click on the PLAP icon again, I only can try to sign-in again an I'm presented with a message that I'm already connected. I do have a new icon near Network Sign-In that allows me to disconnect the active OpenVPN connection if still connected. Maybe this was improved on Windows 11.

At anytime, if the user does decide to use the PLAP icon with an 'X' on it to kill the VPN connection, the icon just then disappears on-click and does not give you ability to connect to the VPN again unless you reboot the system.

As I do not see the "X" on PLAP icon on Windows 11, I can't reproduce this behavior. But if I use the new icon to disconnect the active OpenVPN connection I'm able to connect again. As said above, this can be an improvement of Windows 11.

If I have some time (having some projects running right now at work), I will setup a new computer with Windows 10 Pro on my test lab to test this steps again...

[MaartenJB]

I've tested it on Windows 10 (22H2) with this build: openvpn-master-20230309T0821-83847414-amd64.msi and as ManZosh described.

It's works pretty good. I was able to connect.

There's one thing what would be a bit problematic is that the profile needs to be in the program files folder instead of the users folder. So if that's gonna be the case in the release version, this would still not be a viable option for me as users need to be able to update the certificates themselves.

[selvanair]

The feature is already released in 2.6.0 and 2.6.1.

As SBL/PLAP access is before user logs in, we have no idea of who the "user" is and what privileges they have to pickup configs from user's folder. This feature is mainly useful for computers in an AD domain, and the best option is to make use of facilities that AD provides: push certificates to the machine store of client computers via group policy, push files and updates instead of asking the user to copy them.

If such a centralized management is not an option, here is an untested workaroud. Put the configs in a user-accessible folder and edit the registry key HKLM\Software\OpenVPN\autostart_config_dir to point there. Restart OpenVPNService for changes to take effect.

Keep this location district from where config_dir points to or %USERPROFILE%\OpenVPN\config as configs in those locations are special for the GUI, and using them for SBL/PLAP will cause conflicts.

Another option is to provide necessary access rights to the user for C:\Program Files\OpenVPN\config-auto and its sub-folders so that users can update configs and other files in there. (Edit: do not use any of these options as they are insecure.)

However, if you are using Windows certificate store for certificates and keys (cryptapicert option), this will not work as the certificate has to be in the machine store which a limited user has no write access to. Again, unlike the GUI, picking certificates from user store is not an option for PLAP, as user is unauthenticated at that point. Inline and external files can be updated with the above, but users will have to do so by directly writing to the correct location --- the GUI's import option will not access these folders.

Managing using AD policies is the best option.

[MaartenJB]

Ok nice, Thanks :-)

Ah yes, it's before user logon, Thanks for the detailed answer!

[virtualizer117]

This page is freakin' awesome, so thank you (@selvanair) and everyone else for this incredible timeline of progress. If I found this page looking for a solution to accessing OpenVPN prior to logon, I'm sure others will, too, so I thought I'd add my two cents.

I'm using the OpenVPN-2.6.1-I001-amd64.msi release (found here) on a Windows 10 Pro machine (not domain-joined YET -> domain logon without cached credentials is the end goal). The install itself is flawless, and I went and followed the steps outlined by @ManZosh:

1. Cleanly fresh install OpenVPN GUI v2.7git (beta?), ensure the Pre-Logon Access Provider (PLAP) is enabled for install.
   => (I used the 2.6.1 release mentioned above)
2. Once installed, open services.msc and change the OpenVPNService's Startup Type to Automatic.
   => (actually defaulted to "Automatic" for me)
3. Ensure the following new configuration lines are appended to our OVPN profile:
   * management 127.0.0.1 1200
   * management-hold
   * management-query-passwords
   => (@selvanair also suggests adding * auth-retry interact, though I think it was mentioned that this is not 100% necessary).
4. Insert the modified profile and its dependencies into ..\OpenVPN\config-auto, there should not be a profile in the regular config folder unless you have an otherwise need for it.
5. If you sign-out of the user session or reboot, via the newly implemented PLAP there's now a 4th icon available on the bottom-right of the Windows Logon screen which reads Network sign-in on mouse hover. Clicking this shows the connection the OpenVPN service built where we can simply click the connect arrow and the user can then sign-in using (at least in our case) their LDAPS credentials.
6. Start the OpenVPNService, on startup this service checks the config-auto folder for any connections it should automatically build.
   => (this is the part that I got hung up on--see below)

===================
@Marvo2011 (different thread) and @ManZosh (this thread) both mentioned/provided screenshots of issues where the OpenVPN PLAP window console window hangs with the message "Waiting for the management interface to come up". @ManZosh addresses this issue and actually provides the suggested fix (also referenced by @selvanair here when he references starting the OpenVPNService.

In my case, the OpenVPNService was already running by default, so I had to restart it in order for OpenVPN to recognize the config file/options properly (note: @selvanair mentioned this was necessary if you copy-pasted the config file into the config-auto directory).

That being said, @ManZosh, I know I'm super late to the party, but you said there was an issue with the way the network stack was built on the computer that was preventing the management interface from being built--I'm guessing you would have already restarted the OpenVPNService, so that was actually a different problem, I guess. Did you ever go back to that particular computer, do any sort of wipe, and try it again? Just curious in case I ever come across a similar situation in the future.

I'm running some more tests now; I'll provide any updates if they end up being worthwhile. I'm seriously impressed by how far this has come, so thanks everyone for the amazing effort.

(BTW this is only my third post on GitHub--recent join--so thanks everyone for putting up with my terrible formatting; I will improve :D).

[virtualizer117]

Saw this from @MaartenJB:

There's one thing what would be a bit problematic is that the profile needs to be in the program files folder instead of the users folder. So if that's gonna be the case in the release version, this would still not be a viable option for me as users need to be able to update the certificates themselves.

@selvanair's solution here would work:

If such a centralized management is not an option, here is an untested workaroud. Put the configs in a user-accessible folder and edit the registry key HKLM\Software\OpenVPN\autostart_config_dir to point there. Restart OpenVPNService for changes to take effect.

Keep this location district from where config_dir points to or %USERPROFILE%\OpenVPN\config as configs in those locations are special for the GUI, and using them for SBL/PLAP will cause conflicts.

Another option is to provide necessary access rights to the user for C:\Program Files\OpenVPN\config-auto and its sub-folders so that users can update configs and other files in there.

Another option if you don't want to edit registry keys or change folder permissions is to create symbolic links (using the "mklink" command on Windows) in the config-auto folder mapping back to .ovpn files (and certs + keys, I guess, if you're using those, too) in another folder accessible by the user.

Hope that helps somebody! :)

[selvanair]

Be very careful if you do any of these things: configs in config-auto or linked to there are started as SYSTEM. If there are scripts, those will also run as SYSTEM allowing users to essentially run anything as SYSTEM.

[Luke-Williams9]

Can someone explain quickly how I can test PLAP? I do not see any icon for it on the logon screen. I'm using OpenVPN client 2.6.6, and confirmed that PLAP/gui.onlogon is installed (all components are installed)
I've put a test configuration in the config-auto folder, restarted the services, but there is still no icon. What am I missing?

[selvanair]

I've put a test configuration in the config-auto folder, restarted the services, but there is still no icon. What am I missing?

See this section and the one following it in README
And this: #625 (comment)

[cyacelga]

Hello, could someone please help me so I can launch the automatic OpenVPN connection from the hidden icon, I would appreciate it.
I have passed the username and password through a txt file, now I require the connection to automatically start when logging into Windows 11.
thank you
start .\openvpn-gui.exe --silent_connection 1 --connect archivo_config.ovpn
don´t found this line, please help me.

[selvanair]

start .\openvpn-gui.exe --silent_connection 1 --connect archivo_config.ovpn
don´t found this line, please help me.

Instead asking an unrelated question in a closed issue, open a new issue explaining what you are trying to achieve. I do not see the need for what you are doing as the GUI can be started automatically on login and connections will autostart if you do not actively disconnect on logout.