Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into azuread-elm-arparityupdate

Author: ajburnle

articles/active-directory-b2c/faq.yml

@@ -9,7 +9,7 @@ metadata:
   ms.service: active-directory
   ms.workload: identity
   ms.topic: conceptual
-  ms.date: 09/16/2021
+  ms.date: 10/26/2021
   ms.author: kengaderdus
   ms.subservice: B2C
 
@@ -206,7 +206,15 @@ sections:
           Can I get Azure AD B2C as part of Enterprise Mobility Suite?
         answer: |
           No, Azure AD B2C is a pay-as-you-go Azure service and is not part of Enterprise Mobility Suite.
+          
+      - question: |
+          What Azure AD B2C features are unavailable in Microsoft Azure Government?
+        answer: |
+          The following AD B2C features are currently unavailable in Microsoft Azure Government:
 
+          * API connectors
+          * Conditional Access
+          
       - question: |
           How do I report issues with Azure AD B2C?
         answer: |

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -4,12 +4,12 @@ description: Use filter for devices in Conditional Access to enhance security po
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 10/22/2021
+ms.date: 10/26/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
 manager: karenhoran
-ms.reviewer: sandeo-MSFT
+ms.reviewer: sandeo
 
 ms.collection: M365-identity-device-management
 ---
@@ -109,6 +109,8 @@ The following device attributes can be used with the filter for devices conditio
 | --- | --- | --- | --- |
 | deviceId | Equals, NotEquals, In, NotIn | A valid deviceId that is a GUID | (device.deviceid -eq “498c4de7-1aee-4ded-8d5d-000000000000”) |
 | displayName | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.displayName -contains “ABC”) |
+| deviceOwnership | Equals, NotEquals | Supported values are "Personal" for bring your own devices and "Company" for corprate owned devices  | (device.deviceOwnership -eq “Company”) |
+| isCompliant | Equals, NotEquals | Supported values are "True" for compliant devices and "False" for non compliant devices  | (device.isCompliant -eq “True”) |
 | manufacturer | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.manufacturer -startsWith “Microsoft”) |
 | mdmAppId | Equals, NotEquals, In, NotIn | A valid MDM application ID | (device.mdmAppId -in [“0000000a-0000-0000-c000-000000000000”] |
 | model | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.model -notContains “Surface”) |

articles/active-directory/conditional-access/concept-conditional-access-policies.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 03/17/2021
+ms.date: 10/26/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -23,17 +23,19 @@ How does an organization create these policies? What is required? How are they a
 
 ![Conditional Access (Signals + Decisions + Enforcement = Policies)](./media/concept-conditional-access-policies/conditional-access-signal-decision-enforcement.png)
 
-Multiple Conditional Access policies may apply to an individual user at any time. In this case, all policies that apply must be satisfied. For example, if one policy requires multi-factor authentication (MFA) and another requires a compliant device, you must complete MFA, and use a compliant device. All assignments are logically **ANDed**. If you have more than one assignment configured, all assignments must be satisfied to trigger a policy.
+Multiple Conditional Access policies may apply to an individual user at any time. In this case, all policies that apply must be satisfied. For example, if one policy requires multi-factor authentication (MFA) and another requires a compliant device, you must complete MFA, and use a compliant device. All assignments are logically **ANDed**. If you've more than one assignment configured, all assignments must be satisfied to trigger a policy.
+
+If a policy where "Require one of the selected controls" is selected, we prompt in the order defined, as soon as the policy requirements are satisfied, access is granted.
 
 All policies are enforced in two phases:
 
 - Phase 1: Collect session details 
    - Gather session details, like network location and device identity that will be necessary for policy evaluation. 
    - Phase 1 of policy evaluation occurs for enabled policies and policies in [report-only mode](concept-conditional-access-report-only.md).
 - Phase 2: Enforcement 
-   - Use the session details gathered in phase 1 to identify any requirements that have not been met. 
-   - If there is a policy that is configured to block access, with the block grant control, enforcement will stop here and the user will be blocked. 
-   - The user will be prompted to complete additional grant control requirements that were not satisfied during phase 1 in the following order, until policy is satisfied:  
+   - Use the session details gathered in phase 1 to identify any requirements that haven't been met. 
+   - If there's a policy that is configured to block access, with the block grant control, enforcement will stop here and the user will be blocked. 
+   - The user will be prompted to complete more grant control requirements that weren't satisfied during phase 1 in the following order, until policy is satisfied:  
       - Multi-factor authentication​ 
       - Approved client app/app protection policy​ 
       - Managed device (compliant or hybrid Azure AD join)​ 
@@ -74,9 +76,9 @@ Location data is provided by IP geolocation data. Administrators can choose to d
 
 #### Client apps
 
-By default, all newly created Conditional Access policies will apply to all client app types even if the client apps condition is not configured.
+By default, all newly created Conditional Access policies will apply to all client app types even if the client apps condition isn't configured.
 
