LDAP Synthetic extension
- Latest Dynatrace
- Extension
- Published Oct 27, 2025
Run Synthetic tests against LDAP with different search parameters
Get started
Overview
Dynatrace offers this Synthetic LDAP extension to validate and check your LDAP health. Matching filters will be flagged as successful synthetic tests as well as measuring response time performance.
Requirements
- Communication ports between ActiveGate and LDAP server must be open on whichever port runs on.
- If using a Linux ActiveGate and you would like to use the ldapsearch feature (optional), ldapsearch must be installed on your Linux ActiveGate. This is not supported on Windows.
Activation and setup
- Find the extension in Dynatrace Hub and add it to your environment.
- Add a monitoring configuration.
-
LDAP Server:
Hostname or IP of your LDAP server.
-
LDAP Port:
389 is the default for LDAP. If using SSL, make sure you also change this port number to reflect the correct SSL port.
-
Test name:
The name for this Synthetic test.
-
Test location:
Enter a name of the location where this test will be running from. Otherwise the default name is "ActiveGate".
-
Use credential vault:
Use this feature if you would like to use a pre-stored Username/Password from your Dynatrace credential vault.
-
LDAP Bind DN:
This would be the username to log into your LDAP server.
-
LDAP Password:
Password for the username above.
-
LDAP Base DN:
Entry DN from where to start the search.
-
Use ldapsearch:
This is in case you would like to use a ldapsearch command expression instead. This is due to some LDAP tools having different format and custom properties and fields that the normal LDAP searches cannot see. A ldapsearch might return or provide more hidden fields. You will rarely need to use this feature and it requires you have ldapsearch installed on your ActiveGates.
-
LDAP filters:
Add any filters to get a better focus your search and speed it up.
-
LDAP attributes:
Which attributes to return.
-
LDAP matcher:
The exact text to match in the result (case sensitive). If a matcher is entered, your test will be flagged as successful if the text is found, otherwise, marked as failed if not found.
-
LDAP timeout:
Number of seconds for the request to wait before timing out if no response.
-
Dynatrace token:
Because data is pushed as a third party synthetic test using the API, you must enter an API token with "Create and read synthetic monitors, locations and nodes" scope.
-
Polling frequency:
Interval this synthetic test will run. By default, it will run every 1 minute.
-
Details
Licensing and cost
This extension runs a synthetic test once per minute, by default. This can be changed in the monitoring configuration when setting up the extension.
License consumption will be incurred in the form of a Third Party Synthetic.
DPS Licensing
For DPS licensing, see this Calculate your consumption of Third-Party Synthetic API Integration (DPS) for more details.
The formula for DPS consumption per minute can be seen below, where the polling frequency = 1 minute. Consumption is calculated where a single third-party synthetic result is the number of test results ingested. In the case of this extension, it ingests one (1) test result per execution. As such, the formula is as follows.
number of LDAP Connections x (polling frequency x 1 third-party synthetic test result) = DPS Consumption
Classic Licensing
For Dynatrace classic licensing, see Digital Experience Monitoring (DEM units) for more details on calculating consumption.
For example, a single Third-party synthetic API ingestion consumes 0.1 DEM.
The formula for DEM consumption per minute can be seen below, where the polling frequency = 1 minute.
number of LDAP Connections x (polling frequency x 1 third-party synthetic test result) = DEM Consumption
Feature sets
When activating your extension using monitoring configuration, you can limit monitoring to one of the feature sets. To work properly the extension has to collect at least one metric after the activation.
In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.
All metrics that aren't categorized into any feature set are considered to be the default and are always reported.
A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.
