Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-rbac-arm-quickstart

Author: rolyon

articles/active-directory-b2c/identity-provider-salesforce-custom.md

@@ -205,7 +205,7 @@ Now that you have a button in place, you need to link it to an action. The actio
     <ClaimsExchange Id="SalesforceExchange" TechnicalProfileReferenceId="salesforce" />
     ```
 
-    Update the value of **TechnicalProfileReferenceId** to the **ID** of the technical profile you created earlier. For example, `LinkedIn-OAUTH`.
+    Update the value of **TechnicalProfileReferenceId** to the **ID** of the technical profile you created earlier. For example, `salesforce` or `LinkedIn-OAUTH`.
 
 3. Save the *TrustFrameworkExtensions.xml* file and upload it again for verification.
 

articles/active-directory/authentication/howto-sspr-windows.md

@@ -27,7 +27,7 @@ For machines running Windows 7, 8, 8.1, and 10 you can enable users to reset the
 - Some 3rd party credential providers are known to cause problems with this feature.
 - Disabling UAC via modification of [EnableLUA registry key](https://docs.microsoft.com/openspecs/windows_protocols/ms-gpsb/958053ae-5397-4f96-977f-b7700ee461ec) is known to cause issues.
 - This feature does not work for networks with 802.1x network authentication deployed and the option "Perform immediately before user logon". For networks with 802.1x network authentication deployed it is recommended to use machine authentication to enable this feature.
-- Hybrid Azure AD joined machines must have network connectivity line of sight to a domain controller to use the new password and update cached credentials.
+- Hybrid Azure AD joined machines must have network connectivity line of sight to a domain controller to use the new password and update cached credentials. This means that devices must either be on the organization's internal network or on a VPN with network access to an on-premises domain controller. 
 - If using an image, prior to running sysprep ensure that the web cache is cleared for the built-in Administrator prior to performing the CopyProfile step. More information about this step can be found in the support article [Performance poor when using custom default user profile](https://support.microsoft.com/help/4056823/performance-issue-with-custom-default-user-profile).
 - The following settings are known to interfere with the ability to use and reset passwords on Windows 10 devices
     - If Ctrl+Alt+Del is required by policy in versions of Windows 10 before v1809, **Reset password** will not work.

articles/active-directory/develop/quickstart-modify-supported-accounts.md

@@ -66,6 +66,8 @@ By default, OAuth 2.0 implicit grant is disabled for applications. You can enabl
 
 ### To enable OAuth 2.0 implicit grant
 
+1. In the left-hand navigation pane, select the **Azure Active Directory** service and then select **App registrations**.
+1. Find and select the application you want to configure. Once you've selected the app, you'll see the application's **Overview** or main registration page.
 1. From the app's **Overview** page, select the **Authentication** section.
 1. Under **Advanced settings**, locate the **Implicit grant** section.
 1. Select **ID tokens**, **Access tokens**, or both.

articles/active-directory/hybrid/how-to-connect-sso.md

@@ -30,7 +30,7 @@ Seamless SSO can be combined with either the [Password Hash Synchronization](how
 ![Seamless Single Sign-On](./media/how-to-connect-sso/sso1.png)
 
 >[!IMPORTANT]
->Seamless SSO needs the user's device to be **domain-joined** only, but it is not used on [Azure AD Joined](../devices/concept-azure-ad-join.md) or [Hybrid Azure AD joined](../devices/concept-azure-ad-join-hybrid.md) devices. SSO on Azure AD joined and Hybrid Azure AD joined works based on the [primary refresh token](../devices/concept-primary-refresh-token.md).
+>Seamless SSO needs the user's device to be **domain-joined** only, but it is not used on [Azure AD Joined](../devices/concept-azure-ad-join.md) or [Hybrid Azure AD joined](../devices/concept-azure-ad-join-hybrid.md) devices. SSO on Azure AD joined, Hybrid Azure AD joined, and Azure AD registered devices works based on the [primary refresh token](../devices/concept-primary-refresh-token.md).
 
 ## Key benefits
 

articles/active-directory/hybrid/how-to-connect-sync-change-the-configuration.md

@@ -195,7 +195,7 @@ By default, the UserType attribute is not enabled for synchronization because th
 
 - Azure AD only accepts two values for the UserType attribute: **Member** and **Guest**.
 - If the UserType attribute is not enabled for synchronization in Azure AD Connect, Azure AD users created through directory synchronization would have the UserType attribute set to **Member**.
-- Azure AD does not permit the UserType attribute on existing Azure AD users to be changed by Azure AD Connect. It can only be set during the creation of the Azure AD users and [changed via Powershell](/powershell/module/azuread/set-azureaduser?view=azureadps-2.0).
+- Prior to version 1.5.30.0, Azure AD did not permit the UserType attribute on existing Azure AD users to be changed by Azure AD Connect. In older versions, it could only be set during the creation of the Azure AD users and [changed via Powershell](/powershell/module/azuread/set-azureaduser?view=azureadps-2.0).
 
 Before enabling synchronization of the UserType attribute, you must first decide how the attribute is derived from on-premises Active Directory. The following are the most common approaches:
 
@@ -205,7 +205,7 @@ Before enabling synchronization of the UserType attribute, you must first decide
 
 - Alternatively, you can derive the value for the UserType attribute from other properties. For example, you want to synchronize all users as **Guest** if their on-premises AD userPrincipalName attribute ends with domain part <em>@partners.fabrikam123.org</em>. 
 
-    As mentioned previously, Azure AD Connect does not permit the UserType attribute on existing Azure AD users to be changed by Azure AD Connect. Therefore, you must ensure that the logic you have decided is consistent with how the UserType attribute is already configured for all existing Azure AD users in your tenant.
+    As mentioned previously, older versions of Azure AD Connect do not permit the UserType attribute on existing Azure AD users to be changed by Azure AD Connect. Therefore, you must ensure that the logic you have decided is consistent with how the UserType attribute is already configured for all existing Azure AD users in your tenant.
 
 The steps to enable synchronization of the UserType attribute can be summarized as:
 

articles/key-vault/general/overview-security.md

@@ -38,7 +38,7 @@ The model of a single mechanism for authentication to both planes has several be
 
 - Organizations can control access centrally to all key vaults in their organization.
 - If a user leaves, they instantly lose access to all key vaults in the organization.
-- Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security
+- Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security.
 
 ### Managing administrative access to Key Vault
 
@@ -93,6 +93,6 @@ For recommendation on securely managing storage accounts review the [Azure Stora
 
 ## Next Steps
 
-- [Virtual network service endpoints for Azure Key Vault](overview-vnet-service-endpoints.md))
+- [Virtual network service endpoints for Azure Key Vault](overview-vnet-service-endpoints.md)
 - [RBAC: Built-in roles](../../role-based-access-control/built-in-roles.md)
-- [virtual network service endpoints for Azure Key Vault](overview-vnet-service-endpoints.md))
+- [virtual network service endpoints for Azure Key Vault](overview-vnet-service-endpoints.md)