Merge pull request #234651 from MicrosoftDocs/main

Publish to live, Monday 4 AM PST, 4/17

Author: ttorble

articles/active-directory/develop/includes/web-api/quickstart-aspnet-core.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: include
 ms.workload: identity
-ms.date: 12/09/2022
+ms.date: 04/16/2023
 ms.author: cwerner
 ms.reviewer: jmprieur
 ms.custom: devx-track-csharp, "scenarios:getting-started", "languages:aspnet-core", mode-api, engagement-fy23
@@ -48,10 +48,6 @@ First, register the web API in your Azure AD tenant and add a scope by following
 
 [Download the ASP.NET Core solution](https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/archive/aspnetcore3-1.zip) from GitHub.
 
-> [!Note]
-> The code sample currently targets ASP.NET Core 3.1. The sample can be updated to use .NET Core 6.0 and is covered in the following steps: [Update the sample code to ASP.NET Core 6.0](#step-4-update-the-sample-code-to-aspnet-core-60)
-This quickstart will be deprecated in the near future and will be updated to use .NET 6.0.
-
 ## Step 3: Configure the ASP.NET Core project
 
 In this step, the sample code will be configured to work with the app registration that was created earlier.
@@ -74,26 +70,7 @@ In this step, the sample code will be configured to work with the app registrati
 
 For this quickstart, don't change any other values in the *appsettings.json* file.
 
-### Step 4: Update the sample code to ASP.NET Core 6.0
-
-To update this code sample to target ASP.NET Core 6.0, follow these steps:
-
-1. Open webapi.csproj
-1. Remove the following line:
-
-    ```xml
-   <TargetFramework>netcoreapp3.1</TargetFramework>
-   ```
-
-1. Add the following line in its place:
-
-   ```xml
-   <TargetFramework>netcoreapp6.0</TargetFramework>
-   ```
-
-This step will ensure that the sample is targeting the .NET Core 6.0 framework.
-
-### Step 5: Run the sample
+### Step 4: Run the sample
 
 1. Open a terminal and change directory to the project folder.
 
@@ -167,31 +144,28 @@ public void Configure(IApplicationBuilder app, IHostingEnvironment env)
 namespace webapi.Controllers
 {
     [Authorize]
+    [RequiredScope("access_as_user")]
     [ApiController]
     [Route("[controller]")]
     public class WeatherForecastController : ControllerBase
 ```
 
 ### Validation of scope in the controller
 
-The code in the API verifies that the required scopes are in the token by using `HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi);`:
+The code in the API verifies that the required scopes are in the token by using `[RequiredScope("access_as_user")]` attribute:
 
 ```csharp
 namespace webapi.Controllers
 {
     [Authorize]
+    [RequiredScope("access_as_user")]
     [ApiController]
     [Route("[controller]")]
     public class WeatherForecastController : ControllerBase
     {
-        // The web API will only accept tokens 1) for users, and 2) having the "access_as_user" scope for this API
-        static readonly string[] scopeRequiredByApi = new string[] { "access_as_user" };
-
         [HttpGet]
         public IEnumerable<WeatherForecast> Get()
         {
-            HttpContext.VerifyUserHasAnyAcceptedScope(scopeRequiredByApi);
-
             // some code here
         }
     }

articles/active-directory/develop/includes/web-app/quickstart-aspnet-core.md

@@ -10,7 +10,7 @@ ms.subservice: develop
 ms.topic: quickstart
 ms.workload: identity
 
-ms.date: 12/19/2022
+ms.date: 04/16/2023
 ms.author: cwerner
 
 ms.reviewer: jmprieur
@@ -50,10 +50,6 @@ See [How the sample works](#how-the-sample-works) for an illustration.
 
 [Download the ASP.NET Core solution](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/archive/aspnetcore3-1-callsgraph.zip)
 
-> [!Note]
-> The code sample currently targets ASP.NET Core 3.1. The sample can be updated to use .NET Core 6.0 and is covered in the following steps: [Update the sample code to ASP.NET Core 6.0](#step-4-update-the-sample-code-to-aspnet-core-60)
-This quickstart will be deprecated in the near future and will be updated to use .NET 6.0.
-
 ### Step 3: Configure your ASP.NET Core project
 
 1. Extract the *.zip* file to a local folder that's close to the root of the disk to avoid errors caused by path length limitations on Windows. For example, extract to *C:\Azure-Samples*.
@@ -74,27 +70,8 @@ This quickstart will be deprecated in the near future and will be updated to use
     - Replace `Enter_the_Client_Secret_Here` with the **Client secret** that was created and recorded in an earlier step.
 
 For this quickstart, don't change any other values in the *appsettings.json* file.
-
-### Step 4: Update the sample code to ASP.NET Core 6.0
-
-To update this code sample to target ASP.NET Core 6.0, follow these steps:
-
-1. Open WebApp-OpenIDConnect-DotNet.csproj
-1. Remove the following line:
-
-    ```xml
-   <TargetFramework>netcoreapp3.1</TargetFramework>
-   ```
-
-1. Add the following line in its place:
-
-   ```xml
-   <TargetFramework>netcoreapp6.0</TargetFramework>
-   ```
-
-This step will ensure that the sample is targeting the .NET Core 6.0 framework.
 
-### Step 5: Build and run the application
+### Step 4: Build and run the application
 
 Build and run the app in Visual Studio by selecting the **Debug** menu > **Start Debugging**, or by pressing the F5 key. 
 

articles/active-directory/develop/web-app-quickstart-portal-node-js-ciam.md

@@ -16,25 +16,13 @@ ms.date: 04/12/2023
 # Portal quickstart for React SPA
 
 > In this quickstart, you download and run a code sample that demonstrates how a React single-page application (SPA) can sign in users with Azure AD CIAM.
-
-> [!div renderon="portal" id="display-on-portal" class="sxs-lookup"]
-> ## Prerequisites
->
-> * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)
-> * [Node.js](https://nodejs.org/en/download/)
-> * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor
->
-> ## Run the sample
 >
-> 1. Unzip the downloaded file.
->
-> 1. In your terminal, locate the folder that contains the `package.json` file, then run the following command:
+> [!div renderon="portal" id="display-on-portal" class="sxs-lookup"]
+> 1. Make sure you've installed [Node.js](https://nodejs.org/en/download/).
 >
+> 1. Unzip the sample, `cd` into the folder that contains `package.json`, then run the following commands:
 >     ```console
 >     npm install && npm start
 >     ```
->
-> 1. Open your browser and visit `http://locahost:3000`.
->
-> 1. Select the **Sign-in** link on the navigation bar, then follow the prompts.
+> 1. Open your browser, visit `http://locahost:3000`, select **Sign-in** link, then follow the prompts.
 >

articles/active-directory/external-identities/authentication-conditional-access.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: B2B
 ms.topic: conceptual
-ms.date: 04/03/2023
+ms.date: 04/17/2023
 
 ms.author: mimart
 author: msmimart
@@ -64,13 +64,13 @@ The following diagram illustrates the flow when email one-time passcode authenti
 | Step | Description |
 |--------------|-----------------------|
 | **1** |The user requests access to a resource in another tenant. The resource redirects the user to its resource tenant, a trusted IdP.|
-| **2** | The resource tenant identifies the user as an [external email one-time passcode (OTP) user](./one-time-passcode.md) and sends an email with the OTP to the user.|
+| **2** | The resource tenant identifies the user as an external email one-time passcode (OTP) user and sends an email with the OTP to the user.|
 | **3** | The user retrieves the OTP and submits the code. The resource tenant evaluates the user against its Conditional Access policies.
 | **4** | Once all Conditional Access policies are satisfied, the resource tenant issues a token and redirects the user to its resource. |
 
 ## Conditional Access for external users
 
-Organizations can enforce [Conditional Access](../conditional-access/overview.md) policies for external B2B collaboration and B2B direct connect users in the same way that they’re enabled for full-time employees and members of the organization. With the introduction of cross-tenant access settings, you can also trust MFA and device claims from external Azure AD organizations. This section describes important considerations for applying Conditional Access to users outside of your organization.
+Organizations can enforce Conditional Access policies for external B2B collaboration and B2B direct connect users in the same way that they’re enabled for full-time employees and members of the organization. With the introduction of cross-tenant access settings, you can also trust MFA and device claims from external Azure AD organizations. This section describes important considerations for applying Conditional Access to users outside of your organization.
 
 ### Assigning Conditional Access policies to external user types
 
@@ -81,7 +81,7 @@ When configuring a Conditional Access policy, you have granular control over the
 - **B2B direct connect users** - External users who are able to access your resources via B2B direct connect, which is a mutual, two-way connection with another Azure AD organization that allows single sign-on access to certain Microsoft applications (currently, Microsoft Teams Connect shared channels). B2B direct connect users don’t have a presence in your Azure AD organization, but are instead managed from within the application (for example, by the Teams shared channel owner).
 - **Local guest users** - Local guest users have credentials that are managed in your directory. Before Azure AD B2B collaboration was available, it was common to collaborate with distributors, suppliers, vendors, and others by setting up internal credentials for them and designating them as guests by setting the user object UserType to Guest.
 - **Service provider users** - Organizations that serve as cloud service providers for your organization (the isServiceProvider property in the Microsoft Graph [partner-specific configuration](/graph/api/resources/crosstenantaccesspolicyconfigurationpartner) is true).
-- **Other external users** - Applies to any users who don't fall into the categories above, but who are not considered internal members of your organization, meaning they don't authenticate internally via Azure AD, and the user object created in the resource Azure AD directory does not have a UserType of Member.
+- **Other external users** - Applies to any users who don't fall into the categories above, but who aren't considered internal members of your organization, meaning they don't authenticate internally via Azure AD, and the user object created in the resource Azure AD directory doesn't have a UserType of Member.
 
 >[!NOTE]
 > The "All guest and external users" selection has now been replaced with "Guest and external users" and all its sub types. For customers who previously had a Condtional Access policy with "All guest and external users" selected will now see "Guest and external users" along with all sub types being selected. This change in UX does not have any functional impact on how policy is evaluated by Conditional Access backend. The new selection provides customers the needed granularity to choose specifc types of guest and external users to include/exclude from user scope when creating their Conditional Access policy.
@@ -169,7 +169,7 @@ The following PowerShell cmdlets are available to *proof up* or request MFA regi
 
 ### Authentication strength policies for external users
 
-[Authentication strength](https://aka.ms/b2b-auth-strengths) is a Conditional Access control that lets you define a specific combination of multifactor authentication (MFA) methods that an external user must complete to access your resources. This control is especially useful for restricting external access to sensitive apps in your organization because you can enforce specific authentication methods, such as a phishing-resistant method, for external users.
+Authentication strength is a Conditional Access control that lets you define a specific combination of multifactor authentication (MFA) methods that an external user must complete accessing your resources. This control is especially useful for restricting external access to sensitive apps in your organization because you can enforce specific authentication methods, such as a phishing-resistant method, for external users.
 
 You also have the ability to apply authentication strength to the different types of [guest or external users](#assigning-conditional-access-policies-to-external-user-types) that you collaborate or connect with. This means you can enforce authentication strength requirements that are unique to your B2B collaboration, B2B direct connect, and other external access scenarios.
 
@@ -229,7 +229,7 @@ When device trust settings are enabled, Azure AD checks a user's authentication
 
 ### Device filters
 
-When creating Conditional Access policies for external users, you can evaluate a policy based on the device attributes of a registered device in Azure AD. By using the *filter for devices* condition, you can target specific devices using the [supported operators and properties](../conditional-access/concept-condition-filters-for-devices.md#supported-operators-and-device-properties-for-filters) and the other available assignment conditions in your Conditional Access policies.
+When creating Conditional Access policies for external users, you can evaluate a policy based on the device attributes of a registered device in Azure AD. By using the *filter for devices* condition, you can target specific devices using the supported operators and properties and the other available assignment conditions in your Conditional Access policies.
 
 Device filters can be used together with cross-tenant access settings to base policies on devices that are managed in other organizations. For example, suppose you want to block devices from an external Azure AD tenant based on a specific device attribute. You can set up a device attribute-based policy by doing the following:
 
@@ -279,7 +279,5 @@ For more information, see [Identity Protection and B2B users](../identity-protec
 For more information, see the following articles:
 
 - [Zero Trust policies for allowing guest access and B2B external user access](/microsoft-365/security/office-365-security/identity-access-policies-guest-access?view=o365-worldwide&preserve-view=true)
-- [What is Azure AD B2B collaboration?](./what-is-b2b.md)
 - [Identity Protection and B2B users](../identity-protection/concept-identity-protection-b2b.md)
-- [External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/external-identities/)
 - [Frequently Asked Questions (FAQs)](./faq.yml)

articles/active-directory/manage-apps/configure-permission-classifications.md

@@ -10,7 +10,7 @@ ms.workload: identity
 ms.topic: how-to
 ms.date: 3/28/2023
 ms.author: jomondi
-ms.reviewer: arvindh, luleon, phsignor, jawoods
+ms.reviewer: phsignor, jawoods
 ms.custom: contperf-fy21q2
 zone_pivot_groups: enterprise-apps-all
 
@@ -21,7 +21,7 @@ zone_pivot_groups: enterprise-apps-all
 
 In this article, you learn how to configure permissions classifications in Azure Active Directory (Azure AD). Permission classifications allow you to identify the impact that different permissions have according to your organization's policies and risk evaluations. For example, you can use permission classifications in consent policies to identify the set of permissions that users are allowed to consent to.
 
-Currently, only the "Low impact" permission classification is supported. Only delegated permissions that don't require admin consent can be classified as "Low impact".
+Three permission classifications are supported: "Low", "Medium" (preview), and "High" (preview). Currently, only delegated permissions that don't require admin consent can be classified.
 
 The minimum permissions needed to do basic sign-in are `openid`, `profile`, `email`, and `offline_access`, which are all delegated permissions on the Microsoft Graph. With these permissions an app can read details of the signed-in user's profile, and can maintain this access even when the user is no longer using the app.
 
@@ -30,7 +30,7 @@ The minimum permissions needed to do basic sign-in are `openid`, `profile`, `ema
 To configure permission classifications, you need:
 
 - An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
-- One of the following roles: A global administrator, or owner of the service principal.
+- One of the following roles: Global Administrator, Application Administrator, or Cloud Application Administrator
 
 ## Manage permission classifications
 
@@ -40,7 +40,8 @@ Follow these steps to classify permissions using the Azure portal:
 
 1. Sign in to the [Azure portal](https://portal.azure.com) as a [Global Administrator](../roles/permissions-reference.md#global-administrator), [Application Administrator](../roles/permissions-reference.md#application-administrator), or [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator)
 1. Select **Azure Active Directory** > **Enterprise applications** > **Consent and permissions** > **Permission classifications**.
-1. Choose **Add permissions** to classify another permission as "Low impact".
+1. Choose the tab for the permission classification you'd like to update.
+1. Choose **Add permissions** to classify another permission.
 1. Select the API and then select the delegated permission(s).
 
 In this example, we've classified the minimum set of permission required for single sign-on:
@@ -57,7 +58,7 @@ You can use the latest [Azure AD PowerShell](/powershell/module/azuread/?preserv
 Run the following command to connect to Azure AD PowerShell. To consent to the required scopes, sign in with one of the roles listed in the prerequisite section of this article.
 
 ```powershell
-Connect-AzureAD -Scopes
+Connect-AzureAD
 ```
 
 ### List the current permission classifications
@@ -169,13 +170,9 @@ Connect-MgGraph -Scopes "Policy.ReadWrite.PermissionGrant".
 
    ```powershell
    $params = @{ 
-
-   PermissionId = $delegatedPermission.Id 
-
-   PermissionName = $delegatedPermission.Value 
-
-   Classification = "Low" 
-
+      PermissionId = $delegatedPermission.Id 
+      PermissionName = $delegatedPermission.Value 
+      Classification = "Low"
    } 
 
    New-MgServicePrincipalDelegatedPermissionClassification -ServicePrincipalId $api.Id -BodyParameter $params 
@@ -192,7 +189,7 @@ Connect-MgGraph -Scopes "Policy.ReadWrite.PermissionGrant".
 1. Find the delegated permission classification you wish to remove:
 
    ```powershell
-   $classifications= Get-MgServicePrincipalDelegatedPermissionClassification -ServicePrincipalId $api.Id 
+   $classifications = Get-MgServicePrincipalDelegatedPermissionClassification -ServicePrincipalId $api.Id 
 
    $classificationToRemove = $classifications | Where-Object {$_.PermissionName -eq "openid"}
    ```
@@ -242,4 +239,4 @@ DELETE https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000003-0000-0
 ## Next steps
 
 - [Manage app consent policies](manage-app-consent-policies.md)
-- [Permissions and consent in the Microsoft identity platform](../develop/v2-permissions-and-consent.md)
+- [Permissions and consent in the Microsoft identity platform](../develop/v2-permissions-and-consent.md)

articles/aks/azure-blob-csi.md

@@ -2,7 +2,7 @@
 title: Use Container Storage Interface (CSI) driver for Azure Blob storage on Azure Kubernetes Service (AKS)
 description: Learn how to use the Container Storage Interface (CSI) driver for Azure Blob storage in an Azure Kubernetes Service (AKS) cluster.
 ms.topic: article
-ms.date: 03/29/2023
+ms.date: 04/13/2023
 
 ---
 
@@ -141,9 +141,8 @@ To have a storage volume persist for your workload, you can use a StatefulSet. T
       volumeClaimTemplates:
         - metadata:
             name: persistent-storage
-            annotations:
-              volume.beta.kubernetes.io/storage-class: azureblob-nfs-premium
           spec:
+            storageClassName: azureblob-nfs-premium
             accessModes: ["ReadWriteMany"]
             resources:
               requests:
@@ -191,9 +190,8 @@ To have a storage volume persist for your workload, you can use a StatefulSet. T
       volumeClaimTemplates:
         - metadata:
             name: persistent-storage
-            annotations:
-              volume.beta.kubernetes.io/storage-class: azureblob-fuse-premium
           spec:
+            storageClassName: azureblob-fuse-premium
             accessModes: ["ReadWriteMany"]
             resources:
               requests: