Auditing the use of Managed Service Identity in Azure

Managed Identity in Azure quite simply provides an AAD backed identity for your Web App or Virtual Machine, in order to communicate with other Azure services without explicitly providing credentials.

The range of Azure services that you can communicate with is growing, for the sake of this blog post we’re not going to focus on a specific service – instead querying the control plane to find all applicable RBAC assignments that have been set up for our Managed Identity. Please note that the script and example is all focussed around App Service, not a VM.

Switching it on

Turning on Managed Identity for a Web App you’ve published to Azure is easy. Navigate to the Web App, under settings you’ll finding Managed Service Identity, then flip the toggle box on before hitting Save.

This is what happens under the covers;

The App Gets a nice GUID assigned, this should be familiar to those working with ApplicationId’s and ServicePrincipals.

Toggling it

If you remove the Managed Identity from the app, and then set it back on again then a new PrincipalId is generated and any permissions you’d set up for this identity onto other Azure services will have been removed.

Auditing the Identity permissions

In an ideal world you’ll have a deployment script that sets up permissions for your Web App or VM on it’s dependant services with the least privilege required, however having a way of auditing a deployed applications permissions is going to be helpful in getting to that state. The script I’ve made looks at;

  • All Web Apps in your Azure subscription
  • Reports RBAC assignments for the Web Apps Identity
  • Checks all Keyvaults for Access Policies that the Identity has been allowed to use

The script: https://github.com/Gordonby/Snippets/blob/master/Powershell/Get-ManagedIdentityAssignments.ps1

The script populates two arrays with the pertinent information that you want to capture. From these arrays you can then start building a script that would restore the permissions to be used in a failure scenario.
Here’s what the they look like;

Cloud Solution Architect at Microsoft in the UK.

Azure AD B2C – Using the graph API

There’s a really good guide for getting started with CRUD operations in a AAD B2C tenant on the Azure documentation site;
https://azure.microsoft.com/en-gb/documentation/articles/active-directory-b2c-devquickstarts-graph-dotnet/

As per usual, I’ve ended up putting some powershell together to make it a bit more repeatable when I have to do this for multiple AAD tenants.

This particular script creates the application in the AAD tenant. I’ll be posting further scripts that show off doing some clever stuff when I’ve finished testing and polishing them.

Cloud Solution Architect at Microsoft in the UK.

Azure B2C Unified sign up with Page UI customization

When crafting a new Unified sign-up or sign-in page policy in the Azure Portal I managed to get this error

#error=server_error&error_description=AADB2C90001: The server hosting resource 'https://meetr.azurewebsites.net/account/signinorsignup' is not enabled for CORS requests. Ensure that the 'Access-Control-Allow-Origin' header has been configured.
Correlation ID: 613d1479-d146-4b89-abb8-3264730f5991
Timestamp: 2016-04-13 18:33:30Z

Of course, i’d been a bit quick off the mark and not yet changed my Asp.net website to accept Cross Origin Requests.

Here’s what you’ll need to add to your unified Sign In page to fix the error

Response.AppendHeader("Access-Control-Allow-Origin", "https://login.microsoftonline.com");

Code wise, here’s how the Controller Action and View look;

Cloud Solution Architect at Microsoft in the UK.

Azure AD b2c error – could not load file or assembly ‘microsoft.identitymodel.protocol.extensions’

Following the Azure B2C Dev Quickstarts resulted in a build failure…

Could not load file or assembly ‘Microsoft.IdentityModel.Protocol.Extensions’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The quick fix is to update the Nuget package reference for the Protocol Extensions from version 1.0.0.0 to 1.0.2.33 using the Visual Studio Nuget package manager.

Subsequently the build then fails with this error;

The following errors occurred while attempting to load the app.
– No assembly found containing an OwinStartupAttribute.
– No assembly found containing a Startup or [AssemblyName].Startup class.
To disable OWIN startup discovery, add the appSetting owin:AutomaticAppStartup with a value of “false” in your web.config.
To specify the OWIN startup Assembly, Class, or Method, add the appSetting owin:AppStartup with the fully qualified startup class or configuration method name in your web.config.

The fix for this one is to check your Startup.cs file for the OWIN assembly declaration.

These few changes should then result in a successful build.

Cloud Solution Architect at Microsoft in the UK.