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.

So, 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.

Also, suppose you are looking for an out-of-the-box solution rather than building custom solutions. In that case, this article also recommends one that proactively monitors and alerts on Azure app registration credential expiry without any coding or much manual effort.

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 code:

• 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 select “Directory readers”:

Then, we add an assignment to our service principal:

And we’re done.

Setting up a schedule

Schedule configuration can be done in the runbook blade since each runbook can have its schedule:

The process is straightforward, and the frequency depends on your need. Once every 24 hours can be a reasonable frequency.

*Get proactive alerts on credential expiration with out of box solution
*
Building custom solutions by writing lengthy codes and using various Azure services has been the preference to get notified about the credentials that are about to expire. This is because the native-Azure monitoring tools don’t offer any features to fulfill such App registration credential expiry monitoring needs.

But, following the custom approach involves too many manual tasks, might be error-prone, and if you are from the Azure Operations team, you will have to rely heavily on developers.

So, it’s been a goal of Serverless360 to mitigate this enormous drawback by offering to monitor the expiry dates of credentials associated with App registrations, and here is what it’s currently capable of,

-Manage and monitor any number of credentials with ease.
-Get intelligent alerts before a client secret/credential expires.
-Customize the number of days to notify you before the credential expires.
-Extensively view the properties of your Azure App registrations and their credentials.

To sum it up

Azure Automation is an excellent service that you can use for various management tasks. In this article, we’ve used it to detect and list service principals that are either expired or about to expire so we can act on them and decide whether to renew these credentials.