Merge pull request #204552 from MicrosoftDocs/main

Publish to Live, Wednesday 4AM PST, 7/13

Author: PMEds28

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

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 10/05/2020
+ms.date: 07/12/2022
 
 ms.author: justinha
 author: justinha
@@ -18,7 +18,7 @@ ms.custom: devx-track-azurepowershell
 ---
 # Pre-populate user authentication contact information for Azure Active Directory self-service password reset (SSPR)
 
-To use Azure Active Directory (Azure AD) self-service password reset (SSPR), authentication contact information for a user must be present. Some organizations have users register their authentication data themselves. Other organizations prefer to synchronize from authentication data that already exists in Active Directory Domain Services (AD DS). This synchronized data is made available to Azure AD and SSPR without requiring user interaction. When users need to change or reset their password, they can do so even if they haven't previously registered their contact information.
+To use Azure Active Directory (Azure AD) self-service password reset (SSPR), authentication information for a user must be present. Most organizations have users register their authentication data themselves while collecting information for MFA. Some organizations prefer to bootstrap this process through synchronization of authentication data that already exists in Active Directory Domain Services (AD DS). This synchronized data is made available to Azure AD and SSPR without requiring user interaction. When users need to change or reset their password, they can do so even if they haven't previously registered their contact information.
 
 You can pre-populate authentication contact information if you meet the following requirements:
 
@@ -80,13 +80,13 @@ The following fields can be set through PowerShell:
     * Can only be set if you're not synchronizing with an on-premises directory.
 
 > [!IMPORTANT]
-> There's a known lack of parity in command features between PowerShell v1 and PowerShell v2. The [Microsoft Graph REST API (beta) for authentication methods](/graph/api/resources/authenticationmethods-overview) is the current engineering focus to provide modern interaction.
+> Azure AD PowerShell is planned for deprecation. You can start using [Microsoft Graph PowerShell](/powershell/microsoftgraph/overview) to interact with Azure AD as you would in Azure AD PowerShell, or use the [Microsoft Graph REST API for managing authentication methods](/graph/api/resources/authenticationmethods-overview).
 
