Merge pull request #47744 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/Microsoft/azure-docs (branch master)

Author: huypub

articles/active-directory/user-help/user-help-security-info-overview.md

@@ -24,7 +24,7 @@ ms.author: lizross
 
 Set up your two-step verification and password reset info in **Security info**. After you initially set up your security info, you won't have to do it again. However, you can edit your info and change the default method at any time.
 
-You and add any of the following methods, including:
+You can add any of the following methods, including:
 
 |Article |Description |
 |------|------------|
@@ -35,4 +35,4 @@ You and add any of the following methods, including:
 |[Set up security info to use pre-defined security questions](security-info-setup-questions.md)|Describes how to use security questions to help you reset your password.|
 |[Manage app passwords](security-info-app-passwords.md)|Describes how to set up app passwords using security info.|
 |[Manage your security info](security-info-manage-settings.md)|Describes how to update your security info and work with your app passwords.|
-|[How to sign in](user-help-sign-in.md)|Describes how to sign in using your specified method.|
+|[How to sign in](user-help-sign-in.md)|Describes how to sign in using your specified method.|

articles/firewall/tutorial-firewall-deploy-portal.md

@@ -85,6 +85,9 @@ First, create a resource group to contain the resources needed to deploy the fir
 11. For **Address range**, type **10.0.1.0/24**.
 12. Use the other default settings, and then click **Create**.
 
+> [!NOTE]
+> The minimum size of the AzureFirewallSubnet subnet is /25.
+
 ### Create additional subnets
 
 Next, create subnets for the jump server, and a subnet for the workload servers.
@@ -168,6 +171,9 @@ Use the information in the following table to configure the **Settings** for the
 4. After deployment completes, go to the **Test-FW-RG** resource group, and click the **Test-FW01** firewall.
 6. Note the private IP address. You'll use it later when you create the default route.
 
