Adding a User to a VPN Group Doesn’t Grant Access by Itself
Group membership is one condition, not a permission. Watch what the gateway actually matched, read the accept or deny record, and test both outcomes.
You put the account in the right group, the login succeeded, and the connection is still refused — or it connects and reaches nothing useful. The usual reflex is to add the user to more groups until something gives, which is how organizations end up granting far more than the ticket asked for. Group membership is one input to an authorization decision, never the decision itself: a gateway collects a handful of facts about the session, matches them against ordered policy, and only then decides what that session may touch. If a different condition failed, editing the group changes nothing except your exposure. Here is how the decision is actually assembled, where membership stops being enough, and the check that tells you which failure you are looking at.
Group membership is a condition, not a permission
In RADIUS the group arrives as an authorization attribute, and attributes describe the session rather than grant it. The server answers with Access-Accept or Access-Reject; on accept it may attach Filter-Id, Class, or the tunnel attributes from RFC 2868, and the network gear on the other end interprets those however its vendor decided. Nothing in the protocol maps a group to full access. That mapping is written by whoever configured the policy on the gateway or the network access server, and it can be as narrow as a single host.
Which is why an identical group name behaves differently on two systems. Microsoft NPS assembles network policies from conditions, constraints and settings and evaluates them in a configured order. OpenVPN Access Server has its own group and access-rule model, while a community OpenVPN server often delegates the whole question to a client-connect script or a client-config-dir file. Each consumes a group; none shares another’s precedence logic. A rule set copied between them proves nothing about the one you are debugging.
The rule that matched decides, not the group you expected
Most engines stop at the first policy that matches, or at the most specific one. If policy 3 denies and policy 7 allows, a session can fail without ever reaching the rule that would have let it through. Ordering is a real setting on NPS and on most network access control products, and it drifts when policies are added over years. Someone raises a deny policy to the top to contain an unrelated incident, and a group that worked last quarter stops working.
Conditions that ride along with the group are the other half of the problem. Device posture, authentication method, MFA completion, source network, certificate subject, or a time-of-day window can all sit in the same policy. When one of them is unmet the policy does not match, the engine falls through, and a default deny applies. From the user’s seat this looks like the group being ignored; from the engine’s seat the group was never consulted.
Directory details produce the same illusion. A policy that matches on Windows group membership reads the SIDs in the user’s token, and only security groups are enumerated there — a distribution group never appears. A user’s primary group is carried in its own field rather than the enumerated list, so a policy pinned to that group can silently fail. Renamed groups and cross-domain SIDs add translation steps that fail quietly when a trust is one-way.
Read the accept or deny record before you touch a group
Ask one question first: did the request reach the authorization stage at all? On NPS the answer is already in the event log, where 6272 records a granted access, 6273 a denial, and 6274 a request the server discarded before evaluating policy. Those three numbers split the problem into three different investigations, and only one of them is about groups.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
When the log is out of reach, question the server directly and read what it returns. A reply that carries no Filter-Id and no tunnel attributes tells you the server treats the session as unremarkable and the gateway is applying rules of its own. A reply that carries attributes the enforcement point does not implement is a different fault: authorization passed and the device that was supposed to act on it ignored the result.
radtest alice 'password' 10.0.0.5 0 testing123Compare the returned attributes against the ones the gateway documents, not against what the group name suggests. That comparison usually separates a policy problem from an enforcement problem before anyone edits a group.
A group change is not retroactive
Authorization attributes are returned once, when the session is authenticated. The gateway stores them on the session and does not re-read the directory for every packet, which is exactly why an established session keeps working after you remove someone from a group. It is also why a new session can fail while an old one still runs, and why two users with identical group lists can end up with different results.
To make a change take effect you need a new authorization decision, not just fresh keys. Where the server supports RFC 5176 dynamic authorization, a Disconnect-Request or CoA-Request to UDP 3799 forces the session to be re-evaluated; otherwise disconnect the client and let it reconnect. Renegotiation refreshes the tunnel keys and normally leaves the authorization result untouched, so treating it as a permissions refresh produces contradictory test results.
Fix the condition, not the group
Once you know which policy fired, the repair is usually small: reorder a deny that shadows the intended allow, add the missing device or MFA condition to the policy you meant to match, or write a narrow rule for the one resource instead of promoting the user into a group that carries ten others. Widening membership to clear a ticket is the expensive version of the same fix, and it is how a support shortcut becomes a standing exception that nobody reviews.
A short loop keeps the change honest:
- Reproduce the denial with the original account and write down the event ID before changing anything.
- Change one object — a policy order, a single condition, or one group — and record which one.
- Open a fresh session, confirm the grant appears in the log, and confirm the resource actually opens.
- Test a user who should still be refused, so the fix did not widen the policy by accident.
If the grant is correct and the resource still will not open, the problem moved to routing or name resolution the moment authorization succeeded. Keep those two failures apart and the next ticket takes minutes instead of an afternoon.