Enrolling a VPN User: Find the Identity Owner First

Someone asks for VPN access, and the first instinct is to run adduser on the server. That instinct is right only in a narrow set of deployments. Before creating anything, open the server's configuration and find out which product runs there and where it validates credentials, because the account may live in a product database, in an identity provider, or in the host's own authentication stack. Creating the wrong kind of account leaves the person with a working login and no tunnel.

A client profile that says OpenVPN describes the protocol, not the identity system behind it.

Start From the Server, Not From adduser

Identify the product first. Community OpenVPN is the daemon plus whatever authentication you wired into it, while Access Server is a product with its own user layer. Ask for the configuration, the unit name and the package list, and check whether a web interface exists for user management. Then look at how the deployed profile expects clients to prove who they are: a certificate, a username and password, or both. That answer names the system that owns the account.

Only after that does the phrase creating the user mean anything. In a certificate-only deployment it means issuing a device identity through the approved process, and a Unix login changes nothing. In a password deployment it means the backend that actually validates the password.

Four Backends, Four Places to Create the Account

Access Server's local authentication keeps accounts in its own database, so the interface to create them belongs to the product rather than to the host. PAM delegates validation to the operating system's stack, which is why a local Unix account can be part of enrollment when that stack is what the service selected. LDAP, RADIUS and SAML move validation to an external service, where provisioning, password policy and MFA live. Access Server can still hold per-user certificates and permissions in all four cases, which is what makes the split confusing.

Check the effective method for this specific user rather than the global default. Access Server 2.10 and later can apply different authentication methods per group or per user, so a default of local does not prove that the account in front of you gets validated locally.

Entitlement Is a Separate Decision

Authentication answers who the person is; entitlement answers what they may reach. Keep those as two steps, because a successful login is not a grant. Assign the intended routes, resource permissions and administrative rights deliberately, and confirm that unrelated access stays denied. Where the deployment supports individual identities, issue one per person instead of forwarding somebody else's profile, since a shared profile cannot be retired for one person alone.

The client material matters as well. An auto-login profile and an interactive user login represent different authentication relationships, and swapping one for the other changes what the server actually verifies.

Retiring Access Is Part of the Enrollment

Write down three owners while the user is being created: who validates the account, who authorizes the VPN access, and which device or profile represents the connection. Those can be three different systems, and a revocation plan naming only one of them leaves a path open. When the person leaves, remove the entitlement from its owner and retire every issued credential under its owner. Deleting a downloaded file is not revocation, and neither is deleting a local entry if an external identity still authenticates.

Then test the enrollment the way an attacker would: connect once with the new identity, confirm access to the intended resource, and confirm that an unrelated resource still refuses. A first connection that works plus a negative test is a completed enrollment.

Keep the record with the profile it belongs to. The next auditor will ask who could connect during a given month, and the answer lives in those three owners.