A user-locked Access Server profile is generated for one account and refuses every other one, so the download step decides who the file belongs to before any client setting matters. The order below is the one I hand to whoever asks for "the VPN file": sign in as the person who will use it, find the control for your server version, read what the file is locked to, confirm policy allows that type, then hand it off in a way you can still revoke. Stop at the first step that fails; each later step assumes the earlier one held.

Check 1: sign in as the account, not as the administrator

The client portal is the ordinary user interface, usually at https://vpn.example:943/, while administration sits at https://vpn.example:943/admin. Those are default examples; hostnames, ports and reverse proxies change them, so use the address your operator gave you. Signing in to the admin path first is the most common wrong turn, because the admin session can create and manage accounts but is not the account that will carry the tunnel.

If the person is not yet able to sign in, stop here and fix that first: a password reset, a missing group assignment or an account that only exists as an imported authentication entry will block the download no matter which browser you try. Downloading from the administrator's own session produces the administrator's profile, which is exactly the file that must not end up on someone else's laptop.

Check 2: find the download control for your version

Once signed in, the portal shows a connection-profile control near the top of the page. For Access Server 2.14 and newer the tutorial describes it as a Connection Profile section under "Download your profile below". Where the portal also offers a preconfigured OpenVPN Connect installer, those are two different handoffs: one installs the client with the profile already attached, the other gives you a file to import into a client you already have.

Version matters here. An older portal may label the same button differently, and a heavily customised portal can move it below a notice. If the section is absent entirely, do not start guessing at URLs: move to the policy check rather than experimenting with paths, because a missing control is almost always a server-side decision.

Check 3: read what the file is locked to

A user-locked profile carries an embedded client certificate and key issued for one user, and the server maps that identity to that account. Renaming the file, editing its display name or typing different credentials at the prompt does not change the mapping, which is why a copied profile fails for the second person with an authentication or certificate error rather than a routing problem. Look inside the file if you need to confirm what you have:

grep -c "BEGIN CERTIFICATE" office-user.ovpn
grep -n "^remote " office-user.ovpn

The certificate count tells you an identity is embedded; the remote lines only name the server. Two files that point at the same server can therefore belong to different people, and one file that points at two servers is still tied to its original owner. Server-locked and auto-login profiles have different permitted-use models again: a server-locked profile expects credentials at connect time, and an auto-login profile skips the password prompt by design. None of them becomes another type by editing the file.

Check 4: confirm policy allows that type

Which profile types exist is an administrator setting, not a client preference. If the portal offers only a user-locked download, the server may allow no other type, or may allow one that the account's group does not receive. Asking the administrator to enable a different type to make a missing button appear is a policy change with real consequences, and removing multi-factor authentication to reach a download page trades an authentication control for convenience.

Depending on version, the Admin Web UI also exposes profile management for a user, where an administrator can issue or revoke a profile without signing in as that person. Where that capability is absent, the user downloads their own file. Either way, the correct source is the intended account, never a copied administrator profile treated as a template.

Check 5: hand off, then keep it revocable

Treat the download as credential material rather than as a configuration file. A user-locked profile contains a private key, so it should travel over a channel you would use for a password, not through a shared drive folder or a chat group. Record which user and device received which file, because revocation is per-account: when a laptop is replaced or lost, the administrator revokes that user's access and issues a fresh profile, and the old file stops working at the next connection attempt.

Finish with four checks in this order: the portal sign-in was the intended user, the file contains an identity rather than only a server address, one test connection from the intended client succeeds, and a second connection using another account fails. If the fourth succeeds, you distributed the wrong file, and revocation is the next step rather than a configuration edit. The Access Server download tutorial shows the current portal layout and the difference between a profile and a preconfigured installer.

Amanqephe ahlobene