Create an Azure AD service principal (Based on Azure AD App) secured by a Certificate

When working with Azure, you may need to create an Azure AD Application, to act a Service Principal and use it to run operation on Azure resources. This post will show you how to register an Azure AD application secured by a Self-Signed Certificate, all via Powershell. You can modify the third script if you want to create the application using an existing certificate. The used scripts can be downloaded from here

1- Create a pfx certificate

In order to the Azure AD App to be secured, a certificate needs to be created. You can prepare the following information to create your certificate :

  • common name (cn)
  • A password to protect the private key

The files Create-SSCv1.ps1 (for Windows 2008 R2/7) and Create-SSCv2.ps1 (for Windows 2016 /10) are powershell scripts that allow you to create a self-signed certificate.

Example using Create-SSCv1.ps1 (the DNS name replaces the common name)

.\Create-SSCv1.ps1 -DNSName zookeeperazure -Password P@ssw0rdzook -PFXPath c:\-PFXName 

Example using Create-SSCv2.ps1 (More control over some options)

.\Create-SSCv2.ps1 -SubjectName zookeeper -Password P@ssw0rd -PFXPath C:\temp -PFXName 
zookeeper -MonthsValidity 24 -FriendlyName zookeepernva

2- Import the Certifictate the windows Certificates Store

The file Import-CertToStore.ps1 will import the certificate to the personal Store, in order to be used to create the Azure AD App later. Provide the password used on the previous step

.\Import-CertToStore.ps1 -Path C:\temp\zookeeper.pfx -Password P@ssw0rd

3- Create an Azure AD application to act as a Service Principal Name

Use the script file Create-azureadapp.ps1 to create the Azure AD application. The Azure Ad Application should have the same name than the certificate CN, so that the script can work. You will be prompted to login to Azure

.\Create-azureadapp.ps1 -ApplicationName zookeeper

You can see now that an new Application has been added to your Azure AD registered application. Azure Portal à Azure Active Directory à App registration

4- Add the application to an Azure Role

Now that your application has been created, you can assign it to any Azure RBAC role. For example, I assigned the created application (zookeeper) the Reader role on the resource group RG-Azure

Azure Active Directory integration with Salesforce Sandbox

The main goal of this blog is to show how to integrate Salesforce Sandbox environment with Azure Active Directory, using the Windows Azure AD single Sign-On configuration option.

Before continuing, you should meet the following requirements:

  • A valid Azure Active Directory Subscription
  • A Sandbox environment on Salesforce .com with a System Admin user on this environment.

NB: In this blog, i used the ‘.uisandbox’ as a suffix. You should replace it by the suffix attributed to your sandbox platform

1- Why do not use the same integration procedure with Salesforce (non-Sandbox) ?

A question one may ask is why not use the same Azure Active Directory integration procedure with a (non-Sandbox) Salesforce environment (Described here in a Microsoft Article). The reason is simple : When you get a Salesforce Sandbox environment, your Salesforce production user accounts are cloned to  the Salesforce Sandbox environment (Automatically on the refresh process), but a ‘.uisandbox’ suffix is added to the UserName for each user. This is intentional since a user will know that he is using a Sandbox environment and to avoid confusion just by looking to his username. The email address is also modified to a strange format : Example : –> I personally recommend modifying the email address of a user to match its real email address, but it’s not a must. So, the integration procedure for a production SalesForce environment is not valid for the Sandbox one (The users identifiers changed) . A tuning must be brought in order to achieve the integration. This is the blog’s purpose.


There is an Official Microsoft article about configuring salesforce ‘sandbox’ environment with Azure AD, but, it seems that the content is not accurate and you will not be able to successfully configure the integration.

2- How this will work ?

It’s simple. Thanks to the Azure Active Directory new SAML attributes option (Currently In preview) , we will tell Azure Active Directory to add, every time that an authentication is requested, the suffix ‘.uisandbox’ to the UserName claim. Great !

3- Steps for Integrating Salesforce Sandbox environment with Azure Active Directory

3.1- Configure the Salesforce ‘Sandbox’ application on Azure AD

Where : Azure Management portal

A- Deploy the Salesforce sandbox application

First, connect to the Azure Management portal with an Active Directory tenant administrator account. Go to Active Directory –> Domain Name –> Applications and Click on the Add button

Snap 2015-09-07 at 11.37.03

Choose Add an application form the gallery

Snap 2015-09-07 at 11.37.44

On the Search bar, type salesforce. Choose the Salesforce Sandbox. Type a Display Name for this application (Example : MySalesforceSandbox) and click Okay

Snap 2015-09-07 at 11.39.41

Wait for the application to be successful added. Now we can begin configuring our SSO with Azure AD

B- Configure Single Sign-ON

In this phase, we will configure Azure AD to ‘accept’ authentication requests from Salesforce. In other words, we will configure Azure AD as an identity Provider for Salesforce ‘sandbox’.

Click on Configure Single sign-ON

Snap 2015-09-07 at 11.42.29

Select ‘Microsoft Azure AD single sign-On’

Snap 2015-09-07 at 17.04.57

Type the Sign ON URL. The sign-on URL is the Salesforce ‘custom’ Sandbox domain URL. Go to step ‘3.2.A- Create and switch to a custom domain’ if you are not aware of this information. The URL must begin with https:// and ends with

Snap 2015-09-07 at 17.14.08

