LDAP Configuration

[NOTE: This article is specific to a LDAP support in On-Premises Sysdig Platform environments running version 858 and earlier. If you are running version 890 or newer, refer to this other guide instead.]


LDAP support in Sysdig Monitor allows authentication to an on-premises install of Sysdig Monitor using credentials in a customer’s own directory server. This document describes how to configure the feature as well as its limitations.

Summary of Functionality

Independent of the LDAP feature, Sysdig Monitor ordinarily maintains its own user database to hold not only a username and password hash but also settings for Admin privileges, Sysdig Monitor Team membership, and a user’s configured Dashboards and Alerts. The LDAP feature provides a means to allow Sysdig Monitor to query the customer’s own directory server to validate username/password and (optionally) confirm that the user is a member of one or more groups. Upon successful authentication, a corresponding user record in Sysdig Monitor’s user database is automatically created. When the LDAP feature is in use, the user’s password is not stored in the Sysdig Monitor user database.


The LDAP feature is configured through the Replicated on-premise install option. It is disabled by default and, once LDAP is enabled, it cannot be disabled.

To enable LDAP, first click the checkbox at the bottom of the Settings tab to expand the Advanced Settings:

Then click the checkbox at the bottom of the newly-opened section to Enable LDAP:

When expanded, the following options are revealed:


Configure the settings as follows:




Server endpoint


URL of the directory server for Sysdig Monitor to query. An example for LDAP over SSL:


For cleartext LDAP:


CA Certificate in the PEM format


Click to upload a file containing the Certificate Authority (CA) PEM-format certificate that Sysdig Monitor will use to validate its SSL connection to the server. If you have a host with OpenSSL tools installed that can reach the directory server, you can obtain the certificate by running:

# openssl s_client -showcerts -connect <server-ip>:636 

The command output will show the server certificate first and the CA certificate second, both in PEM format. Into a text file, paste the CA certificate portion of the output that looks like:

[random text...]

Click the "Choose File" button and browse to the file you just created to select and upload it.

Note: For environments using self-signed certificates, the command shown above will return only one certificate.

DN manager


The distinguished name of a user that Sysdig Monitor can authenticate as via LDAP in order to perform further queries about the users attempting to login to Sysdig Monitor. Example:

CN=servicer_acccount,OU=Service accounts,DC=demo,DC=com

This setting is required, as Sysdig Monitor does not support connection to servers via anonymous bind.

Manager password


The password for the DN manager.

Root DN


The distinguished name for the point in the LDAP tree below which all search queries will begin. Example:


User search base


A relative distinguished name (from the Root DN) below which queries about users should be performed. If not specified, the search will be performed across everything below the Root DN. Example:


User search filter


An LDAP search filter (in RFC2254 format) that Sysdig Monitor will use in constructing the query to identify the user record. The marker token {0} represents where Sysdig Monitor will place the username when it constructs its LDAP queries. An example that targets the attribute sAMAccountName in Active Directory:


Group search base No

A relative distinguished name (from the Root DN) below which queries about groups should be performed. Example:

Group search filter No

An LDAP search filter (in RFC2254 format) that Sysdig Monitor may use in constructing the query to identify a group to which the user must belong. An example that only permits users that are in the superusers group in Active Directory:


To permit users that are in the superusers group OR the devops group:


However, AND logic to require membership in all of several groups is not currently supported.

If this setting is left blank, group membership is not required, and hence any user that successfully authenticates via username/password will be permitted to login to Sysdig Monitor.

Group membership filter No An LDAP search filter (in RFC2254 format) that Sysdig Monitor will use to determine group membership. If no setting is specified, a default filter of (| (member={0}) (uniqueMember={0}) (memberUid={1}))is applied, which should work for most environments.
In addition to the LDAP-specific sections of the Settings page, note that the Default user settings near the top of the page are also still required.

This represents the only local user that will still login using an email address, bypassing LDAP. This user is required and cannot be deleted. This login provides a way to access Sysdig Monitor when LDAP connectivity is severed. This user is also the first Admin user in the install and therefore essential for assigning Admin rights to other users once they’ve authenticated via LDAP and their user records have been added in the Sysdig Monitor user database. Once other LDAP-authenticated users have been promoted to Admins, those Admins can promote other LDAP-authenticated users to Admin, and so on.

