Conditional Access for workload identities
Conditional Access policies historically applied only to users when they access apps and services like SharePoint Online. We're now extending support for Conditional Access policies to be applied to service principals owned by the organization. We call this capability Conditional Access for workload identities.
A workload identity is an identity that allows an application or service principal access to resources, sometimes in the context of a user. These workload identities differ from traditional user accounts as they:
- Can’t perform multifactor authentication.
- Often have no formal lifecycle process.
- Need to store their credentials or secrets somewhere.
These differences make workload identities harder to manage and put them at higher risk for compromise.
Important
Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals. In directories without appropriate licenses, existing Conditional Access policies for workload identities will continue to function, but can't be modified. For more information, see Microsoft Entra Workload ID.
Note
Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy.
Conditional Access for workload identities enables blocking service principals:
- From outside of known public IP ranges.
- Based on risk detected by Microsoft Entra ID Protection.
- In combination with authentication contexts.
Implementation
Create a location-based Conditional Access policy
Create a location based Conditional Access policy that applies to service principals.
- Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
- Browse to Protection > Conditional Access > Policies.
- Select New policy.
- Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
- Under Assignments, select Users or workload identities.
- Under What does this policy apply to?, select Workload identities.
- Under Include, choose Select service principals, and select the appropriate service principals from the list.
- Under Target resources > Cloud apps > Include, select All cloud apps. The policy applies only when a service principal requests a token.
- Under Conditions > Locations, include Any location and exclude Selected locations where you want to allow access.
- Under Grant, Block access is the only available option. Access is blocked when a token request is made from outside the allowed range.
- Your policy can be saved in Report-only mode, allowing administrators to estimate the effects, or policy is enforced by turning policy On.
- Select Create to complete your policy.
Create a risk-based Conditional Access policy
Create a risk-based Conditional Access policy that applies to service principals.
- Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
- Browse to Protection > Conditional Access > Policies.
- Select New policy.
- Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
- Under Assignments, select Users or workload identities.
- Under What does this policy apply to?, select Workload identities.
- Under Include, choose Select service principals, and select the appropriate service principals from the list.
- Under Target resources > Cloud apps > Include, select All cloud apps. The policy applies only when a service principal requests a token.
- Under Conditions > Service principal risk
- Set the Configure toggle to Yes.
- Select the levels of risk where you want this policy to trigger.
- Select Done.
- Under Grant, Block access is the only available option. Access is blocked when the specified risk levels are seen.
- Your policy can be saved in Report-only mode, allowing administrators to estimate the effects, or policy is enforced by turning policy On.
- Select Create to complete your policy.
Roll back
If you wish to roll back this feature, you can delete or disable any created policies.
Sign-in logs
The sign-in logs are used to review how policy is enforced for service principals or the expected affects of policy when using report-only mode.
- Browse to Identity > Monitoring & health > Sign-in logs > Service principal sign-ins.
- Select a log entry and choose the Conditional Access tab to view evaluation information.
Failure reason when Conditional Access blocks a Service Principal: "Access has been blocked due to Conditional Access policies."
Report-only mode
To view results of a location-based policy, refer to the Report-only tab of events in the Sign-in report, or use the Conditional Access Insights and Reporting workbook.
To view results of a risk-based policy, refer to the Report-only tab of events in the Sign-in report.
Reference
Finding the objectID
You can get the objectID of the service principal from Microsoft Entra Enterprise Applications. The Object ID in Microsoft Entra App registrations can’t be used. This identifier is the Object ID of the app registration, not of the service principal.
- Browse to Identity > Applications > Enterprise Applications, find the application you registered.
- From the Overview tab, copy the Object ID of the application. This identifier is the unique to the service principal, used by Conditional Access policy to find the calling app.
Microsoft Graph
Sample JSON for location-based configuration using the Microsoft Graph beta endpoint.
{
"displayName": "Name",
"state": "enabled OR disabled OR enabledForReportingButNotEnforced",
"conditions": {
"applications": {
"includeApplications": [
"All"
]
},
"clientApplications": {
"includeServicePrincipals": [
"[Service principal Object ID] OR ServicePrincipalsInMyTenant"
],
"excludeServicePrincipals": [
"[Service principal Object ID]"
]
},
"locations": {
"includeLocations": [
"All"
],
"excludeLocations": [
"[Named location ID] OR AllTrusted"
]
}
},
"grantControls": {
"operator": "and",
"builtInControls": [
"block"
]
}
}
Next steps
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for