Restrict OpenVPN logins to one group with a PAM policy

Keep every account able to log in normally, but allow only one group to use the VPN. PAM can express that difference without a second password store, and the OpenVPN plugin can be pointed at a service that contains only the checks you intend. The trick is building that service without accidentally inheriting a system-wide stack.

The walkthrough here starts from the plugin's service name, builds a policy, and then tests the three outcomes that matter: a member, an outsider with a valid password, and a bad credential.

Why a separate PAM service

The auth-pam plugin takes a service name as its argument. That name selects a file under /etc/pam.d, and the stack in that file is what runs during a VPN login. If you pass the same name a system-wide login uses, you inherit every decision in that stack, including ones added later for unrelated reasons.

Create a dedicated service instead. Start from a working stack that already authenticates against the intended backend, such as a local password file, SSSD, or a directory service, then add the eligibility rule. Copying two lines into an empty file is the common mistake: password expiry, account locking, and other checks may live in the stack you did not copy.

Separating the service also limits blast radius. A VPN-only rule in a shared stack can deny SSH or console access for everyone, which turns an access change into an outage.

Writing the group rule

The eligibility check belongs in the account phase, after the credential has been verified. A rule such as account required pam_succeed_if.so user ingroup vpnusers allows processing to continue only when the authenticated user is a member of that group.

That line is a fragment, not a complete service. Integrate it where every accepted path reaches it, and check the control flags around it. A sufficient or jump control earlier in the stack can end processing before your rule runs, which turns the restriction into a suggestion.

Do not add use_uid by habit. Without it the module evaluates the user being authenticated; with it the module evaluates the account under which the OpenVPN process runs, which is normally root or a service account and therefore not the person logging in.

Group membership comes from the system's identity resolution, not from a name you recognize. For directory users, confirm that the same backend answers group queries for that user, because a local group with a familiar name is a different object from the directory group of the same name.

Order and identity traps

Place the group rule after the authentication stack and after any check that must still apply, but before or alongside the account checks you are keeping. PAM evaluates modules in file order, and the control value on each line decides whether a failure is final.

Watch for duplicated stacks. A common pattern is an include that already contains an account rule, followed by your own group rule, which produces two decisions where you expected one. Read the included file, not only the one you edited. A quick way to see the effective order is to read the file from top to bottom and note each control value.

Keep the other admission requirements intact. A successful password does not replace certificate checks, a second factor, or post-connection authorization, and this policy is not a substitute for any of them. It only decides whether the account is eligible to be considered for VPN access.

Testing members, outsiders and bad passwords

Test three cases before you consider the policy done. A member connects successfully. A valid account outside the group authenticates its password but is denied VPN access. A wrong password for either account is rejected at the authentication stage, not by the group rule.

Look at the client-visible error and the server log together, because both failures can look similar to the person connecting. The distinction matters for support: an outsider with a correct password needs a group change, while a wrong password needs a credential reset.

Keep a second session open while you edit PAM, and verify ordinary SSH login after the change as well. The point of the dedicated service is that system login should be unaffected, and the only way to know is to test it.

If something breaks, restore the previous service file from a copy. The rule you want is simple to state: membership makes an account eligible for VPN access, and every other required check still applies.