Secure remote access remains a priority for service providers, enterprises, and site owners. SSTP (Secure Socket Tunneling Protocol) is a popular VPN transport because it encapsulates PPP frames over an SSL/TLS channel, allowing VPN traffic to traverse strict firewalls and proxy environments. When combined with LDAP-backed authentication — using either Active Directory or OpenLDAP — SSTP can deliver centralized, scalable user authentication and group-based access control. This guide walks you through a practical, hands-on integration of SSTP with LDAP authentication, detailing architecture choices, server configurations, security hardening, and troubleshooting tips.

Why choose SSTP with LDAP?

Before diving into configuration details, it helps to understand the strengths of this pairing:

  • Firewall-friendly transport: SSTP uses TCP/443, making it resilient to restrictive network environments.
  • Centralized identity management: LDAP (including Active Directory) provides a single source of truth for user accounts and groups.
  • Policy-driven access: LDAP attributes and group membership can be used to implement granular access policies.
  • Scalability: LDAP directories are designed to scale; offloading authentication to LDAP avoids per-server user databases.

High-level architecture options

There are two common architecture patterns for integrating SSTP with LDAP:

  • Native LDAP integration: The VPN server directly binds to LDAP/LDAPS to authenticate user credentials. This is possible with some VPN servers or plugins.
  • RADIUS proxy: The VPN server uses RADIUS for AAA and a RADIUS server (e.g., FreeRADIUS or Microsoft NPS) performs LDAP authentication. This is the most flexible and widely supported approach because many VPN servers support RADIUS natively.

For enterprise environments with Active Directory, Microsoft NPS (Network Policy Server) is commonly used. For heterogeneous environments or OpenLDAP, FreeRADIUS is a typical choice.

Prerequisites and preparation

Ensure the following infrastructure and software components are in place before starting configuration:

  • An SSTP-capable VPN server. Options include:
    • Windows Server with RRAS (Routing and Remote Access)
    • SoftEther VPN (supports SSTP)
    • Commercial VPN appliances supporting SSTP
  • An LDAP directory: Active Directory (AD) or OpenLDAP. AD is often used in Windows-centric networks.
  • If using the RADIUS pattern, a RADIUS server (e.g., Microsoft NPS or FreeRADIUS) configured to proxy/authenticate against LDAP.
  • A valid TLS certificate for the SSTP server hostname (issued by a trusted CA). SSTP establishes an SSL/TLS session and clients verify the server cert.
  • Firewall rules to allow TCP/443 to the SSTP server and any required ports between RADIUS and LDAP servers (e.g., 389, 636).

TLS certificate and SSTP binding

SSTP relies on TLS for the tunnel. Use a publicly trusted certificate with a Subject Alternative Name (SAN) that matches the VPN hostname. Self-signed certificates can work for closed deployments but require client trust distribution.

Key points:

  • Use a strong certificate: RSA 2048+ or ECDSA P-256 with SHA-2 hashing.
  • Enforce TLS 1.2+: Disable SSLv3 and TLS 1.0/1.1 on the server and prefer strong cipher suites.
  • Bind certificate to SSTP: On Windows RRAS, import the cert into the Local Computer store and assign it under RRAS server properties → Security. On SoftEther, import via the admin UI.

Option A — Windows RRAS + Microsoft NPS + Active Directory

1. Configure RRAS for SSTP

  • Install the Remote Access role and enable VPN using SSTP. In Server Manager choose “Remote Access” → “DirectAccess and VPN (RAS)”.
  • Configure the SSTP listener: under RRAS properties, ensure the imported certificate is selected for SSTP.
  • Enable PPP authentication methods: typically MS-CHAPv2 is enabled. For higher security, consider EAP methods (EAP-TLS with client certs).

2. Configure NPS to use Active Directory

  • Install the NPS role on a server joined to the domain.
  • Create a RADIUS client entry pointing to the RRAS server (use a shared secret).
  • Create a Connection Request Policy/Network Policy that authenticates users in AD groups. Use condition filters like Windows Groups and constraints like EAP or MS-CHAPv2.
  • Test authentication with the “Policy” test tool in NPS.

3. Client and access control

  • Use AD group membership to control which users can connect. For example, only members of VPNUsers group are allowed.
  • Use NPS network policies to set RADIUS attributes (e.g., Framed-IP-Address, Filter-IDs) for VLAN or IP assignment.

Option B — SoftEther/Other SSTP Server + FreeRADIUS + OpenLDAP

1. FreeRADIUS → LDAP module configuration

When using FreeRADIUS as the authentication broker, configure the mods-available/ldap module (paths vary by distro). Example minimal settings:

<pre>
ldap {
server = “ldap.example.com”
identity = “cn=binduser,dc=example,dc=com”
password = “bindpassword”
base_dn = “ou=users,dc=example,dc=com”
filter = “(uid=%{%{Stripped-User-Name}:-%{User-Name}})”
start_tls = no
tls_require_cert = “demand”
cipher_suite = “HIGH:!aNULL:!MD5”
}
</pre>

