Dynatrace

Dynatrace is an observability platform that holds production monitoring data and its own access controls. Connect your Dynatrace account to Oleria to see every user and service user, the groups, policies, and permissions that give them access, the environments they can reach, the environment API tokens that can act on them, and what changed in the account. Oleria connects with an account OAuth client, so one connection covers every environment in the account.

​

What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Dynatrace account:

• Accounts - every user of the account, including invited users who haven’t accepted yet (shown as disabled), with their last successful login. Users without a name in Dynatrace show their email address as their name. Changes that Dynatrace itself makes appear under a Dynatrace System account. Oleria marks a user as an administrator when they belong to a group that holds the account-level Manage users permission, or a group bound to a policy that allows managing users, groups, policies, policy bindings, or OAuth clients.
• Non-human identities - service users, the API tokens of every environment, including personal access tokens, and platform tokens. Each token is paired with a credential that shows its status (active, disabled, or expired), expiry, last use, scopes, and creation date, which is also its last rotation because Dynatrace tokens are never re-keyed. Each token is linked to the user who owns it. Oleria never reads token secrets.
• Groups - groups and their members, including service users. The built-in group that holds every user appears as a dynamic group, and groups that come from SAML or SCIM appear as synced groups.
• Roles - IAM policies (the policies Dynatrace provides, and your own account and environment policies) and role-based permissions such as Manage users and Access environment, with each group’s assignments and their scope: the account, one environment, or one management zone. Dynatrace assigns roles only to groups, so users get their roles through group membership.
• Resources - the account, which contains every environment, and each environment, with the groups that can access it through which policies or permissions, and the API tokens that can act on it with their scopes. A policy bound at the account level reaches every environment.
• Activity - the account audit log, which records changes to groups, group membership, policies, policy bindings, and tokens. Oleria also reads the last 30 days of each environment’s classic audit log, with logins and configuration and token changes, when audit logging is turned on in the environment. Each event reads as a sentence that names the members added or removed, such as “admin@example.com removed ci-bot from group Deployers”, and links to the environment or the account in Dynatrace.

Oleria refreshes this data on its regular sync schedule.

​

Prerequisites

• A Dynatrace SaaS account and access to Account Management with permission to create OAuth clients.
• Admin access to the Oleria workspace.

Each Oleria integration covers one Dynatrace account. If you have several accounts, add one integration for each.

​

Create an OAuth client in Dynatrace

Read scopes, for discovery: If you leave out an optional scope, Oleria skips that data and still syncs the rest. Write scopes, only if you want Oleria to take remediation actions:

​

Connect Dynatrace to Oleria

If Oleria reports that Dynatrace refused the OAuth client, check the client ID, client secret, and account UUID, and confirm that the client has the account-idm-read scope. If Oleria reports that the OAuth client lacks a required scope, grant that scope to the client in Dynatrace and select Authenticate again.

​

Verify the integration

Confirm Dynatrace appears on the Connected tab of your Oleria Integrations page. After the first sync completes, you can review the discovered users, groups, roles, environments, and tokens in your Oleria workspace.

​

Remediation actions

Beyond discovery, Oleria can act on Dynatrace access to remediate risk. Remediation needs the write scopes described above. Oleria checks each scope before an action runs and reports any that are missing.

​

Known limitations

• No MFA or SSO status. Dynatrace’s APIs don’t expose either, so these fields show as unavailable for users.
• OAuth clients aren’t inventoried. Dynatrace has no public API that lists them.
• No last use or owner for service users. Dynatrace doesn’t expose either, so dormant account detection covers users and tokens, not service users.
• Service users can’t be disabled. Dynatrace can only delete them, so Disable NHI doesn’t apply to service users. To reduce a service user’s access, remove it from groups.
• No disable user action. Dynatrace has no way to suspend a user. Delete user is permanent, so to take access away reversibly, remove the user from groups.
• Platform tokens can’t be disabled from Oleria. Disable NHI covers environment API tokens and personal access tokens. Revoke platform tokens in Dynatrace.
• Environment audit logs cover the last 30 days. Oleria reads the classic environment audit log, not Grail audit events queried with DQL. It skips environments that don’t offer the classic log and still reads the account audit log.
• Administrator detection ignores policy conditions. A group bound to a policy that allows managing users, groups, policies, policy bindings, or OAuth clients makes its members administrators, even if the policy limits that permission with conditions.
• Dynatrace Managed isn’t supported. Oleria reads Dynatrace SaaS accounts. The Account Management API doesn’t list Managed clusters.

​

Contact us

For questions about this integration, contact us at support@oleria.com.