Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into tamram21-1018

Author: tamram

articles/active-directory/app-provisioning/on-premises-application-provisioning-architecture.md

@@ -57,11 +57,11 @@ The following information is provided to better explain the anchor attributes an
 
 The anchor attribute is a unique attribute of an object type that does not change and represents that object in the ECMA Connector Host in-memory cache.
 
-The distinguished name (DN) is a name that uniquely identifies an object by indicating its current location in the directory hierarchy.  Or in the case of SQL, in the partition. The name is formed by concatenating the anchor attribute a the root of the directory partition. 
+The distinguished name (DN) is a name that uniquely identifies an object by indicating its current location in the directory hierarchy.  Or in the case of SQL, in the partition. The name is formed by concatenating the anchor attribute at the root of the directory partition. 
 
 When we think of traditional DNs in a traditional format, for say, Active Directory or LDAP, we think of something similar to:
 
-  CN=Lola Jacobson,CN=Users,DC=contoso,DC=com
+  `CN=Lola Jacobson,CN=Users,DC=contoso,DC=com`
 
 However, for a data source such as SQL, which is flat, not hierarchical, the DN needs to be either already present in one of the table or created from the information we provide to the ECMA Connector Host.  
 

articles/active-directory/app-provisioning/plan-auto-user-provisioning.md

@@ -94,7 +94,7 @@ In this example, users and or groups are created in an HR database connected to
 
 In this example, user creation occurs in Azure AD and the  Azure AD provisioning service manages automatic user provisioning to the target (SaaS) applications.
 
-![Diagram that shows the user/group creation process from an on-premises H R application through the Azure A D Provisioning Service to the target S a a S applications.](./media/plan-auto-user-provisioning/cloudprovisioning.png)
+![Diagram that shows the user/group creation process from an on-premises H R application through the Azure A D Provisioning Service to the target S A A S applications.](./media/plan-auto-user-provisioning/cloudprovisioning.png)
 
 **Description of workflow:**
 

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

@@ -157,7 +157,7 @@ The following client apps have been confirmed to support this setting:
 - Nine Mail - Email & Calendar
 
 > [!NOTE]
-> Microsoft Kaizala, Microsoft Skype for Business and Microsoft Visio do not support the **Require app protection policy** grant. If you require these apps to work, please use the **Require approved apps** grant exclusively. The use of the or clause between the two grants will not work for these three applications.
+> Microsoft Kaizala, Microsoft Skype for Business and Microsoft Visio do not support the **Require app protection policy** grant. If you require these apps to work, please use the **Require approved apps** grant exclusively. The use of the `or` clause between the two grants will not work for these three applications.
 
 **Remarks**
 

articles/active-directory/develop/msal-net-migration-public-client.md

@@ -221,7 +221,7 @@ result = await context.AcquireTokenAsync(resource, clientId,
       // AcquireTokenByIntegratedWindowsAuth form that takes in the username
 
       // Error Code: integrated_windows_auth_not_supported_managed_user
-      // Explanation: This method relies on an a protocol exposed by Active Directory (AD). If a user was created in Azure
+      // Explanation: This method relies on a protocol exposed by Active Directory (AD). If a user was created in Azure
       // Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by
       // AAD ("federated" users) can benefit from this non-interactive method of authentication.
       // Mitigation: Use interactive authentication

articles/active-directory/develop/scenario-desktop-acquire-token-integrated-windows-authentication.md

@@ -124,7 +124,7 @@ static async Task GetATokenForGraph()
       // AcquireTokenByIntegratedWindowsAuth form that takes in the username
 
       // Error Code: integrated_windows_auth_not_supported_managed_user
-      // Explanation: This method relies on an a protocol exposed by Active Directory (AD). If a user was created in Azure
+      // Explanation: This method relies on a protocol exposed by Active Directory (AD). If a user was created in Azure
       // Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by
       // AAD ("federated" users) can benefit from this non-interactive method of authentication.
       // Mitigation: Use interactive authentication

articles/active-directory/devices/azuread-join-sso.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: devices
 ms.topic: conceptual
-ms.date: 06/28/2019
+ms.date: 10/26/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -31,7 +31,7 @@ With an Azure AD joined device, your users already have an SSO experience to the
 
 Azure AD joined devices have no knowledge about your on-premises AD environment because they aren't joined to it. However, you can provide additional information about your on-premises AD to these devices with Azure AD Connect.
 
-If you have a hybrid environment, with both Azure AD and on-premises AD, it is likely that you already have Azure AD Connect deployed to synchronize your on-premises identity information to the cloud. As part of the synchronization process, Azure AD Connect synchronizes on-premises user and domain information to Azure AD. When a user signs in to an Azure AD joined device in a hybrid environment:
+If you have a hybrid environment, with both Azure AD and on-premises AD, it is likely that you already have Azure AD Connect or Azure AD Connect cloud sync deployed to synchronize your on-premises identity information to the cloud. As part of the synchronization process, on-premises user and domain information is synchronized to Azure AD. When a user signs in to an Azure AD joined device in a hybrid environment:
 
 1. Azure AD sends the details of the user's on-premises domain back to the device, along with the [Primary Refresh Token](concept-primary-refresh-token.md)
 1. The local security authority (LSA) service enables Kerberos and NTLM authentication on the device.

articles/active-directory/external-identities/one-time-passcode.md

@@ -7,7 +7,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: B2B
 ms.topic: how-to
-ms.date: 10/21/2021
+ms.date: 10/26/2021
 
 ms.author: mimart
 author: msmimart
@@ -154,7 +154,11 @@ For more information about current limitations, see [Azure US Government clouds]
 
 **Why do I still see “Automatically enable email one-time passcode for guests starting October 2021” selected in my email one-time passcode settings?**
 
-Due to our deployment schedules, we will start rolling out the change to enable email one-time passcode by default globally on November 1, 2021. Until then, you might still see “Automatically enable email one-time passcode for guests starting October 2021” selected in my email one-time passcode settings.
+Due to our deployment schedules, we will start rolling out the change to enable email one-time passcode by default globally on November 1, 2021. Until then, you might still see “Automatically enable email one-time passcode for guests starting October 2021” selected in your email one-time passcode settings.
+
+**What happens to my existing guest users if I enable email one-time passcode?**
+
+Your existing guest users will not be affected if you enable email one-time passcode, as your existing users are already past the point of redemption. Enabling email one-time passcode will only affect future redemption activities where new guest users are redeeming into the tenant.
 
 **What is the user experience for guests during global rollout?**
 
@@ -172,20 +176,20 @@ Before the change is rolled out to your region, guests will see the following be
 
   - If a guest has an existing unmanaged Azure AD account, they'll continue signing in with their unmanaged Azure AD account.
   - If a guest previously redeemed an invitation to your tenant using an unmanaged Azure AD account, and you reset their redemption status and reinvite them, they'll continue signing in with their unmanaged Azure AD account.
-  - If a guest doesn't have an existing unmanaged Azure AD account, they'll redeem using an email one-time passcode link, but they may get a sign-in error if they're not added to the Azure portal in advance.
+  - If a guest doesn't have an existing unmanaged Azure AD account, they'll redeem using an unmanaged Azure AD account, but they may get a sign-in error if they're not added to the Azure portal in advance if redeeming on a direct application link.
 
 After the change is rolled out to your region, guests will see the following behavior.
 
 - With email one-time passcode enabled:
 
-  - If a guest has an existing unmanaged Azure AD account, they'll use email one-time passcode to redeem and sign in going forward.
+  - If a guest has an existing unmanaged Azure AD account, they'll continue signing in with their unmanaged Azure AD account.
   - If a guest previously redeemed an invitation to your tenant using an unmanaged Azure AD account, and you reset their redemption status and reinvite them, they'll use email one-time passcode to redeem and sign in going forward.
   - If a guest doesn't have an unmanaged Azure AD account, they'll use email one-time passcode to redeem and sign in going forward.
 
 - With email one-time passcode disabled:
 
-  - If a guest has an existing unmanaged Azure AD account, they'll use a Microsoft account to redeem. They'll end up with two accounts (the unmanaged Azure AD account and the Microsoft account). To prevent this from happening, we strongly encourage you to enable email one-time passcode.
-  - If a guest previously redeemed an invitation to your tenant using an unmanaged Azure AD account, and you reset their redemption status and reinvite them, they'll use a Microsoft account to redeem. They'll end up with two accounts (the unmanaged Azure AD account and the Microsoft account). To prevent this from happening, we strongly encourage you to enable email one-time passcode.
+  - If a guest has an existing unmanaged Azure AD account, they'll continue signing in with their unmanaged Azure AD account.
+  - If a guest previously redeemed an invitation to your tenant using an unmanaged Azure AD account, and you reset their redemption status and reinvite them, they'll use a Microsoft account to redeem and sign in going forward.
   - If a guest doesn't have an unmanaged Azure AD account, they'll use a Microsoft account to redeem and sign in going forward.
 
 For more information about the different redemption pathways, see [B2B collaboration invitation redemption](redemption-experience.md).

articles/active-directory/fundamentals/security-operations-introduction.md

@@ -151,7 +151,7 @@ As part of an Azure hybrid environment, the following should be baselined and in
 
 * **PTA Agent** – The Pass-through authentication agent is used to enable pass-through authentication and is installed on-premises. See [Azure AD Pass-through Authentication agent: Version release history](../hybrid/reference-connect-pta-version-history.md) for information on verifying your agent version and next steps. 
 
-* **AD FS/WAP** – Azure Active Directory Federation Services (Azure AD FS) and Web Application Proxy (WAP) enable secure sharing of digital identity and entitlement rights across your security and enterprise boundaries. For information on security best practices, see [Best practices for securing Active Directory Federation Services]/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs). 
+* **AD FS/WAP** – Azure Active Directory Federation Services (Azure AD FS) and Web Application Proxy (WAP) enable secure sharing of digital identity and entitlement rights across your security and enterprise boundaries. For information on security best practices, see [Best practices for securing Active Directory Federation Services](/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs). 
 
 * **Azure AD Connect Health Agent** – The agent used to provide a communications link for Azure AD Connect Health. For information on installing the agent, see [Azure AD Connect Health agent installation](../hybrid/how-to-connect-health-agent-install.md). 
 

articles/active-directory/identity-protection/howto-identity-protection-configure-risk-policies.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: identity-protection
 ms.topic: how-to
-ms.date: 05/27/2021
+ms.date: 10/26/2021
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -38,7 +38,7 @@ Configured trusted [network locations](../conditional-access/location-condition.
 
 ### Risk remediation
 
-Organizations can choose to block access when risk is detected. Blocking sometimes stops legitimate users from doing what they need to. A better solution is to allow self-remediation using Azure AD Multi-Factor Authentication (MFA) and self-service password reset (SSPR). 
+Organizations can choose to block access when risk is detected. Blocking sometimes stops legitimate users from doing what they need to. A better solution is to allow self-remediation using Azure AD Multi-Factor Authentication (MFA) and self-service password reset (SSPR).
 
 - When a user risk policy triggers: 
    - Administrators can require a secure password reset, requiring Azure AD MFA be done before the user creates a new password with SSPR, resetting the user risk. 
@@ -65,6 +65,8 @@ There are two locations where these policies may be configured, Conditional Acce
 
 > [!VIDEO https://www.youtube.com/embed/zEsbbik-BTE]
 
+Before enabling remediation policies, organizations may want to [investigate](howto-identity-protection-investigate-risk.md) and [remediate](howto-identity-protection-remediate-unblock.md) any active risks.
+
 ### User risk with Conditional Access
 
 1. Sign in to the **Azure portal** as a global administrator, security administrator, or Conditional Access administrator.

articles/active-directory/identity-protection/howto-identity-protection-simulate-risk.md

@@ -90,7 +90,7 @@ This section provides you with steps for testing the user and the sign-in risk p
 To test a user risk security policy, perform the following steps:
 
 1. Navigate to the [Azure portal](https://portal.azure.com).
-1. Browse to **Azure Active Directory** > **Security** > **Overview**.
+1. Browse to **Azure Active Directory** > **Security** > **Identity Protection** > **Overview**.
 1. Select **Configure user risk policy**.
    1. Under **Assignments**
       1. **Users** - Choose **All users** or **Select individuals and groups** if limiting your rollout.
@@ -110,7 +110,7 @@ To test a user risk security policy, perform the following steps:
 To test a sign in risk policy, perform the following steps:
 
 1. Navigate to the [Azure portal](https://portal.azure.com).
-1. Browse to **Azure Active Directory** > **Security** > **Overview**.
+1. Browse to **Azure Active Directory** > **Security** > **Identity Protection** > **Overview**.
 1. Select **Configure sign-in risk policy**.
    1. Under **Assignments**
       1. **Users** - Choose **All users** or **Select individuals and groups** if limiting your rollout.