📋 Microsoft Entra Documentation Changes

# [PowerShell](#tab/ms-powershell)

# [Microsoft Graph](#tab/ms-graph)

# [PowerShell](#tab/ms-powershell)

* Administrators who need to Create or modify terms of use and Conditional Access policies need at least the [Conditional Access Administrator](~/identity/role-based-access-control/permissions-reference.md#conditional-access-administrator) role assigned.

1. Select, **New terms**.

> Conditional Access policy controls (including terms of use policies) don't support enforcement on service accounts. We recommend excluding all service accounts from the Conditional Access policy.

title: Building Conditional Access policies in Microsoft Entra

# Building a Conditional Access policy

2. [Device to be marked as compliant](./concept-conditional-access-grant.md#require-device-to-be-marked-as-compliant)

3. [Microsoft Entra hybrid joined device](./concept-conditional-access-grant.md#require-hybrid-azure-ad-joined-device)

4. [Approved client app](./concept-conditional-access-grant.md#require-approved-client-app)

5. [App protection policy](./concept-conditional-access-grant.md#require-app-protection-policy)

6. [Password change](./concept-conditional-access-grant.md#require-password-change)

The Office 365 app grouping in Conditional Access makes it possible to target these services all at once. We recommend using the Microsoft 365 grouping, instead of targeting individual cloud apps to avoid issues with [service dependencies](service-dependencies.md).

Targeting this group of applications helps to avoid issues that might arise because of inconsistent policies and dependencies. For example: The Exchange Online app is tied to traditional Exchange Online data like mail, calendar, and contact information. Related metadata might be exposed through different resources like search. To ensure that all metadata is protected by as intended, admins should assign policies to the Microsoft 365 app.

A complete list of all services included can be found in the article [Apps included in Conditional Access Microsoft 365 app suite](reference-office-365-application-contents.md).

When a Conditional Access policy targets the Microsoft Admin Portals cloud app, the policy is enforced for tokens issued to specific underlying resource application IDs associated with Microsoft admin portals. The app grouping doesn't include the backend services that those portals might call or depend on. To identify service dependencies of the admin portals, use the [Conditional Access audience reporting in sign-in logs](troubleshoot-conditional-access.md#audience-reporting)

Test traffic flow:

1. Validate traffic related to the RDP session **isn’t** in the Global Secure Access traffic logs

1. Access Outlook Online (`outlook.com`, `outlook.office.com`, `outlook.office365.com`), SharePoint Online (`<yourtenantdomain>.sharepoint.com`).

Token expiration and refresh are a standard mechanism in the industry. When a client application like Outlook connects to a service like Exchange Online, the API requests are authorized using OAuth 2.0 access tokens. By default, access tokens are valid for one hour, when they expire the client is redirected to Microsoft Entra to refresh them. That refresh period provides an opportunity to reevaluate policies for user access. For example: we might choose not to refresh the token because of a Conditional Access policy, or because the user is disabled in the directory.

Timely response to policy violations or security issues really requires a "conversation" between the token issuer Microsoft Entra, and the relying party (enlightened app). This two-way conversation gives us two important capabilities. The relying party can see when properties change, like network location, and tell the token issuer. It also gives the token issuer a way to tell the relying party to stop respecting tokens for a given user because of account compromise, disablement, or other concerns. The mechanism for this conversation is continuous access evaluation (CAE), an industry standard based on [Open ID Continuous Access Evaluation Profile (CAEP)](https://openid.net/specs/openid-caep-specification-1_0-01.html). The goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time; however, IP locations policy enforcement is instant.

Before continuous access evaluation, clients would replay the access token from its cache as long as it wasn't expired. With CAE, we introduce a new case where a resource provider can reject a token when it isn't expired. To inform clients to bypass their cache even though the cached tokens aren't expired, we introduce a mechanism called **claim challenge** to indicate that the token was rejected and a new access token needs to be issued by Microsoft Entra. CAE requires a client update to understand claim challenge. The latest versions of the following applications support claim challenge:

For an overview of Token Protection and supported platforms, see [Token Protection in Microsoft Entra Conditional Access](concept-token-protection.md). We recommend reviewing the overview documentation before using this deployment guide.

Users who perform specialized roles like those described in [Privileged access security levels](/security/privileged-access-workstations/privileged-access-security-levels#specialized) are possible targets for this functionality. We recommend piloting with a small subset to begin.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

- **Restrict access to privileged resources**. For this example, lets say you want to allow access to Windows Azure Service Management API from a user who:

- **Block access to organization resources from devices running an unsupported Operating System**. For this example, lets say you want to block access to resources from Windows OS version older than Windows 10. For this scenario, organizations would create the following Conditional Access policy:

- **Do not require multifactor authentication for specific accounts on specific devices**. For this example, lets say you want to not require multifactor authentication when using service accounts on specific devices like Teams Phones or Surface Hub devices. For this scenario, organizations would create the following two Conditional Access policies:

> Microsoft recommends using atleast one system defined or admin configurable device property when using Filter for devices condition in Conditional Access.

- We support applying policy to the Microsoft Edge browser on devices running Windows 11 and Windows 10 version 20H2 and higher with KB5031445.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

Clicking on **Switch Edge profile** opens a window listing their Work or school account along with an option to **Sign in to sync data**.

- Create **New attributes** named *policyRequirement* that **Allow multiple values to be assigned** and **Only allow predefined values to be assigned**. We add the following predefined values:

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

1. Select the **Attribute** we created earlier called *policyRequirement*.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

1. Click **Select**.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.

1. Add the **Client App** column if it isn't shown by clicking on **Columns** > **Client App**.

More information can be found about the problem by clicking **More Details** in the initial error page. Clicking **More Details** reveals troubleshooting information that is helpful when searching the Microsoft Entra sign-in events for the specific failure event the user saw or when opening a support incident with Microsoft.

1. To investigate further, drill down into the configuration of the policies by clicking on the **Policy Name**. Clicking the **Policy Name** shows the policy configuration user interface for the selected policy for review and editing.