Free Report! Gartner® Hype Cycle™ for Monitoring and Observability.Read more

Azure LDAP

Configure BindPlane OP to use Azure Entra LDAP as an authentication backend

BindPlane OP's LDAP authentication support can be configured to work with Azure Entra ID.

This guide will walk you through the process of configuring BindPlane OP to use Azure Entra's LDAP functionality as an authentication backend.


Switching authentication backends will require you to migrate your existing resources.


You must have access to an existing Azure account, with permissions to manage users and Microsoft Entra Domain Services.

You must create or have access to an existing Domain Service. You can follow this Microsoft tutorial.

If running outside of Azure, you must enable "secure LDAP" and "Allow secure LDAP access over the internet". See the documentation for details.

You must have DNS configured so the BindPlane server can resolve the Azure Entra Domain Services hostname.

BindPlane Configuration

BindPlane can be configured using the Initialization Command when operating BindPlane on a Linux server. If using Kubernetes, see the Kubernetes configuration section.

Initialization Command

On your BindPlane server, execute the init command.

1sudo BINDPLANE_CONFIG_HOME=/var/lib/bindplane \
2    /usr/local/bin/bindplane init server \
3    --config /etc/bindplane/config.yaml

Follow the prompts until you reach the authentication questions.

  • Select "Active Directory" when prompted for an authentication method.
  • Provide your Directory Services IP address.
    • If BindPlane is operating outside of the Azure environment, provide the "Secure LDAP external IP addresses".
  • Provide the LDAP port.
    • 389 if operating within the Azure environment, without TLS.
    • 636 if operating with TLS, from within or outside of the Azure environment.

If you want to use TLS, choose yes when prompted. TLS is required when operating outside of the Azure environment. It is recommended that you select "No" when prompted to skip TLS verification and provide a certificate authority in the next prompt.

If using TLS, you must choose yes when prompted for mutual TLS, and private a certificate and private key.


The certificate authority and mutual TLS keypair files must be readable by the bindplane Linux user.

When prompted to configure the "Base DN", provide your domain services base dn. For example, if your Domain services name is, your Base DN will be dc=bindplane-ldap,dc=onmicrosoft,dc=com


The Base DN can be extended to include organizational units, using the following syntax:


When prompted for the Use Search Filter, input (userPrincipalName=%s). This will allow users to log in to BindPlane using their Entra ID email address. e.g.

When prompted for the bind username and password, provide the user principal and password for your bind user. This user must have permission to bind to the domain services LDAP server.

Example Configuration

Once the configuration is initialized, the auth section will look like this:

2  type: active-directory
3  ldap:
4    protocol: ldaps
5    server:
6    port: "636"
7    baseDN: dc=bindplane-ldap,dc=onmicrosoft,dc=com
8    bindUser:
9    bindPassword: mypassword
10    searchFilter: (userPrincipalName=%s)
11    tls:
12      tlsCert: /etc/bindplane/azure_ldap/bindplane.crt
13      tlsKey: /etc/bindplane/azure_ldap/bindplane.key
14      tlsCa:
15      - /etc/bindplane/azure_ldap/ca.crt

In this example, the domain services hostname is and the certificate is valid for the hostname

The TLS certificates and private key are located at /etc/bindplane/azure_ldap with the following permissions.

-rw-r--r-- 1 bindplane bindplane 737 Apr 23 12:42 bindplane.crt -rw-r--r-- 1 bindplane bindplane 227 Apr 23 12:42 bindplane.key -rw-r--r-- 1 bindplane bindplane 619 Apr 23 12:42 ca.crt

High Availability

If operating BindPlane in high availability, make sure the configuration changes to the auth section of the configuration file are copied to the other servers.


The BindPlane Helm Chart v1.10.0 or newer supports Azure LDAP. See the Readme and the Initialization section on this page for details on each option.

Before you begin, make sure a secret containing the TLS certificates exists in the namespace that BindPlane is deployed to.

1kubectl create secret generic ldap-tls \
2  --from-file ca.crt \
3  --from-file bindplane.crt \
4  --from-file bindplane.key

Update your values file with the following options. Make sure to update them to reflect your environment.

2  type: active-directory
3  ldap:
4    protocol: ldaps
5    server:
6    port: 636
7    baseDN: dc=bindplane-ldap,dc=onmicrosoft,dc=com
8    bindUser:
9    bindPassword: mypassword
10    searchFilter: (userPrincipalName=%s)
11    tls:
12      insecure: false
13      ca:
14        secret: ldap-tls
15        subPath: ca.crt
16      clientKeyPair:
17        secret: ldap-tls
18        crtSubPath: bindplane.crt
19        keySubPath: bindplane.key

Update your Helm deployment with the new options.


You can use the ldapsearch utility to interface with Azure LDAP. It is useful for validating your certificate, bind user, and base DN.

Example usage:

1export LDAPTLS_CERT="bindplane.crt"
2export LDAPTLS_KEY="bindplane.key"
3export LDAPTLS_CACERT="ca.crt"
5ldapsearch \
6    -x \
7    -H ldaps:// \
8    -D \
9    -w 'password' \
10    -b "dc=bindplane-ldap,dc=onmicrosoft,dc=com"

Make sure to update the LDAP connection string (-H), bind user (-D) bind password (-w) and base dn (-b).