Script: Azure Client ID and Secret

Script: Azure Client ID and Secret

A script has been created to make creating an Azure API Client ID and Secret easier and more foolproof.

What it does

This script connects to Azure, generates a secret, creates a client id with the generated secret, assigns permissions to the client id, and then returns the client id and key on screen and out to keys.txt


  • Azure Powershell module
  • Windows 7/2008 R2 and above


  1. Extract the script
  2. Open Powershell
  3. Run the script: .\CreateAzureAPIClient.ps1 [optional client_name] [optional -PasswordManagement]


  • If client_name is not specified, a default name of "Sailpoint Client" will be used.

  • If you are managing multiple tenants, you must log into as an admin on the tenant that you wish to create the Client ID and Secret on.


12/13/2017 v2 - Stop script on bad credentials. Add admin password reset permission, enable with -PasswordManagement flag.

3/28/2018 v2.1 - Generalize script terminology and default client name so it can be used for IdentityIQ and IdentityNow customers both.


I have several Azure AD lifecycle environments and stumbled a little on how to get this script to create the service principal in the correct tenant.  Using my normal domain credentials it was only allowing me to the service principal in "production".

I was, however, able to create a throw-away account as a "Global administrator" in the "development" tenant and use those credentials to run this script.  Please note that you will have to log into the Azure portal and change the temporary password first or you will get a "password expired" notification via powershell.

You may be thinking, "Hey, why not use the -TenantId parameter on the 'New-MsolServicePrincipal' or try to use 'Select-AzureRmSubscription' to change the context to a different tenant/subscription combo"...Well, I thought those things as well and you don't see me posting solutions around them, do you?

I've updated the script to take a tenant GUID as a -TenantId, I'm working on finding another tenant in addition to my lab tenant to test the script on.

I went down the same rabbit hole that you did with the tenantId and select-azurermsubscription - it just doesn't seem like this functionality is available looking at the structure and permissions model for Azure. I'm going to leave the script as is and have admins simply log in with an account on the desired tenant.


If you have access to run the powershell script you should have the ability to create a throw-away user.

A "User Account Administrator" with RoleID fe930be7-5e62-47db-91af-98c3a49a38b1 will not be able to change the passwords of a higher level administrator like a "Company Administrator" / "Global Administrator" with RoleID 62e90394-69f5-4237-9190-012177145e10.

If you want IDN to change the passwords of global admins you will need to change roleid fe930be7-5e62-47db-91af-98c3a49a38b1 for 62e90394-69f5-4237-9190-012177145e10, below

Add-MsolRoleMember -RoleObjectId fe930be7-5e62-47db-91af-98c3a49a38b1 -RoleMemberObjectId $objectID -RoleMemberType servicePrincipal

Add-MsolRoleMember -RoleObjectId 62e90394-69f5-4237-9190-012177145e10 -RoleMemberObjectId $objectID -RoleMemberType servicePrincipal

Added the -PasswordManagement flag which if included will add the new permissions. Thank you kindly for your contribution!

Is the attached script still the recommended/supported way to generate these?  If so, it needs to be updated at least on line 20:

    Connect-MsolService -Credential $Credential

...should probably be:

    Connect-MsolService -Credential $(Get-Credential)

Version history
Revision #:
1 of 1
Last update:
‎Oct 18, 2017 03:59 PM
Updated by: