Using a Microsoft corporate account and the Sign in with Microsoft option can streamline the sign-in process.
To sign in to Dynatrace SaaS SSO using a Microsoft account
Select Sign in with Microsoft without entering a login in the login field.
On first usage, you are presented with a Permission requested message on the Microsoft portal, where you are asked to allow Dynatrace to process your name and email address before proceeding.
When you select Accept, you are redirected to the Microsoft sign-in screen, where you can easily authenticate with the credentials to your corporate Microsoft account.
Sign in with Microsoft triggers a login process using the OpenID Connect Protocol, but works in the same manner as when you enter your email address in the Dynatrace sign-in form. Signing in with Microsoft can also accelerate the authentication process with Azure: if your domain is configured to use SAML federation with Dynatrace, it will be used as part of the login flow.
Once the user is authenticated in Microsoft, Dynatrace receives their username. Based on the domain of the email address and the environment the user wants to access (see environment discovery algorithm), Dynatrace determines whether to switch to the SAML federation flow or not (see federation discovery algorithm).
If the federation is found, the user is redirected to the SAML IdP for authentication.
If the federation is Azure, the user is seamlessly signed in without needing to re-enter their credentials.
If no eligible SAML federation is found:
Some Azure IdP configurations prohibit users from allowing the Dynatrace OpenID Enterprise Application to give consent to profile information. For a solution, see these instructions for configuring consent and permissions in the Dynatrace Community.
When you use the "Sign in with Microsoft" flow, you're essentially initiating an OpenID Connect (OIDC) authentication process. This flow involves creating a trust relationship between your application and Microsoft Entra ID, which results in the automatic registration of an Enterprise Application in your tenant.
To complete the process, the value of preferred_username field from ID token is required. To receive the preferred_username field in the ID token, your app must request the following scopes during the authentication flow: