On a Dynatrace Managed cluster, the question « who is allowed to see what? » comes up very quickly. At first, a handful of administrators share an account and everyone is happy. Then application teams ask for access, the security audit demands named traceability, a contractor needs to see a single service, and you discover that an intern can replay user sessions containing personal data. Left untended, the access model becomes a risk: Dynatrace Managed users, groups and permissions deserve a plan from day one.
This topic is especially foundational in Managed, because you are both the platform operator and the administrator of the environments. There are two very distinct levels of rights: those that apply to the cluster (nodes, licences, backups, updates, environment creation) and those that apply to each monitoring environment. Mix them up, and you give an application team the ability to stop a node.
In this article, we break down Managed’s users / groups / permissions model, choose an identity source, then build step by step an access model that is clean, testable and automatable.
Dynatrace Managed users, groups and permissions: the building blocks
Dynatrace Managed users
A user is an identity that logs in to the Cluster Management Console (CMC) or to an environment via https://{your-domain}/e/{environment-id}. It can be local (created in the CMC, password managed by Dynatrace) or come from an external directory. Key point: in practice, you never grant rights directly to a user. All rights go through groups.
Groups
The group is the unit of governance. It carries cluster permissions and/or per-environment permissions, optionally restricted to management zones. A user accumulates the rights of every group they belong to: the model is additive, and there is no explicit « deny ».
Permissions
| Level | Example permissions | Typical audience |
|---|---|---|
| Cluster | Cluster permission (« Grant global administrator permissions »): CMC access, adding nodes, upgrades, user and group management, administrator rights on every environment | Platform team (2 to 5 people) |
| Environment | View environment, Change monitoring settings, Download & install OneAgent, Configure request capture data, View/Manage security problems | Observability leads, ops teams |
| Sensitive data | View sensitive request data, Replay session data (with or without masking), View logs | Authorised profiles, individually justified |
| Management zone | Same environment rights, but limited to the scope of a zone | Application teams, contractors |
The exact names of permissions vary between Managed versions: refer to the list shown in your cluster’s CMC.
Choosing your identity source
- Local users: simple, with no external dependency. Note: once you switch to LDAP, only directory accounts and the administrator account created at installation still work; that account becomes your emergency (« break glass ») account.
- LDAP / Active Directory (see connecting Managed to LDAP and SAML SSO): the CMC queries the directory to authenticate and can map LDAP groups to Dynatrace groups. This is the most common choice in enterprises. It requires a network flow from the cluster to the domain controllers (LDAPS recommended).
- SAML 2.0: authentication is delegated to an identity provider (ADFS, Keycloak, Okta…). It enables SSO and strong authentication. Group membership is passed via an attribute in the assertion.
Whichever option you choose, the goal is the same: the account lifecycle is driven by the corporate directory. A leaver in AD must lose Dynatrace access without any manual action.
Step-by-step tutorial
Goal: set up a four-group model connected to LDAP, with one group restricted by management zone, then audit it through the Cluster API.
Step 1 — Define the role matrix
Before clicking anything, write down the matrix. A starting example:
-
dt-cluster-admins: cluster administration, all permissions on all environments. -
dt-{env}-admins: full access to a given environment, no cluster rights. -
dt-{env}-viewers: read access to the environment, no sensitive data. -
dt-{env}-{team}: access and configuration limited to the team’s management zone.
Create the matching groups in your directory with exactly the same names: a one-to-one mapping makes support far simpler.
Step 2 — Connect the LDAP directory
In the CMC, open User authentication > User repository and select External LDAP server. Enter the host with Use SSL (port 636), the service account Bind DN, and the search base for users and groups. Before saving, check from each node that the flow is open:
openssl s_client -connect {ldap-server}:636 -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -subject -enddate
If the directory certificate is signed by an internal authority, import that authority into the trust store used by the cluster (see the documentation for your version) before testing a login.
Step 3 — Create the Dynatrace groups and their permissions
Create each group in User authentication > User groups, entering the matching LDAP group name. Environment rights are then granted from Environments, target environment, section Assign environment permissions to user groups: for dt-{env}-viewers, only View environment. For dt-{env}-{team}, edit the group and use the Management zone permissions section. Leave sensitive data permissions unticked until a need has been formally stated.
Step 4 — Test with a real account
Log in with a test account that belongs to a single group. Check that it sees only the entities in its zone, cannot open the CMC, and that masked values stay masked. Repeat for each group: it is tedious once, but it is what will save you from a compliance failure.
Step 5 — Audit through the Cluster API
Generate a cluster token in the CMC (Settings > API tokens, Cluster tokens section) with only the Service Provider API (ServiceProviderAPI) permission, which these calls require and which has no read-only variant: guard this token carefully and dedicate it to this use. Then export groups and users:
export DT_CLUSTER="https://{your-domain}"
export DT_TOKEN="{token}"
curl -s -H "Authorization: Api-Token $DT_TOKEN" \
"$DT_CLUSTER/api/v1.0/onpremise/groups" | python3 -m json.tool > groups-$(date +%F).json
curl -s -H "Authorization: Api-Token $DT_TOKEN" \
"$DT_CLUSTER/api/v1.0/onpremise/users" | python3 -m json.tool > users-$(date +%F).json
The detailed response format is in the API explorer built into your cluster (Cluster Management API, user menu) (and the guide to automating administration with the Cluster API). Version these exports in a repository: a simple diff between two dates reveals any drift in rights.
Step 6 — Secure the emergency accounts
The administrator account created at installation remains usable whatever the authentication mode: that account, with a long password stored in your secrets vault, is your emergency account (with LDAP, other local accounts stop working). Document how and when to use them, and check periodically that nobody uses them day to day (CMC audit log).
Best practices
- Least privilege: start from zero rights and add as needed, never the other way round.
- Separate cluster and environment: very few people should administer the cluster.
- No individual rights: everything goes through groups, themselves fed by the directory.
- Sensitive data under control: session replay and request data only for dedicated, justified groups (GDPR).
- API tokens: one token per use, minimal scopes, an expiry date, regular rotation.
- Quarterly review: API export, comparison with the matrix, clean-up of orphaned groups.
Frequently asked questions
Can rights be granted directly to a user?
In practice, no: all rights go through groups. A user accumulates the permissions of all their groups, and because the model is additive there is no explicit deny to correct an overly broad right; you have to review group membership instead.
LDAP or SAML: which should you choose for Managed?
LDAP / Active Directory lets the CMC query the directory and map its groups, at the cost of a network flow to the domain controllers (LDAPS recommended). SAML 2.0 delegates authentication to an identity provider, with SSO and strong authentication. Either way, the administrator account created at installation remains your emergency access.
How do you spot drift in access rights?
Regularly export groups and users through the Cluster API with a token dedicated to that use (Service Provider API permission), version those exports and compare them with a diff. A quarterly review checks the result against the role matrix.
Conclusion
The Dynatrace Managed access model is simple in principle — users, groups, permissions on two levels — but it does not forgive improvisation. By aligning your groups with the directory, restricting teams by management zone and auditing regularly through the Cluster API, you get a shared platform where everyone sees what they need, and nothing more. The logical next step: take care of your management zones and automatic tagging, which underpin scope-based restrictions.
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/utilisateurs-groupes-permissions/.
Top comments (0)