Customer Lockbox Preview for Azure VMs

Fear of Operator Access

Despite assurances, some customers are worried that Microsoft support engineers or operators might have unfettered access to their data in the cloud. We can use bring-your-own-key encryption, such as BitLocker inside of Azure virtual machines, but that extreme action can have negative side effects.

Office 365 has an opt-in feature called Customer Lockbox. This lockbox concept is not new – some of you working in controlled environments probably experience something like this:

1. You require physical access to a server
2. It is required that you get sign-off from one or two managers
3. You bring the signed form to Security
4. You are granted one-time access to the computer room or rack in question

The Lockbox concept in Office 365 works as follows:

1. You open a support call with Microsoft
2. The support engineer requests access to something in your subscription
3. You grant access via the Office 365 Admin Portal

This feature is being brought to Azure, starting with a preview for Azure virtual machines:

1. You open a support call about an Azure virtual machine with Microsoft
2. The Microsoft support engineer has no access to the machine and asks for access
3. Anyone marked as the “owner” of the subscription will be notified of a support engineer request
4. The owner can grant access to the support engineer via Customer Lockbox in the Azure Portal

Granting Microsoft access via the Customer Lockbox for Azure [Image Credit: Microsoft]

Enabling Customer Lockbox

Customer Lockbox is disabled by default and you must opt into this lockdown feature. Enablement is done on a per-tenant basis using AzureRM PowerShell cmdlets. If you have access to multiple tenants then you will need to identify the Tenant ID of the required Azure AD domain. You can select the correct tenant by doing the following:
Tip: Make sure you have updated to the latest version of the AzureRM PowerShell modules first!
Log into Azure using PowerShell:

Login-AzureRmAccount

Choose the correct tenant and subscription ID:

Select-AzureRmSubscription -TenantID "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -SubscriptionID "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Now you will create two Service Principals (SPN) in Azure AD; the first is the Customer Lockbox Service Principal – type it exactly as shown:

New-AzureRmADServicePrincipal -ApplicationID a0551534-cfc9-4e1f-9a7a-65093b32bb38

The second SPN is for PIM:

New-AzureRmADServicePrincipal –ApplicationID 01fc33a7-78ba-4d2f-a4b7-768e336e890e

Note that if PIM was previously enabled in the tenant then you might get this error, so don’t worry about it:

New-AzureRmADServicePrincipal : Another object with the same value for property servicePrincipalNames already exists.

Now you can verify the SPNs:
Get-AzureRmADServicePrincipal | ? { $_.applicationID -match “a0551534-cfc9-4e1f-9a7a-65093b32bb38”}
That should return something like:

ServicePrincipalNames : {a0551534-cfc9-4e1f-9a7a-65093b32bb38}
ApplicationId                  : a0551534-cfc9-4e1f-9a7a-65093b32bb38
DisplayName                 : AzureLockbox
Id                                   : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
AdfsId                            :
Type                               : ServicePrincipal

Get-AzureRmADServicePrincipal | ? { $_.applicationID -match "01fc33a7-78ba-4d2f-a4b7-768e336e890e"}

And that should return something like:

ServicePrincipalNames : {01fc33a7-78ba-4d2f-a4b7-768e336e890e, https://api.aadr.mspim.azure.com/, https://api.azrbac.mspim.azure.com/, https://mspim.onmicrosoft.com/}
ApplicationId                  : 01fc33a7-78ba-4d2f-a4b7-768e336e890e
DisplayName                 : MS-PIM
Id                                    : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
AdfsId                             :
Type                               : ServicePrincipal

With the above confirmed, you have enabled the preview of Customer Lockbox for Azure virtual machines.