Azure SAML configuration for Dynatrace

Follow the examples below to configure Azure as the SAML identity provider (IdP) for Dynatrace SSO.

This page describes the IdP (Azure) end of your SAML SSO configuration, not the Dynatrace end. Use it as part of the entire SAML configuration procedure for Dynatrace SaaS if you're using Azure.

While we do our best to provide you with current information, Dynatrace has no control over changes that may be made by third-party providers. Always refer to official third-party documentation from your IdP as your primary source of information for third-party products.

Configuration

  1. In the Azure portal, go to Microsoft Entra ID.
  2. From the leftmost menu, select Manage > Enterprise applications.
  3. Type Dynatrace in the Search application field, then select Dynatrace.
  4. Type the name of the application (for example, Dynatrace) and select Create to add the application. The Overview page of your application will open automatically.
  5. On the application’s overview page, see the Getting Started section, select 2. Set up single sign on. Alternatively, from the leftmost menu, select Manage > Single sign-on.
  6. Select SAML as the single sign-on method.
  7. In Save single sign-on setting pop-up window, select Yes.
  8. In Basic SAML Configuration step, select Edit and set Logout Url to https://sso.dynatrace.com:443/saml2/sp/logout. Save your changes.
  9. In SAML Certificate, download Federation Metadata XML.
  10. Select User and groups from the leftmost menu (Manage > User and groups), to configure user access to the Dynatrace application.
  11. In Dynatrace Account Configuration, provide the metadata you downloaded as Federated Metadata XML and set the following attributes:

First name attribute

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

Last name attribute

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Security group claim attribute

http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

Note that in the SAML message returned by Azure, groups are identified with an ObjectId, not a group name. When configuring the user group mapping, make sure you use ObjectId in Security group claims.

Troubleshooting

Frequently asked questions

Yes, such change is done internally in Azure and would not break the existing federation.