> ## Documentation Index > Fetch the complete documentation index at: https://docs.oleria.com/llms.txt > Use this file to discover all available pages before exploring further. # Dynatrace > Connect your Dynatrace account to Oleria to discover who can reach it: users, service users, groups, IAM policies and permissions, environments, API tokens, and audit activity. 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](mailto: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](/integrations/overview.md#sync-model). ## 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 **1. Create the client** In Dynatrace, go to **Account Management** > **Identity & access management** > **OAuth clients** and create an OAuth client for Oleria. Grant it the scopes in the tables below. **2. Copy the credentials** Copy the client ID, the client secret, and the account UUID shown on the **OAuth clients** page. If Dynatrace shows the account as `urn:dtaccount:`, copy only the UUID. **3. Turn on environment audit logging (optional)** Dynatrace records environment logins and configuration and token changes only when audit logging is on. In each environment, go to **Settings** > **Preferences** > **Log audit events** and turn on **Log all audit-related system events**. Read scopes, for discovery: | Scope | What it adds | | :- | :- | | `account-idm-read` (required) | Users, service users, groups, group members, and role-based permissions. Oleria checks this scope when you connect. | | `account-env-read` (required) | Environments and their addresses. Oleria checks this scope when you connect. | | `iam-policies-management` (required) | IAM policies and their bindings, for roles, environment access, and administrator detection. Dynatrace's policy read scopes alone don't return your account's policies. Oleria only reads policies and bindings. Oleria checks this scope when you connect. | | `account-audit-logs-read` | Account audit log activity. | | `environment-api:api-tokens:read` | Environment API tokens and personal access tokens. | | `environment-api:audit-logs:read` | Environment audit log activity. | | `platform-token:tokens:manage` | Platform tokens. Dynatrace offers no read-only scope for them. Oleria only reads platform tokens. | 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](#remediation-actions): | Scope | What it allows | | :- | :- | | `account-idm-write` | Inviting and deleting users, creating groups, and adding users and service users to groups and removing them. | | `environment-api:api-tokens:write` | Disabling and re-enabling environment API tokens. | ## Connect Dynatrace to Oleria **1. Open the integration** Go to your Oleria workspace, select **Integrations**, then select the **Dynatrace** tile. **2. Complete the connection form** | Field | Notes | | :- | :- | | Account UUID | Required. Your Dynatrace account UUID, for example `01234567-89ab-cdef-0123-456789abcdef`. You can't change it after the integration is connected. | | Client ID | Required. The client ID of the OAuth client you created. | | Client Secret | Required. The client secret of the same OAuth client. | | SSO URL (optional) | Leave it empty to use `https://sso.dynatrace.com`. | | Account Management API URL (optional) | Leave it empty to use `https://api.dynatrace.com`. | Leave both URLs empty unless Dynatrace gave your account different hosts. Oleria accepts only `https` addresses on `dynatrace.com`, without a path. **3. Authenticate** Select **Authenticate**. Oleria checks that the OAuth client can sign in to your account, read its groups, and holds the `account-env-read` and `iam-policies-management` scopes, then saves the integration. 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. > [!NOTE] > > If you rotate the client secret in Dynatrace, edit the integration and enter the new secret. Editing the integration always asks for the client secret, so enter the current one if you don't rotate it. You can change the client ID and the URLs, but not the account UUID. ## 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. | Action | What it does | Reversible? | Dynatrace scopes | | :- | :- | :- | :- | | Add user to group | Adds a user or service user to a Dynatrace group. If they're already a member, nothing changes. Groups from SAML or SCIM, and the built-in group that holds every user, are refused; change those memberships in your identity provider. | Yes - removes them from the group. | `account-idm-write`, `account-idm-read` | | Remove user from group | Removes a user or service user from a Dynatrace group. If they aren't a member, nothing changes. Groups from SAML or SCIM, and the built-in group that holds every user, are refused; change those memberships in your identity provider. | Yes - adds them back to the group. | `account-idm-write`, `account-idm-read` | | Create user | Invites the email to the account. If a user with that email already exists, nothing changes. | Yes - deletes the user, even if they've accepted the invitation since. | `account-idm-write`, `account-idm-read` | | Delete user | Deletes a user from the account. Applies to users only, not service users, and never to the account's emergency contact. | No - Dynatrace deletes the user permanently. | `account-idm-write`, `account-idm-read` | | Create group | Creates a Dynatrace group. If a group with that name already exists, nothing changes. | Yes - deletes the group. | `account-idm-write`, `account-idm-read` | | Disable NHI | Disables an environment API token or personal access token so it stops authenticating. A token that's already disabled is left as is. | Yes - re-enables the token. | `environment-api:api-tokens:write`, `environment-api:api-tokens:read`, `account-env-read` | ## 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](mailto:support@oleria.com). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.