Skip to content

Entra ID application for reset operations

Jump to bottom
directorcia edited this page Jul 28, 2026 · 1 revision

eid-resetapp-set.ps1

Purpose

This script creates or updates a Microsoft Entra application for reset-style operations and configures it with the Microsoft Graph permissions required for common administrative actions. It uses the Microsoft Graph REST API directly through the Azure CLI access token instead of relying on Microsoft Graph PowerShell modules.

The script is designed to be safer for production use by:

  • prompting before making tenant-changing changes
  • supporting an unattended mode with -Force
  • avoiding module dependency issues
  • making the consent flow explicit

Prerequisites

Before running the script, make sure the following are available:

  1. Azure CLI installed and available in PATH
  2. An authenticated Azure CLI session via az login
  3. Permissions in the target tenant to create or update applications, add secrets, create service principals, and update application permissions
  4. Access to Microsoft Graph with the required application permissions and admin consent approval

Required Azure CLI authentication

The script uses Azure CLI to obtain a Microsoft Graph access token:

az account get-access-token --resource-type ms-graph --query accessToken -o tsv

This means you must run the following before the script can work:

az login

If you are working in a specific tenant, you can select it with:

az account set --tenant <tenant-id>

Script parameters

The script accepts the following parameters:

-AppName

Optional. Specifies the display name of the Entra application to create or update.

Default value:

Reset

Example:

./eid-resetapp-set.ps1 -AppName "MyResetApp"

-Force

Optional. Skips the confirmation prompt and proceeds immediately.

Example:

./eid-resetapp-set.ps1 -Force

-SkipConsentUrl

Optional. Prevents the script from copying the consent URL to the clipboard.

Example:

./eid-resetapp-set.ps1 -SkipConsentUrl

Execution flow

The script runs in a straightforward sequence:

  1. Initializes strict mode and error handling.
  2. Validates that Azure CLI is available.
  3. Obtains a Microsoft Graph access token from Azure CLI.
  4. Determines the current tenant ID.
  5. Searches for an existing Entra application with the requested display name.
  6. Prompts for confirmation before making any tenant-changing changes.
  7. Creates a new application if one does not exist, or updates the existing one.
  8. Adds a client secret to the application.
  9. Ensures a service principal exists for the application.
  10. Applies the required Microsoft Graph application permissions.
  11. Builds an admin-consent URL.
  12. Prints a summary and copies the consent URL to the clipboard when enabled.

Detailed operation

1. Startup and configuration

At the top of the script:

  • strict mode is enabled
  • $ErrorActionPreference is set to Stop
  • a helper function is defined to print consistent progress output
  • a confirmation function is defined to gate destructive or tenant-changing actions

This makes the script fail fast and helps prevent accidental changes.

2. Token acquisition

The script calls Azure CLI to retrieve an access token for Microsoft Graph:

az account get-access-token --resource-type ms-graph --query accessToken -o tsv

That token is stored in a script-scoped variable and reused for all REST requests.

3. Tenant detection

The script also asks Azure CLI for the current tenant ID:

az account show --query tenantId -o tsv

This tenant ID is used when constructing the admin-consent URL.

4. Application discovery

The script searches Microsoft Graph for applications whose display name matches AppName:

GET https://graph.microsoft.com/v1.0/applications?$filter=displayName eq '<name>'

If an application exists, the script plans to update it. If not, it will create a new one.

5. Confirmation prompt

Before changing anything in Entra ID, the script prompts the user unless -Force is supplied.

This is the main production-safety guard rail. It prevents accidental execution in the wrong tenant or against the wrong application.

6. Application creation or update

If the application already exists, the script patches it with:

  • the display name
  • the redirect URI configured for https://portal.office.com/

If it does not exist, the script creates a new application with the same redirect URI.

7. Client secret generation

The script then creates an application password using Microsoft Graph:

POST https://graph.microsoft.com/v1.0/applications/{id}/addPassword

This produces a secret that is printed to the console and can be used for authentication.

Important: The secret is shown in the output once. Save it securely because it will not be displayed again later.

8. Service principal handling

The script checks whether a service principal already exists for the application's app ID:

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '<appId>'

If none exists, it creates one with:

POST https://graph.microsoft.com/v1.0/servicePrincipals

9. Required permissions

The script assigns three Microsoft Graph application permissions:

  • User.EnableDisableAccount.All
  • Directory.ReadWrite.All
  • User.ReadWrite.All

These are added through the requiredResourceAccess property of the application object.

10. Admin consent URL

After the app is created or updated, the script builds a consent URL for a tenant administrator:

https://login.microsoftonline.com/<tenant-id>/oauth2/authorize?client_id=<app-id>&response_type=code&redirect_uri=https%3A%2F%2Fportal.office.com%2F&response_mode=query&state=12345&prompt=admin_consent

This URL is:

  • displayed in the console
  • copied to the clipboard unless -SkipConsentUrl is used

The admin must open the link and grant consent for the app to use those permissions.

Output example

When the script completes successfully, it prints a summary similar to:

Application summary:
  Status: Created
  Tenant ID: <tenant-id>
  Object ID: <object-id>
  Application (client) ID: <app-id>
  App Secret: <secret-value>
  Service Principal ID: <service-principal-id>
  Consent URL: <consent-url>

Operational notes

Safety

Because the script can create secrets, modify applications, and update permissions, it should be used carefully. The confirmation prompt helps reduce the chance of accidental execution.

Reliability

Using direct REST requests via Azure CLI avoids several issues that can arise with PowerShell modules, including:

  • module installation differences
  • version mismatches
  • authentication module drift
  • environment-specific dependency issues

Limitations

The script assumes:

  • Azure CLI is installed and current
  • the signed-in identity has sufficient permissions
  • the target tenant is the correct one
  • admin consent will be granted separately through the consent URL

Recommended usage

Run it interactively:

./eid-resetapp-set.ps1

Run it without prompts:

./eid-resetapp-set.ps1 -Force

Use a custom app name:

./eid-resetapp-set.ps1 -AppName "MyApp"

Troubleshooting

Azure CLI not found

Install Azure CLI and ensure it is available in your terminal.

Authentication failure

Run:

az login

Permission denied

Ensure the signed-in account has enough rights to create or update applications in the selected tenant.

Consent not granted

If the admin consent flow is not completed, the application may not be able to use the assigned Graph permissions.

Clone this wiki locally