Azure AD app management policies help tenants with hardening application security posture

News of sophisticated, patiently planned and executed attacks have been common lately, but in the overall picture, they’re largely the exception. In fact, many breaches are only possible because of a single key element – the human factor, and one of its inherent qualities – laziness. The developer crowd is certainly not the exception here. Ignoring best practices and coding standards for the sake of convenience has become a fact of life, even when it comes to storing application “secrets”. A recent study shows just how wide-spread this issue is, with thousands upon thousands of API keys and cryptographic secrets leaked on public code repositories. In turn, this represents an attack vector that even the most inexperienced “script kiddie” can take advantage of.

Microsoft 365 is of course also affected by this. For years, people have been storing credentials for their automated tasks and workflows, often times in plain text. The advent of multi-factor authentication, conditional access policies and security defaults helped address this problem, to an extent. While admins got the tools to enforce modern authentication methods for tasks that run in the context of a user, on the service principal/application front things remain bleak, as those authentication flows are not subjected to the aforementioned controls. At long last, Microsoft is ready to release a set of features that will help assert control over such scenarios, and in this article, we will introduce you to one such feature. Without further ado, meet the Azure AD application authentication method policies.

What are Azure AD application authentication method policies?

In a nutshell, Azure AD application authentication method policies are configuration objects which allow you to control the authentication methods used by application and service principal objects within your tenant’s directory. Note that this does not cover any aspects of the application creation process, nor it affects the permissions granted to the application – these are covered by different controls we already have available in the suite.

Two types of policies are available: a default, tenant-wide policy that covers all application and service principal objects once enabled, and a set of custom policies one can create and assign to specific objects, as needed. The type of restrictions we can currently configure include passwordAddition, which prevents the creation of new client secrets and passwordLifetime, which restricts the maximum validity duration for a client secret. For both types of restrictions, one can additionally configure an enforcement date, limiting the scope to only objects created after the specified datetime.

Configuring the default app management policy

For the time being, application authentication method policies can only be configured via the Graph API. The default tenant-wide policy is pre-created for each tenant, however it is in disabled state and no restrictions are configured. To check the current configuration, one needs to query the /beta/policies/defaultAppManagementPolicy Graph API endpoint, with Policy.Read.All permissions being sufficient for the task. The example below shows the default state of the tenant-wide policy as queried via the Graph explorer tool:

Only a single defaultAppManagementPolicy object can exist in the tenant. The applicationRestrictions and servicePrincipalRestrictions sections define the restrictions that will apply to all application or service principal objects within the directory, respectively. Both types are represented by an appManagementConfiguration object, which in turn contains a passwordCredentialConfiguration object, detailing the restrictions and related properties.

To update the configuration, one must issue a corresponding PATCH request, for which Policy.ReadWrite.ApplicationConfiguration or equivalent permissions are needed. The example below enables the default policy and prevents addition of new password credentials (client secrets) for all application objects created after August 2021:

Testing the effect of the default policy configuration

After executing the PATCH request, we can review the policy settings to confirm the changes were applied. On the screenshot below, we can see that the tenant-wide policy is now enabled and has restriction of type passwordAddition configured for any application object created after August 2021. In effect, this configuration will prevent adding client secrets to any newly created application. At the same time, no third-party apps (service principals) will be affected, as we didn’t configure any servicePrincipalRestrictions. Another interesting thing to note is that the policy now has a random GUID “id” value generated, compared to the “null” one we saw above.

So how does the policy affect our apps? If an admin or developer tries to add a new client secret to an application created before August 2021, no changes will be observed. For any newly created applications however, addition of client secrets will be blocked and instead developers will be forced to use the more secure certificate credential method. In the Azure AD blade, this enforcement will be represented by a yellow warning banner and the corresponding New client secret button will be disabled, as shown below:

Going granular with app management policies

As mentioned above, the default tenant-wide policy applies to all application and service principal objects within the organization. This is a great way to ensure all relevant objects will comply with your requirements, however in some cases a more granular approach might be needed. To address such scenarios, Microsoft is also providing a support for custom “resource” policies, which you can assign to specific application or service principal and effectively override the tenant-wide policy.

No custom policies exist in the tenant by default, as you can verify by querying the /beta/policies/appManagementPolicies endpoint. To create a custom policy, one needs to issue a POST request against the /beta/policies/appManagementPolicies endpoint, with Policy.ReadWrite.ApplicationConfiguration permissions. The request should contain a displayName, description and restrictions elements, with the latter defining the controls which will be enforced by the policy. For example, to configure a restriction on the maximum lifetime allowed for a client secret, one can use the following:

Once created, our custom policy is nothing more than a placeholder for the restrictions defined. In order to apply the restrictions, the policy needs to be assigned to specific object(s), by issuing a POST request against the corresponding /applications or /serviceprincipals endpoint, referencing the policyId in the appManagementPolicies facet. For example, to assign the newly created policy to our App1 application object, we can use the following:

Once the policy has been assigned, we can verify its effect by navigating to the Certificates & secrets page for the app in the Azure AD blade. Since the custom policy takes precedence over the tenant-wide one, the first thing you will notice here is that we are actually allowed to add a new client secret. We are however only able to configure a lifetime for the secret in accordance with the policy restrictions, which are conveniently displayed on top of the Add a client secret pane. Values that conflict with the policy will be grayed out:

Additional operations you can perform on custom application authentication method policies include querying, updating and deleting them, listing resources a given policy applies to, as well as (un)assigning them to specific objects within the directory. In the interest of keeping this article to a manageable size, we will refer to the official documentation for additional details on these operations.

Additional details and summary

So far, we haven’t covered how app authentication method policies apply to service principal objects. This is an important scenario, as the majority of applications your organization is using are likely third-party ones, represented via a service principal object within your directory. Defining a set of servicePrincipalRestrictions within the tenant-wide policy or creating custom policies and assigning them to service principal objects as needed will allow organizations to assert some control over the quality of authentication methods used with such third-party applications. In turn, this will drive ISVs to faster adopt best practices!

While application authentication method policies are a great functionality, it’s important to note that they are still in public preview, and as such there might be some rough edges. We already mentioned that currently, all the configuration needs to be performed via the Graph API, which might be off-putting to some admins. Once the feature reaches GA however, we should be able to configure these controls directly from the Azure AD blade.

Going forward, Microsoft is planning to add additional controls and thus address the limited scope of the current version of the feature. Such controls will likely include key credentials (certificate) restrictions, such as limiting the lifetime or issuer. Some other ideas have been floated by customers, such as the ability to limit the number of credentials configurable for a given application or more exotic things such as preventing credential reuse across multiple applications.

In summary, application authentication method policies are a great feature that will help Microsoft 365 customers adhere to the best practices for managing application credentials, as well as assert some pressure on ISVs to do the same. While the feature is still in public preview and there are some rough edges around the support for service principals, going forward we can expect this to turn into a standard configuration, enforced across many organizations.

It is also worth mentioning that this is just one of multiple features Microsoft is planning to launch in this space. Those include the already available app governance, sign-ins for service principals, support for scoped permissions in SharePoint Online, conditional access-like controls for the client credentials flow, and more. Although one can argue that most of these features are long overdue, we cannot overstate their importance and the effect they will have on improving the threat landscape, at least when it comes to Azure AD integrated applications.