Microsoft Entra PowerShell authentication scenarios

The Microsoft Entra PowerShell module supports several authentication scenarios. This article describes the authentication scenarios for signing into Microsoft Entra ID from the module. The method you choose depends on your use case.

For example, if you're using the module for ad-hoc management of Microsoft Entra resources, you can sign in using an interactive sign-in. If you're writing a script for automation, you can sign in with a service principal. If you're running the module in an Azure resource, you can sign in with a managed identity.

Common authentication scenarios

The two common authentication scenarios are:

• Delegated authentication (interactive) - In this scenario, the application acts on behalf of a signed-in user, accessing resources with the user’s permissions. It requires delegated permissions, which are granted to both the client and the user. The user’s privileges, such as those granted by Microsoft Entra role-based access control (RBAC), determine the extent of access. For more information on delegated authentication, see Authenticate with delegated access.
• App-only authentication (noninteractive) - This scenario allows the application to act solely as itself without a user being signed in. It’s used for scenarios like automation or backup, involving background services or daemons. This scenario utilizes app roles or application permissions, which are granted to the client app to access data associated with the permission. For more information on app-only authentication, see Authenticate with app-only access.

Other authentication scenarios

The Microsoft Entra PowerShell module supports other authentication scenarios that we discuss in the rest of this article.

Sign in to a national cloud

National clouds, also known as sovereign clouds, are physically isolated instances of Azure designed to ensure data residency, sovereignty, and compliance requirements are honored within geographical boundaries. If you have an account in a national cloud, specify the environment using the Environment parameter when you sign in. This parameter is compatible with all sign-in methods. For instance, for an account in Azure China 21Vianet, use the following command:

Connect-Entra -Environment China

Note

Globally registered apps don't replicate to Azure China. You need to register your own applications in Azure China and use them when connecting to Microsoft Graph.

To get a list of available environments, run this command:

Get-EntraEnvironment

Connect to Microsoft Entra ID as a different identity

To connect as a different identity other than CurrentUser, specify the -ContextScope parameter with the value Process.

Connect-Entra -ContextScope 'Process'

Set HTTP client timeout

You can set the HTTP client timeout (in seconds) by running.

Connect-Entra -ClientTimeout 60

Enhance security with the least privilege principle

To keep your Microsoft Entra resources secure, restrict permissions of the identity for the authentication method you choose to use the principle of least privilege. Limiting sign-in permissions as much as possible for your use case helps keep your Microsoft Entra resources secure. For more information, see Enhance security with the principle of least privilege.

We recommend the use of a custom application to help isolate and limit the permissions granted for Microsoft Entra PowerShell usage. To learn how to create a custom application and grant it permissions in Microsoft Entra ID, see Create a custom application to connect with Microsoft Entra PowerShell

See Also

• Authenticate with delegated access
• Authenticate with app-only access
• Best Practices