Additional Azure AD app management policy controls introduced

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:

Graph API explorerKeep 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:

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

appMethodPolicyKey2Isn’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:

Updating an app management policy via the Graph explorer toolThe 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:

appMethodPolicyKey4

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 🙂

6 thoughts on “Additional Azure AD app management policy controls introduced

  1. Jeff P. says:

    Great news, I have tested and through API (not azure portal) one can set defaultmanagement policy for both applicationrestrictions/passwordCredentials and applicationrestrictions/KeyCredentials to be active at the same time successfully.

    thanks again for your write up, it has saved me MANY hours of pain and suffering.

    https://graph.microsoft.com/beta/policies/defaultappManagementPolicy

    {
    “isEnabled”: true,
    “applicationRestrictions”: {
    “passwordCredentials”: [
    {
    “restrictionType”: “passwordLifetime”,
    “maxLifetime”: “P365D”,
    “restrictForAppsCreatedAfterDateTime”: “2024-06-25T00:00:00Z”
    },
    {
    “restrictionType”: “symmetricKeyAddition”,
    “maxLifetime”: null,
    “restrictForAppsCreatedAfterDateTime”: “2024-06-25T00:00:00Z”
    }
    ],
    “keyCredentials”: [
    {
    “restrictionType”: “asymmetricKeyLifetime”,
    “maxLifetime”: “P365D”,
    “restrictForAppsCreatedAfterDateTime”: “2024-06-25T00:00:00Z”,
    “certificateBasedApplicationConfigurationIds”: []
    }
    ]
    },
    “servicePrincipalRestrictions”: {
    “passwordCredentials”: [],
    “keyCredentials”: []
    }
    }

    Reply
  2. Jeff P. says:

    Great article! Have you been able to set a defaultappManagementPolicy applicationRestrictions for both keyCredentials asymetrickeylifetime maxlifetime and passwordCredentials passwordLifetime?

    it seems like I can only do defaultappManagementPolicy for applicationRestrictions/PasswordCredentials or applicationRestrictions/KeyCredentials but not both

    Reply
    1. Vasil Michev says:

      Should be possible, though I cannot test this currently due to the Workload Identity license requirements 🙁

      Reply
      1. Jeff P. says:

        I did not know it was tied to the workload identity advanced license. I have the workload identity advanced license trial in my sandbox and will give this a try. When I attempt to do it from the GUI portal.azure.com/entra/security/authentication methods/application policies/default policy, you get the option of enabling default policy restrictions for “Password restrictions” or “Certificate restrictions” but not both. if you configure and enable one, the other moves to “unconfigured”.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.