Create Azure AD App Registration with Azure CLI 2.0

Previously, I have written about creating an Azure AD App registration using the Microsoft Graph API and PowerShell. But since then, the beta endpoint for creating app registrations had stopped working as reported in this GitHub issue: https://github.com/microsoftgraph/microsoft-graph-docs/issues/1365

Fortunately, I have recently discovered a great way to create Azure AD App Registrations using the Azure CLI 2.0. This also includes adding any permissions the app requires on resources e.g. Microsoft Graph, Office 365 SharePoint Online etc. This has not been previously possible with the Azure AD PowerShell Cmdlets.

So in this post, let's go through what is needed to achieve this:

First, you need to have the Azure CLI 2.0 installed on your machine. Follow this link to get it if you haven't already:
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest

Once you have the CLI, here is the code to create an Azure AD App Registration including the required permissions:

	az login -u $adminUserName -p $adminPassword
	az ad app create --display-name $azureADAppDisplayName `
	--identifier-uris "https://$tenantDomain/$uniqueGUID" `
	--reply-urls "https://$functionAppName.azurewebsites.net/.auth/login/aad/callback" `
	--required-resource-accesses "$executingScriptDirectory/AADApp/requiredResourceManifest.json"

view raw CreateAADApp.ps1 hosted with ❤ by GitHub

	[
	{
	"resourceAppId": "c5393580-f805-4401-95e8-94b7a6ef2fc2",
	"resourceAccess": [
	{
	"id": "594c1fb6-4f81-4475-ae41-0c394909246c",
	"type": "Role"
	},
	{
	"id": "e2cea78f-e743-4d8f-a16a-75b629a038ae",
	"type": "Role"
	}
	]
	},
	{
	"resourceAppId": "00000002-0000-0000-c000-000000000000",
	"resourceAccess": [
	{
	"id": "311a71cc-e848-46a1-bdf8-97ff7156d8e6",
	"type": "Scope"
	}
	]
	},
	{
	"resourceAppId": "00000003-0000-0000-c000-000000000000",
	"resourceAccess": [
	{
	"id": "5b567255-7703-4780-807c-7be8301ae99b",
	"type": "Role"
	},
	{
	"id": "7ab1d382-f21e-4acd-a863-ba3e13f7da61",
	"type": "Role"
	}
	]
	},
	{
	"resourceAppId": "00000003-0000-0ff1-ce00-000000000000",
	"resourceAccess": [
	{
	"id": "678536fe-1083-478a-9c59-b99265e6b0d3",
	"type": "Role"
	}
	]
	}
	]

view raw requiredResourceManifest.json hosted with ❤ by GitHub

The JSON in the requiredResourceManifest.json file can be fetched from the manifest of an App registration already created in Azure AD. So the recommendation would be to manually create an App Registration in Azure AD and configure the required permissions. Once you have the right set of permissions, edit the manifest and grab the JSON from the requiredResourceAccess array.

Trusting the App:

Update (5th April 2019):

The Azure CLI now has a command to grant the app permissions on behalf of the admin as well
https://docs.microsoft.com/en-us/cli/azure/ad/app/permission?view=azure-cli-latest#az-ad-app-permission-admin-consent

az ad app permission admin-consent --id [--subscription]

If you still want to use the portal to grant the permissions you can do so as an Admin by going to the app and clicking on the "Grant Permissions" button:

For more possibilities with the Azure CLI 2.0, checkout the reference: https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest

Sync Azure AD profile properties to SharePoint User Profiles using Azure Durable Functions

Recently, a client had asked us to synchronise user properties from their Azure AD profile to custom properties in their SharePoint UserProfile. This had to be a scheduled process as the data had to be kept up to date as well as it had to cater for any new profiles created in Azure AD/SharePoint.

We decided to use Azure Functions for this given the ease of configuring a timer triggered function (to run on schedule) and also the fact that functions run on a consumption based billing plan. This means that the client would get charged only for when the function executes (oh and also, the first million executions are free every month)

The main challenge we had to overcome was the limitation that an Azure Function has a default timeout of 5 minutes (which can be increased up to 10 minutes at the time of this writing) This means that if we were using a single Azure Function to update SharePoint UserProfile Properties for thousands of users, we were going to hit the timeout sooner or later. 

Fortunately, Durable Functions went GA recently which means that we have a way of managing state in the traditionally "state-less" Azure Functions. With durable functions, we can create an "activity" function to update the SharePoint User Profile properties for a single user. This function can be called in a loop for each user from an "orchestrator" function. Each run of the activity function is treated as a single execution and can be finished in the 5 minute default timeout.

So let's see how this can be done! We are using precompiled C# functions and Visual Studio 2017 to achieve this. Also make sure to have the Durable Functions nuget package installed in your Azure Functions project:
https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.DurableTask/

The Durable Function workflow can be categorised into three different types of functions:

1) Client Function

These are standard Azure Functions which can be triggered by external events like timers, HTTP requests, queues etc. The only difference being they have an OrchestrationClient binding which is required to start orchestrations.

In our case, the Client Function is a simple timer triggered function which uses the OrchestrationClient to start a new Orchestration Function with the name O_SyncProfileProperties

	using Microsoft.Azure.WebJobs;
	using Microsoft.Extensions.Logging;
	using System;
	namespace DFDemo.ProfileSync.Function
	{
	public static class C_StartSync
	{
	[FunctionName("C_StartSync")]
	public static void Run([TimerTrigger("0 0 */4 * * *")]TimerInfo myTimer, [OrchestrationClient]DurableOrchestrationClient starter, ILogger log)
	{
	log.LogInformation($"Profile Sync started at: {DateTime.Now}");
	starter.StartNewAsync("O_SyncProfileProperties", null);
	}
	}
	}

view raw Client_StartSync.cs hosted with ❤ by GitHub

2) Orchestrator Function

As the name suggests, the Orchestrator function acts as a coordinator of the Durable Functions workflow. It does the job of starting, stopping and waiting for activity functions and is also in charge of passing data (or state) in between them.

In our case, it calls the A_GetUsersToSync activity function to get the user profiles from Azure AD (using the Microsoft Graph API which is out of scope for this article) and then loops through the users to call the A_UpdateSharePointProfile function for each user

	using DFDemo.ProfileSync.Infrastructure.Model;
	using Microsoft.Azure.WebJobs;
	using System.Collections.Generic;
	using System.Threading.Tasks;
	namespace DFDemo.ProfileSync.Function
	{
	public static class O_SyncProfileProperties
	{
	[FunctionName("O_SyncProfileProperties")]
	public static async Task Run([OrchestrationTrigger]DurableOrchestrationContext durableCtx)
	{
	//Get users from Azure AD using the Microsoft Graph API
	List<Person> usersToSync = await durableCtx.CallActivityAsync<List<Person>>("A_GetUsersToSync", null);
	//Update SharePoint user profile property for each user.
	//This will execute the Activity functions in sequence one after the other for each user.
	foreach (var user in usersToSync)
	{
	await durableCtx.CallActivityAsync("A_UpdateSharePointProfile", user);
	}
	//This will execute the activity functions for each user in parallel.
	//If you have a large number of users, make sure to include code to handle if you get throttled by SPO
	//as a result of making a large number of requests in parallel
	/*var tasks = new List<Task>();
	foreach (var user in usersToSync)
	{
	var task = durableCtx.CallActivityAsync("A_UpdateSharePointProfile", user);
	tasks.Add(task);
	}
	await Task.WhenAll(tasks);*/
	}
	}
	}

view raw Orchestrator_SyncProfileProperties.cs hosted with ❤ by GitHub

3) Activity Functions

As you might have guessed by now the Activity function is the one which actually does all the heavy lifting. For example, the actual CSOM code which will update the SharePoint UserProfile properties will live in the A_UpdateSharePointProfile activity function:

	using Microsoft.SharePoint.Client;
	using Microsoft.SharePoint.Client.UserProfiles;
	using System.Threading.Tasks;
	namespace DFDemo.ProfileSync.Function
	{
	public static class A_UpdateSharePointProfile
	{
	//So that all instances of the function share a common clientContext without the need to initialize it everytime.
	private static ClientContext tenantContext;
	[FunctionName("A_UpdateSharePointProfile")]
	public static async Task Run([ActivityTrigger]Person user, ILogger log)
	{
	if (tenantContext == null)
	{
	//Custom helper function to get tenant context. You will need to create your own.
	tenantContext = await SPAuthentication.GetAppOnlyTenantContext();
	}
	var peopleManager = new PeopleManager(tenantContext);
	string userLoginName = $"i:0#.f|membership|{user.UserPrincipalName}";
	peopleManager.SetSingleValueProfileProperty(userLoginName, "SPDFDemoLocation", user.Location);
	await tenantContext.ExecuteQueryAsync();
	}
	}
	}

view raw Activity_UpdateSharePointProfile.cs hosted with ❤ by GitHub

And that's it! In 3 simple steps, we have a Durable Functions Orchestration set up. For more information on Durable Functions including dos and don'ts, please see the documentation: https://docs.microsoft.com/en-us/azure/azure-functions/durable-functions-overview

Hope you found this post useful!