Azure AD application registration monitoring: All you need to know 

by | Dec 6, 2022 | BizTalk Community Blogs via Syndication | 0 comments

This post was originally published here

App registrations is a mechanism in Azure AD allowing to work with an application and its permissions. It’s an object in Azure AD that represents the application, its redirect URI (where to redirect users after they have signed in), its logout URL (where to redirect users after they’ve signed out), API access and custom application roles for managing permissions to users and apps. 

As a matter of fact, through an app registration, you can restrict access to an application to only a specific group of users, if needed. An example of this is a solution I built a few years ago where we had two separate apps: a customer-facing app and a management app. Each had its app registration. I’ve restricted access to only a select group of people responsible for managing the system for the management app. 

Associated with an app registration is a service principal, which is the identity of that application. As you undoubtedly know, a service principal has credentials. However, you may not know that these credentials have an expiry date (end-date). If you’re not aware of that and don’t monitor and manage that, you may end up with applications and services that stop working. 

The Microsoft identity platform handles identity and access management (IAM) only for registered applications. Registering an application creates trust between the application and the Microsoft identity platform. 

The trust is unidirectional which means that the registered application trusts the Microsoft identity platform, but not the other way around. 

In Azure AD, applications can be represented in two ways: 

Application objects – Application objects define the application for Azure AD and can be viewed as the definition of the application. This enables the service to understand how to issue tokens to the application based on its settings. 

Service principals – The instance of the application in the user’s directory that controls connections to Azure AD is known as a service principal. 

Monitoring 

Serverless360 is an out-of-the-shelf platform to keep track of the expiration of client secrets for specific app registrations and delivering notifications prior to the expiration date, prompting you to renew it. 

Navigate to the Monitoring section of the resource to specify the number of days before which the expiry alert must be received, that’s pretty much the user has to configure and the rest of the work the platform will take care for you. 

Can you achieve the same from the Azure portal? 

In this section, we’ll see how we can define an Azure Automation runbook that we can run periodically to detect and get a list of those credentials that are either expired or about to expire. 

Setting up the automation runbook 

Creating an Azure Automation runbook can be done through the Azure portal or a CLI. We’ll show the portal way here. 

We first start by creating an Automation account. In the Azure portal, look for “Automation accounts”, then create a new instance: 

Once the account is created, we need to make a runbook (Use an Automation account to do many tasks where each runbook will handle a given task). 

Go to the “Runbooks” section, then click “Create a runbook” and enter the requested information 

You’re then presented with a screen to enter the code for that runbook. Our code will be in PowerShell. We’ll get to the complete source code in the next section. 

For now, I’ve displayed some sample codes:

  • You can notice, in line 3, that we import the “AzureAD” PowerShell module to interact with Azure AD. We use it at line 13 to get the list of all app registrations. 
  • You can notice that, too, between lines 6 and 9, we are authenticating to Azure AD before getting the list of app registrations (again, at line 13). 
From the toolbar (above the text editor), you can save the runbook, test it, publish it (you need to do that before you can use it in production), and revert to the previous version (in case the new version doesn’t work as expected).
 
We need first to install it since we’re importing a module (here, “AzureAD” at line 3). 

For that matter, at the Automation account level, we click on “Modules”, and we look for “AzureAD”: 

Since that module isn’t installed, we need to install it from the gallery by clicking on “Add a module”. We’ll pick 5.1 as the runtime version: 

The code 

The PowerShell code to be added to the runbook is listed?here. Replace the previous code with this one. 

The code is pretty easy to understand. One thing worth mentioning is the $daysToExpire variable that you’ll have to set to an appropriate value for your scenario. It’s intended to detect the service principals whose credentials are about to expire in the x coming days. 

Configuring the permissions for the runbook 

At this point, if you execute the runbook, you’ll notice that it might not work. That’s because the identity under which the runbook runs doesn’t have permissions to interact with Azure AD. 

An Azure Automation account has an associated identity. Find it in the “Connection” section under “Shared resources” in the Azure portal. 

I’ll choose the “AzureRunAsConnection”, which is of type “Service principal”, and give it the appropriate

To find that service principal in Azure AD, I need to search for the name of the Automation account in the list of “All applications” under “App registrations”: 
Since we want to list app registrations from the Azure AD, we need to assign the directory role “Directory readers” to the service principal associated with our Automation account (the one that will execute the runbook) following the least privileges principle. 
 
So, we go to “Roles and administrators” in our Azure AD tenant and select “Directory readers”: 
Then, we add an assignment to our service principal: 
And we’re done. 

The post Azure AD application registration monitoring: All you need to know  appeared first on Steef-Jan Wiggers Blog.

Submit a Comment