Application management policies allow for enhanced governance, management and control over application and service principal credentials in Entra ID tenant.
Note:
You’ll find more information in the MS Learn documentation here and here.
Why proper governance over authentication methods for applications and service principals is important?
You say you have very comprehensive, field-tested Conditional Access policies?
Multi-factor authentication and compliant devices mandated for everyone, phishing resistant factors required for critical privileged roles, legacy authentication blocked, user and risk level policies configured, authentication transfer and device code flow blocked for 99% of user base…
You got your entire authentication stack under control, right?
Well, you probably did a very good job but there’s an enhancement waiting.
Conditional Access policies, regardless of how well thought out they are, in a tenant with Entra ID P1/P2 licensing without any add-ons:
- Don’t apply to service principals.
- Can’t govern authentication methods used by application objects and service principals in the tenant.
First point can be partially fixed through equipping your tenant with appropriate amount of Entra ID Workload Identities Premium licenses and applying Conditional Access policies to 1st party service principals. As of now, you can’t apply Conditional Access policies to govern 3rd party service principal access - you must risk accept it.
Holistic authentication strategy must also address risks related to application objects and service principals. What are some of those risks?
- Any consented/pre-consented service principal in your tenant is linked to an application object in your or foreign tenant. If linked to an object in foreign tenant - it represents supply chain risk. Owners of application objects registered in foreign tenants can authenticate as an application to your tenant and use permissions from linked, local service principal instance (Midnight Blizzard attack is a proof of it). That’s why it’s important to thoroughly vet every Entra ID integrated application you’re providing consent for.
- Application objects domiciled in your tenant and all service principals can be used to authenticate and access data in your Entra ID directory or integrated apps. To do that they need credentials. Applying governance over credentials, their types, lifetime, and lifecycle is a good technical measure to reduce risks related to their malicious use.
Tenant-level authentication method policies described below help with reduction of certain risks outlined above, by enforcing baseline level of controls over credentials used by applications and service principals.
Configuration steps
Configuration proposed below enforces following tenant-wide restrictions:
- Application objects - configures client secret lifetime of maximum 365 days, asymmetric credential lifetime of 1095 days, blocks the capability to set arbitrary secrets (i.e. not automatically generated by Entra ID) and ability to add symmetric credentials.
- Service principal objects - configures client secret lifetime of maximum 365 days, asymmetric credential lifetime of 1095 days (default certificate generated by Entra ID during SAML configuration has 3Y lifetime - you can shorten this parameter if you generate your own SAML token signing certs with shorter lifetimes), blocks the capability to set arbitrary secrets (i.e. not automatically generated by Entra ID) and ability to add symmetric credentials.
Microsoft Graph PowerShell is preferred as Entra ID portal GUI is not yet behaving correctly (you can’t configure client secrets restrictions and certificate restrictions to be active at the same time).
Using Microsoft Graph PowerShell to configure Entra ID is always a good idea and a general best practice as well 😀
Import-Module Microsoft.Graph.Beta.Identity.SignIns
#Activate 'Global Administrator' Entra ID role first. If you're prompted for consent, verify app name and domicile (Microsoft Graph Powershell), verify permissions asked for and only then grant your consent.
#Theoretically, 'Security Administrator' is the least privileged role that can be used for completing this configuration, however I was getting '403 Insufficient privileges to complete the operation' from MS Graph during my tests.
#Make sure that 'Microsoft Entra Workload ID Premium' license is present and active in the environment. Otherwise, your policy configuration request will be rejected.
Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
#Gets the current date and moves it back ten years.
#This is to ensure that app management policies will apply to all apps and service principals in the directory
$Date = (Get-Date).ToUniversalTime().AddMonths(-120)
#Actual definition of tenant app management policies
$params = @{
isEnabled = $true
#This section applies to application objects (registered by admin in the directory)
applicationRestrictions = @{
passwordCredentials = @(
@{
#Restricts lifetime of client secrets to 365 days
restrictionType = "passwordLifetime"
maxLifetime = "P365D"
restrictForAppsCreatedAfterDateTime = $Date
}
@{
#Restricts ability to add symmetric keys. This ability is getting deprecated Entra ID, at least for MSFT 1-st party service principals - see: https://mc.merill.net/message/MC792991. This configuration setting will make sure that other objects are also covered.
restrictionType = "symmetricKeyAddition"
maxLifetime = $null
restrictForAppsCreatedAfterDateTime = $Date
}
@{
#Restricts the ability to create arbitrary client secrets. This will block any legacy PowerShell modules that provide a client generated password secret for applications. Instead, it enforces Entra ID service side client secret generation process
restrictionType = "customPasswordAddition"
maxLifetime = $null
restrictForAppsCreatedAfterDateTime = $Date
}
)
keyCredentials = @(
@{
#Restricts maximum lifetime of assymentric key based credentials to 1095 days
restrictionType = "asymmetricKeyLifetime"
maxLifetime = "P1095D"
restrictForAppsCreatedAfterDateTime = $Date
}
)
}
servicePrincipalRestrictions = @{
#This section applies to service principals (application objects domiciled in a foreign directory but for which consent has been granted by an admin in the past). Applied policy is the same as for applications.
passwordCredentials = @(
@{
#Restricts lifetime of client secrets to 365 days
restrictionType = "passwordLifetime"
maxLifetime = "P365D"
restrictForAppsCreatedAfterDateTime = $Date
}
@{
#Restricts ability to add symmetric keys. This ability is getting deprecated Entra ID, at least for MSFT 1-st party service principals - see: https://mc.merill.net/message/MC792991. This configuration setting will make sure that other objects are also covered.
restrictionType = "symmetricKeyAddition"
maxLifetime = $null
restrictForAppsCreatedAfterDateTime = $Date
}
@{
#Restricts the ability to create arbitrary client secrets. This will block any legacy PowerShell modules that provide a client generated password secret for applications. Instead, it enforces Entra ID service side client secret generation process
restrictionType = "customPasswordAddition"
maxLifetime = $null
restrictForAppsCreatedAfterDateTime = $Date
}
)
keyCredentials = @(
@{
#Restricts maximum lifetime of assymentric key based credentials to 1095 days
restrictionType = "asymmetricKeyLifetime"
maxLifetime = "P1095D"
restrictForAppsCreatedAfterDateTime = $Date
}
)
}
}
Update-MgBetaPolicyDefaultAppManagementPolicy -BodyParameter $params
Disconnect-MgGraph
Additional hardening - not for every environment
If you want to entirely disable the ability to create client secrets and rely only on asymmetric credentials, add the following code in the applicationRestrictions and servicePrincipalRestrictions sections:
@{
restrictionType = "passwordAddition"
maxLifetime = $null
restrictForAppsCreatedAfterDateTime = $null
}
Result?
All additions of client secrets for all applications and service principals, regardless of their creation timestamp (restrictForAppsCreatedAfterDateTime = $null is key here) are blocked! (In case you wonder, you can add credentials to service principals too! Only through PowerShell, but still!)
Configuration effects
A. Tenant-wide application authentication methods policy exists but is not enabled.
Addition of a client secret on application object - default Entra ID client secret restrictions are applied.
Addition of an asymmetric key on application object - no particular restricions are applied to asymmetric key credential.
->
B. Tenant-wide application authentication methods policies are configured and enforced as per above configuration.
Addition of a client secret on application object - tenant app management policies are now enforced and restrict client secret lifetime to maximum 1 year.
Addition of an asymmetric key on application object - tenant app management policies are now enforced and reject upload of certificates with lifetime exceeding 2 years.
FAQ:
Q: What happens to the current authentication methods (i.e. secrets and certificates) for already existing applications or service principals?
A: These entities are not impacted until next credential rotation, when tenant-level app management policies will start to be enforced.
Q: What options do I have if I want to apply different policy restrictions to an application or service principal object?
A: You can apply app-specific application policy that would override restrictions set by tenant-wide policies - > see this.
Q: I am getting Update-MgBetaPolicyDefaultAppManagementPolicy : To add and configure organizational settings,you'll need to link a subscription with Azure AD Workload identity license to your tenant. HTTP 400 status code when trying to set the configuration. What shall I do to fix this issue?
A: Make sure you have activated Entra ID Workload Identity Premium license in your tenant.
Q: What is the difference between application and service principal?
A: Entra ID application object is a blueprint used to create one or more service principal objects, which are representing a particular workload in the directory and can be granted permissions.
Application objects exist only in a single tenant. They can be registered by an admin as a single-tenant, or - if created by SaaS software vendor - as a multi-tenant configuration. Multi-tenant applications are used as a template to create concrete instances in the form of service principals in the multiple tenants where users or admins have decided to grant consent and consequently sanctioned the use of an application.
All work is licensed under a Creative Commons Attribution 4.0 International License.