Important fields:

  • identity/password: Use a dedicated bind account with least privilege to perform searches.
  • filter: Map the RADIUS User-Name to LDAP attributes (uid, sAMAccountName).
  • start_tls vs LDAPS: Prefer LDAPS (636) or STARTTLS; never send credentials over plaintext LDAP.

2. Integrate FreeRADIUS with SSTP server

  • Configure your SSTP server to use RADIUS for authentication (point to FreeRADIUS host, port 1812, and shared secret).
  • On FreeRADIUS, ensure the virtual server for PAP/MS-CHAP/EAP handles incoming requests. If using MS-CHAPv2, modules like mschap require NT-hash — calculate from LDAP or use proxying to a system that stores these hashes.
  • For OpenLDAP, you may store userPassword as {SSHA} hashed values; MS-CHAPv2 needs NT-Hash (MS-CHAPv2 uses NT password hash). One approach is to require EAP methods, or use LDAP overlay that stores ntHash, or to use a PAM/SSSD intermediary.

Authentication flow and considerations

Typical SSTP + LDAP authentication flow (RADIUS proxy pattern):

  • Client initiates SSTP handshake to server on TCP/443; server presents TLS certificate and negotiates TLS session.
  • Client and server establish PPP over the TLS channel.
  • During PPP authentication, the SSTP server queries the configured RADIUS server.
  • RADIUS server binds to LDAP or AD to validate the credentials and returns Access-Accept or Access-Reject and optional attributes.
  • If accepted, the server completes PPP and assigns an IP, routes, and any vendor-specific attributes.

Security cautions:

  • Do not send LDAP binds over plaintext: always use LDAPS (636) or STARTTLS (389).
  • Protect shared secrets: RADIUS shared secrets and LDAP bind passwords must be treated like credentials — rotate them and store securely.
  • EAP vs MS-CHAPv2: While MS-CHAPv2 is widely supported, it has known weaknesses. Prefer EAP-TLS (client certificates) or EAP methods that provide mutual authentication and strong crypto.

Group-based access and attribute-driven policies

LDAP directories provide attributes and group memberships you can use to enforce access policies:

  • Use group membership filters (e.g., memberOf in Active Directory) to allow or deny VPN access.
  • Map LDAP attributes to RADIUS Response attributes. For example, use LDAP attributes to set IP address pools, VLAN assignment, or custom tunnel filters.
  • Implement short-lived attributes for temporary access or expiration timestamps (e.g., an attribute that you evaluate in your RADIUS policy).

Monitoring, logging, and troubleshooting

Collect logs at multiple points:

  • SSTP server logs (Windows Event Logs for RRAS, SoftEther logs).
  • RADIUS server logs (FreeRADIUS debug mode: run radiusd -X or freeradius -X).
  • LDAP server logs for bind/search failures and TLS negotiation problems.

Common troubleshooting commands and checks:

  • Use openssl s_client -connect ldap.example.com:636 to validate LDAPS and certificate chain.
  • Test RADIUS from a client machine using radclient to ensure requests reach FreeRADIUS and receive expected responses.
  • On Windows, use the VPN client built-in logs and Event Viewer to diagnose authentication failures (e.g., MS-CHAP error details).

Hardening checklist

  • Enforce strong TLS and cipher suites on SSTP endpoint and LDAP (LDAPS/TLS).
  • Use EAP-TLS where possible for mutual certificate authentication and to avoid password-based attacks.
  • Harden RADIUS servers: apply OS patches, restrict management interfaces, and limit access to known SSTP servers via IP allowlists.
  • Monitor for brute force attempts: implement account lockouts or use a fail2ban-like mechanism for RADIUS logs.
  • Rotate credentials: periodically rotate secrets and certificates with automated processes where feasible.

Example configuration snippets

FreeRADIUS ldap module (concise example):

<pre>
ldap {
server = “ldap.example.com”
identity = “cn=binduser,dc=example,dc=com”
password = “changeme”
base_dn = “dc=example,dc=com”
filter = “(uid=%{User-Name})”
access_attr = “uid”
start_tls = yes
tls_require_cert = “demand”
}
</pre>

Windows NPS policy example (conceptual):

  • Policy condition: Windows Group = “VPNUsers”
  • Constraints: Authentication methods = MS-CHAPv2 (or EAP) ; NAS-Port-Type = Virtual
  • Settings: Filter-Id or Vendor-Specific to assign routing policies

Wrap-up and recommended next steps

Integrating SSTP with LDAP for authentication provides a robust, centralized approach to VPN access control that is both firewall-friendly and enterprise-grade. The recommended path for heterogeneous deployments is to use a RADIUS intermediary (FreeRADIUS or NPS) to bridge SSTP and LDAP. For Active Directory environments, Microsoft NPS offers a straightforward, fully-supported solution. Pay close attention to TLS configuration, cipher selection, and prefer certificate-based EAP where practical.

Start by provisioning a trusted TLS certificate on your SSTP gateway, configure RADIUS to authenticate against LDAP with secure binds (LDAPS/STARTTLS), implement group-based policies, and enable detailed logging for visibility. Iterate by tightening authentication mechanisms (move to EAP-TLS), automating certificate lifecycle, and continuously monitoring logs for anomalous patterns.

For more detailed tutorials, configuration templates, and production-ready checklists, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.