The Active Directory Problem MSPs Keep Solving the Hard Way

If you manage Windows environments for multiple clients, you've developed a mental model for the ticket that's about to come in. The user says they can't log in. You ask a few questions. Domain-joined machine, working remotely, VPN client needs to be running first, but they can't get into Windows to start it. You've handled this before. You have a script.

The question worth asking is: why do you still have a script for this?

The Ticket That Shouldn't Exist

The remote Windows login problem in Active Directory environments is well understood. It's also persistent — not because there's no solution, but because the solutions most MSPs reach for either require significant infrastructure investment or involve telling clients to accept a degraded experience.

The infrastructure investment path is always-on VPN (a secure remote access approach). It works, but it's expensive to run, complex to provision across multiple client environments, and overkill for clients who just need VPN up before login. You're adding licensing, management overhead, and client conversations about cost for a problem that most users encounter once a week at most.

The degraded experience path is cached credentials and a two-step login process: enter credentials, get logged in via cache, launch VPN, re-authenticate to anything that failed. This works until it doesn't — cached credentials expire, users travel somewhere new, someone forces a password reset. Then it's a support ticket, and sometimes an emergency.

Neither solution closes the problem cleanly. Both require ongoing management. And clients don't understand why, in a world where their phone connects to everything seamlessly, their work laptop requires a workaround to log in from home. We've covered the full breakdown of why this keeps happening and why standard workarounds fall short.

What Windows PLC Enables for Your Clients

OpenVPN's Windows Pre-Login Connect (PLC) is a capability that addresses this at the right layer — the Windows sign-in screen itself, before any user session exists.

The mechanism is PLAP (Pre-Login Access Provider), which is built into Windows 10 and 11. PLC integrates with it to show a "Network Sign-in" icon at the lock screen. A user clicks it, selects a profile, authenticates (with MFA, SAML, or standard credentials), and the VPN tunnel comes up. They then sign in to Windows normally. Active Directory sees the login exactly as it would from inside the corporate network. GPOs apply. Logon scripts run. Password changes work. (For environments using Active Directory LDAP authentication with OpenVPN Access Server, PLC works seamlessly alongside your existing configuration.)

For your clients, this means the problem simply goes away. No workaround. No user education. No explained-but-still-annoying two-step login.

For you as an MSP, a few things follow from that:

• Fewer support tickets. The remote login/cached credentials failure mode is a recurring ticket category. PLC eliminates the root cause rather than addressing the symptom.

• Cleaner policy enforcement. Group Policy Objects and logon scripts that your clients rely on for device management, software deployment, and security settings run reliably at login. This matters when you're enforcing security baselines across client fleets.

• Consistent experience across locations. Whether a user is at home, in a hotel, or at a client site, login behavior is the same. That consistency reduces the cognitive overhead for both users and your helpdesk.

• Admin-controlled profiles. System profiles for PLC are deployed via command line and aren't end-user configurable. You control what's available at the sign-in screen. Users can't add, remove, or change profiles. That's the right posture for an MSP managing client security.

Why This Is the Right Time to Bring It to Clients

Windows PLC is a recent addition to OpenVPN Connect (available in version 3.9+), which means many of your clients with existing OpenVPN deployments are already close to having access to this; they may just need an update. If you've already had the conversation with prospects about Windows Server and Active Directory challenges, this gives you a concrete, demonstrable answer to a problem they already feel.

This isn't a feature that requires rearchitecting anything. It deploys on top of existing OpenVPN infrastructure, it's compatible with the authentication methods your clients already use, and the configuration lives in a manageable place. For multi-tenant MSP environments, that matters. Learn more about the OpenVPN MSP partner program.

The clients who benefit most are SMB and mid-market organizations with remote or hybrid workforces running domain-joined Windows machines. If that describes a large portion of your book of business, Windows PLC is worth putting in front of them.

Talk to our team about deploying Windows PLC for your clients.