One User Cannot Sign In to the VPN: An Ordered Diagnosis

When one person fails to connect while the rest of the team keeps working, the useful question is not what is broken but which layer disagreed. Sign-in is a chain: the client starts, the gateway answers, an identity is asserted, a second factor is satisfied, policy is evaluated, and only then does traffic flow. A break anywhere in that chain reaches you as the same sentence from the user, so the first job is to find the link that actually failed.

Treat the report as a starting point rather than a diagnosis. The checks below run cheapest first, and each one is written to end the investigation when it fails.

Pin down the stage and the timestamp

Write down four things before touching any configuration: the client and its version, the exact wording on screen, the minute of the attempt, and the network the person was on. The wording carries real information, because a rejected credential, an unanswered gateway and a completed sign-in that still cannot open an internal page are three different problems with three different owners. Note whether the client produced a local log line, since a client that never sent a packet has nothing to add to a server-side search. With the timestamp recorded, every later query becomes a lookup instead of a hunt.

Stop guessing passwords at this point. Where the account has a retry limit, a burst of quick attempts can lock it and add a second, artificial fault on top of the real one. Record how many attempts were already made, so a lockout is not later mistaken for a fresh symptom. A locked account also removes your ability to tell a wrong password from a rejected policy, since both arrive as a refusal.

Read the identity event for that single attempt

Ask the administrator to pull the authentication record that matches the minute you recorded. In a Windows NPS deployment, Microsoft's NPS troubleshooting guidance documents rejection event 6273 together with the reason code that travels with it, which usually separates an unknown user, a bad credential, a policy mismatch and a call dropped for an unrelated reason.

An empty result is information too. If nothing reached the identity service, the attempt died earlier: a stale gateway address in the profile, a listener the client cannot reach, or a host that was decommissioned while the profile lived on. If the record exists and reports success, the credential is not the problem and the argument moves to authorization or to routing behind the gateway. Those two outcomes point in opposite directions, which is why the log search has to happen before anyone reinstalls a client.

Keep the reason code in the ticket. That one field turns the next occurrence into a five-minute lookup rather than a repeat investigation. Pair it with the client version, because a code that appears on one build is a different conversation from one that appears on every build.

Change one condition at a time, within policy

The temptation is to reinstall the client, reset the password and move the laptop to another network in a single pass. That sometimes fixes the symptom and always destroys the evidence. Pick one permitted swap instead: the same person on a second enrolled device, or an approved test identity on the same device. Each swap answers exactly one question, so a success narrows the fault to the side you changed instead of blaming the VPN as a whole.

Do not borrow a colleague's credentials to make this comparison. Use a test identity through the supported process, and never copy a device key or skip enrolment because it would be quicker. Where policy forbids a swap entirely, that restriction is part of the system under test and belongs in the record rather than in a workaround.

Confirm the repair on the original path

When the broken link is identified, repair that link alone and repeat the original attempt: same person, same device, same network, same application. A test account that connects from the admin VLAN proves the gateway is alive, and it proves nothing about the user's Tuesday morning. Ask the user to perform the action that failed rather than a simpler one, since a successful ping says little about a rejected file share.

Close the ticket with what was ruled out and what changed. That note is the difference between a one-off rescue and something the next engineer on call can reuse.