An Azure service principal is a security identity used by applications, services, and automation tools to access designated Azure resources. The service principal is a ‘user identity’ (username and password) with an assigned role/permissions in Azure Active Directory (AAD). The service principal should only need to do specific things, unlike a general user identity. In this example, a new Service Principal will be created in AAD and assigned to an Azure Resource Group. Read here for the steps to register a new Service Principal using PowerShell.
Using the Azure Portal
Adding a service principal in the Azure Portal is very straight forward.
Go to Azure Active Directory > App registrations > Add New application registration > create a Display Name > Save
Assign Name and an URL for a web app – which can be changed at any time later.
Azure assigns an Application/Client ID for the new service principal
To create the Key for the new Service Principal go to Settings > Keys > Add the Display Name into the Description > select Duration > Save
Copy/paste the Key Value saving it before leaving the Keys blade:
The new Service Principal (Login in this example) shows in the list of Azure Active Directory App registrations:
Now apply the new Service Principal ‘Login’ to a specific Resource Group (or subscription). Note that all objects in the Subscription or the Resource Group will inherit the Contributor permission for access. Go to the Resource Group or Subscription or other Azure object > Access control (IAM) > +Add > select permission level/Role that the service principal will be assigned> type in the display name of the new service principal > Select > Save. Note that all objects in the Resource Group will now inherit permission for the service principal to access them as a Contributor
This is a screen shot of the Access control (IAM) for a web app that had the Service Principal added at the Subscription level:
An Azure service principal is a security identity used by applications, services, and automation tools to access designated Azure resources. The service principal is a ‘user identity’ (username and password) with an assigned role/permissions in Azure Active Directory (AAD). The service principal should only need to do specific things, unlike a general user identity. In this example, a new Service Principal will be created in AAD and assigned to an Azure Resource Group. Read here for the steps to register a new Service Principal using the Azure ARM Portal
1. #Login to Azure Subscription
Connect-AzureRmAccount -Subscription <Your Subscription Name>
2. #Declare Variables
$subscriptionId = <YOUR SUBSCRIPTION ID>
$tenantId = <YOUR TENANT ID>
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String 'YOUR SECURE PASSWORD OF CHOICE'
We are currently using an expensive wildcard SSL certificate from a CA for all of our websites, that is expiring soon. Yes – there IS a very simple and straightforward way within Azure to add this wildcard certificate for multiple domain and sub-domain DEV, TEST and PROD Azure-hosted websites – but at an annual cost in excess of $750 Canadian dollars!
With Azure supporting use of Let’s Encrypt, the free, automated and open CA for Azure-hosted websites, we decided to secure all our websites with free LetsEncrypt SSL certificates working for each website before the expensive wildcard SSL expired.
NOTE: The Let’s Encrypt certificates DO expire after 90 days, so a background process using Azure Web Jobs, is necessary to automatically renew and install new certificates. Simon J.K.Pedersen has developed the Azure Let’s Encrypt Web App Site Extension to do the heavy lifting of requesting, installing and renewing of the Let’s Encrypt certificates. What a help this all is! Once the preparations are complete (as outlined below) the new Let’s Encrypt SSL certificate is working in less than 5 minutes.
After reading Simon’s documentation on How to Install, Known Issues, and How to Troubleshoot this is the process we used to change the SSL certificates on our websites. Simon J. K. Pedersen said he is actively working on an Azure extension to create a LetsEncrypt wildcard certificate. That will save even MORE time.
At the time of writing this, moving/migration of VMs with managed disks to a new Azure Subscription, is not supported in Azure. It is possible however, to move managed snapshots of a VM’s vhds to another Azure subscription, and then ‘reconstruct’ the VM using the OS and data disks snapshots or managed disks. The VM object itself is just metadata running the vhds (The Move option for both snapshots or managed disks displays in the Azure portal, but we found that the portal Move option does not work for our various Azure Accounts and Subscriptions.(See screen shot below).) The Move operations of snapshots or managed disks can be done easily via PowerShell.
Why move managed disks to another subscription? For example, once a Dev/Test environment is proven, the typical procedure is to migrate the IaaS infrastructure to an Enterprise Subscription for a production environment. Also, moving copies of snapshots out of the main subscription is beneficial for data retention in case of Disaster Recovery or accidental deletions.
A work around for this current limitation – not being able to move/migrate a VM, is to move the managed snapshot(s) to a new Subscription, and then create new managed disks of OS and data vhds for VM in another subscription. It is also possible to migrate a copy of a snapshot or a managed disk into a Storage Account as a page blob to be used by other subscriptions or even other Azure accounts. Read about moving Snapshots to a Storage Account
Unsuccessful Snapshot Move In ARM Portal:
While the option to Move to another subscription is shown on the snapshot blade, validation of the process failed giving the error that this subscription is not ‘registered to use Microsoft.Computer/ManagedResourcesMove feature…but a snap shot can easily be copied to another subscription via PowerShell.
Azure Snapshots of managed virtual hard drives (vhds) are stored in Resource Groups (as opposed to ‘unmanaged’ Snapshots being stored in storage accounts). While it is possible to move the managed snapshots to another subscription using PowerShell, there are advantages to having a copy of crucial core snapshots readily available and protected as a Page Blobs in a Storage Account.
With PowerShell, copies of the Snapshots can be exported to an Azure Storage Account to be able to:
- Maintain a separated set of crucial snapshot copies that cannot be deleted by accident, helpful as another Disaster Recovery point
- Quickly & easily copy Snapshots to a different Azure account or subscription using Microsoft Azure Storage Explorer and then create new managed disks and VMs in the different Account or subscription
- At the time of this writing, VMs with managed disks cannot be moved from one Azure region to another. The workaround is to export a snapshot of the VMs managed disks to a storage account in a different region, and then re-create the VM with the managed disk(s) in a Resource Group in the different region. Read more here.
1. #Login to Azure Portal (read here for a slick way to select the correct subscription context)
Working in Hyper-V before moving all of our resources from physical servers in datacenters to Azure IaaS or PaaS, we regularly took new snapshots of Virtual Machines (VMs) before testing major development changes, adding Windows updates, testing new application settings etc., to allow us to easily revert to the previous state of the VM if desired. In Azure, snapshots are taken of the virtual disks (vhd), not the VM instance itself. Snapshots are full, read-only copies of the vhds. A new VM is created with new managed disks created from stored snapshots of OS data disks; data disk snapshots are turned into managed data disks and then attached to a VM.
An Azure snapshot of a data or operating system (os) vhd can be used:
- For custom backup/restore of a VMs vhds
- For troubleshooting disk problems.
- To create a copy of production servers for use in development, or the opposite, copy a dev environment into production mode.
- To quickly duplicate a fresh VM instance. For example, we use specific single-tier and double-tier web server/sql server environments that need to be reproduced for various testing scenarios. A new ‘exact copy’ environment, with all accounts and applications in place, can be ready for access within 5 minutes if necessary, using stored Azure Snapshots of the OS and data disks. These are considered ‘specialized’ disks…
- To create a ‘repository’ of prepared OS and data disks for use in creating multiple VM copies.
- To create a dr backup repository of snapshots in a different region or subscription (or both), in case of accidental deletion of key OS or data disks.
- Backing up a VM before making a major change – although it is not possible to revert the VM to the previous state, the VM can be deleted and using the saved snapshots > create new managed OS and data disks > create a new VM using the previous VMs Nic, etc.
One way to move an on-premises Hyper-V Windows virtual machine (VM) with all its user accounts, policies and applications fully intact up to Azure, is to create a specialized disk of the VM’s operating system virtual hard disk (VHD). This specialized VHD is then uploaded to Azure, after being properly prepped to work in the Azure environment and attached to a new VM.
- Only Generation 1 Hyper-V VMs are supported on Azure. Keep this in mind when creating or are considering moving Hyper-V machines to Azure. A Generation 2 Hyper-V VM cannot be converted to a Generation 1 Hyper-V VM.
- The Hyper-V vhdx disk format must be converted to vhd, and the dynamically expanding property of the Hyper-V vhd changed to fixed-sized. This is done easily in PowerShell
- In Azure, the size of a managed or unmanaged VHD can be increased, but not decreased, so to speed the uploading time of the prepared VHD to Azure, make sure the Hyper-V VMs OS disk is as small as possible when the Hyper-VM is first created.
In the 2 sets of .vhdx drives converted to .vhd drives shown below:
With multiple Azure subscriptions within a single Azure account, it is crucial to be logged into the correct Azure subscription (AzureRM Context), to be able to access the Azure resources within a specific subscription, via PowerShell (POSH). There is a default subscription that is set to open with each new POSH session. If this default subscription isn’t the preferred working subscription, you will have to select the correct subscription for every new POSH session.
With the Azure Context Autosave feature (added Sept 2017), it is possible that after setting the subscription for the current session, you can have the Azure credentials, account and subscription information saved and automatically loaded when you open a new POSH window – by using the Enable-AzureRmContextAutosave cmdlet
And for easy subscription selection, I recently found these simple POSH cmdlets here, to be able to brilliantly select the correct Azure Subscription by clicking on the list of Azure subscriptions in the Azure Windows account. No copying and pasting of subscription ID, name and/or tenant ID required!
This is the Export step in the process of generating and uploading self-signed Root and client certificates to Azure for authentication for a Point-to-Site VPN Gateway. The PowerShell to create the root and client certificates is found here.
After creating the self-signed root certificate, it must be exported so it can be uploaded to Azure for the P2S configuration. It is only necessary to export the generated client certificate if it is to be installed on another client/computer. It is automatically installed on the client/computer it was generated from. Instructions are given here for exporting both the .cer file and the client certificate.
Export .cer file from Root Certificate
Export Client Certificate
Azure’s Point-to-Site (P2S) VPN gateway connection creates a secure connection to an Azure virtual network’s (VNet) resources from an individual client computer. A VPN gateway is created on its own subnet in an Azure VNet, and then configured to allow P2S connections. No VPN physical device is required and there are minimal, if any, changes required to be made to the on-prem network. A P2S VPN connection is established by starting it from the client computer.
A P2S solution is useful for connecting to Azure VNets from a remote location or when there are only a few clients that need to access an Azure VNet’s resources. We use a P2S connection as a proof-of-concept (POC) for a .Net Web App hosted within an Azure VM webserver to be able to connect to an on-prem Sql Database.
The following cmdlets and process flow is from an excellent article in Azure Documentation, Configure a Point-to-Site connection to a VNet using native Azure certificate authentication: PowerShell with detailed explanations for each of the following steps – we’ve just put it all together in a single, easy to follow list of PowerShell cmdlets to run sequentially in an elevated Windows PowerShell ISE session, to quickly set up a P2S Gateway – after changing the variables for each use case.
Download Zip of POSH cmdlets
There is also an ARM Quickstart Template Point-to-Site Gateway that will quickly provision a P2S Gateway on Azure for you covering Steps 2 – 7 below!