This step is very important, since it contains ‘required information’ for setting up the SAML settings in Salesforce. Keep the following information:

  • Download the Certificate in a local location. You can name it ‘AzureADSalesforcesandboxsso.cert’
  • Save the following URL to a text file for example (Of course you can retrieve them later)
    • Issuer URL
    • Remote Login URL
    • Remote Logout URL

Snap 2015-09-07 at 17.16.11

Click Next

Type an Email address to receive information about SSO events with this application.

Snap 2015-09-07 at 17.16.47

This phase is completed, now we will pass to the next step, a very crucial configuration.

C- Change the SAML attributes claims to match the Salesforce ‘Sandbox’ users settings

Go to Attributes (Even if this feature is currently on preview, it works as expected)

Snap 2015-09-07 at 17.24.23

The goal is tell Azure AD that the Name it will receive during the SAML handshake, is not the UserName is AzureAD, but it’s a concatenation of the UserName is AzureAD and the ‘.uisandbox’ expression.

For this, we will edit the ‘’ attribute like the following.

Click on the Edit symbol for the ‘’ attribute

Snap 2015-09-07 at 17.28.43

Change it like the following:

Attribute Value : Join()

STRING1 : User.userPrincipalName

String2 : uisandbox

Separator : .

Snap 2015-09-07 at 17.29.51

Click OK then Click Apply Changes

NB: In my example, I used the Name as a claim attribute, you can use the email address if you want. But, you have to also to change it in the SAML settings configuration on salesforce on Step ‘3.2.B- Create a new SAML SSO settings’

3.2- Configure the Salesforce ‘Sandbox’ SSO on Salesforce

Where : Salesforce Sandbox portal

Go to and login with a ‘sandbox’ user account (This user must have System Admin rights on this environment). NB: As discussed, The sandbox user account by default ends with .uisandbox

Snap 2015-09-07 at 11.46.11

A- Create and switch to a custom domain

First step to do is to switch to the sandbox domain if it’s already created, or create a new domain for your environment (For users not familiar with Salesforce domains, a Salesforce domain is just a domain name to be used when connecting to your Salesforce environment, this will make you use a domain name like ‘’ instead of ‘’).

Go to Setup –> Domain Management –> Domains

Snap 2015-09-07 at 12.01.02

If you did not already  created a domain, create a new one.

Now, go to Setup –> Domain Management –> My Domain and login to your domain by clicking on Click here to login

Snap 2015-09-07 at 12.52.42

Once connected, you will be switched to the custom domain

Snap 2015-09-07 at 12.52.58

B- Create a new SAML SSO settings

Now, it’s the main part, where we will configure the settings that will allow the SSO to Azure AD and the matching between the user in Azure AD and in the Salesforce ‘sandbox’.

Go to Setup –> Security Controls –> Single Sign-On Settings and click New

Snap 2015-09-07 at 12.54.12

You will have to provide the following information:

Snap 2015-09-08 at 16.58.03




Name A name for your SSO configuration (Will be shown for users so choose a descriptive  Name) AzureADSSOSandbox
API Name Used by SalesForce, keep it the same as the Name AzureADSSOSandbox
Identity Provider Certificate The Certificate that you bring from the Azure AD SSO configuration (AzureADSSOSalesforce.cert) AzureADSSOSalesforce.cert
Entity Id Used by Salesforce, need to set it to
Issuer Paste here the Issuer URL got from Azure ADD SSO configuration wizard
Request Signing Certificate Which Certificate to use to sign the request Default Certificate
Request Signature Method The method for the Request signing certificate RSA-SHA1
Assertion Decryption Certificate If your assertion is encrypted, choose a certificate to decrypt it with. Otherwise, choose Assertion not encrypted Assertion not encrypted
SAML Identity Type Which identity type will be used Assertion contains User’s username
SAML Identity Location Where the identity is located Identity is in an Attribute element
Attribute Name Which attribute will be used. In our configuration, the name will contain the name that will match the user name in Salesforce ‘sandbox’. In fact, we have to set this attribute in Azure AD to add the ‘.uisandbox’ suffix to the user name
Name ID Format leave it blank
Service Provider Initiated Request Binding HTTP POST
Identity Provider Login URL Paste here the Identity Provider Login URL copied from the Azure AD SSO config wizard
Identity Provider Logout URL Paste here the Identity Provider Logout URL copied from the Azure AD SSO config wizard
Custom Error URL Leave it blank
User Provisioning Enabled Check this box if you want to enable the User Provisioning feature on Azure AD

C- Enable the SSO settings for the ‘salesforce’ domain

This is the last step in this configuration walkthrough. We have now to enable the configured SSO authentication for the ‘salesforce’ sandbox domain.

Go to Go to Setup –> Domain Management –> Domains

Select your ‘sandbox’ domain and click Edit

Snap 2015-09-04 at 12.18.06

Affect the SSO configuration which was created during the previous steps to this domain then click Save


  • You can affect more than one SSO configuration to your domain
  • If you uncheck the ‘Login page’, users will not be able to use local ‘salesforce’ users to login to the domain

3.3- Test the configuration

Now, we can test our configuration.

First, you must assign users or groups to be be authorized to use this application (to use the Azure AD Authentication).

In Azure AD, go to the Application –> Users and Groups. Choose the ‘All Users’ or ‘Groups’ filter and assign the desired users.

Snap 2015-09-07 at 18.08.43

Now connect to the ‘Salesforce’ sandbox URL (sign-on URL ie your Salesforce ‘sandbox’ domain name ). And choose your ‘AzureAD SSO’ that you already configured.

Snap 2015-09-07 at 18.10.52

You have successfully logged using SSO to Salesforce ‘sandbox’ environment.