Why You Should Monitor Azure AD App Client Secret and Certificate Expirations

Monitoring and Alerting on Azure AD App Client Secret and Certificate Expirations

The Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management (IAM) service and an identity provider (IdP).

Azure AD is the backbone for authentication in Microsoft 365 and for thousands of cloud-based SaaS applications.

Azure AD provides several features for your organization and one of the features is the Microsoft Identity Platform. This feature helps developers to build applications where users and customers can sign into the application using their Microsoft identities or social accounts and get authorized access to application APIs or Microsoft APIs like “Microsoft Graph”.

You should register your application with Azure AD to prove your Identity and access resources in both Azure and Office 365 programmatically. Infrastructure as code (IaC) and DevOps Pipeline require an App registration in Azure AD for their automation.

When you register an Azure AD application in the Azure portal, two objects are created in your Azure AD Tenant:

• An application objects
• A service principal object

Application Objects

An Azure AD application is identified by an application object that resides in the Azure AD tenant where the application is registered. The application object is used as a template or blueprint to create one or more service principal objects.

The application object describes three aspects of an application:

• How the service can issue tokens to access the application
• Resources that the application might need to access
• The actions that the application can take

Service Principal Object/Enterprise Applications

An application object on its own cannot do much really. After all, it is only a definition of the application.

This is where the Enterprise Application (Service Principal) comes into the picture. The enterprise application (service principal) object is an instance of Azure AD App registration. To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This requirement is true for both users (user principal) and applications (service principal).

Every Application Object created through the Azure Portal, or using the Microsoft Graph APIs, or AzureAD PS (a PowerShell) module would create a corresponding Service Principal Object in Enterprise applications as shown below and inherits certain properties from that application object:

The service principal object defines:

• What the app can do (permissions) in the specific tenant
• Who can access the app (entity)
• What resources the app can access (scope).

Types of Permissions

There are hundreds of combinations of permissions that can be given to an application. You first need to choose the API you need and then select the permissions you want.

There are two kinds of permissions you can choose:

• Delegated
• Application

Delegated permissions are used when you want to authenticate the currently logged-on user to an API or other services. This typically involves a physical user and a user interface. A delegated permission will never give the user more permissions than they already have within this AD.

Application permissions are used when there is no user present and are usually used for API-to-other-API calls. These are also used for background services in Infrastructure as code (IaC) workflows or DevOps Pipeline services.

Unlike delegated permissions, application permissions, however, uses the app ID and secret or certificate to log in and always has the given permissions of the application. Application permissions always require admin consent as they can give users more permission than their own user account. These means great care should be taken around which permissions are given to an app registration that uses Application permissions.

There is literally only one secret needed to access the application because the app ID is often publicly known. As there is no Multi-Factor Authentication (MFA) available, because this authentication is based on no user interaction, it is a recommended best practice to generate the secrets with an expiration time or rotate them on a scheduled basis by process.

Every service principal object has a Client ID and Client Secret/Certificate. Every client secret has an expiration time period, and it is a best practice to set it to the lowest possible period.

Ideally, you should proactively monitor and audit the application secret expiry limits and proactively create a new secret and update it to avoid application downtime and failures.

There’s an insightful thread on Reddit with users discussing ways to monitor the application secret expiry and receive alerts prior to expiry. Though the Azure App registration shows the expiry status of the secret, you do not get an alert from the portal without using Azure Sentinel tool and users seem to have resorted to a variety of PowerShell, scripts, kusto queries, and similar.

Besides Azure application client secret/certificate expiry, Azure AD administrators need answers to some of the questions below:

• Are any of my application client secrets/certificates expiring soon or have expired?
• Can I get proactive alerts before an application secret/certificate expires?
• Who has created these applications and when?
• Who is the owner for these applications?
• Do any of my applications have dangerous permissions that could allow hackers to compromise my Azure AD tenant?
• Do any of my applications have Admin Consent grants given?

Phishing remains one of the most successful ways to infiltrate an organization. We’ve seen a massive amount of malware attacks happening from users opening infected e-mail attachments or clicking links that redirect them to malicious sites and compromise vulnerable browsers or plugins.

Nobelium (previously known as “Solarigate”) was the most advanced sophisticated Phishing attack in the recent years and many top fortune MNCs were affected. See here for more details on Nobelium attack. Recently, Microsoft has removed a lot of malicious enterprise applications from Azure AD. Please click here for more details.

These compromises demonstrate the need to continuously audit and monitor your Azure AD applications in tenants and the permissions assigned to them by process and to record that this due diligence has occurred. The risk for organizations in failing to have automated processes in place extends beyond security breaches to legal liabilities from increased regulation and compliance requirements.

Monitoring Azure Active Directory Application Registrations with eG Enterprise

eG Enterprise’s Azure Active Directory monitoring answers all of the common questions about Azure AD application client/certificates out-of-the-box without having to write any KQL queries or implement Azure Sentinel.

Dashboards can be accessed out-of-the-box or created with just a few clicks, without having to rely on public domain workbooks.

Besides continually monitoring logs, metrics, and error messages, eG Enterprise also automatically performs deeper diagnostic tests, if issues exist. For example, if the client secrets or certificates are going to expire, details on those Azure AD applications are collected automatically and proactive alerts are sent to you.

Client Secrets about to Expire

Certificates about to Expire

Azure APP Registration Dashboard

A few of the best practices to follow when configuring Azure permissions are given below:

• Enforce MFA on all user accounts
• Don’t share accounts
• Each user should log in with their own identity so that the activity log can be properly audited
• Assign access to security groups not to individual accounts
• Don’t assign access at the resource level where possible
• Assign access based on the least privilege access principle
• Avoid creating custom RBAC roles where possible
• Consider using Privileged Identity Management (PIM) for allowing temporary (just-in-time) access to resources
• Perform Access Reviews to prevent stale access assignments

This blog post is the third one in a series covering monitoring of various aspects of Azure AD, previously I have covered: An Overview of Azure Active Directory (Azure AD) – 101 and How to monitor and audit Azure AD Users, and how to monitor Azure AD audit logs. Many of our customers use eG Enterprise to monitor Azure infrastructures, other clouds, and on-premises infrastructure and applications.

Please see the links below for relevant information:

• Azure Monitoring
• Azure AVD (Azure Virtual Desktops) Monitoring
• Microsoft Monitoring: One-Stop Shop for Everything Microsoft
• Other technologies supported by eG Enterprise