Microsoft Entra ID

This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.

This guide explains what capabilities StrongDM can provide for the management of privileges in Microsoft Entra ID. It also provides setup and configuration instructions to add a Microsoft Entra ID cloud resource in StrongDM and begin using StrongDM to manage Entra ID groups for your StrongDM users. StrongDM users in your organization can be granted privilege levels for a Microsoft Entra ID resource. Those privilege levels add them to Entra ID groups, so that when the users use Entra ID to authenticate to services as normal, their access is elevated based on those groups for a limited period of time.

Microsoft Entra ID resources in StrongDM can be used to support the use case of Just-in-Time access. Admins have the choice between providing temporary access directly to particular users within the StrongDM organization, or granting JIT access through access workflows. StrongDM users are able to use these access workflows set up by an admin to request various levels of access that correspond to Entra ID group membership. For more details on how Access Workflows function, see the Access Workflows section.

Limitations

• The Microsoft Entra ID resource type is unique. No end user connections are facilitated for Microsoft Entra ID resources. Instead, users can be directly added to or can request to be added to Entra ID groups via StrongDM’s privilege levels. They can then authenticate to services using Entra ID as they normally do, but with elevated permissions provided by the Entra ID groups.

• Currently, Microsoft Entra ID privilege levels cannot be used in policies.

• Currently, Microsoft Entra ID resources cannot be added to access rules within roles or dynamic access rules in workflows.

Prerequisites

• In StrongDM, you must have the Admin permission level.

• You must have administrator access to your Microsoft Entra Admin Center.

• Your StrongDM organization must have Enterprise capabilities.

Privilege Levels

Privilege levels for the Microsoft Entra ID resource type are slightly different than the Kubernetes privilege levels offered by StrongDM. The functionality is the same for the day-to-day admin of StrongDM, selecting privilege levels to assign to users who access the resource, or approving and denying requests for access to the resource. However, for Microsoft Entra ID resource types, privilege levels represent Entra ID groups that the user is added to (or removed from) within Entra ID.

Privilege levels are required in order for the Microsoft Entra ID resource to be useful, as StrongDM is not facilitating user authentication and connection with Azure. StrongDM privilege levels assign the user within Entra ID with groups, which an administrator can use to provide further privileges to the user through Entra ID groups.

Node Configuration

You must configure your node to be able to authenticate to Microsoft Entra ID and assign Entra ID groups to your resources. This can be done either using a node hosted on an Azure VM, or by creating an enterprise application to connect your node hosted elsewhere to the Azure portal. If you wish to perform IAM discovery using the Microsoft Management API, you should also grant those permissions.

Configure your node using one of these:

• Configure your Azure VM node (hosted in Azure)

• Configure your node with an enterprise application (hosted elsewhere)

If you intend to use IAM discovery to help manage groups, follow these steps as well:

• Microsoft Management API permissions for discovery of IAM

Configure your Azure VM node

You can use managed identities to attach permissions to your Azure VM node.

1. In the Azure portal, go to the Overview blade of your node, and then go to Security > Identity.

2. Switch the status of the System Assigned identity to On and wait for it to provision.

3. Azure does not allow you to directly set permissions on a managed identity via the Admin portal, so you will need to run a powershell script to grant the relevant permissions:

   • Microsoft Graph Directory.Read.All: This permission allows your node to get all of the groups needed by name.

   • Microsoft Graph GroupMember.ReadWrite.All: This permission allows your node to put your users into (and remove them from) the groups found.

   • (optional) Microsoft Graph RoleManagement.ReadWrite.Directory: This permission allows your node to manage role-assignable groups. This permission is necessary if you are planning on managing role-assignable groups.

