Configuring Google Secure LDAP with OpenVPN Access Server

Before you begin

The following are important to understand in order to integrate OpenVPN Access Server with Google LDAP.

  • As per Google's documentation, supported editions of G Suite for this feature are 'Business Plus', 'Enterprise', 'Education', or 'Enterprise for Education'.
  • This will not work with the normal 'Business' or basic Gmail/Google Drive user accounts.
  • Rather than creating a Bind user like most LDAP integrations, Google LDAP requires an SSL certificate, making the integration slightly more complex.
  • You will need to be familiar with the sacli tool for advanced configuration of OpenVPN Access Server. More information about it here: Access Server Command Line Interface Tools.

1. Create LDAP client in GSuite

Begin by signing into the Google Admin console. Then click on Apps and LDAP, or select Apps from the hamburger menu and choose LDAP. (If you don’t have LDAP as an option, you likely have G Suite Business instead. It’s not available for these accounts.)

Create LDAP client in GSuite
google admin

From the LDAP app, click on Add Client. Name your client, enter a description (optional), and click CONTINUE.

Create LDAP client in GSuite

Next, you’ll need to configure access permissions. This will pertain to your network setup. A few notes on that:

  • For “Verify user credentials”, choose “Entire domain” unless you are using organizational units for more granularity (i.e. marketing, sales, etc).
  • For “Read user information” make sure to choose “Entire domain”.
  • For “Read group information”, turn this on if you will be mapping to groups using the MEMBER_OF in your LDAP query; otherwise, leave off.

Once you’ve chosen permissions, click ADD LDAP CLIENT.

2. Start Google LDAP Client

Your LDAP Client starts in an OFF status and needs to be turned on. You can do this from the Client Details page by changing Service status from OFF to ON. Click on Edit details, then choose the radio button for ON for everyone and click SAVE.

Start Google LDAP Client

Now that the client’s service status is set to on, you can configure your users in Admin Web UI for access.

3. Add Certificate and Key to Access Server

Now that you’ve started your new client, you need to add the certificate and key to your Access Server:

  • Download the generated certificate (from the link on the confirmation page or from the client’s details page). You’ll download a ZIP file that includes both the certificate and the key.
  • We suggest renaming these files and will refer to them as gldap.crt and gldap.key.
  • Upload your certificate to your Access Server in this directory: /etc/ssl/certs/.
  • Upload your key to your Access Server in this directory: /etc/ssl/private/.
  • Next you need to ensure that OpenVPN Access Server has rights to read this file by executing these commands:
chown openvpn_as:openvpn_as /etc/ssl/certs/gldap.crt
chown openvpn_as:openvpn_as /etc/ssl/private/gldap.key
chmod 644 /etc/ssl/certs/gldap.crt
chmod 640 /etc/ssl/private/gldap.key

The next step is to configure the Google LDAP integration with OpenVPN Access Server. To do this, you will use the sacli tool in the /usr/local/openvpn_as/scripts/ directory. Make sure you have root privileges and execute the following commands (replace DC=example, DC=com with your Google LDAP domain name):

./sacli --key "" --value "Google Secure LDAP" ConfigPut
./sacli --key "" --value "" ConfigPut
./sacli --key "auth.ldap.0.use_ssl" --value "always" ConfigPut
./sacli --key "auth.ldap.0.ssl_verify" --value "internal" ConfigPut
./sacli --key "auth.ldap.0.ssl_auth_cert" --value "/etc/ssl/certs/gldap.crt" ConfigPut
./sacli --key "auth.ldap.0.ssl_auth_key" --value "/etc/ssl/private/gldap.key" ConfigPut
./sacli --key "auth.ldap.0.min_ssl" --value "tls1_2" ConfigPut
./sacli --key "auth.ldap.0.sasl_external" --value "true" ConfigPut
./sacli --key "auth.ldap.0.uname_attr" --value "uid" ConfigPut
./sacli --key "auth.ldap.0.users_base_dn" --value "OU=Users, DC=example, DC=com" ConfigPut
./sacli --key "auth.module.type" --value "ldap" ConfigPut
./sacli start

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 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. Here is information on how to update your version.

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 Web UI should also be configured using the principle username only (i.e.: “mike” instead of “”).

4. Review and Configure Admin Web UI

Login to your OpenVPN Access Server Admin Web UI with an admin account. You’ll see that on the Status Overview, “Authenticate users with” now states ldap.

You can now add users under User Management that you want access to the VPN. In addition, you can create Groups through your G Suite account and align those with Group Permissions in OpenVPN Access Server at that access control level.

