In a previous article, we introduced the concept of Azure AD application management policies, a configuration object that allows tenants to control the type and lifetime of credentials used across Azure AD integrated applications and service principals. Said article was supposed to be published a month back, when the feature was released in preview, but due to some unforeseen delays lingered in limbo for a while. In the meantime, Microsoft has released some new additions to the app management policy controls, so let’s go over them.
First, the policies now support key credential (certificate) restrictions. You could actually see a hint about this in the default tenant policy output, which returns two sections: passwordCredentials and keyCredentials. For the time being, the only restrictions supported for keyCredentials is the lifetime of the certificate, configurable via the asymmetricKeyLifetime property. The example below shows how you can set such restrictions in the default tenant-wide policy:
Keep in mind that the example above is effectively overwriting the existing configuration. If you have already set restrictions for passwordCredentials, make sure to add them to the PATCH request. Here’s how the updated default policy settings look like:
And how do these restrictions affect the app registration/SP credentials, you ask? Basically, it restricts the maximum lifetime of a certificate credential, as in any certificate you want to assign to a given app/sp object must have validity equal to or less than the value specified in the asymmetricKeyLifetime property. Otherwise, you will be greeted by the following error message:
Isn’t that just beautiful? In case you are wondering, the GUID visible in the error message above is the one for the default policy, namely 4f9428ab-d614-4792-8e04-d3dfd3c7fd40.
Moving on to the next set of restrictions. Those include symmetricKeyAddition and symmetricKeyLifetime, both configurable within the passwordCredentials section (not sure why?). Generally speaking, symmetricKeys is not something you should be using, even though configuring them is still possible via PowerShell or by manually editing the manifest file. Since they are much less secure than using assymmetric keys (public/private key pair), being able to prevent their creation is a welcome addition. To do this, add the corresponding elements within the passwordCredentials section. If you want to block the use of symmetric keys altogether, set symmetricKeyAddition restriction, and if you want to limit their lifetime, set symmetricKeyLifetime, or configure both. Here’s an example:
The above restrictions were applied on both application and service principal objects, as part of the default tenant-wide policy. In effect, they should be enforced on every new application or service principal object created after August 1st, 2021. To test whether the restrictions are in effect, we can use the Graph API endpoints, or try to add a key manually via the app manifest. In both cases, we should be prevented from completing this successfully, with an error message similar to the previous scenario:
Do note that the restrictions do not apply to the older Azure AD API endpoints, including the good old New-MsolServicePrincipalCredential cmdlet and it’s sibling from the Azure AD PowerShell module, New-AzureADServicePrincipalKeyCredential.
Overall, these new restrictions were more or less what we expected to be delivered before the app management policies feature goes GA. I’m still having some trouble with getting the service principal restrictions work as expected, or at least as I would expect them to work – preventing third-party applications from actually being added to the tenant, in case they don’t comply with the policy. Once I figure this out, I’ll update here 🙂