Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Banani-Rath

.openpublishing.redirection.json

@@ -25946,6 +25946,11 @@
       "redirect_url": "/azure/sendgrid-dotnet-how-to-send-email",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/sentinel/automate-playbook-watchlist.md",
+      "redirect_url": "https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/playbooks-amp-watchlists-part-1-inform-the-subscription-owner/ba-p/1768917",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/sentinel/connect-microsoft-waf.md",
       "redirect_url": "/azure/sentinel/connect-azure-waf",

articles/active-directory/develop/active-directory-saml-protocol-reference.md

@@ -1,6 +1,6 @@
 ---
 title: How the Microsoft identity platform uses the SAML protocol
-description: This article provides an overview of the Single Sign-On and Single Sign-Out SAML profiles in Azure Active Directory.
+description: This article provides an overview of the single sign-on and Single Sign-Out SAML profiles in Azure Active Directory.
 services: active-directory
 author: kenwith
 manager: CelesteDG
@@ -9,27 +9,29 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 10/05/2018
+ms.date: 10/27/2021
 ms.author: kenwith
 ms.custom: aaddev
 ms.reviewer: paulgarn
 ---
 
 # How the Microsoft identity platform uses the SAML protocol
 
-The Microsoft identity platform uses the SAML 2.0 protocol to enable applications to provide a single sign-on experience to their users. The [Single Sign-On](single-sign-on-saml-protocol.md) and [Single Sign-Out](single-sign-out-saml-protocol.md) SAML profiles of Azure AD explain how SAML assertions, protocols, and bindings are used in the identity provider service.
+The Microsoft identity platform uses the SAML 2.0 and other protocols to enable applications to provide a single sign-on (SSO) experience to their users. The [SSO](single-sign-on-saml-protocol.md) and [Single Sign-Out](single-sign-out-saml-protocol.md) SAML profiles of Azure Active Directory (Azure AD) explain how SAML assertions, protocols, and bindings are used in the identity provider service.
 
-SAML Protocol requires the identity provider (Microsoft identity platform) and the service provider (the application) to exchange information about themselves.
+The SAML protocol requires the identity provider (Microsoft identity platform) and the service provider (the application) to exchange information about themselves.
 
 When an application is registered with Azure AD, the app developer registers federation-related information with Azure AD. This information includes the **Redirect URI** and **Metadata URI** of the application.
 
-The Microsoft identity platform uses the cloud service's **Metadata URI** to retrieve the signing key and the logout URI. Customer can open the app in **Azure AD -> App Registration** and then in **Settings -> Properties**, they can update the Logout URL. This way the Microsoft identity platform can send the response to the correct URL. 
+The Microsoft identity platform uses the cloud service's **Metadata URI** to retrieve the signing key and the logout URI. In the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>, you can open the app in **Azure Active Directory -> App registrations**, and then in **Manage -> Authentication**, you can update the Logout URL. This way the Microsoft identity platform can send the response to the correct URL.
 
-Azure Active Directory exposes tenant-specific and common (tenant-independent) single sign-on and single sign-out endpoints. These URLs represent addressable locations -- they are not just identifiers -- so you can go to the endpoint to read the metadata.
+Azure AD exposes tenant-specific and common (tenant-independent) SSO and single sign-out endpoints. These URLs represent addressable locations--they're not just identifiers--so you can go to the endpoint to read the metadata.
 
-* The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The *\<TenantDomainName>* placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the contoso.com tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
+- The tenant-specific endpoint is located at `https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml`. The _\<TenantDomainName>_ placeholder represents a registered domain name or TenantID GUID of an Azure AD tenant. For example, the federation metadata of the contoso.com tenant is at: https://login.microsoftonline.com/contoso.com/FederationMetadata/2007-06/FederationMetadata.xml
 
-* The tenant-independent endpoint is located at
+- The tenant-independent endpoint is located at
   `https://login.microsoftonline.com/common/FederationMetadata/2007-06/FederationMetadata.xml`. In this endpoint address, **common** appears instead of a tenant domain name or ID.
 