-The behavior of the client apps condition was updated in August 2020. If you have existing Conditional Access policies, they will remain unchanged. However, if you click on an existing policy, the configure toggle has been removed and the client apps the policy applies to are selected.
+The behavior of the client apps condition was updated in August 2020. If you have existing Conditional Access policies, they'll remain unchanged. However, if you select on an existing policy, the configure toggle has been removed and the client apps the policy applies to are selected.
 
 #### Device state
 

articles/active-directory/conditional-access/concept-conditional-access-session.md

@@ -71,14 +71,14 @@ For more information, see the article [Configure authentication session manageme
 
 ## Customize continuous access evaluation
 
-[Continuous access evaluation](concept-continuous-access-evaluation.md) is auto enabled as part of an organization's Conditional Access policies. For organizations who wish to disable or strictly enforce continuous access evaluation, this configuration is now an option within the session control within Conditional Access. Admins can make this selection while creating a new policy or while editing an existing Conditional Access policy. 
+[Continuous access evaluation](concept-continuous-access-evaluation.md) is auto enabled as part of an organization's Conditional Access policies. For organizations who wish to disable or strictly enforce continuous access evaluation, this configuration is now an option within the session control within Conditional Access. Continuous access evaluation policies can be scoped to all users or specific users and groups. Admins can make the following selections while creating a new policy or while editing an existing Conditional Access policy.
 
-**Disable** works when **All cloud apps** are selected, and no conditions are selected.
+- **Disable** is accomplished when **All cloud apps** are selected, no conditions are selected, and **Disable** is selected under **Session** > **Customize continuous access evaluation** in a Conditional Access policy.
+- **Strict enforcement** means that any critical event and policy will be enforced in real time. All CAE-capable services always get CAE tokens, whatever the client or user might ask for or do. There are two scenarios where CAE won't come into play when strict enforcement mode is turned on:
+   - Non-CAE capable clients shouldn't get a regular token for CAE-capable services.
+   - Reject when IP seen by resource provider isn't in the allowed range.
 
-**Strict enforcement** means that any critical event and policy will be enforced in real time. All CAE-capable services always get CAE tokens, whatever the client or user might ask for or do. There are two scenarios where CAE won't come into play when strict enforcement mode is turned on:
-
-- Non-CAE capable clients shouldn't get a regular token for CAE-capable services.
-- Reject when IP seen by resource provider isn't in the allowed range.
+:::image type="content" source="media/concept-conditional-access-session/continuous-access-evaluation-session-controls.png" alt-text="CAE Settings in a new Conditional Access policy in the Azure portal." lightbox="media/concept-conditional-access-session/continuous-access-evaluation-session-controls.png":::
 
 ## Disable resilience defaults (Preview)
 

articles/active-directory/conditional-access/media/concept-conditional-access-session/continuous-access-evaluation-session-controls.png

@@ -23,7 +23,7 @@ This article describes how to create a trust relationship between an application
 
 Anyone with permissions to create an app registration and add a secret or certificate can add a federated identity credential.  If the **Users can register applications** switch in the [User Settings](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/UserSettings) blade is set to **No**, however, you won't be able to create an app registration or configure the federated identity credential.  Find an admin to configure the federated identity credential on your behalf.  Anyone in the Application Administrator or Application Owner roles can do this.
 
-After you configure your app to trust a GitHub repo, configure your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources (described in the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure)).
+After you configure your app to trust a GitHub repo, [configure your GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure AD protected resources.
 
 ## Prerequisites
 [Create an app registration](quickstart-register-app.md) in Azure AD.  Grant your app access to the Azure resources targeted by your GitHub workflow.  
@@ -145,4 +145,6 @@ az rest -m DELETE  -u 'https://graph.microsoft.com/beta/applications/f6475511-fd
 Before configuring your GitHub Actions workflow, get the *tenant-id* and *client-id* values of your app registration.  You can find these values in the Azure portal. Go to the list of [registered applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps) and select your app registration.  In **Overview**->**Essentials**, find the **Application (client) ID** and **Directory (tenant) ID**. Set these values in your GitHub environment to use in the Azure login action for your workflow.  
 
 ## Next steps
-[Configure a GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure resources.
+[Configure a GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure resources.
+
+Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.

articles/active-directory/develop/workload-identity-federation-create-trust-github.md

@@ -53,3 +53,4 @@ The workflow for exchanging an external token for an access token is the same, h
 Learn more about how workload identity federation works:
 - How Azure AD uses the [OAuth 2.0 client credentials grant](v2-oauth2-client-creds-grant-flow.md#third-case-access-token-request-with-a-federated-credential) and a client assertion issued by another IdP to get a token.
 - How to create, delete, get, or update [federated identity credentials](/graph/api/resources/federatedidentitycredentials-overview?view=graph-rest-beta&preserve-view=true) on an app registration using Microsoft Graph.
+- Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.