Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update concept-conditional-access-grant.md #1302

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

goncalo12345
Copy link

The idea is to explain the order in which the conditional access policy evaluates grant controls. MFA is at the top of the list, followed by device validation and then Terms of Use.

That will help customers to understand how to read logs when grant control requires TOU or device ID and is pending MFA , TOU and device requirement will show as "failure"

The idea is to explain the order in which the conditional access policy evaluates grant controls. MFA is at the top of the list, followed by device validation and then Terms of Use.

That will help customers to understand how to read logs when grant control requires TOU or device ID and is pending MFA , TOU and device requirement will show as "failure"
Copy link
Contributor

@goncalo12345 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Copy link
Contributor

Learn Build status updates of commit 7490bc1:

✅ Validation status: passed

File Status Preview URL Details
docs/identity/conditional-access/concept-conditional-access-grant.md ✅Succeeded

For more details, please refer to the build report.

For any questions, please:

@Court72
Copy link
Contributor

Court72 commented Jan 6, 2025

@MicrosoftGuyJFlo

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Comment on lines +204 to +209
> [!NOTE]
> When multiple grant controls are applied to a user, it's important to understand that conditional access policies follow a specific validation order by design. For example, if a user has two policies requiring Multi-Factor Authentication (MFA) and Terms of Use (ToU), the conditional access will first validate the user's MFA and then the ToU.
If the MFA claim is not present in the token, you will see an "interrupt" (pending MFA) and a failure for ToU, even if the ToU was already accepted in a previous sign-in.
Once the MFA is completed, a second log will appear, validating the ToU. If the user has already accepted the ToU, you will see success for both MFA and ToU. However, if the MFA claim is present in the token, a single log will show success for both MFA and ToU.
If multiple policies are applied to a user requiring MFA, Device State, and ToU, the process will be similar. The validation order will be MFA, Device State, and then ToU.

Copy link
Contributor

@MicrosoftGuyJFlo MicrosoftGuyJFlo Jan 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
> [!NOTE]
> When multiple grant controls are applied to a user, it's important to understand that conditional access policies follow a specific validation order by design. For example, if a user has two policies requiring Multi-Factor Authentication (MFA) and Terms of Use (ToU), the conditional access will first validate the user's MFA and then the ToU.
If the MFA claim is not present in the token, you will see an "interrupt" (pending MFA) and a failure for ToU, even if the ToU was already accepted in a previous sign-in.
Once the MFA is completed, a second log will appear, validating the ToU. If the user has already accepted the ToU, you will see success for both MFA and ToU. However, if the MFA claim is present in the token, a single log will show success for both MFA and ToU.
If multiple policies are applied to a user requiring MFA, Device State, and ToU, the process will be similar. The validation order will be MFA, Device State, and then ToU.
## Multiple grant controls
When multiple grant controls are applied to a user, it's important to understand that Conditional Access policies follow a specific validation order by design. For example, if a user has two policies requiring multifactor authentication (MFA) and Terms of Use (ToU), Conditional Access first validates the user's MFA claim and then the ToU.
- If a valid MFA claim isn't present in the token, you see an "interrupt" (pending MFA) and a failure for ToU in the logs, even if the ToU was already accepted in a previous sign-in.
- Once multifactor authentication is completed, a second log entry appears, validating the ToU. If the user already accepted the ToU, you see success for both MFA and ToU.
- If a valid MFA claim is present in the token, a single log shows success for both MFA and ToU.
If multiple policies are applied to a user requiring MFA, Device State, and ToU, the process is similar. The validation order is MFA, Device State, and then ToU.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about something like this?

@MicrosoftGuyJFlo
Copy link
Contributor

#label:"triaged"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants