Picture this: A remote employee turns on their laptop Monday morning. They need to connect to the VPN before they can authenticate against your domain controller — but they need to be logged in to Windows to launch the VPN client. It's a catch-22 that IT teams have been duct-taping around for years.
If you're running a Windows domain environment with remote workers, you've almost certainly seen the symptoms: help desk tickets about "can't log in," users stuck at the Windows lock screen, logon scripts that silently fail because the network wasn't there yet. The root cause is almost always the same thing — a gap between when Windows needs domain access and when the VPN tunnel actually exists.
The Problem Is Structural, Not a Configuration Error
Active Directory authentication isn’t like local account authentication. When a domain-joined machine tries to validate a user’s credentials, it needs to talk to a domain controller. If that domain controller is on your corporate network — and your remote employees connect via VPN — there’s an ordering problem baked into the login sequence itself.
The machine boots. Windows reaches the sign-in screen. The user types their credentials. Windows tries to authenticate against the domain. But the VPN client hasn't launched yet — it can't, because no one is logged in to start it. The domain controller is unreachable. Windows either fails the login outright, falls back to cached credentials (if they're still valid), or hangs.
This plays out in several ways IT teams know well:
Cached credentials expire. Windows caches domain credentials locally, but only for a limited number of sign-ins. For users who travel or work from different locations, those cached credentials age out. The next time they try to log in remotely, there are no valid cached creds and the domain controller is unreachable. They're locked out.
Logon scripts and GPOs don't run. Group Policy and logon scripts depend on network connectivity at login time. Without VPN up before sign-in, those scripts run late or not at all — leading to missing drive mappings, failed software pushes, and inconsistent policy enforcement that's hard to diagnose.
Password change becomes a support event. Users forced to change their domain password face a particularly bad situation. Windows needs to contact the domain controller to process the change. Without a VPN, that can't happen. Users end up calling IT just to change a password.
The Workaround Isn't Working
Most organizations handle this in one of two ways, and both create their own problems.
The first approach is telling users to sign in with cached credentials, then connect to the VPN from within Windows, then re-do whatever failed. This works if cached credentials are valid and nothing critical broke at login time. It's also a support burden and creates unpredictable behavior that erodes user trust in the system.
The second approach is deploying an always-on VPN. This keeps the tunnel up continuously, which solves the login-time problem — but comes with its own overhead. Always-on VPN requires more licensing, more infrastructure planning, and more ongoing management. It’s often more than the problem demands.
There's a middle ground that most IT teams don't know is available.
Connect Before Login — Without Always-On Complexity
OpenVPN’s Windows Pre-Login Connect (PLC) is designed specifically for this gap. It uses a Windows capability called the Pre-Login Access Provider (PLAP) — built into Windows 10 and 11 — to bring up a VPN connection at the sign-in screen, before any user account is involved.
Here’s what that looks like in practice: the user arrives at the Windows sign-in screen and sees a “Network Sign-in” icon. They click it, select their VPN profile, authenticate (including MFA or SAML if your environment requires it), and the tunnel comes up. Then they sign in to Windows normally. Active Directory authentication works exactly as it would on a wired corporate network. GPOs apply. Logon scripts run. Password changes go through.
No always-on VPN infrastructure. No persistent tunnel you have to manage. No change to how users authenticate once they're in Windows. Just a clean handoff.
Learn more about Windows Pre-Login Connect.
What This Means for Your Environment
For IT teams managing domain-joined Windows fleets with remote workers, PLC closes a gap that workarounds don’t actually fix — they just hide it until something breaks. If your users are on Windows 10 or 11 and you’re running OpenVPN Connect 3.9 or later, you already have what you need to deploy this.
The configuration is admin-driven (profiles are deployed as system profiles via command line, not imported by users), which means you control what’s available at the sign-in screen, and users don’t need to do anything differently.
If the scenarios in this post sound familiar, Windows Pre-Login Connect is worth a closer look.