Other local, non-LDAP users that were created before LDAP was enabled can still authenticate via LDAP as long as the username portion of their email address in the Sysdig Monitor user database matches their LDAP username. For example, consider a user [email protected] who had been a user in the environment before LDAP was enabled. Once LDAP is enabled, if a user "johndoe" exists in the directory server and is able to authenticate successfully via LDAP, they will be permitted to log in to Sysdig Monitor as the pre-existing [email protected] user. Any user-specific configuration (Alerts, Dashboards, etc.) that were attached to [email protected] will still be visible to this user.

Limitations and Caveats

  • LDAP support has been tested with Active Directory in Windows Server 2012 R2. It may work with AD versions that ship with other versions of Windows, or other directory servers that use the LDAP protocol.
  • The LDAP feature as it exists in version version 858 and earlier of the Sysdig platform will always chase referrals found in LDAP query responses. If your directory is partitioned, ensure all necessary routing and/or firewall settings are present to permit the Sysdig platform backend to contact all directory servers that may be referral destinations.
  • The LDAP feature is only present in on-premise installs (not the SaaS version of Sysdig Monitor).
  • LDAP support cannot be disabled once enabled.
  • Only one LDAP config can exist per deployment (i.e. can only query one directory server endpoint).
  • Because on-premise Sysdig Monitor is based on the same technology as SaaS-based Sysdig Monitor, it theoretically supports the configuration of multiple “customers” using the same install. However, the multi-customer option is not supported when the LDAP feature is enabled.
  • When LDAP support is enabled, other means of adding/validating users (e.g. sending “invites” to users, or e-mail verification) are not possible.
  • The LDAP feature does not attempt any ongoing “sync” back from the Sysdig Monitor user database to the directory server. Note how this impacts the following:
    • If a user is deleted from the directory server, their user record will remain in the Sysdig Monitor user database until a Sysdig Monitor Admin deletes it. Of course, that user will not be able to login since they will no longer be able to authenticate successfully via LDAP.
    • If a Sysdig Monitor Admin deletes a user from the Sysdig Monitor user database, but the user can still authenticate successfully via LDAP, their Sysdig Monitor user record will be recreated if they login again via LDAP.
    • If a person’s username should change in the directory server (e.g. the value for sAMAccountName in our example config table above), the next time they login, a new user record will be created for them in the Sysdig Monitor user database. In addition to user settings such as Admin rights, any Alerts or Dashboards attached to the prior username will not be visible.
  • Other LDAP-centric functionality that is not currently supported (not an exhaustive list);
    • Mapping a user in the directory server to the Sysdig Monitor Admin (such as to avoid the need to configure the one local Default user).
    • Mapping groups in the directory server to Sysdig Monitor Teams.
    • Session expiry based on configuration in the directory server (such as to set a user account to only be valid until a certain date).
    • Login policies based on configuration in the directory server (such as to restrict login to certain hours).
    • User timeout functionality (such as to remove a user from the Sysdig Monitor user database if they have not logged in for a certain amount of time).
  • Take special care when entering configuration settings, since small typos in fields such as search filters can cause failures that are difficult to debug. You may want to perfect your more complex configurations before plugging them into the install Settings page for Sysdig Monitor. For instance, if you have an Ubuntu Linux host at your disposal that can access your directory server via LDAP, install the ldap-utils package:

    # sudo apt install ldap-utils

    If accessing LDAP over SSL, edit the file /etc/ldap/ldap.conf and add the following line:

    TLS_REQCERT allow

    Then copy the server’s PEM certificate (the same one that was uploaded in the Sysdig Monitor install Settings above) to a location on the host, such as /tmp/cert.pem.

    Now you can run arbitrary queries via LDAP and study their success or failure. For instance, the following command-line uses some of the example settings we configured earlier:

    # LDAPTLS_CACERT=/tmp/cert.pem ldapsearch  -H ldaps://  -M  -b "DC=demo,DC=com" -D "servicer_acccount,OU=Service accounts,DC=demo,DC=com" -w "DnMgrPasswd" "(&(objectClass=organizationalPerson)(sAMAccountName={0}))"

Have more questions? Submit a request