Configuring Google Secure LDAP with OpenVPN Access Server


In order to configure OpenVPN Access Server with Google Secure LDAP, you must be running OpenVPN Access Server 2.5.3 or greater. Previous versions are not supported because some of the options that are to be used in this article are not available on older versions. This guide also assumes that you have already downloaded the LDAP client certificate and private key from the Google Admin console and that a basic VPN configuration has been created. If you have not already created a basic VPN configuration, please run the OpenVPN Access Server setup wizard to create a basic VPN server setup prior to beginning the steps in this article.

Configuration Steps

  1. SSH/SFTP into your Access Server instance using the appropriate credentials for the instance.
  2. Copy the certificate and private key acquired from the Google Admin console to /usr/local/openvpn_as/etc/gldap.crt and /usr/local/openvpn_as/etc/gldap.key, respectively.
  3. Ensure that the OpenVPN Access Server has rights to read this file by executing the following commands:
    sudo chown openvpn_as:openvpn_as /usr/local/openvpn_as/etc/gldap.crt
    sudo chown openvpn_as:openvpn_as /usr/local/openvpn_as/etc/gldap.key
    sudo chmod 644 /usr/local/openvpn_as/etc/gldap.crt
    sudo chmod 640 /usr/local/openvpn_as/etc/gldap.key
  4. Replace (DC=example, DC=com) with your Google LDAP domain name, and then execute the following commands:
    /usr/local/openvpn_as/scripts/sacli -k "" -v "Google Secure LDAP" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "" -v "" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.use_ssl" -v "always" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.ssl_verify" -v "internal" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.ssl_auth_cert" -v "/usr/local/openvpn_as/etc/gldap.crt" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.ssl_auth_key" -v "/usr/local/openvpn_as/etc/gldap.key" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.min_ssl" -v "tls1_2" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.ssl_ciphers" -v "ECDHE-RSA-AES128-GCM-SHA256" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.sasl_external" -v "true" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.uname_attr" -v "uid" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.ldap.0.users_base_dn" -v "OU=Users, DC=example, DC=com" ConfigPut
    /usr/local/openvpn_as/scripts/sacli -k "auth.module.type" -v "ldap" ConfigPut
    /usr/local/openvpn_as/scripts/sacli start
  5. If the configuration was successful, the server will return "WILL_RESTART ['client']" as part of the return message. This indicates that the server is now configured and is ready to accept LDAP authenticated connections. If you receive an ERRBACK message, please ensure you are using the latest version of OpenVPN Access Server and try again. Please note, this configuration uses the principal username for LDAP configuration, and not the user's email address. If a user's email address was, the user would login as "mike" instead of "". As such, User and Group permissions within the Admin UI should also be configured using the principal username only (i.e. "mike" instead of "").


If you are having troubles connecting using Google Secure LDAP and have followed the instructions indicated in full, you can enable verbose authentication debugging by executing the following commands:

sudo echo "DEBUG_AUTH=true" >> /usr/local/openvpn_as/etc/as.conf
sudo service openvpnas restart

The verbose authentication messages will then be logged to the standard OpenVPN Access Server log file at /var/log/openvpnas.log. You can then send the file to one of our OpenVPN Access Server technical engineers and they would be more than happy to assist you further.

To turn off authentication verbose logging, simply comment the line by putting a pound/hash sign before the DEBUG_AUTH line and save the file (you can also delete the line altogether). Afterward, restart the service using the aforementioned restart command.