+## Next steps
+
 For information about the federation metadata documents that Azure AD publishes, see [Federation Metadata](../azuread-dev/azure-ad-federation-metadata.md).

articles/active-directory/develop/consent-framework.md

@@ -56,7 +56,7 @@ The following steps show you how the consent experience works for both the appli
       ![Grant permissions for explicit admin consent](./media/consent-framework/grant-consent.png)
 
    > [!IMPORTANT]
-   > Granting explicit consent using the **Grant permissions** button is currently required for single-page applications (SPA) that use ADAL.js. Otherwise, the application fails when the access token is requested.
+   > Granting explicit consent using the **Grant permissions** button is currently required for single-page applications (SPA) that use MSAL.js. Otherwise, the application fails when the access token is requested.
 
 ## Next steps
 

articles/active-directory/hybrid/how-to-connect-install-express.md

@@ -11,7 +11,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: how-to
-ms.date: 09/28/2018
+ms.date: 11/29/2021
 ms.subservice: hybrid
 ms.author: billmath
 
@@ -25,7 +25,6 @@ Before you start installing Azure AD Connect, make sure to [download Azure AD Co
 If express settings does not match your topology, see [related documentation](#related-documentation) for other scenarios.
 
 ## Express installation of Azure AD Connect
-You can see these steps in action in the [videos](#videos) section.
 
 1. Sign in as a local administrator to the server you wish to install Azure AD Connect on. You should do this on the server you wish to be the sync server.
 2. Navigate to and double-click **AzureADConnect.msi**.
@@ -48,12 +47,6 @@ You can see these steps in action in the [videos](#videos) section.
 9. When the installation completes, click **Exit**.
 10. After the installation has completed, sign off and sign in again before you use Synchronization Service Manager or Synchronization Rule Editor.
 
-## Videos
-For a video on using the express installation, see:
-
-> [!VIDEO https://channel9.msdn.com/Series/Azure-Active-Directory-Videos-Demos/Azure-Active-Directory-Connect-Express-Settings/player]
->
->
 
 ## Next steps
 Now that you have Azure AD Connect installed you can [verify the installation and assign licenses](how-to-connect-post-installation.md).

articles/active-directory/hybrid/tshoot-connect-connectivity.md

@@ -13,7 +13,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: troubleshooting
-ms.date: 04/25/2019
+ms.date: 11/18/2021
 ms.subservice: hybrid
 ms.author: billmath
 
@@ -24,7 +24,10 @@ ms.custom: has-adal-ref
 This article explains how connectivity between Azure AD Connect and Azure AD works and how to troubleshoot connectivity issues. These issues are most likely to be seen in an environment with a proxy server.
 
 ## Troubleshoot connectivity issues in the installation wizard
-Azure AD Connect is using Modern Authentication (using the ADAL library) for authentication. The installation wizard and the sync engine proper require machine.config to be properly configured since these two are .NET applications.
+Azure AD Connect uses the MSAL library for authentication. The installation wizard and the sync engine proper require machine.config to be properly configured since these two are .NET applications.
+
+>[!NOTE]
+>Azure AD Connect v1.6.xx.x uses the ADAL library.  The ADAL library is being depricated and support will end in June 2022.  Microsot recommendeds that you upgrade to the latest version of [Azure AD Connect v2](whatis-azure-ad-connect-v2.md).
 
 In this article, we show how Fabrikam connects to Azure AD through its proxy. The proxy server is named fabrikamproxy and is using port 8080.
 

articles/api-management/api-management-howto-ip-addresses.md

@@ -14,13 +14,11 @@ ms.custom: fasttrack-edit
 
 # IP addresses of Azure API Management
 
-In this article we describe how to retrieve the IP addresses of Azure API Management service. IP addresses can be public or private if the service is in a virtual network.
-
-You can use IP addresses to create firewall rules, filter the incoming traffic to the backend services, or restrict the outbound traffic.
+In this article we describe how to retrieve the IP addresses of Azure API Management service. IP addresses can be public or private if the service is in a virtual network. You can use IP addresses to create firewall rules, filter the incoming traffic to the backend services, or restrict the outbound traffic.
 
 ## IP addresses of API Management service
 
-Every API Management service instance in Developer, Basic, Standard, or Premium tier has public IP addresses, which are exclusive only to that service instance (they are not shared with other resources). 
+Every API Management service instance in Developer, Basic, Standard, or Premium tier has public IP addresses, which are exclusive only to that service instance (they are not shared with other resources).
 
 You can retrieve the IP addresses from the overview dashboard of your resource in the Azure portal.
 
@@ -54,7 +52,7 @@ In [multi-regional deployments](api-management-howto-deploy-multi-region.md), ea
 
 If your API Management service is inside a virtual network, it will have two types of IP addresses - public and private.
 
-Public IP addresses are used for internal communication on port `3443` - for managing configuration (for example, through Azure Resource Manager). In the external VNet configuration, they are also used for runtime API traffic. 
+Public IP addresses are used for internal communication on port `3443` - for managing configuration (for example, through Azure Resource Manager). In the external VNet configuration, they are also used for runtime API traffic.
 
 Private virtual IP (VIP) addresses, available **only** in the [internal VNet mode](api-management-using-with-internal-vnet.md), are used to connect from within the network to API Management endpoints - gateways, the developer portal, and the management plane for direct API access. You can use them for setting up DNS records within the network.
 
@@ -82,15 +80,15 @@ GET https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/
 }
 ```
 
-API Management uses a public IP address for connections outside the VNet and a private IP address for connections within the VNet. 
+API Management uses a public IP address for connections outside the VNet and a private IP address for connections within the VNet.
 
-When API management is deployed in the [internal VNet configuration](api-management-using-with-internal-vnet.md) and API management connects to private (intranet-facing) backends, internal IP addresses from the subnet are used for the runtime API traffic. When a request is sent from API Management to a private backend, a private IP address will be visible as the origin of the request. Therefore in this configuration, if a requirement exists to restrict traffic between API Management and an internal backend, it is better to use the whole API Management subnet prefix with an IP rule and not just the private IP address associated with the API Management resource. 
+When API management is deployed in the [internal VNet configuration](api-management-using-with-internal-vnet.md) and API management connects to private (intranet-facing) backends, internal IP addresses from the subnet are used for the runtime API traffic. When a request is sent from API Management to a private backend, a private IP address will be visible as the origin of the request. Therefore in this configuration, if a requirement exists to restrict traffic between API Management and an internal backend, it is better to use the whole API Management subnet prefix with an IP rule and not just the private IP address associated with the API Management resource.
 
 When a request is sent from API Management to a public-facing (internet-facing) backend, a public IP address will always be visible as the origin of the request.
 
 ## IP addresses of Consumption tier API Management service
 
-If your API Management service is a Consumption tier service, it doesn't have a dedicated IP address. Consumption tier service runs on a shared infrastructure and without a deterministic IP address. 
+If your API Management service is a Consumption tier service, it doesn't have a dedicated IP address. Consumption tier service runs on a shared infrastructure and without a deterministic IP address.
 
 For traffic restriction purposes, you can use the range of IP addresses of Azure data centers. Refer to [the Azure Functions documentation article](../azure-functions/ip-addresses.md#data-center-outbound-ip-addresses) for precise steps.
 
@@ -102,5 +100,6 @@ In the Developer, Basic, Standard, and Premium tiers of API Management, the publ
 * The service subscription is [suspended](https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/subscription-lifecycle-api-reference.md#subscription-states) or [warned](https://github.com/Azure/azure-resource-manager-rpc/blob/master/v1.0/subscription-lifecycle-api-reference.md#subscription-states) (for example, for nonpayment) and then reinstated.
 * Azure Virtual Network is added to or removed from the service.
 * API Management service is switched between External and Internal VNet deployment mode.
+* [Availability zones](zone-redundancy.md) are enabled, added, or removed.
 
-In [multi-regional deployments](api-management-howto-deploy-multi-region.md), the regional IP address changes if a region is vacated and then reinstated. The regional IP address also changes when you enable, add, or remove [availability zones](zone-redundancy.md).
+In [multi-regional deployments](api-management-howto-deploy-multi-region.md), the regional IP address changes if a region is vacated and then reinstated.