Azure Active Directory

New-SBAZServicePrincipal cmdlet to create new Azure AD Service Principal added to AZSBTools PowerShell module

For the use case of running PowerShell scripts that perform tasks on objects in an Azure subscription, we need to be able to run such scripts under a user context other than the script author which is what typically happens during script development. A Service Principal is an Azure AD user intended for this purpose. The New-SBAZServicePrincipal function automates and simplifies the process of creating an Azure Service principal.


The New-SBAZServicePrincipal function takes the following parameters


This parameter accepts one or more Service Principal names


This parameter accepts a value that represents which Azure cloud to create the SPN in. This parameter default to Azure Commercial cloud. As of 15 March 2018 that list is:

  • AzureCloud
  • AzureUSGovernment
  • AzureChinaCloud
  • AzureGermanCloud

To see the current list, use: (Get-AzureRMEnvironment).Name


This parameter is used to assign Role/Permissions for the Service Principal in the current subscription.
The default value is ‘Owner’ role.
As of 16 March 2018 the following default roles are defined:
API Management Service Contributor
Application Insights Component Contributor
Automation Operator
BizTalk Contributor
Classic Network Contributor
Classic Storage Account Contributor
Classic Storage Account Key Operator Service Role
Classic Virtual Machine Contributor
ClearDB MySQL DB Contributor
Cosmos DB Account Reader Role
Data Factory Contributor
Data Lake Analytics Developer
DevTest Labs User
DNS Zone Contributor
DocumentDB Account Contributor
Intelligent Systems Account Contributor
Log Analytics Contributor
Log Analytics Reader
Network Contributor
New Relic APM Account Contributor
Redis Cache Contributor
Scheduler Job Collections Contributor
Search Service Contributor
Security Manager
SQL DB Contributor
SQL Security Manager
SQL Server Contributor
Storage Account Contributor
Storage Account Key Operator Service Role
Traffic Manager Contributor
User Access Administrator
Virtual Machine Contributor
Web Plan Contributor
Website Contributor
For more details on roles, type in:

Get-AzureRmRoleDefinition | select name,description,actions | Out-GridView


The New-SBAZServicePrincipal function returns a PS Object for each input Service Principal Name containing the following properties:


The New-SBAZServicePrincipal function performs the following tasks for each provided Service Principal name:

  1. Create/Validate Azure AD App. The Azure AD App is required to create a Service Principal. It carries the same name and has an initial URL matching the same name as well
  2. Create/Validate Azure AD Service Principal. The user is prompted to enter the desired password for the SPN. The password is encrypted and saved in the user’s temp folder for use with future automations
  3. Assign the provided Role to the SPN for the current subscription. By default this is the ‘Owner’ role. This allows the created SPN to perform all tasks against the current subscription.

Registered Apps can be also viewed in the Azure portal under Azure Active Directory/App Registrations blade:


$SPList = New-SBAZServicePrincipal -ServicePrincipalName PowerShell01,samtest1

This example creates 2 Service Prinsipals; PowerShell01 and samtest1 in the default Azure Commercial cloud, and assigns them the default Owner Role in the current subscription.

The New-SBAZServicePrincipal function first pops the Azure login Window to identify which subscription to use:

This function has been tested with both Azure Commercial and Azure US GOV clouds.

Next enter the desired password for each of the 2 provided Service Principals:

The function saves the encrypted password to the user temp folder for future use/automation.

It also display console output similar to:

The Service Principals can be used now to run other PowerShell scripts

The newly registered/validated Apps can also be viewed from the Azure Portal

To use the AZSBTools PowerShell module which is available in the PowerShell Gallery, you need PowerShell 5. To view your PowerShell version, in an elevated PowerShell ISE window type


To download and install the latest version of AZSBTools from the PowerShell Gallery and its dependencies, type

Install-Module POSH-SSH,SB-Tools,AZSBTools,AzureRM -Force

AZSBTools contains functions that depend on POSH-SSH, SB-Tools, and AzureRM modules, and they’re typically installed together.

To load the POSH-SSH, SB-Tools, AZSBTools, and AzureRM modules type:

Import-Module POSH-SSH,SB-Tools,AZSBTools,AzureRM -DisableNameChecking

To view a list of cmdlets/functions in SB-Tools, type

Get-Command -Module AZSBTools

To view the built-in help of one of the AZSBTools functions/cmdlets, type