4. Run the following powershell script, replacing <NODE_VM_NAME> with the name of the Azure VM running your node.

   Connect-AzureAD
   
   $GraphAppId = "00000003-0000-0000-c000-000000000000"
   $VMName = "<NODE_VM_NAME>"
   $AppPermissions = "Directory.Read.All","GroupMember.ReadWrite.All","RoleManagement.ReadWrite.Directory"
   
   $GraphApp = Get-AzureADServicePrincipal -Filter "appId eq '$GraphAppId'"
   $ManagedIdentity = Get-AzureADServicePrincipal -Filter "displayName eq '$VMName'"
   
   foreach ($AppPermission in $AppPermissions)
   {
      $Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq $AppPermission}
      $AppRoleAssignment = New-AzureADServiceAppRoleAssignment -ObjectId $ManagedIdentity.ObjectId -PrincipalId $ManagedIdentity.ObjectId -ResourceId $GraphApp.ObjectId -Id $Role.Id
      $AppRoleAssignment
   }

5. Search for "tenant" in the top bar, go to the Tenant Properties view, and copy your Tenant ID.

You should then set up your Microsoft Entra ID resource in StrongDM.

Configure your node with an enterprise application

You can also use a node that is not an Azure VM by adding it as an enterprise application in the Azure portal and using credentials to authenticate.

1. In the Azure portal, go to Enterprise Applications > New application > Create your own application.

2. In the dialog, for the What's the name of your app? field, enter a useful name. For What are you looking to do with your application?, select Register an application to integrate with Microsoft Entra ID. Then, select Create.

3. The Name field is populated with what you wrote in the previous view. You can choose who can use the application and a Redirect URI based on your needs, and then select Register.

4. Back in the Enterprise Applications view, you should be able to search for your new application name and open it.

5. Under Security > Permissions, select Application Registration in the Permissions section.

6. Select Add a permission, and in the dialog, choose Microsoft Graph and then choose Application permissions.

7. Search for and add the read and write permissions that you need:

   • Microsoft Graph Directory.Read.All: This permission allows your node to get all of the groups needed by name.

   • Microsoft Graph GroupMember.ReadWrite.All: This permission allows your node to put your users into (and remove them from) the groups found.

   • (optional) Microsoft Graph RoleManagement.ReadWrite.Directory: This permission allows your node to manage role-assignable groups. This permission is necessary if you are planning on managing role-assignable groups.

8. After adding your permissions, you must check the box that says Grant admin consent for and confirm with Yes.

9. Still in the Application Registration, go to Certificates and secrets in the sidebar and in the Client secrets tab, select New client secret.

10. In the dialog, enter a Description and Expires date for your credential as desired.

11. Copy and record safely the Value, which you will need later.

12. Return to your application overview for the enterprise application and copy the Application ID.

13. Search for "tenant" and go to the Tenant Properties view to copy your Tenant ID.

14. Leaving Azure, connect to your node and set the following environment variables with the corresponding values that you copied (retain the Tenant ID for StrongDM configuration as well):

• AZURE_TENANT_ID=<TENANT_ID>: The Tenant ID you copied previously

• AZURE_CLIENT_ID=<APPLICATION_ID>: The Application ID you copied previously

• AZURE_CLIENT_SECRET=<CLIENT_SECRET_VALUE>: The client secret Value you copied previously

You should then set up your Microsoft Entra ID resource in StrongDM.

Microsoft Management API permissions for discovery of IAM

Microsoft Management API permissions are only required if you would also like to discover your tenant's IAM structure to aid in selecting groups to provision. These will only be used when the resource in StrongDM is marked Discovery Enabled.

Management API permissions are granted via role assignments. In order for discovery to function, these will need to be assigned at the tenant root management group level. You should be able to find either your Application or Managed Identity when searching for members to assign.

It is recommended to create a custom role with just these permissions to allow for least-privilege access, but if you would like to use a Built In Role Security Reader contains all the necessary permissions.

The required permissions are:

"permissions": [
    {
        "actions": [
            "Microsoft.Authorization/roleAssignments/read",
            "Microsoft.Management/managementGroups/read",
            "Microsoft.Resources/subscriptions/resourceGroups/read",
            "Microsoft.Authorization/roleDefinitions/read"
        ],
        "notActions": [],
        "dataActions": [],
        "notDataActions": []
    }
]

