How to - Authenticate OneConnect users with Clavister IdAuth on-premises

Users open Clavister OneConnect, sign in with their normal Active Directory (AD) account in a browser, and the VPN comes up. Clavister NetWall keeps no VPN users and no VPN passwords. Membership of one AD group decides who may connect.

This is the same OIDC sign-in that Clavister IdAuth Cloud offers as a service, described in How to - Authenticate OneConnect users using Clavister IdAuth Cloud. Here the organisation runs its own Clavister IdAuth on-premises, next to its AD, so the identities and the sign-in stay in its own network. This article explains what the setup does and helps you pick the guide for your deployment.

How it works

1. The user presses Connect in OneConnect. The OneConnect server on NetWall uses OIDC as its authentication source.
2. A browser opens on the IdAuth sign-in page. The user signs in with the AD user name and password.
3. IdAuth checks the password against AD over LDAPS, and sends a signed token back. The token carries the user's AD groups.
4. NetWall checks the token and the group. A member of the VPN group gets a tunnel. Everyone else is refused.

OneConnect is an OIDC public client: it has no client secret, and PKCE protects the sign-in.

Three things must be right. Every guide handles them with small scripts, so you only need to know that they exist:

• The TLS link from NetWall to IdAuth: the Windows guides set IdAuth to TLS 1.2; the Linux guides put a small reverse proxy in front of IdAuth.
• AD gives group names as distinguished names (DN); NetWall matches plain names. IdAuth is set to send plain group names.
• NetWall must find the IdAuth name on the inside network, and only there.

What you need

• Clavister NetWall with cOS Core 15.00.06 or later, and SSL VPN in its licence.
• The Clavister IdAuth 7.0.2 media and licence file, from Clavister.
• Active Directory with LDAPS.
• For IdAuth on Linux: a Linux host with Docker. The guides were tested on Debian 13.
• For IdAuth on Windows: a server with Windows Server. The guides were tested on Windows Server 2025. NetWall must be its way back to the internet. If this IdAuth already serves other applications, they get TLS 1.2 only and a new certificate on port 8443.
• A public DNS name for the VPN. The Let's Encrypt setups and the own-CA setup on Linux also need TCP port 80 free on NetWall's outside address.
• Windows PCs with OneConnect 3.15.4 from the Microsoft Store, and one test PC outside your network (a laptop on a phone hotspot is enough).

Choose your deployment

Two choices decide which guide to follow: where IdAuth runs, and where the users’ certificate comes from.

Each guide is complete on its own: seven steps, each with a check, from an empty server to a working VPN, and how to remove it again.

Where IdAuth runs.

• Linux: IdAuth runs as a Docker container. One Linux host does all the IdAuth work: IdAuth, a small reverse proxy and the scripts.
• Windows Server: IdAuth runs as a Windows service, and no other server is needed. PowerShell scripts do the expert parts.

Where the users’ certificate comes from.

• Let's Encrypt on the firewall: NetWall gets a public certificate by itself (ACME), and is set to renew it by itself. Client PCs need nothing but OneConnect. NetWall's own reverse proxy sits in front of IdAuth. This is the simplest choice.
• Your own CA: a script makes a CA, and every client PC gets it. Use this when you cannot use a public certificate. On Linux the guide also publishes a revocation list (CRL), and the NetWall forwards the sign-in port and port 80 straight to the IdAuth host, so that host faces the internet. On Windows Server the guide runs no CRL: CRL checking is turned off on NetWall and in each OneConnect profile. NetWall's own reverse proxy sits in front of IdAuth, as with Let's Encrypt.

The Let’s Encrypt setups need TCP port 80 free on NetWall’s outside address: Let’s Encrypt checks there that you control the name (the HTTP-01 check, which Let’s Encrypt allows only on port 80). The own-CA setup on Linux needs port 80 too: client PCs download the CRL from there.

Reference setup

Each guide was tested on cOS Core 15.00.06.10, Clavister IdAuth 7.0.2 and OneConnect 3.15.4 on Windows 11, with Samba AD as the directory. The Windows own-CA guide was also run against Windows Server 2025 AD with AD CS. A member of the VPN group connected, and a user outside the group was refused. Each guide lists its own reference setup and what was not tested.

Other ways to use OIDC with OneConnect: Clavister IdAuth Cloud and Microsoft Entra ID.

Related articles