help <function/cmdlet name> -show

such as

help New-SBAZServicePrincipal -show

Setting up Azure AD Connect, 2-way directory synchronization, password write-back, online-password reset

For this demo, I will create a new Azure Active Directory (AAD) called Vertitech3AAD and a new on-premise Active Directory called Vertitech3OP.local (NetBIOS name Vertitech3OP) in a new 2012 R2 AD forest.

Create a new Azure Active Directory:

As of 24 February 2016, creating a directory is available only in the classic portal ( If you try to do it in the new portal (


You’ll simply be redirected to the classic portal:

I created Vertitech3AAD Azure Active directory in Azure, and created an on-premise AD domain called Vertitech3OP.local in new 2012 R2 forest:


I can see the new AAD (Azure Active Directory) domain:


Create new AAD Global Admin user:

We create a new AAD user for AD Connect because we need a Global Admin that has rights to a single AAD. In the new AAD I create a new user with Global Admin permissions:


The new AAD user is created:


Change the temporary user password:

Next, I must change the new user password. I browse to, log off and login again using the new user credentials and temp password:


I’m then prompted to change my password:


Download and install AD Connect on an on-premise machine:

AD Connect can be downloaded from the Azure AD page or this link.


Install AD Connect



Using Express Settings:


Enter the AAD Global Admin user name and password:


And local (on-premise) AD credentials – this account needs to be member of the Enterprise Admins group:


The message/recommendation about custom domain verification can be safely ignored.


AD Connect uses SQL Express – but can be configured to use other on-premise full deployment of SQL:


And we’re all done:


I recorded the machine services in an XML file before installing AD Connect using the Powershell command:

Get-Service | Export-Clixml .\Services1.xml

After installing AD Connect, I ran this small script to identify new services added:

$Services1 = Import-Clixml .\Services1.xml
$NewServices = @()
(Import-Clixml .\Services2.xml) | % {
     if ($_.Name -notin $Services1.Name) {
         $NewServices += $_
$NewServices | sort name | select name, displayname,status | FT -a

We can see 5 new services. Some are running under LocalSystem.


In Computer Management under Local Users and Groups, we can see a number of new local groups that have been created during AD Connect installation:


Only ADSyncAdmins local group has users. It has the local user account (service account for ADSync service) and the domain account that the AD Connect installation ran under,

And in Azure we can see a new Synchronization service account:


Also, note that Directory integration is now Activated:


To view synchronization activity, run Synchronization Service Manager (c:\program files\Microsoft Azure AD Sync\UIShell\miisclient.exe)


User objects in the on-premise AD need to have inheritance enabled for AD Connect to work and synchronize these objects to Azure AD.

Enable Password Write-back:

We can also see Azure AD Connect icon on the desktop (shortcut to “C:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe”)


Which shows the following options:


First option is to View Current Configuration:


Note the default settings above. To change synchronization settings, click Customize Synchronization Options:


Next we enter our Azure AD Global Admin user credentials:


And our local (on-premise) AD admin credentials:


We can select to synchronize all domains and OUs or specific domains and OUs:


As well as optional features:


I check the box to enable Password Write-back, and click Install to reconfigure the synchronization process:



To test synchronization, I create a local AD user:


By default AD Connect synchronizes every 30 minutes. To force a manual synchronization I use this Powershell cmdlet on the AD Connect machine:

Start-ADSyncSyncCycle -PolicyType Delta

Now I can see the user in Azure:


Configure Password Reset Policy:

In the Azure classic portal at, browse to your directory/configure page:


Click the Yes button for ‘Users Enabled for Password Reset’.

Don’t forget to click the Save icon on the bottom center to save and apply your new settings.

Accept the remaining default settings or customize them as needed under the ‘user password reset policy’ section.

I changed the default setting ‘Require Users to Register When Signing in’ from Yes to No. This feature will require users to enter Mobile Phone OR Alternate Email Address as configured in this section. You may want to warn users before hand to expect that requirement, or/and tackle any internal organization/privacy issues related to users’ alternate emails and mobile phone numbers.

One last note here; Password Reset Policy is a directory-wide setting. It will apply to all users. As of 7 March 2016, it cannot be configured to apply to a certain user/group/OU.

Finally, users can change their passwords online using the standard Azure password reset pages/links such as


which can be reached from the settings/password link under for example: