BuildFixes

Author: MicrosoftGuyJFlo

articles/active-directory/conditional-access/TOC.yml

@@ -88,6 +88,8 @@
       href: howto-policy-persistent-browser-session.md
     - name: Require compliant device, hybrid joined, or MFA for users
       href: howto-conditional-access-policy-compliant-device.md
+    - name: Use application enforced restrictions
+      href: howto-policy-app-enforced-restriction.md
     - name: Require MFA for Intune enrollment
       href: /mem/intune/enrollment/multi-factor-authentication?toc=/azure/active-directory/conditional-access/TOC.json
     - name: Block access by location

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

@@ -21,7 +21,7 @@ When creating Conditional Access policies, administrators have asked for the abi
 
 There are multiple scenarios that organizations can now enable using filter for devices condition. Below are some core scenarios with examples of how to use this new condition.
 
-- **Restrict access to privileged resources**. For this example, lets say you want to allow access to Microsoft Azure Management from a user who is assigned a privilged role Global Admin, has satisfied multifactor authentication and accessing from a device that is [privileged or secure admin workstations](/security/compass/privileged-access-devices) and attested as compliant. For this scenario, organizations would create two Conditional Access policies:
+- **Restrict access to privileged resources**. For this example, lets say you want to allow access to Microsoft Azure Management from a user who is assigned a privileged role Global Admin, has satisfied multifactor authentication and accessing from a device that is [privileged or secure admin workstations](/security/compass/privileged-access-devices) and attested as compliant. For this scenario, organizations would create two Conditional Access policies:
    - Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.
    - Policy 2: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, excluding a filter for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block. Learn how to [update extensionAttributes on an Azure AD device object](/graph/api/device-update?view=graph-rest-1.0&tabs=http&preserve-view=true).
 - **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:
@@ -48,7 +48,7 @@ Policy 1: All users with the directory role of Global Administrator, accessing t
 1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
 1. Select **New policy**.
 1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
-1. Under **Assignments**, select **Users or workload identities**..
+1. Under **Assignments**, select **Users or workload identities**.
    1. Under **Include**, select **Directory roles** and choose **Global Administrator**.
 
       > [!WARNING]
@@ -65,7 +65,7 @@ Policy 2: All users with the directory role of Global Administrator, accessing t
 
 1. Select **New policy**.
 1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
-1. Under **Assignments**, select **Users or workload identities**..
+1. Under **Assignments**, select **Users or workload identities**.
    1. Under **Include**, select **Directory roles** and choose **Global Administrator**.
 
       > [!WARNING]
@@ -89,7 +89,7 @@ Setting extension attributes is made possible through the Graph API. For more in
 
 ### Filter for devices Graph API
 
-The filter for devices API is available in Microsoft Graph v1.0 endpoint and can be accessed using https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/. You can configure a filter for devices when creating a new Conditional Access policy or you can update an existing policy to configure the filter for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph v1.0 endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filter for devices condition excluding device that are not marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see [dynamic membership rules for groups in Azure Active Directory](../enterprise-users/groups-dynamic-membership.md). 
+The filter for devices API is available in Microsoft Graph v1.0 endpoint and can be accessed using https://graph.microsoft.com/v1.0/identity/conditionalaccess/policies/. You can configure a filter for devices when creating a new Conditional Access policy or you can update an existing policy to configure the filter for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph v1.0 endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filter for devices condition excluding devices that aren't marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see [dynamic membership rules for groups in Azure Active Directory](../enterprise-users/groups-dynamic-membership.md). 
 
 ```json
 {
@@ -130,7 +130,7 @@ The following device attributes can be used with the filter for devices conditio
 
 ## Policy behavior with filter for devices
 
-The filter for devices condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it is important to understand under what circumstances the policy is applied or not applied. The table below illustrates the behavior when a filter for devices condition are configured. 
+The filter for devices condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it's important to understand under what circumstances the policy is applied or not applied. The table below illustrates the behavior when a filter for devices condition is configured. 
 
 | Filter for devices condition | Device registration state | Device filter Applied 
 | --- | --- | --- |

articles/active-directory/conditional-access/howto-conditional-access-policy-compliant-device-admin.md

@@ -17,7 +17,7 @@ ms.collection: M365-identity-device-management
 ---
 # Common Conditional Access policy: Require compliant or hybrid Azure AD joined device for administrators
 
-Accounts that are assigned administrative rights are targeted by attackers. Reqiring those with these rights to perform actions from devices marked as compliant or hybrid Azure AD joined can help limit possible exposure.
+Accounts that are assigned administrative rights are targeted by attackers. Requiring users with these highly privileged rights to perform actions from devices marked as compliant or hybrid Azure AD joined can help limit possible exposure.
 
 More information about device compliance policies can be found in the article, [Set rules on devices to allow access to resources in your organization using Intune](/intune/protect/device-compliance-get-started)
 

articles/active-directory/conditional-access/terms-of-use.md

@@ -89,7 +89,7 @@ Once you've completed your terms of use policy document, use the following proce
    | Expire starting on | Frequency | Result |
    | --- | --- | --- |
    | Today's date  | Monthly | Starting today, users must accept the terms of use policy and then reaccept every month. |
-   | Date in the future  | Monthly | Starting today, users must accept the terms of use policy. When the future date occurs, consents will expire and then users must reaccept every month.  |
+   | Date in the future  | Monthly | Starting today, users must accept the terms of use policy. When the future date occurs, consents will expire, and then users must reaccept every month.  |
 
    For example, if you set the expire starting on date to **Jan 1** and frequency to **Monthly**, this is how expirations might occur for two users:
 
@@ -249,10 +249,9 @@ You can edit some details of terms of use policies, but you can't modify an exis
 1. Browse to **Azure Active Directory** > **Security** > **Conditional Access** > **Terms of use**.
 1. To see who has currently accepted the ToU, select the number under the **Accepted** column for the ToU you want.
 1. By default, the next page will show you the current state of each user's acceptance to the ToU
-1. If you would like to see the previous consent events, you can select **All** from the **Current State** drop-down. Now you can see each users events in details about each version and what happened.
+1. If you would like to see the previous consent events, you can select **All** from the **Current State** drop-down. Now you can see each user's events in details about each version and what happened.
 1. Alternatively, you can select a specific version from the **Version**  drop-down to see who has accepted that specific version.
 
-
 ## Add a ToU language
 
 The following procedure describes how to add a ToU language.

articles/active-directory/fundamentals/7-secure-access-conditional-access.md

@@ -55,7 +55,7 @@ To create a policy that blocks access for external users to a set of application
 1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
 1. Select **New policy**.
 1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies, for example ExternalAccess_Block_FinanceApps.
-1. Under **Assignments**, select **Users or workload identities**..
+1. Under **Assignments**, select **Users or workload identities**.
    1. Under **Include**, select **All guests and external users**. 
    1. Under **Exclude**, select **Users and groups** and choose your organization's [emergency access or break-glass accounts](../roles/security-emergency-access.md). 
    1. Select **Done**.
@@ -75,7 +75,7 @@ There may be times you want to block external users except a specific group. For
 1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
 1. Select **New policy**.
 1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies, for example ExternalAccess_Block_AllButFinance.
-1. Under **Assignments**, select **Users or workload identities**..
+1. Under **Assignments**, select **Users or workload identities**.
    1. Under **Include**, select **All guests and external users**. 
    1. Under **Exclude**, select **Users and groups**, 
       1. Choose your organization's [emergency access or break-glass accounts](../roles/security-emergency-access.md). 

articles/active-directory/fundamentals/concept-secure-remote-workers.md

@@ -68,7 +68,7 @@ The following table is intended to highlight the key actions for the following l
 
 - Azure Active Directory Premium P1 (Azure AD P1)
 - Enterprise Mobility + Security (EMS E3)
-- Microsoft 365 (M365 E3, A3, F1, F3)
+- Microsoft 365 (E3, A3, F1, F3)
 
 | Recommended action | Detail |
 | --- | --- |
@@ -98,7 +98,7 @@ The following table is intended to highlight the key actions for the following l
 
 - Azure Active Directory Premium P2 (Azure AD P2)
 - Enterprise Mobility + Security (EMS E5)
-- Microsoft 365 (M365 E5, A5)
+- Microsoft 365 (E5, A5)
 
 | Recommended action | Detail |
 | --- | --- |