Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into release-synapse-current

Author: v-alje

.openpublishing.redirection.json

@@ -33927,6 +33927,11 @@
       "redirect_url": "/azure/role-based-access-control/role-assignments-portal",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/role-based-access-control/tutorial-role-assignments-user-template.md",
+      "redirect_url": "/azure/role-based-access-control/quickstart-role-assignments-template",
+      "redirect_document_id": true
+    },
     {
       "source_path": "articles/active-directory/privileged-identity-management/active-directory-securing-privileged-access.md",
       "redirect_url": "/azure/active-directory/users-groups-roles/directory-admin-roles-secure",

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-b2c/secure-rest-api.md

@@ -237,7 +237,7 @@ For the ServiceUrl, replace your-tenant-name with the name of your Azure AD tena
   <DisplayName></DisplayName>
   <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
   <Metadata>
-    <Item Key="ServiceUrl">https://login.microsoftonline.com/your-tenant-name.microsoft.com/oauth2/v2.0/token</Item>
+    <Item Key="ServiceUrl">https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token</Item>
     <Item Key="AuthenticationType">Basic</Item>
      <Item Key="SendClaimsIn">Form</Item>
   </Metadata>

articles/active-directory-domain-services/alert-service-principal.md

@@ -98,7 +98,7 @@ To recreate the Azure AD application used for credential synchronization, use Az
     $app = Get-AzureADApplication -Filter "IdentifierUris eq 'https://sync.aaddc.activedirectory.windowsazure.com'"
     Remove-AzureADApplication -ObjectId $app.ObjectId
     $spObject = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Azure AD Domain Services Sync'"
-    Remove-AzureADServicePrincipal -ObjectId $app.ObjectId
+    Remove-AzureADServicePrincipal -ObjectId $spObject
     ```
 
 After you delete both applications, the Azure platform automatically recreates them and tries to resume password synchronization. The Azure AD DS managed domain's health automatically updates itself within two hours and removes the alert.

articles/active-directory/app-provisioning/toc.yml

@@ -99,8 +99,8 @@
           href: /azure/active-directory/develop/developer-support-help-options
         - name: Azure feedback forum
           href: https://feedback.azure.com/forums/169401-azure-active-directory
-        - name: MSDN forum
-          href: https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=WindowsAzureAD
+        - name: Microsoft Q&A question page
+          href: https://docs.microsoft.com/answers/topics/azure-active-directory.html
         - name: Pricing
           href: https://azure.microsoft.com/pricing/details/active-directory
         - name: Service updates

articles/active-directory/authentication/TOC.yml

@@ -138,6 +138,8 @@
       href: howto-password-ban-bad-on-premises-agent-versions.md
   - name: Use SMS-based authentication (preview)
     href: howto-authentication-sms-signin.md
+  - name: Use email address sign-in (preview)
+    href: howto-authentication-use-email-signin.md
   - name: Azure AD smart lockout
     href: howto-password-smart-lockout.md
   - name: Certificate-based authentication
@@ -223,8 +225,8 @@
   items:
   - name: Azure feedback forum
     href: https://feedback.azure.com/forums/169401-azure-active-directory
-  - name: MSDN forum
-    href: https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=WindowsAzureAD
+  - name: Microsoft Q&A question page
+    href: https://docs.microsoft.com/answers/topics/azure-active-directory.html
   - name: Pricing
     href: https://azure.microsoft.com/pricing/details/active-directory/
   - name: Service updates

articles/active-directory/authentication/active-directory-passwords-faq.md

@@ -19,7 +19,7 @@ ms.collection: M365-identity-device-management
 
 The following are some frequently asked questions (FAQ) for all things related to password reset.
 
-If you have a general question about Azure Active Directory (Azure AD) and self-service password reset (SSPR) that's not answered here, you can ask the community for assistance on the [Azure AD forum](https://social.msdn.microsoft.com/Forums/en-US/home?forum=WindowsAzureAD). Members of the community include engineers, product managers, MVPs, and fellow IT professionals.
+If you have a general question about Azure Active Directory (Azure AD) and self-service password reset (SSPR) that's not answered here, you can ask the community for assistance on the [Microsoft Q&A question page for Azure Active Directory](https://docs.microsoft.com/answers/topics/azure-active-directory.html). Members of the community include engineers, product managers, MVPs, and fellow IT professionals.
 
 This FAQ is split into the following sections:
 

articles/active-directory/authentication/active-directory-passwords-troubleshoot.md

@@ -254,7 +254,7 @@ Azure AD Connect requires Active Directory **Reset password** permission to perf
 
 ## Azure AD forums
 
-If you have a general question about Azure AD and self-service password reset, you can ask the community for assistance on the [Azure AD forums](https://social.msdn.microsoft.com/Forums/en-US/home?forum=WindowsAzureAD). Members of the community include engineers, product managers, MVPs, and fellow IT professionals.
+If you have a general question about Azure AD and self-service password reset, you can ask the community for assistance on the [Microsoft Q&A question page for Azure Active Directory](https://docs.microsoft.com/answers/topics/azure-active-directory.html). Members of the community include engineers, product managers, MVPs, and fellow IT professionals.
 
 ## Contact Microsoft support
 

articles/active-directory/authentication/howto-authentication-use-email-signin.md

@@ -0,0 +1,186 @@
+---
+title: Sign in with email as an alternate login ID for Azure Active Directory
+description: Learn how to configure and enable users to sign in to Azure Active Directory using their email address as an alternate login ID (preview)
+
+services: active-directory
+ms.service: active-directory
+ms.subservice: authentication
+ms.topic: how-to
+ms.date: 05/22/2020
+
+ms.author: iainfou
+author: iainfoulds
+manager: daveba
+ms.reviewer: scottsta
+
+---
+# Sign-in to Azure using email as an alternate login ID (preview)
+
+Many organizations want to let users sign in to Azure using the same credentials as their on-premises directory environment. With this approach, known as hybrid authentication, users only need to remember one set of credentials.
+
+Some organizations haven't moved to hybrid authentication for the following reasons:
+
+* By default, the Azure Active Directory (Azure AD) user principal name (UPN) is set to the same UPN as the on-premises directory.
+* Changing the Azure AD UPN creates a mis-match between on-prem and Azure environments that could cause problems with certain applications and services.
+* Due to business or compliance reasons, the organization doesn't want to use the on-premises UPN to sign in to Azure.
+
+To help with the move to hybrid authentication, you can now configure Azure AD to let users sign in to Azure with an email in your verified domain as an alternate login ID. For example, if *Contoso* rebranded to *Fabrikam*, rather than continuing to sign in with the legacy `[email protected]` UPN, email as an alternate login ID can now be used. To access an application or services, users would sign in to Azure using their assigned email, such as `[email protected]`.
+
+|     |
+| --- |
+| Sign in to Azure AD with email as an alternate login ID is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).|
+|     |
+
+## Overview of Azure AD sign-in approaches
+
+User Principal Names (UPNs) are unique identifiers for a user account in both your on-premises directory, and in Azure AD. Each user account in a directory is represented by a UPN, such as `[email protected]`. By default, when you synchronize an on-premises Active Directory Domain Services (AD DS) environment with Azure AD, the Azure AD UPN is to set to match the on-premises UPN.
+
+In many organizations, it's fine to set the on-premises UPN and Azure AD UPN to match. When users sign in to Azure applications and services, they use their Azure AD UPN. However, some organizations can't use matching UPNs for sign-in due to business policies or user experience issues.
+
+Organizations that can't use matching UPNs in Azure AD have a few options:
+
+* One approach is to set the Azure AD UPN to something different based on the business needs, such as `[email protected]`.
+    * However, not all applications and services are compatible with using a different value for the on-premises UPN and the Azure AD UPN.
+* A better approach is to ensure the Azure AD and on-premises UPNs are set to the same value, and configure Azure AD to let users sign into Azure with their email as an alternate login ID.
+
+With email as an alternate login ID, users can still sign in to Azure by entering their UPN, but can also sign in using their email. To support this, you define an email address in the user's *ProxyAddresses* attribute in the on-premises directory. This *ProxyAddress* attribute supports one or more email addresses.
+
+## Synchronize sign-in email addresses to Azure AD
+
+Traditional Active Directory Domain Services (AD DS) or Active Directory Federation Services (AD FS) authentication happens directly on your network and is handled by your AD DS infrastructure. With hybrid authentication, users can instead sign in directly to Azure AD.
+
+To support this hybrid authentication approach, you synchronize your on-premises AD DS environment to Azure AD using [Azure AD Connect][azure-ad-connect] and configure it to use Password Hash Sync (PHS) or Pass-Through Authentication (PTA).
+
+In both configuration options, the user submits their username and password to Azure AD, which validates the credentials and issues a ticket. When users sign in to Azure AD, it removes the need for your organization to host and manage an AD FS infrastructure.
+
+![Diagram of Azure AD hybrid identity with password hash synchronization](media/howto-authentication-use-email-signin/hybrid-password-hash-sync.png)
+
+![Diagram of Azure AD hybrid identity with pass-through authentication](media/howto-authentication-use-email-signin/hybrid-pass-through-authentication.png)
+
+One of the user attributes that's automatically synchronized by Azure AD Connect is *ProxyAddresses*. If users have an email address defined in the on-prem AD DS environment as part of the *ProxyAddresses* attribute, it's automatically synchronized to Azure AD. This email address can then be used directly in the Azure AD sign-in process as an alternate login ID.
+
+> [!IMPORTANT]
+> Only emails in verified domains for the tenant are synchronized to Azure AD. Each Azure AD tenant has one or more verified domains, for which you have proven ownership, and are uniquely bound to you tenant.
+>
+> For more information, see [Add and verify a custom domain name in Azure AD][verify-domain].
+
+For more information, see [Choose the right authentication method for your Azure AD hybrid identity solution][hybrid-auth-methods].
+
+## Enable user sign-in with an email address
+
+Once users with the *ProxyAddresses* attribute applied are synchronized to Azure AD using Azure AD Connect, you need to enable the feature for users to sign in with email as an alternate login ID for your tenant. This feature tells the Azure AD login servers to not only check the sign-in name against UPN values, but also against *ProxyAddresses* values for the email address.
+
+During preview, you can currently only enable the sign-in with email as an alternate login ID feature using PowerShell. You need *tenant administrator* permissions to complete the following steps:
+
+1. Open an PowerShell session as an administrator, then install the *AzureADPreview* module using the [Install-Module][Install-Module] cmdlet:
+
+    ```powershell
+    Install-Module AzureADPreview
+    ```
+
+    If prompted, select **Y** to install NuGet or to install from an untrusted repository.
+
+1. Sign in to your Azure AD tenant as a *tenant administrator* using the [Connect-AzureAD][Connect-AzureAD] cmdlet:
+
+    ```powershell
+    Connect-AzureAD
+    ```
+
+    The command returns information about your account, environment, and tenant ID.
+
+1. Check if the *HomeRealmDiscoveryPolicy* policy already exists in your tenant using the [Get-AzureADPolicy][Get-AzureADPolicy] cmdlet as follows:
+
+    ```powershell
+    Get-AzureADPolicy | where-object {$_.Type -eq "HomeRealmDiscoveryPolicy"} | fl *
+    ```
+
+1. If there's no policy currently configured, the command returns nothing. If a policy is returned, skip this step and move on to the next step to update an existing policy.
+
+    To add the *HomeRealmDiscoveryPolicy* policy to the tenant, use the [New-AzureADPolicy][New-AzureADPolicy] cmdlet and set the *AlternateIdLogin* attribute to *"Enabled": true* as shown in the following example:
+
+    ```powershell
+    New-AzureADPolicy -Definition @('{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}') `
+        -DisplayName "BasicAutoAccelerationPolicy" `
+        -IsOrganizationDefault $true `
+        -Type "HomeRealmDiscoveryPolicy"
+    ```
+
+    When the policy has been successfully created, the command returns the policy ID, as shown in the following example output:
+
+    ```powershell
+    Id                                   DisplayName                 Type                     IsOrganizationDefault
+    --                                   -----------                 ----                     ---------------------
+    5de3afbe-4b7a-4b33-86b0-7bbe308db7f7 BasicAutoAccelerationPolicy HomeRealmDiscoveryPolicy True
+    ```
+
+1. If there's already a configured policy, check if the *AlternateIdLogin* attribute is enabled, as shown in the following example policy output:
+
+    ```powershell
+    Id : 5de3afbe-4b7a-4b33-86b0-7bbe308db7f7
+    OdataType :
+    AlternativeIdentifier :
+    Definition : {{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}}
+    DisplayName : BasicAutoAccelerationPolicy
+    IsOrganizationDefault : True
+    KeyCredentials : {}
+    Type : HomeRealmDiscoveryPolicy
+    ```
+
+    If the policy exists but the *AlternateIdLogin* attribute that isn't present or enabled, or if other attributes exist on the policy you wish to preserve, update the existing policy using the [Set-AzureADPolicy][Set-AzureADPolicy] cmdlet.
+
+    > [!IMPORTANT]
+    > When you update the policy, make sure you include any old settings and the new *AlternateIdLogin* attribute.
+
+    The following example adds the *AlternateIdLogin* attribute and preserves the *AllowCloudPasswordValidation* attribute that may have already been set:
+
+    ```powershell
+    Set-AzureADPolicy -id b581c39c-8fe3-4bb5-b53d-ea3de05abb4b `
+        -Definition @('{"HomeRealmDiscoveryPolicy" :{"AllowCloudPasswordValidation":true,"AlternateIdLogin":{"Enabled": true}}}') `
+        -DisplayName "BasicAutoAccelerationPolicy" `
+        -IsOrganizationDefault $true `
+        -Type "HomeRealmDiscoveryPolicy"
+    ```
+
+    Confirm that the updated policy shows your changes and that the *AlternateIdLogin* attribute is now enabled:
+
+    ```powershell
+    Get-AzureADPolicy | where-object {$_.Type -eq "HomeRealmDiscoveryPolicy"} | fl *
+    ```
+
+## Test user sign-in with email
+
+To test that users can sign in with email, browse to [https://myprofile.microsoft.com][my-profile] and sign in with a user account based on their email address, such as `[email protected]`, not their UPN, such as `[email protected]`. The sign-in experience should look and feel the same as with a UPN-based sign-in event.
+
+## Troubleshoot
+
+If users have trouble with sign-in events using their email address, review the following troubleshooting steps:
+
+1. Make sure the user account has their email address set for the *ProxyAddresses* attribute in the on-prem AD DS environment.
+1. Verify that Azure AD Connect is configured and successfully synchronizes user accounts from the on-prem AD DS environment into Azure AD.
+1. Confirm that the Azure AD *HomeRealmDiscoveryPolicy* policy has the *AlternateIdLogin* attribute set to *"Enabled": true*:
+
+    ```powershell
+    Get-AzureADPolicy | where-object {$_.Type -eq "HomeRealmDiscoveryPolicy"} | fl *
+    ```
+
+## Next steps
+
+To learn more about hybrid identity, such as Azure AD App Proxy or Azure AD Domain Services, see [Azure AD hybrid identity for access and management of on-prem workloads][hybrid-overview].
+
+For more information on hybrid identity operations, see [how password hash sync][phs-overview] or [pass-through authentication][pta-overview] synchronization work.
+
+<!-- INTERNAL LINKS -->
+[verify-domain]: ../fundamentals/add-custom-domain.md
+[hybrid-auth-methods]: ../hybrid/choose-ad-authn.md
+[azure-ad-connect]: ../hybrid/whatis-azure-ad-connect.md
+[hybrid-overview]: ../hybrid/cloud-governed-management-for-on-premises.md
+[phs-overview]: ../hybrid/how-to-connect-password-hash-synchronization.md
+[pta-overview]: ../hybrid/how-to-connect-pta-how-it-works.md
+
+<!-- EXTERNAL LINKS -->
+[Install-Module]: /powershell/module/powershellget/install-module
+[Connect-AzureAD]: /powershell/module/azuread/connect-azuread
+[Get-AzureADPolicy]: /powershell/module/azuread/get-azureadpolicy
+[New-AzureADPolicy]: /powershell/module/azuread/new-azureadpolicy
+[Set-AzureADPolicy]: /powershell/module/azuread/set-azureadpolicy
+[my-profile]: https://myprofile.microsoft.com

articles/active-directory/authentication/howto-mfa-nps-extension-vpn.md

@@ -242,9 +242,9 @@ In this section, you configure your VPN server to use RADIUS authentication. The
     b. For the **Shared secret**, select **Change**, and then enter the shared secret password that you created and recorded earlier.
 
     c. In the **Time-out (seconds)** box, enter a value of **30**.  
-    The timeout value is necessary to allow enough time to complete the second authentication factor.
+    The timeout value is necessary to allow enough time to complete the second authentication factor. Some VPNs or regions require time-out settings greater than 30 seconds to prevent users from receiving multiple phone calls. If users do experience this issue, increase the **Time-out (seconds)** value in increments of 30 seconds until the issue doesn't reoccur.
 
-    ![Add RADIUS Server window configuring the Time-out](./media/howto-mfa-nps-extension-vpn/image16.png)
+    ![Add RADIUS Server window configuring the Time-out](./media/howto-mfa-nps-extension-vpn/image16.png) 
 
 8. Select **OK**.