Dynatrace Managed LDAP and SAML SSO: connecting to Active Directory

When a Dynatrace Managed cluster starts out, accounts are created locally in the Cluster Management Console. That is handy for a pilot, but untenable at scale: dozens of teams, joiners and leavers every week, auditors asking who has access to what. A local account forgotten after a contractor leaves is exactly the kind of gap a security review flags first. Dynatrace Managed LDAP or SAML authentication solves this at the source.

Because the cluster lives in your infrastructure, connecting it to your corporate directory is your job. Managed can rely on LDAP / Active Directory for authentication and group synchronisation, or on a SAML 2.0 identity provider (ADFS, Keycloak, Okta, Entra ID…) for SSO. The choice depends on your identity architecture, the network flows allowed between the cluster and your domain controllers, and your MFA requirements.

This article compares the two approaches, details the configuration in the CMC and offers a cutover method that never locks you out.

Dynatrace Managed LDAP or SAML: which approach?

In practice, SAML is often preferred as soon as a corporate IdP exists, because it centralises MFA and conditional access policies. LDAP remains relevant in isolated environments or when no SAML IdP is available in the cluster’s zone.

The permission model: groups first

Whatever the protocol, best practice is never to grant rights to an individual. In the CMC, you create Dynatrace user groups with permissions (cluster administration, access to an environment, settings management, access to sensitive data…), then map them to directory or IdP groups. Membership is then managed where it belongs: in your identity tool.

• DT-Cluster-Admins → CMC administration
• DT-Prod-Ops → full access to production environments
• DT-Prod-ReadOnly → read-only access
• DT-Staging-Dev → staging environment

Step-by-step tutorial

Step 1 — Create a local emergency account

Before touching authentication, make sure at least one working local administrator account exists, with a strong password stored in your vault. It is your safety net in case of a configuration error or directory outage. Test it in a private browsing session. Note: as soon as you switch to LDAP, local accounts stop working, except the administrator account created at installation; that account is therefore your emergency account.

Step 2 — Prepare the groups in the directory

Create the groups listed above in AD (or your IdP) and add a few test users. For LDAP, create a read-only service account dedicated to searching (bind) and note its DN.

Step 3 — Check LDAPS connectivity from the nodes

From each cluster node, check network access and the directory certificate:

openssl s_client -connect {ad-controller}:636 -showcerts </dev/null | head -n 30
ldapsearch -H ldaps://{ad-controller}:636 -D "{service-account-dn}" -W \
  -b "{base-dn}" "(sAMAccountName={test-user})" memberOf

If the directory certificate is issued by an internal authority, its root certificate will need to be trusted by the cluster (see cluster SSL certificates) (following the procedure for your version).

Step 4 — Configure LDAP in the CMC

In the CMC, under User authentication > User repository, select External LDAP server. The page has three steps (connection, groups query, users query); fill in:

• host {ad-controller} with Use SSL checked (port 636; avoid unencrypted LDAP on 389);
• Bind DN and password of the service account (read-only is enough);
• groups Base DN and filter (default (objectClass=group) for Active Directory), then users Base DN;
• attributes: identifier (sAMAccountName or userPrincipalName), email, name, group membership.

Use Test connection, then Test query. Dynatrace groups are created manually: in User authentication > User groups, enter for each one the AD group name in the LDAP groups field. Users are created automatically on their first successful login.

Step 5 — Or configure SAML SSO

For SAML, open User authentication > Single sign-on settings in the CMC and select SAML 2.0, then the login page (Standard + SSO to keep local login, or SSO only). Download the service provider metadata (Download SP metadata, file sp.xml) and use it to register a new application in your IdP. Configure the IdP to send:

• a stable identifier (email or UPN) in the NameID;
• first name, last name and email as attributes;
• a groups attribute, filtered to the DT-* groups only to keep the assertion small.

Then upload the IdP metadata file to the CMC, enter the first name, last name and email attributes, turn on automatic group assignment and enter the name of the groups attribute. The values received must exactly match (case included) the Dynatrace group names. You can check the IdP metadata before importing it:

curl -s "https://{idp}/{metadata-path}" | grep -o 'entityID="[^"]*"'

Step 6 — Test with a pilot user

In a private browsing window, log in as a user who belongs only to DT-Prod-ReadOnly. Check that they see the expected environments and cannot change anything. Then test a user with no DT-* group: access must be denied. If something fails, check the server logs:

sudo journalctl -u dynatrace-server --since "15 min ago" | grep -i -E "ldap|saml|auth"

Step 7 — Cut over and clean up local accounts

Once the configuration is validated, announce the cutover date, then disable unneeded local accounts, keeping only the emergency account (with SAML, keep the Standard + SSO login page if that account must remain usable). Document the emergency login procedure in your runbook.

Best practices

• Always keep a local emergency account, tested regularly, whose use triggers an alert.
• LDAPS only and a least-privilege service account, with scheduled password rotation.
• Explicitly named groups managed in the directory, never individual assignments in the CMC.
• Watch the certificates: if the IdP’s SAML signing certificate or the LDAPS certificate expires, nobody can log in.
• Periodic access reviews of the DT-* groups, especially those granting access to sensitive data (request captures, sessions).

Frequently asked questions

Should I prefer LDAP or SAML?

SAML as soon as a corporate IdP exists, because it centralises MFA and conditional access policies. LDAP remains relevant in isolated environments or when no SAML IdP is reachable from the cluster’s zone.

How do I log in if the directory or IdP is unavailable?

With the local emergency administrator account, kept in a vault, tested regularly and whose use triggers an alert.

Why does an authenticated user have access to nothing?

Rights go through groups: a user with no matching DT-* group is refused. Check their membership in the directory, the name of the groups attribute in SAML, then the server logs.

Conclusion

Connecting Dynatrace Managed to your directory or SAML IdP transforms access management: joiners and leavers are handled where they should be, rights follow an auditable group-based model, and MFA applies naturally with SAML. With an emergency account, private-browsing tests and a gradual cutover, the change happens without ever losing control of your cluster.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) against the official documentation for your Managed version.

Originally published on span.observer. French version: https://span.observer/fr/ldap-saml-authentification/.