Set up Microsoft Entra ID in StrongDM

Verify the node is reachable

If you look at the Microsoft Entra ID resource in the Admin UI, under Diagnostics, since your gateway is running with credentials the healthcheck should already be successful. The nodes in the diagnostics list that are healthy are the ones with access.

If you have set up a proxy cluster to communicate with Azure, the healthcheck should be successful as long as you have assigned the proxy cluster to the resource.

You can also tag your nodes with the tag sdm admin nodes update <NODE_ID> --tags sdm__azure_tenant=<TENANT_ID> (note the two underscores between sdm and azure). This forces StrongDM to use this node (and any other node tagged in this manner) to connect, regardless of the health status of it or any other node that has been configured to access Azure.

Set up Identity Aliases

1. Set up an Identity Set for use with your Microsoft Entra ID resource in the Admin UI at Principals > Identity Sets > Add set. See the Identity Alias section for more information on Identity Sets.

2. Open the Principals > Users page, find a user you wish to add to this Identity Set, open the user’s details page, and choose the Identity Aliases tab.

3. Select Add Alias, and then fill out the alias as the user’s exact Microsoft User principal name, such as [email protected].

When you set up the Microsoft Entra ID resource with StrongDM and select this Identity Set, the StrongDM user can be added to this resource with various privilege levels to manage the groups of the corresponding user in Entra ID.

Set up the resource in StrongDM

Admin UI setup

If you prefer to set up your Microsoft Entra ID resource in StrongDM using the CLI, skip this step and read the CLI setup section. If you want to set up your Microsoft Entra ID resource in the StrongDM Admin UI, go to Resources > Clouds in the Admin UI and click the Add cloud button.

Set the following properties:

