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 [email protected]

[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]

(link updated) @gitnewcomer I had worked on this on and off over the years, but I've been holding-off to release it for several reasons including (i) IMO, PLAP UX is not very user friendly (ii) as these dlls are loaded by LogonUI before logon, any bug can badly lockup the machine etc.

I'm also very reluctant to put a major chunk of the GUI-code loaded into a dll running as system -- I know many commercial implementations out there run the whole client GUI process from the logon screen, an approach that is flawed in my view.

By the way, please do not post links to sample implementations unless they are compliant with GPL v2 or later. I'm not a licensing expert, but I avoid MS samples as some of those are released under MS-PL which is not GPL compatible -- don't want to end up with a derived work that will conflict with GPL.

Now, with all those caveats out of the way, here is an implementation to test out and provide feedback. Implementing this based on MSDN docs is not easy, so use at your own risk.

PLAP module for OpenVPN See the README in the zip (link above) on how to test.

After logging in, if you want the GUI to show the connection, use openvpn-gui.exe from build-artifacts of PR #512. Currently released GUI versions have no ability to connect to prestarted instances.

WARNING: A crash in the plap dll will lock you out of the system. You may need to reboot into safe mode and edit the registry to get back in, or have some other backup plan.

[selvanair]

fwiw a screenshot of the plap-login screen