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.
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:
- 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).
For that matter, at the Automation account level, we click on “Modules”, and we look for “AzureAD”:
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