Merge pull request #202668 from HeidiSteen/heidist-support-case

Edits to network security docs

Author: laurabren

articles/search/search-indexer-howto-access-ip-restricted.md

@@ -22,15 +22,15 @@ This article explains how to find the IP address of your search service and conf
 
 ## Get a search service IP address
 
-1. Determine the fully qualified domain name (FQDN) of your search service. This will look like `<search-service-name>.search.windows.net`. You can find the FQDN by looking up your search service on the Azure portal.
+1. Get the fully qualified domain name (FQDN) of your search service. This will look like `<search-service-name>.search.windows.net`. You can find the FQDN by looking up your search service on the Azure portal.
 
    :::image type="content" source="media\search-indexer-howto-secure-access\search-service-portal.png" alt-text="Screenshot of the search service Overview page." border="true":::
 
 1. Look up the IP address of the search service by performing a `nslookup` (or a `ping`) of the FQDN on a command prompt. Make sure you remove the "https://" prefix from the FQDN.
 
 1. Copy the IP address so that you can specify it on an inbound rule in the next step. In the example below, the IP address that you should copy is "150.0.0.1".
 
-   ```azurepowershell
+   ```bash
    nslookup contoso.search.windows.net
    Server:  server.example.org
    Address:  10.50.10.50
@@ -43,23 +43,40 @@ This article explains how to find the IP address of your search service and conf
 
 ## Get the Azure portal IP address
 
-If you're using the Azure portal or the [Import Data wizard](search-import-data-portal.md) to create an indexer, you'll need an inbound rule for the Azure portal.
+If you're using the Azure portal or the [Import Data wizard](search-import-data-portal.md) to create an indexer, you'll need an inbound rule for the Azure portal as well.
 
-To get the portal IP address, perform `nslookup` on `stamp2.ext.search.windows.net`, which is the domain of the traffic manager. 
+To get the portal's IP address, perform `nslookup` (or `ping`) on `stamp2.ext.search.windows.net`, which is the domain of the traffic manager. For nslookup, the IP address is visible in the "Non-authoritative answer" portion of the response. 
 
-For nslookup, the IP address be visible in the "Non-authoritative answer" portion of the response. For ping, the request will time out, but the IP address will be visible in the response. For example, in the message "Pinging azsyrie.northcentralus.cloudapp.azure.com [52.252.175.48]", the IP address is "52.252.175.48".
+In the example below, the IP address that you should copy is "52.252.175.48".
+
+```bash
+$ nslookup stamp2.ext.search.windows.net
+Server:  ZenWiFi_ET8-0410
+Address:  192.168.50.1
+
+Non-authoritative answer:
+Name:    azsyrie.northcentralus.cloudapp.azure.com
+Address:  52.252.175.48
+Aliases:  stamp2.ext.search.windows.net
+          azs-ux-prod.trafficmanager.net
+          azspncuux.management.search.windows.net
+```
 
 Clusters in different regions connect to different traffic managers. Regardless of the domain name, the IP address returned from the ping is the correct one to use when defining an inbound firewall rule for the Azure portal in your region.
 
+For ping, the request will time out, but the IP address will be visible in the response. For example, in the message "Pinging azsyrie.northcentralus.cloudapp.azure.com [52.252.175.48]", the IP address is "52.252.175.48".
+
 ## Get IP addresses for "AzureCognitiveSearch" service tag
 
-We also require customers to create an inbound rule that allows requests from the [multi-tenant execution environment](search-indexer-securing-resources.md#indexer-execution-environment) to ensure we optimize the resource availability for search services. This step explains how to get the range of IP addresses needed for this inbound rule.
+You'll also need to create an inbound rule that allows requests from the [multi-tenant execution environment](search-indexer-securing-resources.md#indexer-execution-environment). This environment is managed by Microsoft and it's used to offload processing intensive jobs that could otherwise overwhelm your search service. This section explains how to get the range of IP addresses needed to create this inbound rule.
 
-An IP address range is defined for each region that supports Azure Cognitive Search. You can get this IP address range from the `AzureCognitiveSearch` service tag.
+An IP address range is defined for each region that supports Azure Cognitive Search. You'll need to specify the full range to ensure the success of requests originating from the multi-tenant execution environment. 
 
-1. Get the IP address ranges for the `AzureCognitiveSearch` service tag using either the [discovery API](../virtual-network/service-tags-overview.md#use-the-service-tag-discovery-api) or the [downloadable JSON file](../virtual-network/service-tags-overview.md#discover-service-tags-by-using-downloadable-json-files).
+You can get this IP address range from the `AzureCognitiveSearch` service tag.
 
-1. If the search service is the Azure Public cloud, download the [Azure Public JSON file](https://www.microsoft.com/download/details.aspx?id=56519).
+1. Use either the [discovery API](../virtual-network/service-tags-overview.md#use-the-service-tag-discovery-api) or the [downloadable JSON file](../virtual-network/service-tags-overview.md#discover-service-tags-by-using-downloadable-json-files).
+
+  If the search service is the Azure Public cloud, download the [Azure Public JSON file](https://www.microsoft.com/download/details.aspx?id=56519).
 
 1. Open the JSON file and search for "AzureCognitiveSearch". For a search service in WestUS2, the IP addresses for the multi-tenant indexer execution environment are:
 
@@ -89,21 +106,23 @@ An IP address range is defined for each region that supports Azure Cognitive Sea
 
 1. For IP addresses have the "/32" suffix, drop the "/32" (40.91.93.84/32 becomes 40.91.93.84 in the rule definition). All other IP addresses can be used verbatim.
 
+1. Copy all of the IP addresses for the region.
+
 ## Add IP addresses to IP firewall rules
 
-Now that you have the necessary IP addresses, you can set up the inbound rule. The easiest way to add IP address ranges to a storage account's firewall rule is through the Azure portal. 
+Now that you have the necessary IP addresses, you can set up the inbound rules. The easiest way to add IP address ranges to a storage account's firewall rule is through the Azure portal. 
 
 1. Locate the storage account on the portal and open **Networking** on the left navigation pane.
 
 1. In the **Firewall and virtual networks** tab, choose **Selected networks**.
 
    :::image type="content" source="media\search-indexer-howto-secure-access\storage-firewall.png" alt-text="Screenshot of Azure Storage Firewall and virtual networks page" border="true":::
 
-1. Add the IP addresses obtained previously in the address range and select **Save**. You should have rules for the search service, Azure portal (optional), plus all of the IP ranges for the "AzureCognitiveSearch" service tag for your region
+1. Add the IP addresses obtained previously in the address range and select **Save**. You should have rules for the search service, Azure portal (optional), plus all of the IP addresses for the "AzureCognitiveSearch" service tag for your region.
 
    :::image type="content" source="media\search-indexer-howto-secure-access\storage-firewall-ip.png" alt-text="Screenshot of the IP address section of the page." border="true":::
 
-It can take five to ten minutes for the firewall rules to be updated, after which indexers should be able to access the data in the storage account.
+It can take five to ten minutes for the firewall rules to be updated, after which indexers should be able to access storage account data behind the firewall.
 
 ## Next Steps
 

articles/search/search-indexer-howto-access-private.md

@@ -17,7 +17,7 @@ Many Azure resources, such as Azure storage accounts, can be configured to accep
 
 For [Azure Storage](../storage/common/storage-network-security.md?tabs=azure-portal), if both the storage account and the search service are in the same region, outbound traffic uses a private IP address to communicate to storage and occurs over the Microsoft backbone network. For this scenario, you can omit private endpoints through Azure Cognitive Search. For other Azure PaaS resources, we suggest that you review the networking documentation for those resources to determine whether a private endpoint is helpful.
 
-To create a shared private link, use the Azure portal or the [Create Or Update Shared Private Link](/rest/api/searchmanagement/2020-08-01/shared-private-link-resources/create-or-update) operation in the Azure Cognitive Search Management REST API.
+To create a private endpoint that an indexer can use, use the Azure portal or the [Create Or Update Shared Private Link](/rest/api/searchmanagement/2020-08-01/shared-private-link-resources/create-or-update) operation in the Azure Cognitive Search Management REST API. A private endpoint that's used by your search service is created using Cognitive Search APIs or the portal pages for Azure Cognitive Search.
 
 ## Terminology
 

articles/search/search-indexer-securing-resources.md

@@ -13,7 +13,7 @@ ms.date: 06/20/2022
 
 # Indexer access to content protected by Azure network security
 
-If your search application requirements include an Azure virtual network, this concept article explains how a search indexer can access content that's protected by network security. It describes the outbound traffic patterns and indexer execution environments. It also covers the network protections supported by Cognitive Search and factors that might influence your approach. Finally, because Azure Storage is used for both data access and persistent storage, this article also covers network considerations that are specific to search and storage connectivity.
+If your search application requirements include an Azure virtual network, this concept article explains how a search indexer can access content that's protected by network security. It describes the outbound traffic patterns and indexer execution environments. It also covers the network protections supported by Cognitive Search and factors that might influence your security strategy. Finally, because Azure Storage is used for both data access and persistent storage, this article also covers network considerations that are specific to search and storage connectivity.
 
 Looking for step-by-step instructions instead? See [How to configure firewall rules to allow indexer access](search-indexer-howto-access-ip-restricted.md) or [How to make outbound connections through a private endpoint](search-indexer-howto-access-private.md).
 
@@ -102,9 +102,9 @@ When integrating Azure Cognitive Search into a solution that runs on a virtual n
 
 Given the above constrains, your choices for achieving search integration in a virtual network are:
 
-- Configure an inbound firewall rule on your Azure resource that admits indexer requests for data.
+- Configure an inbound firewall rule on your Azure PaaS resource that admits indexer requests for data.
 
-- Configure an outbound connection that makes indexer connections using a [private endpoint](../private-link/private-endpoint-overview.md). 
+- Configure an outbound connection from Search that makes indexer connections using a [private endpoint](../private-link/private-endpoint-overview.md). 
 
   For a private endpoint, the search service connection to your protected resource is through a *shared private link*. A shared private link is an [Azure Private Link](../private-link/private-link-overview.md) resource that's created, managed, and used from within Cognitive Search. If your resources are fully locked down (running on a protected virtual network, or otherwise not available over a public connection), a private endpoint is your only choice.