Configure Microsoft authentication with Entra ID

Configure Microsoft Entra ID and Devolutions Server properly to use Microsoft authentication by following the instructions below.

Devolutions Server supports two authentication modes for Microsoft sign-in: Application permissions (recommended default) and Delegated permissions (for tenants where application permissions are blocked by policy).

Feature	Application	Delegated
Acts as	The app	A user (service account)
Redirect URI	Not required	Required
Admin consent	Required	Required for *.All scopes
Login authentication	Yes	Yes
PAM	Yes	No, use Application
Microsoft 365 email	Yes	No ,use Application
Auto-create users	Yes	Yes

Requirements

• Devolutions Server scheduler installed and running

• A Microsoft Entra ID subscription

• An Entra ID web application for the Devolutions Server web application and the cache

Creation of Entra ID applications and Devolutions Server Microsoft configuration

App registration in the Azure Portal

1. Log in to your Microsoft Azure Portal using administrator credentials.

2. Once logged in, select Microsoft Entra ID in the Azure services section. If you do not see it, click on More services to make other services appear or search for it in the search bar.

3. In the left navigation pane, select App registrations.

4. Click + New registration.

5. Enter a name for the application. This name will not be used outside of the Azure Portal.

6. Set which Supported account types are allowed to connect. Usually, selecting Single tenant only is more than enough for your Entra ID authentication.

7. Set the Redirect URI based on your authentication mode:

   • Application permissions: Set to Web and enter your Devolutions Server instance URL with /api/external-provider-response appended at the end. No further redirect URI configuration is required.

   • Delegated permissions: Set to Web and enter your Devolutions Server instance URL using the following pattern:

     https://<your-dvls-host>/<instance-path>/api/configuration/authentication/azure/connect-callback

     Example for a local instance at /dps:

     http://localhost/dps/api/configuration/authentication/azure/connect-callback

8. Then, in your app registration, go to Authentication – Redirect URI configuration – + Add Redirect URI – Web, and enter the redirect URI. If you are setting up the Application permissions authentication mode, you need to tick the ID tokens (used for implicit and hybrid flows) checkbox here as well. Click on Configure.

9. Select the app registration you just created. In the Certificates & secrets section, click + New client secret.

When the client secret expires, no one will be able to connect to the associated Devolutions Server instance. You will then need to create a new client secret. We recommend setting yourself a reminder before the expiration date.

1. Enter a description and set an expiry date.

2. Click Add.

3. Copy the Value. Be sure to save it in a safe place before switching to another Azure Portal page, as the copy button will no longer be available.

4. Select the app registration you just created.

5. In the API permissions section, click + Add a permission.

6. Select Microsoft Graph.

7. Choose the API permission type and add permissions based on your authentication mode:

   Mode	API Permissions
   Application permissions	User.Read.All, Group.Read.All (type Application) — admin consent required.
   Delegated permissions	User.Read (type Delegated, user-consentable) plus User.Read.All, Group.Read.All (type Delegated) for directory reads — admin consent required for *.All.

openid, profile, and offline_access are implicit OIDC scopes and therefore do not need to be manually added here.

1. Click Add permissions.

2. On the app registration Overview page, located the Application (client) ID in the Essentials section and the Tenant ID in the Basic information section. These will be needed later for the configuration of Devolutions Server so keep the page open.

Authentication mode configuration in Devolutions Server

1. Log in to your Devolutions Server and navigate to Administration – Server settings – Authentication.

2. Under Authentication modes, ensure Authenticate with Microsoft user is enabled.

3. Under Configuration, click on Microsoft authentication.

4. In the Authentication mode dropdown, select a permission model suitable for your environment:

   • Application permissions (recommended default): Devolutions Server authenticates as the app itself using client credentials.

   • Delegated permissions: Devolutions Server impersonates a service account user to make Microsoft Graph calls. Use this mode only if your tenant policy blocks Application permissions.

5. Paste application's tenant ID in the Tenant ID field of the Microsoft Authentication configuration page (see step #18 of the App registration in Azure portal section).

The Use specific client ID for users and user groups cache option should only be checked to support configurations when migrating from an older Devolutions Server version.

1. Paste the Application (client) ID in the Client ID field (see step #18 of the App registration in Azure portal section).

2. Paste the Value in the Secret value field.

3. In the Type of user interaction on login dropdown, set the Entra ID sign-in prompt behavior:

   • Select account (select_account): Always displays the account picker, even if the user already has an active session.

   • Leave at default for silent sign-in when a valid session already exists.

4. For Delegated permissions mode only, in the Service account email field, enter the UPN of the user account Devolutions Server will impersonate for Microsoft Graph calls (e.g., [e-mail]).

5. For Delegated permissions mode only, click Connect to Microsoft. An OAuth sign-in window opens. Sign in with the service account to bind it to Devolutions Server. Once the OAuth flow completes successfully, the Connected status displays the UPN of the bound service account.

6. For Delegated permissions mode only, click Test connection to run a delegated Graph API call and verify the service account token is working correctly.

To revoke the cached token and clear the service account binding at any time, click Disconnect. Do this before changing the service account or rotating credentials.

Rotating the client secret or changing the tenant configuration invalidates the cached delegated token automatically. On service account password change or session revocation, an admin must reconnect from Administration – Server settings – Authentication – Microsoft authentication; the rest of the configuration is preserved.

1. Click Save.

You should now be able to use the Microsoft button on Devolutions Server's web interface.

After activating Microsoft authentication, it may take a while for the cache to load before being able to import users and user groups.

Consent flow

Depending on your tenant configuration, one of the following outcomes will occur after consent is handled:

Scenario	Result
Admin grants tenant-wide consent in the portal	Silent — all users covered, no popup.
Admin doesn't consent + service account holds User Administrator and Groups Administrator roles	First sign-in shows a consent popup; the service account can self-consent.
Admin doesn't consent + service account cannot self-consent	Sign-in blocked with AADSTS65001.

For restricted tenants: users who cannot get tenant-wide admin consent can still operate Delegated mode if they grant the service account the two Entra built-in roles above.

Delegated mode limitations

• Login only: PAM (privileged access) and Microsoft 365 email integration require Application permissions. If you use those features, keep Application mode or run a hybrid configuration with separate app registrations.

• Tenant-wide directory reads: User.Read.All and Group.Read.All are tenant-wide scopes. Entra ID has no native subset scope for OAuth. To restrict which users Devolutions Server can auto-create, use the auto-create restriction by group option in Devolutions Server itself.

• Service account dependency: Delegated mode binds Devolutions Server to a single service account's identity. If the service account is disabled, password-rotated, or has its session revoked, an admin must reconnect via Administration – Server settings – Authentication – Microsoft authentication.