Clarify CA policy enforcement for service principals in groups #1731
Conversation
…oup are not enforced for service principals within that group. To apply a policy to a service principal, it must be assigned directly as a workload identity.
There was a problem hiding this comment.
Pull Request Overview
This PR adds a clarification note to the workload identity documentation to address a common misconception about Conditional Access policy enforcement for service principals.
- Adds a [!NOTE] section clarifying that service principals in groups are not subject to group-targeted Conditional Access policies
- Explains that policies must be assigned directly to service principals as workload identities to be effective
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
@NoahJenkins : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit b0866f7: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
This pull request adds an important clarification to the "Conditional Access for workload identities" documentation.
It addresses a common scenario where administrators might add a service principal to a group and assume that any Conditional Access policies targeting that group will apply to the service principal. This is not the case.
This change adds a [!NOTE] to explicitly state that Conditional Access policies are not enforced on service principals through group membership. To be effective, the policy must be assigned directly to the service principal as a workload identity. This helps prevent misconfiguration and ensures administrators understand the correct procedure for securing workload identities.