Individual VPN Identities for a Small Team, No Directory

Six people share one VPN login, one of them leaves, and the only way to remove their access is to change the secret everyone else uses. That is the actual problem, and it does not require Active Directory to solve. A small office can keep separate identities in whatever local store its gateway supports and still treat departures as routine. The work is in choosing the store and writing down the removal steps before you need them.

Start with the credential each person holds

List what each person connects with before choosing a backend. One laptop, a phone, maybe a home desktop, and each of those is a separate credential or a separate device certificate. If you cannot name the credential a person holds, you cannot remove it later.

Two people sharing one profile is the case that makes every other step harder. Fix that first, because no directory solves a shared secret.

Pick the store the gateway actually supports

Choose the identity store the gateway already supports rather than the one you would like to run. A gateway with a local user database can hold individual accounts with per-user policy. An IKEv2 deployment can map an EAP identity to a specific secret, provided the client method and the verifier match. Certificate-based setups can issue one certificate per device from a common authority, which keeps the trust anchor shared while the credentials stay separate.

The store's location matters less than its operations: enrollment, backup, renewal and revocation. If any of those has no answer, the choice is not finished.

If the gateway offers both local accounts and certificates, prefer the one your team can operate at two in the morning without the vendor on the phone. That preference is about recovery time, not about which option is technically stronger.

Separate the person from the devices

Decide what a credential represents: a person, a device, or both. A laptop and a phone belonging to one employee are two devices and one person, and losing the phone should not necessarily disable the laptop. Write that model down, because it determines what removal means.

Record the owner, the device, the issuance date and the revocation path for each credential. Keep that record somewhere the office can read without the person who set it up. A table with those four columns is enough for six people and still scales to sixty.

Make removal an ordinary operation

Write the departure procedure before the first departure. Disable the identity, terminate any active session, and confirm the tunnel actually drops rather than waiting for a reauthentication timer. Then check that the former credential fails from a machine outside the office network. The whole sequence should take minutes and require no reissue for anyone else.

sudo swanctl --terminate --ike alice-laptop

Keep an administrator recovery path that does not depend on the disabled account, and reconcile any local accounts that later move to a directory. The goal is simple: removing one person is a routine task, not a project that touches everyone else's profile. Access Server's local authentication is one documented example of a store that fits this shape.