OpenVPN Security Advisory: Dec 14, 2018
Action needed: Important update for OpenVPN Access Server

Configuring Google Secure LDAP with OpenVPN Access Server

Prerequisites

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

As always, all command line options on the Access Server should be performed as root user to ensure you have the right permissions, and all commands are assumed to be started in the /usr/local/openvpn_as/scripts/ directory on the Access Server, where the configuration scripts such as sacli and confdba are present.

  1. To begin, copy the certificate and private key acquired from the Google Admin console to /etc/ssl/certs/gldap.crt and /etc/ssl/private/gldap.key, respectively.
  2. Ensure that the OpenVPN Access Server has rights to read this file by executing the following 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
  1. SSH into the OpenVPN Access Server instance, obtain root privileges, and execute the following commands, pressing Enter after the last line to ensure all commands are executed. Replace (DC=example, DC=com) with your Google LDAP domain name.
./sacli --key "auth.ldap.0.name" --value "Google Secure LDAP" ConfigPut
./sacli --key "auth.ldap.0.server.0.host" --value "ldap.google.com:636" 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.ssl_ciphers" --value 'ECDHE-RSA-AES128-GCM-SHA256' 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
  1. 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 mike@example.com, the user would login as “mike" instead of “mike@example.com". As such, User and Group permissions within the Admin UI should also be configured using the principal username only (i.e. “mike" instead of “mike@example.com").

Common problems and solutions

It’s a known issue that the Access Server can freeze for a time if you input invalid certificates or incorrect connection settings for the secure LDAP connection. If this occurs try restarting the Access Server service and 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

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 means that the LDAP server has an untrusted or self signed certificate in the certificate chain, and starting from Access Server version 2.6.1 we now check to see if this certificate is valid by default. We do this to be sure that you’re actually talking to the LDAP server that you think you are talking to, to ward against a Man-in-The-Middle attack. This behaviour is controlled by auth.ldap.0.ssl_verify key, which can have the following values:

  1. never – no peer certificate is required.
  2. allow – a peer certificate is requested, however the session will not be aborted if the certificate cannot be validated.
  3. demand – a valid peer certificate is required, and the session will aborted if one is not provided.
  4. internal – a valid peer certificate is required, and will be validated against an internal 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 <PATH_TO_FILENAME> ConfigPut
./sacli start

Or point which directory to use to scan for CA certificate for validating the LDAP server certificate with:

./sacli --key "auth.ldap.0.ssl_verify" --value "demand" ConfigPut
./sacli --key "auth.ldap.0.ssl_ca_dir" --value <PATH_TO_DIRECTORY> ConfigPut
./sacli start

To disable this check entirely and just accept any certificate, which is not a recommended procedure:

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

Troubleshooting

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.

 

Share