Configuring Google Secure LDAP with Access Server

Upgrade to Latest Version

Before you begin

The following are important to understand in order to integrate 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 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 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 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 "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.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 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 mike@example.com, the user would login as “mike” instead of “mike@example.com”. 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 “mike@example.com”).

4. Review and Configure Admin Web UI

Sign in to your 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 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

If you encounter errors, refer to our LDAP troubleshooting guide for help.

Test Connectivity with ldapsearch

You can use ldapsearch, an LDAP utility, by referring to installation steps in our general LDAP troubleshooting guide.

Google LDAP setup ldapsearch example

Here's an example using ldapsearch to check if a specific LDAP user is a member of a specific LDAP group 

("memberOf=CN=groupa,CN=Users,DC=domain,DC=com")
.

ldapsearch -x -D "ovpnuser" -b "CN=users,DC=domain,DC=com" -H ldap://10.20.30.30 "(&(sAMAccountName=specific-user)(memberOf=CN=groupa,CN=Users,DC=domain,DC=com))" -W

When prompted, enter your bind user password to return the results with user information.

  1. Run this command (you’ll need to adjust to match your specific configuration settings—our example uses a Google LDAP setup):
    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://ldap.google.com:636 -b ‘dc=domaingoes,dc=here’ '(mail=*)’
  2. 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 primary email address instead.
    In the cipher suite setting within the command, we specify to disallow TLS 1.3 in the test. If you use TLS 1.3, it is necessary to use SNI, and ldapsearch does not have SNI support at the time of writing. Lowering it to TLS 1.2 bypasses this issue in the test. The parameter LDAPTLS_CERT is for an LDAP client certificate if you have a setup with this for your directory service (such as using Google LDAP). LDAPTLS_KEY points to a private key used with a Google LDAP setup. 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