+> [!NOTE]
+> The Public IP address must be the Standard SKU type.
+
 [//]: # (Remember to note the private IP for the firewall.)
 
 ## Create a default route

articles/key-vault/about-keys-secrets-and-certificates.md

@@ -114,46 +114,48 @@ Where:
 
 Cryptographic keys in Azure Key Vault are represented as JSON Web Key [JWK] objects. The base JWK/JWA specifications are also extended to enable key types unique to the Azure Key Vault implementation, for example the import of keys to Azure Key Vault using the HSM vendor (Thales) specific packaging to enable secure transportation of keys such that they may only be used in the Azure Key Vault HSMs.  
 
-The initial Azure Key Vault release supports RSA keys only; future releases may support other key types such as symmetric and elliptic curve.  
-
--   **RSA**: A 2048-bit RSA key. This is a "soft" key, which is processed in software by Key Vault but is stored encrypted at rest using a system key that is in an HSM. Clients may import an existing RSA key or request that Azure Key Vault generate one.  
--   **RSA-HSM**: An RSA key that is processed in an HSM. RSA-HSM keys are protected in one of the Azure Key Vault HSM Security Worlds (there is a Security World per geography to maintain isolation). Clients may import an RSA key, either in soft form or by exporting from a compatible HSM device, or request that Azure Key Vault generate one. This key type adds the T attribute to the JWK obtain to carry the HSM key material.  
+- **"Soft" keys**: A key processed in software by Key Vault, but is encrypted at rest using a system key that is in an HSM. Clients may import an existing RSA or EC key, or request that Azure Key Vault generate one.
+- **"Hard" keys**: A key processed in an HSM (Hardware Security Module). These keys are protected in one of the Azure Key Vault HSM Security Worlds (there is a Security World per geography to maintain isolation). Clients may import an RSA or EC key, either in soft form or by exporting from a compatible HSM device, or request that Azure Key Vault generate one. This key type adds the T attribute to the JWK obtain to carry the HSM key material.
 
      For more information on geographical boundaries, see [Microsoft Azure Trust Center](https://azure.microsoft.com/support/trust-center/privacy/)  
 
-###  <a name="BKMK_RSAAlgorithms"></a> RSA algorithms  
- The following algorithm identifiers are supported with RSA keys in Azure Key Vault.  
+Azure Key Vault supports RSA and Elliptic Curve keys only; future releases may support other key types such as symmetric.
 
-#### WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT
+-   **EC**: "Soft" Elliptic Curve key.
+-   **EC-HSM**: "Hard" Elliptic Curve key.
+-   **RSA**: "Soft" RSA key.
+-   **RSA-HSM**: "Hard" RSA key.
 
--   **RSA1_5** - RSAES-PKCS1-V1_5 [RFC3447] key encryption  
--   **RSA-OAEP** - RSAES using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with the default parameters specified by RFC 3447 in Section A.2.1. Those default parameters are using a hash function of SHA-1 and a mask generation function of MGF1 with SHA-1.  
+Azure Key Vault supports RSA keys of sizes 2048, 3072 and 4096, and Elliptic Curve keys of type P-256, P-384, P-521 and P-256K.
 
-#### SIGN/VERIFY
+### <a name="BKMK_Cryptographic"></a> Cryptographic protection
 
--   **RS256** - RSASSA-PKCS-v1_5 using SHA-256. The application supplied digest value must be computed using SHA-256 and must be 32 bytes in length.  
--   **RS384** - RSASSA-PKCS-v1_5 using SHA-384. The application supplied digest value must be computed using SHA-384 and must be 48 bytes in length.  
--   **RS512** - RSASSA-PKCS-v1_5 using SHA-512. The application supplied digest value must be computed using SHA-512 and must be 64 bytes in length.  
--   **RSNULL** - See [RFC2437], a specialized use-case to enable certain TLS scenarios.  
+The cryptographic modules that Azure Key Vault uses, whether HSM or software, are FIPS validated. You don’t need to do anything special to run in FIPS mode. If you **create** or **import** keys as HSM-protected, they are guaranteed to be processed inside HSMs validated to FIPS 140-2 Level 2 or higher. If you **create** or **import** keys as software-protected then they are processed inside cryptographic modules validated to FIPS 140-2 Level 1 or higher. For more information, see [Keys and key types](about-keys-secrets-and-certificates.md#BKMK_KeyTypes).
 
-###  <a name="BKMK_RSA-HSMAlgorithms"></a> RSA-HSM algorithms  
-The following algorithm identifiers are supported with RSA-HSM keys in Azure Key Vault.  
+###  <a name="BKMK_ECAlgorithms"></a> EC algorithms
+ The following algorithm identifiers are supported with EC and EC-HSM keys in Azure Key Vault. 
 
-### <a name="BKMK_Cryptographic"></a> Cryptographic protection
+#### SIGN/VERIFY
 
-The cryptographic modules that Azure Key Vault uses, whether HSM or software, are FIPS validated. You don’t need to do anything special to run in FIPS mode. If you **create** or **import** keys as HSM-protected, they are guaranteed to be processed inside HSMs validated to FIPS 140-2 Level 2 or higher. If you **create** or **import** keys as software-protected then they are processed inside cryptographic modules validated to FIPS 140-2 Level 1 or higher. For more information, see [Keys and key types](about-keys-secrets-and-certificates.md#BKMK_KeyTypes).
+-   **ES256** - ECDSA for SHA-256 digests and keys created with curve P-256. This algorithm is described at [RFC7518].
+-   **ES256K** - ECDSA for SHA-256 digests and keys created with curve P-256K. This algorithm is pending standardization.
+-   **ES384** - ECDSA for SHA-384 digests and keys created with curve P-384. This algorithm is described at [RFC7518].
+-   **ES512** - ECDSA for SHA-512 digests and keys created with curve P-521. This algorithm is described at [RFC7518].
+
+###  <a name="BKMK_RSAAlgorithms"></a> RSA algorithms  
+ The following algorithm identifiers are supported with RSA and RSA-HSM keys in Azure Key Vault.  
 
-#### WRAP/UNWRAP, ENCRYPT/DECRYPT
+#### WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT
 
--   **RSA1_5** - RSAES-PKCS1-V1_5 [RFC3447] key encryption.  
+-   **RSA1_5** - RSAES-PKCS1-V1_5 [RFC3447] key encryption  
 -   **RSA-OAEP** - RSAES using Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], with the default parameters specified by RFC 3447 in Section A.2.1. Those default parameters are using a hash function of SHA-1 and a mask generation function of MGF1 with SHA-1.  
 
- #### SIGN/VERIFY  
+#### SIGN/VERIFY
 
 -   **RS256** - RSASSA-PKCS-v1_5 using SHA-256. The application supplied digest value must be computed using SHA-256 and must be 32 bytes in length.  
 -   **RS384** - RSASSA-PKCS-v1_5 using SHA-384. The application supplied digest value must be computed using SHA-384 and must be 48 bytes in length.  
 -   **RS512** - RSASSA-PKCS-v1_5 using SHA-512. The application supplied digest value must be computed using SHA-512 and must be 64 bytes in length.  
--   RSNULL: See [RFC2437], a specialized use-case to enable certain TLS scenarios.  
+-   **RSNULL** - See [RFC2437], a specialized use-case to enable certain TLS scenarios.  
 
 ###  <a name="BKMK_KeyOperations"></a> Key operations
 

articles/log-analytics/log-analytics-containers.md

@@ -176,7 +176,7 @@ For Docker Swarm, once the secret for Workspace ID and Primary Key is created, u
 3. Run the following command to mount the secrets to the containerized OMS Agent.
 
     ```
-    sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --secret source=WSID,target=WSID --secret source=KEY,target=KEY  -p 25225:25225 -p 25224:25224/udp --restart-condition=on-failure microsoft/oms
+    sudo docker service create  --name omsagent --mode global  --mount type=bind,source=/var/run/docker.sock,destination=/var/run/docker.sock --mount type=bind,source=/var/lib/docker/containers,destination=/var/lib/docker/containers --secret source=WSID,target=WSID --secret source=KEY,target=KEY  -p 25225:25225 -p 25224:25224/udp --restart-condition=on-failure microsoft/oms
     ```
 
 #### Configure an OMS Agent for Red Hat OpenShift

articles/service-fabric-mesh/service-fabric-mesh-monitoring-diagnostics.md

@@ -36,7 +36,7 @@ az mesh code-package-log get --resource-group <nameOfRG> --app-name <nameOfApp>
 ```
 
 > [!NOTE]
-> You can use the "az mesh servicereplica" command to get the replica name. Replica names are incrementing numbers from 0.*
+> You can use the "az mesh service-replica" command to get the replica name. Replica names are incrementing numbers from 0.*
 
 Here is what this looks like for seeing the logs from the VotingWeb.Code container from the voting application:
 

articles/virtual-machines/linux/azure-dns.md

@@ -20,7 +20,7 @@ ms.author: rclaus
 # DNS Name Resolution options for Linux virtual machines in Azure
 Azure provides DNS name resolution by default for all virtual machines that are in a single virtual network. You can implement your own DNS name resolution solution by configuring your own DNS services on your virtual machines that Azure hosts. The following scenarios should help you choose the one that works for your situation.
 
-* [Name resolution that Azure provides](#azure-provided-name-resolution)
+* [Name resolution that Azure provides](#name-resolution-that-azure-provides)
 * [Name resolution using your own DNS server](#name-resolution-using-your-own-dns-server)
 
 The type of name resolution that you use depends on how your virtual machines and role instances need to communicate with each other.

articles/virtual-machines/workloads/sap/sap-hana-backup-storage-snapshots.md

@@ -85,7 +85,7 @@ Azure Backup has four major phases:
 For details on where to copy these scripts and details on how Azure Backup works exactly, check the following articles:
 
 - [Plan your VM backup infrastructure in Azure](https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction)
-- [Application consistent consistent backup of Azure Linux VMs](https://docs.microsoft.com/en-us/azure/backup/backup-azure-linux-app-consistent)
+- [Application-consistent backup of Azure Linux VMs](https://docs.microsoft.com/en-us/azure/backup/backup-azure-linux-app-consistent)
 
 
 

includes/active-directory-protocols-getting-started.md

@@ -19,12 +19,13 @@ ms.author: priyamo
 First, you need to register your application with your Azure Active Directory (Azure AD) tenant. This will give you an Application ID for your application, as well as enable it to receive tokens.
 
 * Sign in to the [Azure portal](https://portal.azure.com).
-* Choose your Azure AD tenant by clicking on your account in the top right corner of the page.
+* Choose your Azure AD tenant by clicking on your account in the top right corner of the page, followed by clicking on the **Switch Directory** navigation and then select the appropriate tenant. 
+  * Skip this step, if you've only one Azure AD tenant under your account or if you've already selected the appropriate Azure AD tenant.
 * In the left hand navigation pane, click on **Azure Active Directory**.
 * Click on **App Registrations** and click on **New application registration**.
 * Follow the prompts and create a new application. It doesn't matter if it is a web application or a native application for this tutorial, but if you'd like specific examples for web applications or native applications, check out our [quickstarts](../articles/active-directory/develop/active-directory-developers-guide.md).
   * For Web Applications, provide the **Sign-On URL**, which is the base URL of your app, where users can sign in e.g `http://localhost:12345`.
 <!--TODO: add once App ID URI is configurable: The **App ID URI** is a unique identifier for your application. The convention is to use `https://<tenant-domain>/<app-name>`, e.g. `https://contoso.onmicrosoft.com/my-first-aad-app`-->
   * For Native Applications provide a **Redirect URI**, which Azure AD will use to return token responses. Enter a value specific to your application, .e.g `http://MyFirstAADApp`
 * Once you've completed registration, Azure AD will assign your application a unique client identifier, the **Application ID**. You need this value in the next sections, so copy it from the application page.
-* To find your application in the Azure portal, click **App registrations**, and then click **View all applications**.
+* To find your application in the Azure portal, click **App registrations**, and then click **View all applications**.