If you plan to set up group mapping, once you have users assigned to a group, the group email name is used in the group mapping script.

Troubleshooting Tips

Issue from invalid certificates or configurations

It’s a known issue that Access Server can freeze if you input invalid certificates or incorrect connection settings for the secure LDAP connection. If this occurs, restart the Access Server service. Then, attempt configuration again. In a future release, we will resolve this known issue.

If a connection is made to a port on the LDAP server that uses plain text authentication but also supports the start_tls command to encrypt the authentication, then you should configure this:

./sacli --key "auth.ldap.0.start_ssl" --value "True" ConfigPut
./sacli start

Certificate verify failed

If you see this error in the /var/log/openvpnas.log:

Cannot connect to LDAP server: {'info': 'error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain)

This occurs when the LDAP server has an untrusted or self-signed certificate in the certificate chain. Access Server version 2.6.1 and later checks to see if this certificate is valid by default. This is to ensure that the LDAP server you’re talking to is what you should be talking to, to ward against a Man-in-the-Middle attack. This behavior is controlled by the auth.ldap.0.ssl_verify key, which can have the following values:

  • never – no peer certificate required
  • allow – if a peer certificate is provided, it must pass validation; if no peer certificate is provided, the session will continue.
  • demand – a valid peer certificate is required and the session aborts if it’s not.
  • internal - a valid peer certificate is required and must validate successfully against an internal Mozilla root CA bundle.

You can upload your own CA certificate bundle to verify an LDAP server certificate with manually:

./sacli --key "auth.ldap.0.ssl_verify" --value "demand" ConfigPut
./sacli --key "auth.ldap.0.ssl_ca_cert" --value_file <PATH_TO_FILENAME> ConfigPut
./sacli start

The <PATH_TO_FILENAME> must be a full path like “/usr/local/openvpn_as/ca_cert.pem”.

Or you can point to a specific directory to scan for a CA certificate for validating the LDAP server certificate with:

./sacli --key "auth.ldap.0.ssl_verify" --value "never" ConfigPut
./sacli start

Enable verbose debugging

If you are having troubles connecting after following instructions indicated in full, it may be helpful to enable verbose authentication debugging. To do this, execute the following commands:

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

The verbose authentication messages will be logged to the standard OpenVPN Access Server log file at /var/log/openvpnas.log. You can 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.

Test Connectivity

If you continue to experience issues with your Google LDAP integration, the following may help you test access and connectivity. Optionally, you may find helpful information on Google’s website: Connectivity testing and troubleshooting.

Test connectivity with OpenSSL

The first step is to try and connect from your Access Server itself to the Google LDAP server. You can do this with the OpenSSL command line tool. As a root user, run this command on your Access Server:

openssl s_client -connect

If connection is successful, the last line should read “Verify return code: 0 (ok)”. If you see anything else, you’ll need to investigate your network settings and firewall settings on devices that stand between your Access Server instance and the Google LDAP server. A failure to verify the certificate could mean a local problem where your root CA certificate bundle is outdated, or it could indicate that the certificate being offered by the server is not valid for The latter usually means that your connection is being intercepted by a firewall or antivirus solution.

Test with ldapsearch

The next test is using ldapsearch.

  1. Install the LDAP utilities:
    apt install ldap-tools
  2. Run this command (you’ll need to adjust as needed to match your specific configuration settings):
    LDAPTLS_CIPHER_SUITE='NORMAL:!VERS-TLS1.3' LDAPTLS_CACERT=/usr/local/openvpn_as/etc/cacert.pem LDAPTLS_CERT=/etc/ssl/certs/gldap.crt LDAPTLS_KEY=/etc/ssl/private/gldap.key ldapsearch -H ldaps:// -b dc=domaingoes,dc=here '(mail=*)'

    Where it says 'dc=domaingoes,dc=here' you should put your baseDN. The last part, 'mail=*' should return all user object results - but you may specify a specific primary email address instead.
    We specify in the ciphersuite setting within the command to disallow the use of TLS 1.3 in the test. If TLS 1.3 is used, it is necessary to use SNI, and ldapsearch does not have SNI support at the time of writing. Lowering it to TLS 1.2 will bypass this issue in the test. The parameter LDAPTLS_CERT should point to the Google LDAP client certificate, and LDAPTLS_KEY should point to the Google LDAP private key. These are available from your Google admin console where your LDAP connector is set up.

  3. You should get back a search result with something like this at the end:
    # search result
    search: 3
    result: 0

If you do not return search results, please let us know. Send a support ticket and we will help you troubleshoot.