The Azure PowerShell cmdlets support two authentication techniques: AAD and self-signed X.509 certificates. AAD authentication can be used for both the classic Azure Service Management (ASM) mode and the new Azure Resource Manager (ARM) mode of the Azure cmdlets. Certificate authentication can be used only for ASM mode. Although certificate authentication is the traditional way to authenticate there is no longer any need to use it since AAD authentication works in all modes of Azure PowerShell and provides role-based access control (RBAC) in ARM mode.
There were several presentations at //Build2015 and Microsoft Ignite indicating that, going forward, ARM is central to the consistent management layer for Azure and the Azure Stack. New cmdlets have been added to the Azure cmdlets to support the use of ARM for many Azure resource types - including VMs, Azure Storage and VNETs.
AAD authentication typically makes use of AAD users added either as a co-admin for ASM or to some role for ARM. This identification is normally done in the Production Portal and Preview Portal respectively. However, it is also possible to use a service principal for authentication in ARM mode. David Ebbo has a post showing how to configure a service principal, through the creation of a dummy application, in the Azure Active Directory section of the Production Portal. Max Vaughan has a post showing how to create a service principal using the Azure Active Directory (formerly MSOL) cmdlets. This post builds on these, and shows how to create a service principal and associate it with ARM roles only using PowerShell. Note that there is no portal support for service principals and they are not surfaced into the portal UI. Service principals can be managed through PowerShell.
AAD and Azure Cmdlets
The AAD cmdlets can be downloaded and installed from here. Note that the Microsoft Online Services Sign-In Assistant for IT Professionals must also be installed, and this can be downloaded from the same page. The Azure cmdlets can be downloaded directly from the GitHub release page.
The service principal is added to the AAD tenant using the AAD cmdlets and then given access to ARM mode using the Azure cmdlets. Consequently, the following must be done by a user who is a co-admin for ASM and in the Owner role for ARM. This user must be signed-in to both MSOL and Azure.
The following cmdlet is used to sign-in to Azure:
Add-AzureAccount
The following cmdlet is used to sign-in to MSOL:
Connect-MsolService
If necessary, the following Azure cmdlets can be used to select the desired subscription:
Get-AzureSubscription
Select-AzureSubscription -SubscriptionName "SomeSubscription"
Set-AzureSubscription -SubscriptionName "SomeSubscription " `
-CurrentStorageAccountName "somestorageaccount"
The ARM mode of Azure PowerShell is selected using the following cmdlet:
Switch-AzureMode -Name AzureResourceManager
Service Principal Creation
The following AAD cmdlet is used to add the service principal:
New-MSolServicePrincipal -DisplayName "ServicePrincipalName" `
-Type Password -Value "StrongPassword"
This cmdlet provides output like the following:
DisplayName : TestServicePrincipal
ServicePrincipalNames : {f24663fe-52f4-4d02-a0f9-8a4138b870d9}
ObjectId : 2824dc38-f543-4f4b-91a0-93b490141a18
AppPrincipalId : f24663fe-52f4-4d02-a0f9-8a4138b870d9
TrustedForDelegation : False
AccountEnabled : True
Addresses : {}
KeyType : Password
KeyId : c754f373-e14c-4dae-9981-0b99666c15b9
StartDate : 5/14/2015 6:50:20 AM
EndDate : 5/14/2016 6:50:20 AM
Usage : Verify
The New-MSolServicePrincipal cmdlets has parameters allowing the StartDate and EndDate to be specified. The Get-MsolServicePrincipal cmdlet can be used to retrieve information on all the service principals configured for the tenant or for a specific service principal. For example:
Get-MsolServicePrincipal `
-ServicePrincipalName "f24663fe-52f4-4d02-a0f9-8a4138b870d9"
ExtensionData : System.Runtime.Serialization.ExtensionDataObject
AccountEnabled : True
Addresses : {}
AppPrincipalId : f24663fe-52f4-4d02-a0f9-8a4138b870d9
DisplayName : TestServicePrincipal
ObjectId : 2824dc38-f543-4f4b-91a0-93b490141a18
ServicePrincipalNames : {f24663fe-52f4-4d02-a0f9-8a4138b870d9}
TrustedForDelegation : False
Azure Role Assignment
The New-AzureRoleAssignment cmdlet is used to assign a service principal to a role. This is done at one of the three supported scopes: subscription, resource group or resource. The role assignment is inherited from subscription through resource group to resource. ARM supports three system roles (Owner, Contributor and Reader) as well as many resource-provider specific roles (Virtual Machine Contributor, Virtual Network Contributor, etc.). The Get-AzureRoleDefinition cmdlet can be used to retrieve the list of roles and their definition as follows:
Get-AzureRoleDefinition
The following assigns the service principal to the Virtual Network Contributor role for the WestUSDemo resource group:
New-AzureRoleAssignment `
-ServicePrincipalName "f24663fe-52f4-4d02-a0f9-8a4138b870d9" `
-RoleDefinitionName "Virtual Network Contributor" `
-Scope "/subscriptions/27182818-405e-b406-284590452353/resourceGroups/WestUSDemo"
The Get-AzureRoleAssignment is used to retrieve the role assignments for all users and service principals. For example, the following retrieves the role assignments for the specified service principal:
Get-AzureRoleAssignment `
-ServicePrincipalName "f24663fe-52f4-4d02-a0f9-8a4138b870d9"
ServicePrincipalName : f24663fe-52f4-4d02-a0f9-8a4138b870d9
RoleAssignmentId : /subscriptions/27182818-405e-b406-284590452353/resourceGroups/WestUSDemo/providers/Microsoft.Authorization/roleAssignments/66a4d61a-75ee-4532-8143-ba35c54bda28
DisplayName : TestServicePrincipal
RoleDefinitionName : Virtual Network Contributor
Actions : {Microsoft.ClassicNetwork/virtualNetworks/*, Microsoft.Authorization/*/read, Microsoft.Resources/subscriptions/resources/read, Microsoft.Resources/subscriptions/resourceGroups/read...}
NotActions : {}
Scope : /subscriptions/27182818-405e-b406-284590452353/resourceGroups/WestUSDemo
ObjectId : 2824dc38-f543-4f4b-91a0-93b490141a18
The service principal can be configured as an Azure PowerShell account as follows:
$tenantId = Get-AzureSubscription | `
Where {$_.IsCurrent -eq "True"} | `
Select TenantId
$securePassword = ConvertTo-SecureString "StrongPassword" -AsPlainText -Force
$secureCredential = `
New-Object System.Management.Automation.PSCredential ("f24663fe-52f4-4d02-a0f9-8a4138b870d9", $securePassword)
Add-AzureAccount -ServicePrincipal -Tenant $tenantId -Credential $secureCredential
The Get-AzureSubscription, Select-AzureSubscription and Set-AzureSubscription cmdlets can be used as before to specify that the service principal is used as the account going forward.
![clip_image001[6]](http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-30-98-metablogapi/0250.clip_5F00_image001_5B00_6_5D005F00_thumb.jpg "clip_image001[6]")
