Configuring the Rublon Authentication Proxy as an LDAP Proxy Server

Last updated on August 5, 2025

Starting from version 3 of the Rublon Authentication Proxy, it can serve as an LDAP proxy server. However, as long as the configuration of the “plain” transport type of the LDAP connection is fairly simple, “ssl” configuration might get a bit confusing. Therefore, in this article, we will walk you through the configuration and explain it step by step. We will be using the .yaml format for the configuration file, as it was introduced in version 3 together with the LDAP proxy feature.

We will configure a single LDAP Proxy server that connects to a single LDAP authentication source. For this article, our LDAP authentication source will be set from an OpenLDAP docker image.

Start From the Configuration Template

In the config/examples directory (for both Windows and Linux) you can find the config.template.yaml file. Let’s use it.

 log:
  debug: false

rublon:
  api_server: https://core.rublon.net
  system_token:
  secret_key:

proxy_servers:
  - name: RADIUS-Proxy
    type: RADIUS
    radius_secret: secret_to_communicate_with_the_proxy
    ip:
    port: 1812
    mode: standard
    auth_source: LDAP_SOURCE_1
    auth_method: email
  - name: LDAP-Proxy
    type: LDAP
    ip:
    port: 389
    auth_source: LDAP_SOURCE_1
    auth_method: email

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip:
    port: 389
    transport_type: plain
    search_dn:
    access_user_dn:
    access_user_password:
  - name: RADIUS_SOURCE_1
    type: RADIUS
    ip:
    port: 1812
    radius_secret: secret_to_communicate_with_the_auth_source

As you can see, the template provides options for both LDAP and RADIUS proxy. Let’s remove the RADIUS-related fields, as we won’t need them. Let’s also temporarily set the debug option to “true”.

 log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token:
  secret_key:

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip:
    port: 389
    auth_source: LDAP_SOURCE_1
    auth_method: email

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip:
    port: 389
    transport_type: plain
    search_dn:
    access_user_dn:
    access_user_password:

Now we have the basic template that we can build upon.

Configuring the rublon and global Section

To get the API credentials required for the rublon section, sign in to the Rublon Admin Console and add a new application of type Rublon Authentication Proxy. Then, update your rublon section with the values of System Token and Secret Key copied from the Admin Console. It should look something like this:

rublon:
  api_server: https://core.rublon.net
  system_token: YOURTOKEN
  secret_key: yoursecret

Note: Starting with version 3.8.0, you can store Rublon Authentication Proxy secrets in OS environment variables by setting the secret_source option to env in the global section of the config. For more information, refer to Configuring the Rublon Authentication Proxy Secret Source.

Note: You can define more than one rublon section. For more information, refer to the Auth Proxy documentation on the rublon section.

Be aware that when users log in for the first time, they will not have an email address associated with their account. When the default Automatic enrollment type is set in the Admin Console, users will be added to the Users tab during the first login, but will not have an email address assigned to their profile, which is required to perform Rublon MFA. You will have to import users from CSV or manually set the users’ email addresses.

Configuring the LDAP Authentication Source

Let’s have a look at the current auth_sources section:

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip:
    port: 389
    transport_type: plain
    search_dn:
    access_user_dn:
    access_user_password:

You can read more about each option in the Rublon Authentication Proxy documentation.

When it comes to the LDAP proxy, unlike the RADIUS proxy, it does not require all the fields within the LDAP authentication source. The following fields can be safely removed when using an LDAP authentication source with the LDAP proxy server:

search_dn
access_user_password

Let’s set the rest of the settings and change the transport_type to “ssl”:

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: localhost
    port: 636
    transport_type: ssl
    access_user_dn: cn=admin,dc=example,dc=org

Later on, we will extend this configuration by adding the CA certificates, but for now, we’re good to go.

Configuring the LDAP Proxy Server

Our current proxy_servers section in the configuration looks like this:

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip:
    port: 389
    auth_source: LDAP_SOURCE_1
    auth_method: email

Again, you can read more about each option in the Rublon Authentication Proxy documentation.

Let’s start with setting the IP address and port. We will set the port to “555”, to distinguish between our LDAP Proxy server and the OpenLDAP docker image that resides on the same host. Keep in mind that it’s usually better to stick with the default ports, which are 389 and 636 for “plain” and “ssl” connections respectively.

The proxy_servers section now looks like this:

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip: 192.168.1.13
    port: 555
    auth_source: LDAP_SOURCE_1
    auth_method: email

Now comes the part where things might get a bit confusing.
How does the server know which transport type it should use? Should it use “plain” or maybe “ssl”? The answer is simple. The server simply takes the transport type from the auth_source. In our case, it’s the one we configured in the previous step called “LDAP_SOURCE_1”:

auth_sources:
  - name: LDAP_SOURCE_1
    transport_type: ssl # this will be used by the LDAP proxy server as well
  ...

But that’s not the end. We’re using the “ssl” transport type, so we have to specify a certificate and a private key for the server. We can do it by adding the cert_path and pkey_path options to the server configuration:

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip: 192.168.1.13
    port: 555
    auth_source: LDAP_SOURCE_1
    auth_method: email
    cert_path: path/to/cert.pem  # added
    pkey_path: path/to/key.pem  # added

If your private key is password-protected, you can supply the password using the pkey_password option.

The Configuration File We Ended Up With

log:
  debug: true

rublon:
  api_server: https://core.rublon.net
  system_token: YOURTOKEN
  secret_key: yoursecret

proxy_servers:
  - name: LDAP-Proxy
    type: LDAP
    ip: 192.168.1.13
    port: 555
    auth_source: LDAP_SOURCE_1
    auth_method: email
    cert_path: path/to/cert.pem
    pkey_path: path/to/key.pem

auth_sources:
  - name: LDAP_SOURCE_1
    type: LDAP
    ip: localhost
    port: 636
    transport_type: ssl
    access_user_dn: cn=admin,dc=example,dc=org

Running and Testing

After the configuration is finished, let’s run the Rublon Authentication Proxy and see if it’s working. Use whatever software you try to integrate with. In our case, we will use a simple LDAP Client application (LDAP Admin).

Here are the connection details:

Image showing setting up the connection properties for Rublon Authentication Proxy in LDAP Admin

We have set Port to 555 as specified in the configuration file. We also set Connection to SSL.

After clicking Test connection, we received an Email Link. After finishing MFA authentication, we got a successful response:

Image showing that the LDAP Admin connection was successful

Additionally, a message in the rublon-authproxy.log file confirms our test’s success.

Rublon: User: test (test@rublon.com) has confirmed their identity using 2FA. Access granted.

Verifying the CA certificate

To make the Rublon Authentication Proxy verify the client’s certificate, add a PEM formatted certificate(s) to the config/ca_certs directory. You can change this default directory by setting the ca_certs_dir_path option within the LDAP authentication source configuration.

If none of the certificates in the ca_certs dir matches the LDAP authentication source’s certificate, the connection with the client trying to authenticate will time out and you will get the following error in the Rublon Authentication Proxy:

LDAP-Proxy - Connection to the proxied LDAP server was lost. Reason: <class 'OpenSSL.SSL.Error'>: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')]

(Optional) Enabling AD Sync

Active Directory Sync (AD Sync) lets you automatically import Active Directory accounts into the Rublon Admin Console.

For step-by-step instructions, see our dedicated guide:

How to synchronize users from Active Directory using Directory Sync

Summary

As you can see, the final configuration ended up being pretty brief. The only thing to remember is that the LDAP proxy server will copy the transport type (in our case “ssl”) from the LDAP authentication source. Also, because SSL connections require a certificate, we had to add it together with a private key to our server’s configuration.