Property	Requirement	Description
Display Name	Required	A meaningful name for this resource; displays throughout StrongDM; no special characters like quotes (") or angle brackets (< or >)
Cloud Type	Required	Microsoft Entra ID
Proxy Cluster	Required	Defaults to “None (use gateways)”; if using proxy clusters, select the appropriate cluster to be used for Entra ID group manipulation
Discovery Enabled	Optional	Enable discovery for this resource
Tenant ID	Required	Azure Tenant ID
Subscription ID	Optional	Subscription ID restricts available discovered groups to those within a subscription; appears when discovery is enabled
Management Group ID	Optional	Management Group ID restricts available discovered groups to those within a management group; appears when discovery is enabled
Resource Group ID	Optional	Resource Group ID restricts available discovered groups to those within a resource group; appears when discovery is enabled
Group Names	Optional	Filter string(s) that restrict available discovered groups, comma separated; supports wildcards such as "M365 Admin*"; appears when discovery is enabled
Privilege Levels	Required	Exact names of the Entra ID groups that you want to provision access to, comma separated, such as sdm_group1,sdm_group2; appears when discovery is not enabled
Identity Set	Required	Identity Set to map to use to map StrongDM users to Entra ID users
Resource Tags	Optional	Enter tags consisting of key-value pairs <KEY>=<VALUE> (for example, env=dev)

Click Create to save the configuration settings.

CLI setup

If you would rather set up your Microsoft Entra ID resource using the CLI, open your terminal. While logged in to StrongDM, use the following command:

sdm admin clouds add entraID [command options] <name>

You can view all help text and options by appending --help or -h to the same command:

NAME:
   sdm admin clouds add entraID - create Microsoft Entra ID cloud

USAGE:
   sdm admin clouds add entraID [command options] <name>

OPTIONS:
   --discovery-enabled          Enable discovery for the tenant.
   --egress-filter value        apply filter to select egress nodes e.g. 'field:name tag:key=value ...'
   --group-names value          Enter one or more group names to match. Use commas to separate multiple names. Supports wildcards (e.g., M365 Admin*). Only groups with matching names will be discovered.
   --identity-set-id value      (required)
   --identity-set-name value    set the identity set by name
   --management-group-id value  Restrict discovery to groups associated with this management group. Useful for multi-subscription organizations with a shared hierarchy.
   --privilege-levels value     comma separated list of Entra Group Names (conditional)
   --proxy-cluster-id value     proxy cluster id
   --resource-group-id value    Restrict discovery to groups associated with a resource group.
   --subscription-id value      Restrict discovery to groups linked to this Azure subscription. Use this if you only want groups associated with a specific subscription.
   --tags value                 tags e.g. 'key=value,...'
   --template, -t               display a JSON template
   --tenant-id value            the tenant to authenticate with (required)
   --timeout value              set time limit for command

Manage Entra ID Group Membership With StrongDM

There are currently two ways to grant privileges to StrongDM users on an Microsoft Entra ID resource. You can grant temporary access in the Admin UI by going to Principals > Users and then the Temporary Access tab and selecting the resource.

Alternatively, you can create an access workflow that facilitates JIT access for users using a static access rule that specifies the Microsoft Entra ID resource. Users can then request various privilege levels for the resource and be approved or denied by configured approvers.

At this time, granting and revoking privilege levels via dynamic access rules or directly through StrongDM roles is not available.

StrongDM periodically verifies that the user is still a member of the relevant Entra ID group(s), and re-adds them if necessary, until the access grant in StrongDM expires or is revoked.

Verifying group membership additions or revocations

Once a user has been granted a privilege level, you can verify this by checking your Entra ID group membership directly and see that the user is now in the corresponding group.

If they are removed from the privilege level in StrongDM, they are also removed from the group in Entra ID. Note that revocations also work when the group was originally granted outside of StrongDM.

For example, if Alice was added to the group engineers1 directly in Entra ID and then later was given a privilege level in StrongDM that corresponds to the engineers1 group as well, when her access in StrongDM is revoked, she is removed from the Entra ID group.

Connection through CLI

When a user requests access to an Microsoft Entra ID resource via an access workflow through the CLI, they need to append a --entraGroup option to their command:

sdm access to <RESOURCE_ID> --duration 10m --reason "example reason for request" --entraGroup sdmGroup1

Logs

When a user is given a privilege level for a Microsoft Entra ID resource, StrongDM Activity logs reflect this with events that say User external grant provisioned.

Activity log events when a user privilege level for a Microsoft Entra ID resource is revoked in StrongDM say User external grant revoked.

No user actions against Microsoft Entra ID resources are logged, since StrongDM does not facilitate connections or authentication for users.

Connect to Microsoft Entra ID

In summary, before users can connect to the Entra ID services with the groups that are provided through privilege levels, the following things must occur:

• The node is given correct Azure permissions.

• An Identity Set is configured and Identity Aliases are added to users.

• The Microsoft Entra ID resource is configured in StrongDM, using the Identity Set and with configured privilege levels that correspond to existing Entra ID groups.

• Temporary access is granted to user(s) or an access workflow is set up to allow requests for access.

Once the resource is configured correctly, and once the user is assigned privilege levels within StrongDM or requests and is granted them, the user should be able to authenticate and connect as normal, now with escalated privileges via the additional Entra ID groups.

Using the StrongDM Desktop application or CLI to launch the resource is not necessary, as the user was directly added to Entra ID groups. The user can simply go to authenticate to various services using Entra ID as normal.

Troubleshooting

• Healthchecks for this resource type get and check the Azure token for permissions, so any error messages or failed routes through nodes should appear in the Diagnostics tab in the Admin UI.

• If you’re having intermittent errors converging, try tagging nodes that you are certain are healthy with sdm__azure_tenant=<TENANT_ID>. This forces those healthy nodes to be selected, and you can see if your connections work when using only the healthy nodes.

• If your users are failing to be provisioned or revoked, check the activity logs for any “user external grant provision failed” or “user external grant revocation failed” logs.