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

v-sonan · v-sonan · commit a5adeaef5d54 · 2019-10-09T13:16:54.000-07:00
diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json
@@ -42203,7 +42203,7 @@
     },
     {
       "source_path": "articles/security/fundamentals/network-security.md",
-      "redirect_url": "/azure/security/fundamentals/network-security",
+      "redirect_url": "/azure/security/fundamentals/network-overview",
       "redirect_document_id": false
     },
     {
diff --git a/articles/active-directory/saas-apps/cs-stars-tutorial.md b/articles/active-directory/saas-apps/cs-stars-tutorial.md
@@ -108,7 +108,7 @@ To configure Azure AD single sign-on with CS Stars, perform the following steps:
     `https://<subdomain>.csstars.com/enterprise/`
 
 	> [!NOTE]
-	> These values are not real. Update these values with the actual Sign on URL and Identifier. Contact [CS Stars Client support team](https://www.marshclearsight.com/support/) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.
+	> These values are not real. Update these values with the actual Sign on URL and Identifier. Contact [CS Stars Client support team](http://www.riskonnectclearsight.com/support/) to get these values. You can also refer to the patterns shown in the **Basic SAML Configuration** section in the Azure portal.
 
 4. On the **Set up Single Sign-On with SAML** page, in the **SAML Signing Certificate** section, click **Download** to download the **Federation Metadata XML** from the given options as per your requirement and save it on your computer.
 
@@ -126,7 +126,7 @@ To configure Azure AD single sign-on with CS Stars, perform the following steps:
 
 ### Configure CS Stars Single Sign-On
 
-To configure single sign-on on **CS Stars** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [CS Stars support team](https://www.marshclearsight.com/support/). They set this setting to have the SAML SSO connection set properly on both sides.
+To configure single sign-on on **CS Stars** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [CS Stars support team](http://www.riskonnectclearsight.com/support/). They set this setting to have the SAML SSO connection set properly on both sides.
 
 ### Create an Azure AD test user 
 
@@ -181,7 +181,7 @@ In this section, you enable Britta Simon to use Azure single sign-on by granting
 
 ### Create CS Stars test user
 
-In this section, you create a user called Britta Simon in CS Stars. Work with [CS Stars support team](https://www.marshclearsight.com/support/) to add the users in the CS Stars platform. Users must be created and activated before you use single sign-on.
+In this section, you create a user called Britta Simon in CS Stars. Work with [CS Stars support team](http://www.riskonnectclearsight.com/support/) to add the users in the CS Stars platform. Users must be created and activated before you use single sign-on.
 
 ### Test single sign-on 
 
diff --git a/articles/application-gateway/end-to-end-ssl-portal.md b/articles/application-gateway/end-to-end-ssl-portal.md
@@ -1,6 +1,6 @@
 ---
 title: Quickstart - Configure end-to-end SSL encryption with Azure Application Gateway - Azure portal | Microsoft Docs
-description: Learn how to use the Azure portal to create an Azure Application Gateway with end-to-end SSL encryption.
+description: Learn how to use the Azure portal to create an application gateway with end-to-end SSL encryption.
 services: application-gateway
 author: vhorne
 ms.service: application-gateway
@@ -11,7 +11,7 @@ ms.custom: mvc
 ---
 # Configure end-to-end SSL by using Application Gateway with the portal
 
-This article shows you how to use the Azure portal to configure end-to-end SSL encryption with an application gateway v1 SKU.  
+This article describes how to use the Azure portal to configure end-to-end Secure Sockets Layer (SSL) encryption through Azure Application Gateway v1 SKU.
 
 > [!NOTE]
 > Application Gateway v2 SKU requires trusted root certificates for enabling end-to-end configuration.
@@ -20,94 +20,97 @@ If you don't have an Azure subscription, create a [free account](https://azure.m
 
 ## Before you begin
 
-To configure end-to-end SSL with an Application Gateway, a certificate is required for the gateway and certificates are required for the back-end servers. The gateway certificate is used to derive a symmetric key as per SSL protocol specification. The symmetric key is then used to encrypt and decrypt the traffic sent to the gateway. For end-to-end SSL encryption, the right back-end servers must be allowed in the application gateway. To do this, upload the public certificate of the back-end servers, also known as Authentication Certificates (v1) or Trusted Root Certificates (v2), to the Application Gateway. Adding the certificate ensures that the Application Gateway only communicates with known back-end instances. This further secures the end-to-end communication.
+To configure end-to-end SSL with an application gateway, you need a certificate for the gateway. Certificates are also required for the back-end servers. The gateway certificate is used to derive a symmetric key in compliance with the SSL protocol specification. The symmetric key is then used to encrypt and decrypt the traffic sent to the gateway. 
+
+For end-to-end SSL encryption, the right back-end servers must be allowed in the application gateway. To allow this access, upload the public certificate of the back-end servers, also known as Authentication Certificates (v1) or Trusted Root Certificates (v2), to the application gateway. Adding the certificate ensures that the application gateway communicates only with known back-end instances. This configuration further secures end-to-end communication.
 
 To learn more, see [SSL termination and end-to-end SSL](https://docs.microsoft.com/azure/application-gateway/ssl-overview).
 
 ## Create a new application gateway with end-to-end SSL
 
-To create a new application gateway with end-to-end SSL encryption, you'll need to first enable SSL termination while creating a new application gateway. This will enable SSL encryption for the communication between the client and application gateway. Then, you'll need to whitelist certificates for backend servers in the HTTP settings to enable SSL encryption for the communication between the application gateway and backend servers, accomplishing end-to-end SSL encryption.
+To create a new application gateway with end-to-end SSL encryption, you'll need to first enable SSL termination while creating a new application gateway. This action enables SSL encryption for communication between the client and application gateway. Then, you'll need to put on the Safe Recipients list the certificates for the back-end servers in the HTTP settings. This configuration enables SSL encryption for communication between the application gateway and the back-end servers. That accomplishes end-to-end SSL encryption.
 
 ### Enable SSL termination while creating a new application gateway
 
-Refer to this article to understand how to [enable SSL termination while creating a new application gateway](https://docs.microsoft.com/azure/application-gateway/create-ssl-portal).
+To learn more, see [enable SSL termination while creating a new application gateway](https://docs.microsoft.com/azure/application-gateway/create-ssl-portal).
 
-### Add authentication/root certificate of back-end servers
+### Add authentication/root certificates of back-end servers
 
 1. Select **All resources**, and then select **myAppGateway**.
 
-2. Select **HTTP settings** from the left menu. Azure automatically created a default HTTP setting, **appGatewayBackendHttpSettings**, when you created the application gateway. 
+2. Select **HTTP settings** from the left-side menu. Azure automatically created a default HTTP setting, **appGatewayBackendHttpSettings**, when you created the application gateway. 
 
 3. Select **appGatewayBackendHttpSettings**.
 
-4. Under **Protocol**, select **HTTPS**. A pane for **Backend authentication certificates or Trusted root certificates** will appear. 
+4. Under **Protocol**, select **HTTPS**. A pane for **Backend authentication certificates or Trusted root certificates** appears.
 
-5. Choose **Create new**.
+5. Select **Create new**.
 
-6. Enter a suitable **Name**.
+6. In the **Name** field, enter a suitable name.
 
-7. Select the certificate file using the **Upload CER certificate** box.
+7. Select the certificate file in the **Upload CER certificate** box.
 
-   For Standard and WAF (v1) Application Gateways, you should upload the public key of your backend server certificate in .cer format.
+   For Standard and WAF (v1) application gateways, you should upload the public key of your back-end server certificate in .cer format.
 
-   ![addcert](./media/end-to-end-ssl-portal/addcert.png)
+   ![Add certificate](./media/end-to-end-ssl-portal/addcert.png)
 
-   For Standard_v2 and WAF_v2 Application Gateways, you should upload the **root certificate** of the backend server certificate in .cer format. If the backend certificate is issued by a well-known CA, you can check the "Use Well Known CA certificate" box and there is no need to upload a certificate.
+   For Standard_v2 and WAF_v2 application gateways, you should upload the root certificate of the back-end server certificate in .cer format. If the back-end certificate is issued by a well-known certificate authority (CA), you can select the **Use Well Known CA Certificate** check box, and then you don't have to upload a certificate.
 
-   ![addtrustedrootcert](./media/end-to-end-ssl-portal/trustedrootcert-portal.png)
+   ![Add trusted root certificate](./media/end-to-end-ssl-portal/trustedrootcert-portal.png)
 
-   ![rootcert](./media/end-to-end-ssl-portal/trustedrootcert.png)
+   ![Root certificate](./media/end-to-end-ssl-portal/trustedrootcert.png)
 
 8. Select **Save**.
 
-## Enable end-to-end SSL for existing application gateway
+## Enable end-to-end SSL for an existing application gateway
 
-To configure an existing application gateway with end-to-end SSL encryption, you'll need to first enable SSL termination in the listener. This will enable SSL encryption for the communication between the client and application gateway. Then, you'll need to whitelist certificates for backend servers in the HTTP settings to enable SSL encryption for the communication between the application gateway and backend servers, accomplishing end-to-end SSL encryption.
+To configure an existing application gateway with end-to-end SSL encryption, you must first enable SSL termination in the listener. This action enables SSL encryption for communication between the client and the application gateway. Then, put those certificates for back-end servers in the HTTP settings on the Safe Recipients list. This configuration enables SSL encryption for communication between the application gateway and the back-end servers. That accomplishes end-to-end SSL encryption.
 
-You'll need to use a listener with HTTPS protocol and certificate for enabling SSL termination. So, you can either choose to use an existing listener with HTTPS protocol and certificate, or create a new listener. In case you choose the former, you can ignore the below mentioned steps to **Enable SSL termination in existing application gateway** and directly move to **Add authentication/trusted root certificates for back-end servers** section. If you choose the latter, use these steps.
+You'll need to use a listener with the HTTPS protocol and a certificate for enabling SSL termination. You can either use an existing listener that meets those conditions or create a new listener. If you choose the former option, you can ignore the following "Enable SSL termination in an existing application gateway" section and move directly to the "Add authentication/trusted root certificates for backend servers" section.
 
-### Enable SSL termination in existing application gateway
+If you choose the latter option, apply the steps in the following procedure.
+### Enable SSL termination in an existing application gateway
 
 1. Select **All resources**, and then select **myAppGateway**.
 
-2. Select **Listeners** from the left menu.
+2. Select **Listeners** from the left-side menu.
 
-3. Choose between **Basic** and **Multi-site** listener as per your requirement.
+3. Select either **Basic** or **Multi-site** listener depending on your requirements.
 
-4. Under **Protocol**, select **HTTPS**. A pane for **Certificate** will appear.
+4. Under **Protocol**, select **HTTPS**. A pane for **Certificate** appears.
 
-5. Upload the PFX certificate that you intend to use for SSL termination between the client and application gateway.
+5. Upload the PFX certificate you intend to use for SSL termination between the client and the application gateway.
 
    > [!NOTE]
-   > For testing purposes, you can use a self-signed certificate. but not advised for production workloads as they are harder to manage and not completely secure. Learn how to [create a self-signed certificate](https://docs.microsoft.com/azure/application-gateway/create-ssl-portal#create-a-self-signed-certificate).
+   > For testing purposes, you can use a self-signed certificate. However, this is not advised for production workloads, because they're harder to manage and aren't completely secure. For more info, see [create a self-signed certificate](https://docs.microsoft.com/azure/application-gateway/create-ssl-portal#create-a-self-signed-certificate).
 
-6. Add other required settings for the **Listener** as per your requirement.
+6. Add other required settings for the **Listener**, depending on your requirements.
 
 7. Select **OK** to save.
 
 ### Add authentication/trusted root certificates of back-end servers
 
 1. Select **All resources**, and then select **myAppGateway**.
 
-2. Select **HTTP settings** from the left menu. You can either whitelist certificates in an existing backend HTTP setting or create a new HTTP setting. In the below step, we will whitelist certificate for the default HTTP setting, **appGatewayBackendHttpSettings**.
+2. Select **HTTP settings** from the left-side menu. You can either put certificates in an existing back-end HTTP setting on the Safe Recipients list or create a new HTTP setting. (In the next step, the certificate for the default HTTP setting, **appGatewayBackendHttpSettings**, is added to the Safe Recipients list.)
 
 3. Select **appGatewayBackendHttpSettings**.
 
-4. Under **Protocol**, select **HTTPS**. A pane for **Backend authentication certificates or Trusted root certificates** will appear. 
+4. Under **Protocol**, select **HTTPS**. A pane for **Backend authentication certificates or Trusted root certificates** appears. 
 
-5. Choose **Create new**.
+5. Select **Create new**.
 
-6. Enter suitable **Name**.
+6. In the **Name** field, enter a suitable name.
 
-7. Select the certificate file using the **Upload CER certificate** box.
+7. Select the certificate file in the **Upload CER certificate** box.
 
-   For Standard and WAF (v1) Application Gateways, you should upload the public key of your backend server certificate in .cer format.
+   For Standard and WAF (v1) application gateways, you should upload the public key of your back-end server certificate in .cer format.
 
-   ![addcert](./media/end-to-end-ssl-portal/addcert.png)
+   ![Add certificate](./media/end-to-end-ssl-portal/addcert.png)
 
-   For Standard_v2 and WAF_v2 Application Gateways, you should upload the **root certificate** of the backend server certificate in .cer format. If the backend certificate is issued by a well-known CA, you can check the "Use Well Known CA certificate" box and there is no need to upload a certificate.
+   For Standard_v2 and WAF_v2 application gateways, you should upload the root certificate of the back-end server certificate in .cer format. If the back-end certificate is issued by a well-known CA, you can select the **Use Well Known CA Certificate** check box, and then you don't have to upload a certificate.
 
-   ![addtrustedrootcert](./media/end-to-end-ssl-portal/trustedrootcert-portal.png)
+   ![Add trusted root certificate](./media/end-to-end-ssl-portal/trustedrootcert-portal.png)
 
 8. Select **Save**.
 
diff --git a/articles/automation/automation-dsc-cd-chocolatey.md b/articles/automation/automation-dsc-cd-chocolatey.md
@@ -40,7 +40,7 @@ intro. In a nutshell, Chocolatey allows you to install packages from a central r
 packages into a Windows system using the command line. You can create and manage your own
 repository, and Chocolatey can install packages from any number of repositories that you designate.
 
-Desired State Configuration (DSC) ([overview](/powershell/dsc/overview)) is a PowerShell tool that
+Desired State Configuration (DSC) ([overview](/powershell/scripting/dsc/overview/overview)) is a PowerShell tool that
 allows you to declare the configuration that you want for a machine. For example, you can say, "I
 want Chocolatey installed, I want IIS installed, I want port 80 opened, I want version 1.0.0 of my
 website installed." The DSC Local Configuration Manager (LCM) implements that configuration. A DSC
diff --git a/articles/automation/automation-dsc-compile.md b/articles/automation/automation-dsc-compile.md
@@ -133,7 +133,7 @@ For information about passing PSCredentials as parameters, see [Credential Asset
 
 **Composite Resources** allow you to use DSC configurations as nested resources inside of a
 configuration. This enables you to apply multiple configurations to a single resource. See
-[Composite resources: Using a DSC configuration as a resource](/powershell/dsc/authoringresourcecomposite)
+[Composite resources: Using a DSC configuration as a resource](/powershell/scripting/dsc/resources/authoringresourcecomposite)
 to learn more about **Composite Resources**.
 
 > [!NOTE]
diff --git a/articles/security/develop/threat-modeling-tool-authentication.md b/articles/security/develop/threat-modeling-tool-authentication.md
@@ -305,7 +305,7 @@ The `<netMsmqBinding/>` element of the WCF configuration file below instructs WC
 | **SDL Phase**               | Build |  
 | **Applicable Technologies** | .NET Framework 3 |
 | **Attributes**              | Client Credential Type - None |
-| **References**              | [MSDN](https://msdn.microsoft.com/library/ff648500.aspx), [Fortify](https://vulncat.fortify.com/en/detail?id=desc.semantic.dotnet.wcf_misconfiguration_anonymous_message_client) |
+| **References**              | [MSDN](https://msdn.microsoft.com/library/ff648500.aspx), [Fortify](https://community.microfocus.com/t5/UFT-Discussions/UFT-API-Test-with-WCF-wsHttpBinding/m-p/600927) |
 | **Steps** | The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows access to all users. Configure the application to authenticate against client credentials. This can be done by setting the message clientCredentialType to Windows or Certificate. |
 
 ### Example
@@ -321,7 +321,7 @@ The `<netMsmqBinding/>` element of the WCF configuration file below instructs WC
 | **SDL Phase**               | Build |  
 | **Applicable Technologies** | Generic, .NET Framework 3 |
 | **Attributes**              | Client Credential Type - None |
-| **References**              | [MSDN](https://msdn.microsoft.com/library/ff648500.aspx), [Fortify](https://vulncat.fortify.com/en/detail?id=desc.semantic.dotnet.wcf_misconfiguration_anonymous_transport_client) |
+| **References**              | [MSDN](https://msdn.microsoft.com/library/ff648500.aspx), [Fortify](https://community.microfocus.com/t5/UFT-Discussions/UFT-API-Test-with-WCF-wsHttpBinding/m-p/600927) |
 | **Steps** | The absence of authentication means everyone is able to access this service. A service that does not authenticate its clients allows all users to access its functionality. Configure the application to authenticate against client credentials. This can be done by setting the transport clientCredentialType to Windows or Certificate. |
 
 ### Example
diff --git a/articles/security/fundamentals/azure-log-integration-ad.md b/articles/security/fundamentals/azure-log-integration-ad.md
diff --git a/articles/sql-database/toc.yml b/articles/sql-database/toc.yml

Original file line number	Diff line number	Diff line change
`@@ -42203,7 +42203,7 @@`
`42203`	`42203`	`},`
`42204`	`42204`	`{`
`42205`	`42205`	`"source_path": "articles/security/fundamentals/network-security.md",`
`42206`		`- "redirect_url": "/azure/security/fundamentals/network-security",`
	`42206`	`+ "redirect_url": "/azure/security/fundamentals/network-overview",`
`42207`	`42207`	`"redirect_document_id": false`
`42208`	`42208`	`},`
`42209`	`42209`	`{`