-### Use PowerShell version 1
+### Use Azure AD PowerShell version 1
 
 To get started, [download and install the Azure AD PowerShell module](/previous-versions/azure/jj151815(v=azure.100)#bkmk_installmodule). After it's installed, use the following steps to configure each field.
 
-#### Set the authentication data with PowerShell version 1
+#### Set the authentication data with Azure AD PowerShell version 1
 
 ```PowerShell
 Connect-MsolService
@@ -98,7 +98,7 @@ Set-MsolUser -UserPrincipalName [email protected] -PhoneNumber "+1 4252345678"
 Set-MsolUser -UserPrincipalName [email protected] -AlternateEmailAddresses @("[email protected]") -MobilePhone "+1 4251234567" -PhoneNumber "+1 4252345678"
 ```
 
-#### Read the authentication data with PowerShell version 1
+#### Read the authentication data with Azure AD PowerShell version 1
 
 ```PowerShell
 Connect-MsolService
@@ -120,21 +120,21 @@ Get-MsolUser -UserPrincipalName [email protected] | select -Expand StrongAuthentic
 Get-MsolUser -UserPrincipalName [email protected] | select -Expand StrongAuthenticationUserDetails | select Email
 ```
 
-### Use PowerShell version 2
+### Use Azure AD PowerShell version 2
 
 To get started, [download and install the Azure AD version 2 PowerShell module](/powershell/module/azuread/).
 
 To quickly install from recent versions of PowerShell that support `Install-Module`, run the following commands. The first line checks to see if the module is already installed:
 
 ```PowerShell
-Get-Module AzureADPreview
-Install-Module AzureADPreview
+Get-Module AzureAD
+Install-Module AzureAD
 Connect-AzureAD
 ```
 
 After the module is installed, use the following steps to configure each field.
 
-#### Set the authentication data with PowerShell version 2
+#### Set the authentication data with Azure AD PowerShell version 2
 
 ```PowerShell
 Connect-AzureAD
@@ -146,7 +146,7 @@ Set-AzureADUser -ObjectId [email protected] -TelephoneNumber "+1 4252345678"
 Set-AzureADUser -ObjectId [email protected] -OtherMails @("[email protected]") -Mobile "+1 4251234567" -TelephoneNumber "+1 4252345678"
 ```
 
-#### Read the authentication data with PowerShell version 2
+#### Read the authentication data with Azure AD PowerShell version 2
 
 ```PowerShell
 Connect-AzureAD
@@ -158,6 +158,45 @@ Get-AzureADUser -ObjectID [email protected] | select TelephoneNumber
 Get-AzureADUser | select DisplayName,UserPrincipalName,otherMails,Mobile,TelephoneNumber | Format-Table
 ```
 
+### Use Microsoft Graph PowerShell
+
+To get started, [download and install the Microsoft Graph PowerShell module](/powershell/microsoftgraph/overview).
+
+To quickly install from recent versions of PowerShell that support `Install-Module`, run the following commands. The first line checks to see if the module is already installed:
+
+```PowerShell
+Get-Module Microsoft.Graph
+Install-Module Microsoft.Graph
+Select-MgProfile -Name "beta"
+Connect-MgGraph -Scopes "User.ReadWrite.All"
+```
+
+After the module is installed, use the following steps to configure each field.
+
+#### Set the authentication data with Microsoft Graph PowerShell
+
+```PowerShell
+Connect-MgGraph -Scopes "User.ReadWrite.All"
+
+Update-MgUser -UserId '[email protected]' -otherMails @("[email protected]")
+Update-MgUser -UserId '[email protected]' -mobilePhone "+1 4251234567"
+Update-MgUser -UserId '[email protected]' -businessPhones "+1 4252345678"
+
+Update-MgUser -UserId '[email protected]' -otherMails @("[email protected]") -mobilePhone "+1 4251234567" -businessPhones "+1 4252345678"
+```
+
+#### Read the authentication data with Microsoft Graph PowerShell
+
+```PowerShell
+Connect-MgGraph -Scopes "User.Read.All"
+
+Get-MgUser -UserId '[email protected]' | select otherMails
+Get-MgUser -UserId '[email protected]' | select mobilePhone
+Get-MgUser -UserId '[email protected]' | select businessPhones
+
+Get-MgUser -UserId '[email protected]' | Select businessPhones, mobilePhone, otherMails | Format-Table
+```
+
 ## Next steps
 
 Once authentication contact information is pre-populated for users, complete the following tutorial to enable self-service password reset:

articles/active-directory/external-identities/faq.yml

@@ -189,9 +189,19 @@ sections:
           For information about what licenses your organization needs to use Azure AD B2B, see [External Identities pricing](external-identities-pricing.md).
 
       - question: |
-          Can B2B collaboration users sign in with their non-UPN email address?
+          What happens if I invite a user whose email and UPN don’t match?
         answer: |
-          Yes. For more information about email as an alternate login ID for B2B collaboration, see [B2B guest user sign-in with an email address](../authentication/howto-authentication-use-email-signin.md#b2b-guest-user-sign-in-with-an-email-address).
+          It depends. By default, Azure AD only allows UPN for login ID. When UPN and email are the same, Azure AD B2B invitations and subsequent sign-ins work as expected. However, issues can arise when a user’s email and UPN don’t match, and the email is used instead of the UPN to sign in.
+          When a user is invited with a non-UPN email, they will be able to redeem the invitation if they redeem using the [email invitation link](https://docs.microsoft.com/azure/active-directory/external-identities/redemption-experience#redemption-through-the-invitation-email), but redemptions via a [direct link](https://docs.microsoft.com/azure/active-directory/external-identities/redemption-experience#redemption-through-a-direct-link) will fail. However, even if the user successfully redeems the invitation, subsequent sign-in attempts using the non-UPN email will fail unless the identity provider (either Azure AD or a federated identity provider) is configured to allow email as an alternative login ID. 
+          This issue can be mitigated by:
+          1. [Enabling email as an alternate login ID](https://docs.microsoft.com/azure/active-directory/authentication/howto-authentication-use-email-signin) in the invited/home Azure AD tenant
+          2. Enabling the federated identity provider to support email as login ID (if Azure AD is federated to another identity provider) or
+          3. Instructing the user to redeem/sign-in using their UPN.
+          To avoid this issue entirely, administrators should ensure users’ UPN and email are the same value.
+
+          ![Screenshot shows the flow for guest redemption.](media/user-invitation-different-email-upn/guest-redemption.png)
+
+          ![Screenshot shows the flow for subsequent sign-ins.](media/user-invitation-different-email-upn/subsequent-sign-in.png)
 
       - question: |
           Instant-on: What can cause replication latency?

articles/active-directory/external-identities/media/user-invitation-different-email-upn/guest-redemption.png

@@ -53,7 +53,7 @@ In enterprise-sized organizations, IAM transformation, or even transformation fr
 [ ![Diagram that shows five elements, each depicting a possible network architecture. Options include cloud attached, hybrid, cloud first, AD minimized, and 100% cloud.](media/road-to-cloud-posture/road-to-the-cloud-five-states.png) ](media/road-to-cloud-posture/road-to-the-cloud-five-states.png#lightbox)
 
 >[!NOTE]
-> The states in this diagram represent a logical progression of cloud transformation.
+> The states in this diagram represent a logical progression of cloud transformation. Your ability to move from one state to the next is dependent on the functionality that you have implemented and the capabilities within that functionality to move to the cloud.
 
 **State 1 Cloud attached** - In this state, organizations have created an Azure AD tenant to enable user productivity and collaboration tools and the tenant is fully operational. Most companies that use Microsoft products and services in their IT environment are already in or beyond this state. In this state operational costs may be higher because there's an on-premises environment and cloud environment to maintain and make interactive. Also, people must have expertise in both environments to support their users and the organization. In this state:
 

articles/active-directory/external-identities/media/user-invitation-different-email-upn/subsequent-sign-in.png

@@ -241,7 +241,7 @@
     - name: Security and authentication
       items:
         - name: Overview of Defender for Containers
-          href: ../defender-for-cloud/defender-for-containers-introduction.md?tabs=defender-for-container-arch-aks#what-are-the-benefits-of-microsoft-defender-for-containers
+          href: ../defender-for-cloud/defender-for-containers-introduction.md
           maintainContext: true
         - name: Enable Defender for Containers
           href: ../defender-for-cloud/defender-for-containers-enable.md?tabs=aks-deploy-portal%2Ck8s-deploy-asc%2Ck8s-verify-asc%2Ck8s-remove-arc%2Caks-removeprofile-api&pivots=defender-for-container-aks

articles/active-directory/fundamentals/road-to-the-cloud-posture.md

@@ -555,7 +555,7 @@ This policy can be used in the following policy [sections](./api-management-howt
 
 ## <a name="ValidateJWT"></a> Validate JWT
 
-The `validate-jwt` policy enforces existence and validity of a JSON web token (JWT) extracted from either a specified HTTP header or a specified query parameter.
+The `validate-jwt` policy enforces existence and validity of a JSON web token (JWT) extracted from a specified HTTP header, extracted from a specified query parameter, or matching a specific value.
 
 > [!IMPORTANT]
 > The `validate-jwt` policy requires that the `exp` registered claim is included in the JWT token, unless `require-expiration-time` attribute is specified and set to `false`.
@@ -569,10 +569,11 @@ The `validate-jwt` policy enforces existence and validity of a JSON web token (J
 
 ```xml
 <validate-jwt
-    header-name="name of http header containing the token (use query-parameter-name attribute if the token is passed in the URL)"
+    header-name="name of HTTP header containing the token (alternatively, use query-parameter-name or token-value attribute to specify token)"
+    query-parameter-name="name of query parameter used to pass the token (alternative, use header-name or token-value attribute to specify token)"
+    token-value="expression returning the token as a string (alternatively, use header-name or query-parameter attribute to specify token)"
     failed-validation-httpcode="http status code to return on failure"
     failed-validation-error-message="error message to return on failure"
-    token-value="expression returning JWT token as a string"
     require-expiration-time="true|false"
     require-scheme="scheme"
     require-signed-tokens="true|false"
@@ -724,7 +725,7 @@ This example shows how to use the [Validate JWT](api-management-access-restricti
 | failed-validation-httpcode      | HTTP Status code to return if the JWT doesn't pass validation.                                                                                                                                                                                                                                                                                                                                                                                         | No                                                                               | 401                                                                               |
 | header-name                     | The name of the HTTP header holding the token.                                                                                                                                                                                                                                                                                                                                                                                                         | One of `header-name`, `query-parameter-name` or `token-value` must be specified. | N/A                                                                               |
 | query-parameter-name            | The name of the query parameter holding the token.                                                                                                                                                                                                                                                                                                                                                                                                     | One of `header-name`, `query-parameter-name` or `token-value` must be specified. | N/A                                                                               |
-| token-value                     | Expression returning a string containing JWT token. You must not return `Bearer ` as part of the token value.                                                                                                                                                                                                                                                                                                                                           | One of `header-name`, `query-parameter-name` or `token-value` must be specified. | N/A                                                                               |
+| token-value                     | Expression returning a string containing the token. You must not return `Bearer ` as part of the token value.                                                                                                                                                                                                                                                                                                                                           | One of `header-name`, `query-parameter-name` or `token-value` must be specified. | N/A                                                                               |
 | id                              | The `id` attribute on the `key` element allows you to specify the string that will be matched against `kid` claim in the token (if present) to find out the appropriate key to use for signature validation.                                                                                                                                                                                                                                           | No                                                                               | N/A                                                                               |
 | match                           | The `match` attribute on the `claim` element specifies whether every claim value in the policy must be present in the token for validation to succeed. Possible values are:<br /><br /> - `all` - every claim value in the policy must be present in the token for validation to succeed.<br /><br /> - `any` - at least one claim value must be present in the token for validation to succeed.                                                       | No                                                                               | all                                                                               |
 | require-expiration-time         | Boolean. Specifies whether an expiration claim is required in the token.                                                                                                                                                                                                                                                                                                                                                                               | No                                                                               | true                                                                              |

articles/aks/TOC.yml

@@ -118,7 +118,6 @@ Application Gateway supports the following cipher suites from which you can choo
 
 - The connections to backend servers are always with minimum protocol TLS v1.0 and up to TLS v1.2. Therefore, only TLS versions 1.0, 1.1 and 1.2 are supported to establish a secured connection with backend servers. 
 - As of now, the TLS 1.3 implementation is not enabled with "Zero Round Trip Time (0-RTT)" feature.
-- The Portal support for the new policies and TLS 1.3 is currently unavailable.
 - Application Gateway v2 does not support the following DHE ciphers. These won't be used for the TLS connections with clients even though they are mentioned in the predefined policies. Instead of DHE ciphers, secure and faster ECDHE ciphers are recommended.
   - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
   - TLS_DHE_RSA_WITH_AES_128_CBC_SHA