Merge pull request #249467 from MicrosoftDocs/main

Publish to live, Monday 4 AM PST, 8/28

Author: ttorble

.openpublishing.redirection.json

@@ -1,5 +1,15 @@
 {
     "redirections": [
+        {
+            "source_path": "articles/migrate/tutorial-assess-webapps-physical.md",
+            "redirect_URL": "tutorial-assess-webapps",
+            "redirect_document_id": false
+        },
+        {
+            "source_path": "articles/migrate/tutorial-assess-webapps-hyper-v.md",
+            "redirect_URL": "tutorial-assess-webapps",
+            "redirect_document_id": false
+        },
         {
             "source_path": "articles/route-server/tutorial-protect-route-server.md",
             "redirect_URL": "/azure/route-server/tutorial-protect-route-server-ddos",

articles/active-directory/app-provisioning/inbound-provisioning-api-grant-access.md

@@ -86,6 +86,6 @@ This section describes how you can assign the necessary permissions to a managed
 ## Next steps
 - [Quick start using cURL](inbound-provisioning-api-curl-tutorial.md)
 - [Quick start using Postman](inbound-provisioning-api-postman.md)
-- [Quick start using Postman](inbound-provisioning-api-graph-explorer.md)
+- [Quick start using Graph Explorer](inbound-provisioning-api-graph-explorer.md)
 - [Frequently asked questions about API-driven inbound provisioning](inbound-provisioning-api-faqs.md)
 

articles/active-directory/external-identities/customers/how-to-web-app-node-use-certificate.md

@@ -19,9 +19,9 @@ ms.custom: developer, devx-track-js
 
 Azure Active Directory (Azure AD) for customers supports two types of authentication for [confidential client applications](../../../active-directory/develop/msal-client-applications.md); password-based authentication (such as client secret) and certificate-based authentication. For a higher level of security, we recommend using a certificate (instead of a client secret) as a credential in your confidential client applications.
 
-In production, you should purchase a certificate signed by a well-known certificate authority, and use [Azure Key Vault](https://azure.microsoft.com/products/key-vault/) to manage certificate access and lifetime for you. However, for testing purposes, you can create a self-signed certificate and configure your apps to authenticate with it.
+In production, you should purchase a certificate signed by a well-known certificate authority, and use [Azure Key Vault](https://azure.microsoft.com/products/key-vault/) to manage certificate access and lifetime for you. However, for testing purposes, you can create a self-signed certificate and configure your apps to authenticate with it. 
 
-In this article, you learn to generate a self-signed certificate by using [Azure Key Vault](https://azure.microsoft.com/products/key-vault/) on the Azure portal, OpenSSL or Windows PowerShell.  
+In this article, you learn to generate a self-signed certificate by using [Azure Key Vault](https://azure.microsoft.com/products/key-vault/) on the Azure portal, OpenSSL or Windows PowerShell. If you have a client secret already, you'll learn how to safely delete it.
 
 When needed, you can also create a self-signed certificate programmatically by using [.NET](/azure/key-vault/certificates/quick-create-net), [Node.js](/azure/key-vault/certificates/quick-create-node), [Go](/azure/key-vault/certificates/quick-create-go), [Python](/azure/key-vault/certificates/quick-create-python) or [Java](/azure/key-vault/certificates/quick-create-java) client libraries.
 
@@ -88,11 +88,13 @@ After the command finishes execution, you should have a *.crt* and a *.key* file
 
 [!INCLUDE [active-directory-customers-app-integration-add-user-flow](./includes/register-app/add-client-app-certificate.md)]
 
+[!INCLUDE [remove-client-secret](./includes/remove-client-secret.md)]
+
 ## Configure your Node.js app to use certificate
 
 Once you associate your app registration with the certificate, you need to update your app code to start using the certificate:
 
-1. Locate the file that contains your MSAL configuration object, such as `msalConfig`  in *authConfig.js*, then update it to look similar to the following code:
+1. Locate the file that contains your MSAL configuration object, such as `msalConfig`  in *authConfig.js*, then update it to look similar to the following code. If you have a client secret present, make sure you remove it:
 
     ```javascript
     require('dotenv').config();
@@ -124,7 +126,6 @@ Once you associate your app registration with the certificate, you need to updat
             auth: {
                 clientId: process.env.CLIENT_ID || 'Enter_the_Application_Id_Here', // 'Application (client) ID' of app registration in Azure portal - this value is a GUID
                 authority: process.env.AUTHORITY || `https://${TENANT_SUBDOMAIN}.ciamlogin.com/`, 
-                //clientSecret: process.env.CLIENT_SECRET || 'Enter_the_Client_Secret_Here', // Client secret generated from the app registration in Azure portal
                 clientCertificate: {
                     thumbprint: "YOUR_CERT_THUMBPRINT", // replace with thumbprint obtained during step 2 above
                     privateKey: privateKey
@@ -174,14 +175,13 @@ Once you associate your app registration with the certificate, you need to updat
 
 You can use your existing certificate directly from Azure Key Vault:
 
-1. Locate the file that contains your MSAL configuration object, such as `msalConfig`  in *authConfig.js*, then comment the `clientSecret` property:
+1. Locate the file that contains your MSAL configuration object, such as `msalConfig`  in *authConfig.js*, then remove the `clientSecret` property:
     
     ```java
     const msalConfig = {
         auth: {
             clientId: process.env.CLIENT_ID || 'Enter_the_Application_Id_Here', // 'Application (client) ID' of app registration in Azure portal - this value is a GUID
             authority: process.env.AUTHORITY || `https://${TENANT_SUBDOMAIN}.ciamlogin.com/`, 
-            //clientSecret: process.env.CLIENT_SECRET || 'Enter_the_Client_Secret_Here', // Client secret generated from the app registration in Azure portal
         },
         //...
     };

articles/active-directory/external-identities/customers/includes/remove-client-secret.md

@@ -0,0 +1,13 @@
+---
+author: cilwerner
+ms.service: active-directory
+ms.subservice: ciam
+ms.topic: include
+ms.date: 08/28/2023
+ms.author: cwerner
+---
+
+If you've a client secret already in place for your application, you need to delete it to avoid a malicious application for impersonating your application:
+
+1. Go to the **Client secrets** tab, and select the **Delete** icon.
+2. In the pop-up window that appears, select **Yes**.

articles/active-directory/saas-apps/uber-tutorial.md

@@ -69,11 +69,11 @@ Complete the following steps to enable Azure AD single sign-on in the Azure port
 
 ## Configure Uber SSO
 
-To configure single sign-on on **Uber** side, you need to send the downloaded **Certificate (PEM)** and appropriate copied URLs from Azure portal to [Uber support team](mailto:business-api-[email protected]). They set this setting to have the SAML SSO connection set properly on both sides.
+To configure single sign-on on **Uber** side, you need to send the downloaded **Certificate (PEM)** and appropriate copied URLs from Azure portal to [Uber support team](mailto:[email protected]). They set this setting to have the SAML SSO connection set properly on both sides.
 
 ### Create Uber test user
 
-In this section, you create a user called Britta Simon in Uber. Work with [Uber support team](mailto:business-api[email protected]) to add the users in the Uber platform. Users must be created and activated before you use single sign-on. Uber also supports automatic user provisioning, you can find more details [here](uber-provisioning-tutorial.md) on how to configure automatic user provisioning.
+In this section, you create a user called Britta Simon in Uber. Work with [Uber support team or your Uber POC](mailto:[email protected]) to add the users in the Uber platform. Users must be created and activated before you use single sign-on. Uber also supports automatic user provisioning, you can find more details [here](uber-provisioning-tutorial.md) on how to configure automatic user provisioning.
 
 ## Test SSO 
 

articles/ai-services/speech-service/bring-your-own-storage-speech-resource.md

@@ -154,7 +154,7 @@ General rule is that you need to pass this JSON string as a value of `--storage`
 
 To create a BYOS-enabled Speech resource with a REST Request to Cognitive Services API, we use [Accounts - Create](/rest/api/cognitiveservices/accountmanagement/accounts/create) request.
 
-You need to have a meaning of authentication. The example in this section uses [Microsoft Azure Active Directory token](/azure/active-directory/develop/access-tokens).
+You need to have a means of authentication. The example in this section uses [Microsoft Azure Active Directory token](/azure/active-directory/develop/access-tokens).
 
 This code snippet generates Azure AD token using interactive browser sign-in. It requires [Azure Identity client library](/dotnet/api/overview/azure/identity-readme):
 ```csharp

articles/app-service/environment/networking.md

@@ -25,20 +25,22 @@ The size of the subnet can affect the scaling limits of the App Service plan ins
 >
 > Sample calculation:
 >
-> For each App Service plan instance, you need:  
-> 5 Windows Container apps = 5 IP addresses  
-> 1 IP address per App Service plan instance  
+> For each App Service plan instance, you need:
+> 5 Windows Container apps = 5 IP addresses
+> 1 IP address per App Service plan instance
 > 5 + 1 = 6 IP addresses
 >
-> For 25 instances:  
+> For 25 instances:
 > 6 x 25 = 150 IP addresses per App Service plan
 >
 > Since you have 2 App Service plans, 2 x 150 = 300 IP addresses.
 
 If you use a smaller subnet, be aware of the following limitations:
 
-- Any particular subnet has five addresses reserved for management purposes. In addition to the management addresses, App Service Environment dynamically scales the supporting infrastructure, and uses between 4 and 27 addresses, depending on the configuration and load. You can use the remaining addresses for instances in the App Service plan. The minimal size of your subnet is a `/27` address space (32 addresses).
-
+- Any particular subnet has five addresses reserved for management purposes. In addition to the management addresses, App Service Environment dynamically scales the supporting infrastructure, and uses between 7 and 27 addresses, depending on the configuration and load. You can use the remaining addresses for instances in the App Service plan. The minimal size of your subnet is a `/27` address space (32 addresses).
+- For any App Service plan OS/SKU combination used in your App Service Environment like I1v2 Windows, one standby instance is created for every 20 active instances. The standby instances also require IP addresses.
+- When scaling App Service plans in the App Service Environment up/down, the amount of IP addresses used by the App Service plan is temporarily doubled while the scale operation completes. The new instances need to be fully operational before the existing instances are deprovisioned.
+- Platform upgrades need free IP addresses to ensure upgrades can happen without interruptions to outbound traffic. Finally, after scale up, down, or in operations complete, there might be a short period of time before IP addresses are released.
 - If you run out of addresses within your subnet, you can be restricted from scaling out your App Service plans in the App Service Environment. Another possibility is that you can experience increased latency during intensive traffic load, if Microsoft isn't able to scale the supporting infrastructure.
 
 ## Addresses
@@ -58,11 +60,11 @@ You can find details in the **IP Addresses** portion of the portal, as shown in
 
 ![Screenshot that shows details about IP addresses.](./media/networking/networking-ip-addresses.png)
 
-As you scale your App Service plans in your App Service Environment, you'll use more addresses out of your subnet. The number of addresses you use varies, based on the number of App Service plan instances you have, and how much traffic there is. Apps in the App Service Environment don't have dedicated addresses in the subnet. The specific addresses used by an app in the subnet will change over time.
+As you scale your App Service plans in your App Service Environment, you use more addresses out of your subnet. The number of addresses you use varies, based on the number of App Service plan instances you have, and how much traffic there is. Apps in the App Service Environment don't have dedicated addresses in the subnet. The specific addresses used by an app in the subnet will change over time.
 
 ## Ports and network restrictions
 
-For your app to receive traffic, ensure that inbound network security group (NSG) rules allow the App Service Environment subnet to receive traffic from the required ports. In addition to any ports you'd like to receive traffic on, you should ensure that Azure Load Balancer is able to connect to the subnet on port 80. This port is used for health checks of the internal virtual machine. You can still control port 80 traffic from the virtual network to your subnet.
+For your app to receive traffic, ensure that inbound network security group (NSG) rules allow the App Service Environment subnet to receive traffic from the required ports. In addition to any ports, you'd like to receive traffic on, you should ensure that Azure Load Balancer is able to connect to the subnet on port 80. This port is used for health checks of the internal virtual machine. You can still control port 80 traffic from the virtual network to your subnet.
 
 It's a good idea to configure the following inbound NSG rule:
 
@@ -95,11 +97,11 @@ The normal app access ports inbound are as follows:
 
 You can set route tables without restriction. You can tunnel all of the outbound application traffic from your App Service Environment to an egress firewall device, such as Azure Firewall. In this scenario, the only thing you have to worry about is your application dependencies.
 
-Application dependencies include endpoints that your app needs during runtime. Besides APIs and services the app is calling, dependencies could also be derived endpoints like certificate revocation list (CRL) check endpoints and identity/authentication endpoint, for example Azure Active Directory. If you're using [continuous deployment in App Service](../deploy-continuous-deployment.md), you might also need to allow endpoints depending on type and language. Specifically for [Linux continuous deployment](https://github.com/microsoft/Oryx/blob/main/doc/hosts/appservice.md#network-dependencies), you'll need to allow `oryx-cdn.microsoft.io:443`.
+Application dependencies include endpoints that your app needs during runtime. Besides APIs and services the app is calling, dependencies could also be derived endpoints like certificate revocation list (CRL) check endpoints and identity/authentication endpoint, for example Azure Active Directory. If you're using [continuous deployment in App Service](../deploy-continuous-deployment.md), you might also need to allow endpoints depending on type and language. Specifically for [Linux continuous deployment](https://github.com/microsoft/Oryx/blob/main/doc/hosts/appservice.md#network-dependencies), you need to allow `oryx-cdn.microsoft.io:443`.
 
 You can put your web application firewall devices, such as Azure Application Gateway, in front of inbound traffic. Doing so allows you to expose specific apps on that App Service Environment.
 
-Your application will use one of the default outbound addresses for egress traffic to public endpoints. If you want to customize the outbound address of your applications on an App Service Environment, you can add a NAT gateway to your subnet.
+Your application uses one of the default outbound addresses for egress traffic to public endpoints. If you want to customize the outbound address of your applications on an App Service Environment, you can add a NAT gateway to your subnet.
 
 > [!NOTE]
 > Outbound SMTP connectivity (port 25) is supported for App Service Environment v3. The supportability is determined by a setting on the subscription where the virtual network is deployed. For virtual networks/subnets created before 1. August 2022 you need to initiate a temporary configuration change to the virtual network/subnet for the setting to be synchronized from the subscription. An example could be to add a temporary subnet, associate/dissociate an NSG temporarily or configure a service endpoint temporarily. For more information and troubleshooting, see [Troubleshoot outbound SMTP connectivity problems in Azure](../../virtual-network/troubleshoot-outbound-smtp-connectivity.md).
@@ -119,7 +121,7 @@ For more information about Private Endpoint and Web App, see [Azure Web App Priv
 
 ## DNS
 
-The following sections describe the DNS considerations and configuration that apply inbound to and outbound from your App Service Environment. The examples use the domain suffix `appserviceenvironment.net` from Azure Public Cloud. If you're using other clouds like Azure Government, you'll need to use their respective domain suffix.
+The following sections describe the DNS considerations and configuration that apply inbound to and outbound from your App Service Environment. The examples use the domain suffix `appserviceenvironment.net` from Azure Public Cloud. If you're using other clouds like Azure Government, you need to use their respective domain suffix.
 
 ### DNS configuration to your App Service Environment
 
@@ -153,7 +155,7 @@ In addition to setting up DNS, you also need to enable it in the [App Service En
 
 ### DNS configuration from your App Service Environment
 
-The apps in your App Service Environment will use the DNS that your virtual network is configured with. If you want some apps to use a different DNS server, you can manually set it on a per app basis, with the app settings `WEBSITE_DNS_SERVER` and `WEBSITE_DNS_ALT_SERVER`. `WEBSITE_DNS_ALT_SERVER` configures the secondary DNS server. The secondary DNS server is only used when there's no response from the primary DNS server.
+The apps in your App Service Environment uses the DNS that your virtual network is configured with. If you want some apps to use a different DNS server, you can manually set it on a per app basis, with the app settings `WEBSITE_DNS_SERVER` and `WEBSITE_DNS_ALT_SERVER`. `WEBSITE_DNS_ALT_SERVER` configures the secondary DNS server. The secondary DNS server is only used when there's no response from the primary DNS server.
 
 ## More resources