Merge pull request #99536 from MicrosoftDocs/master

Merge Master to Live, 3 AM

Author: PMEds28

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

@@ -371,7 +371,7 @@ This adds the new Active Directory server to the Active Directory Servers list.
     >[!Note]
     > You will need the Kerberos Delegation Account to be created and specified. Refer KCD Section (Refer Appendix for Variable References)
 
-    * **Username Source**: session.saml.last.attr.name.http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
+    * **Username Source**: session.saml.last.attr.name.http:\//schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
 
     * **User Realm Source**: session.logon.last.domain
 

articles/active-directory/saas-apps/media/officespace-software-provisioning-tutorial/userattributes.png

@@ -65,7 +65,7 @@ To configure and test Azure AD SSO with productboard, complete the following bui
     * **[Create an Azure AD test user](#create-an-azure-ad-test-user)** - to test Azure AD single sign-on with B.Simon.
     * **[Assign the Azure AD test user](#assign-the-azure-ad-test-user)** - to enable B.Simon to use Azure AD single sign-on.
 1. **[Configure productboard SSO](#configure-productboard-sso)** - to configure the single sign-on settings on application side.
-    * **[Create productboard test user](#create-productboard-test-user)** - to have a counterpart of B.Simon in EZOfficeInventory that is linked to the Azure AD representation of user.
+    * **[Create productboard test user](#create-productboard-test-user)** - to have a counterpart of B.Simon in productboard that is linked to the Azure AD representation of user.
 1. **[Test SSO](#test-sso)** - to verify whether the configuration works.
 
 ### Configure Azure AD SSO

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

@@ -57,9 +57,7 @@ To protect an API with Azure AD, the first step is to register an application in
 
 1. On the app **Overview** page, find the **Application (client) ID** value and record it for later.
 
-When the application is created, make a note of the **Application ID**, for use in a subsequent step. 
-
-1. Select **Expose an API** and click on **Save and continue** to create an Application ID URI.
+1. Select **Expose an API** and set the **Application ID URI** with the default value. Record this value for later.
 
 1. In the **Add a scope** page, create a new scope supported by the API. (e.g., Read) then click on *Add scope* to create the scope. Repeat this step to add all scopes supported by your API.
 
@@ -200,7 +198,7 @@ You can use the [Validate JWT](api-management-access-restriction-policies.md#Val
     <openid-config url="https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration" />
     <required-claims>
         <claim name="aud">
-            <value>{Application ID of backend-app}</value>
+            <value>{Application ID URI of backend-app}</value>
         </claim>
     </required-claims>
 </validate-jwt>

articles/api-management/api-management-howto-protect-backend-with-aad.md

@@ -1,6 +1,6 @@
 ---
-title: Restrict access for IP addresses 
-description: Learn how to secure your app in Azure App Service by explicitly whitelisting client IP addresses or address ranges. 
+title: Azure App Service access restrictions 
+description: Learn how to secure your app in Azure App Service by specifying access restrictions. 
 author: ccompy
 
 ms.assetid: 3be1f4bd-8a81-4565-8a56-528c037b24bd
@@ -12,19 +12,19 @@ ms.custom: seodec18
 ---
 # Azure App Service Access Restrictions #
 
-Access Restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
+Access restrictions enable you to define a priority ordered allow/deny list that controls network access to your app. The list can include IP addresses or Azure Virtual Network subnets. When there are one or more entries, there is then an implicit "deny all" that exists at the end of the list.
 
-The Access Restrictions capability works with all App Service hosted work loads including; web apps, API apps, Linux apps, Linux container apps, and Functions.
+The access restrictions capability works with all App Service hosted work loads including; web apps, API apps, Linux apps, Linux container apps, and Functions.
 
 When a request is made to your app, the FROM address is evaluated against the IP address rules in your access restrictions list. If the FROM address is in a subnet that is configured with service endpoints to Microsoft.Web, then the source subnet is compared against the virtual network rules in your access restrictions list. If the address is not allowed access based on the rules in the list, the service replies with an [HTTP 403](https://en.wikipedia.org/wiki/HTTP_403) status code.
 
 The access restrictions capability is implemented in the App Service front-end roles, which are upstream of the worker hosts where your code runs. Therefore, access restrictions are effectively network ACLs.
 
-The ability to restrict access to your web app from an Azure Virtual Network (VNet) is called [service endpoints][serviceendpoints]. Service endpoints enable you to restrict access to a multi-tenant service from selected subnets. It must be enabled on both the networking side as well as the service that it is being enabled with. It does not work to restrict traffic to apps that are hosted in an App Service Environment.  If you are in an App Service Environment, you can control access to your app with IP address rules.
+The ability to restrict access to your web app from an Azure Virtual Network (VNet) is called [service endpoints][serviceendpoints]. Service endpoints enable you to restrict access to a multi-tenant service from selected subnets. It must be enabled on both the networking side as well as the service that it is being enabled with. It does not work to restrict traffic to apps that are hosted in an App Service Environment. If you are in an App Service Environment, you can control access to your app with IP address rules.
 
 ![access restrictions flow](media/app-service-ip-restrictions/access-restrictions-flow.png)
 
-## Adding and editing Access Restriction rules in the portal ##
+## Adding and editing access restriction rules in the portal ##
 
 To add an access restriction rule to your app, use the menu to open **Network**>**Access Restrictions** and click on **Configure Access Restrictions**
 
@@ -54,7 +54,7 @@ Service endpoints enables you to restrict access to selected Azure virtual netwo
 
 Service endpoints cannot be used to restrict access to apps that run in an App Service Environment. When your app is in an App Service Environment, you can control access to your app with IP access rules. 
 
-With service endpoints, you can configure your app with Application Gateways or other WAF devices. You can also configure multi-tier applications with secure backends. For more details on some of the possibilities, read [Networking features and App Service](networking-features.md).
+With service endpoints, you can configure your app with Application Gateways or other WAF devices. You can also configure multi-tier applications with secure backends. For more details on some of the possibilities, read [Networking features and App Service](networking-features.md) and [Application Gateway integration with service endpoints](networking/app-gateway-with-service-endpoints.md).
 
 ## Managing access restriction rules
 
@@ -86,34 +86,50 @@ In addition to being able to control access to your app, you can also restrict a
 
 ## Programmatic manipulation of access restriction rules ##
 
-There currently is no CLI or PowerShell for the new Access Restrictions capability but the values can be set manually with an [Azure REST API](https://docs.microsoft.com/rest/api/azure/) PUT operation on the app configuration in Resource Manager. As an example, you can use resources.azure.com and edit the ipSecurityRestrictions block to add the required JSON.
+[Azure CLI](https://docs.microsoft.com/cli/azure/webapp/config/access-restriction?view=azure-cli-latest) and [Azure PowerShell](https://docs.microsoft.com/powershell/module/Az.Websites/Add-AzWebAppAccessRestrictionRule?view=azps-3.1.0) has support for editing access restrictions. 
+Example of adding an access restriction using Azure CLI:
+
+```azurecli-interactive
+az webapp config access-restriction add --resource-group ResourceGroup --name AppName \
+    --rule-name 'IP example rule' --action Allow --ip-address 122.133.144.0/24 --priority 100
+```
+Example of adding an access restriction using Azure PowerShell:
+
+```azurepowershell-interactive
+Add-AzWebAppAccessRestrictionRule -ResourceGroupName "ResourceGroup" -WebAppName "AppName"
+    -Name "Ip example rule" -Priority 100 -Action Allow -IpAddress 122.133.144.0/24
+```
+
+Values can also be set manually with an [Azure REST API](https://docs.microsoft.com/rest/api/azure/) PUT operation on the app configuration in Resource Manager or using an Azure Resource Manager template. As an example, you can use resources.azure.com and edit the ipSecurityRestrictions block to add the required JSON.
 
 The location for this information in Resource Manager is:
 
 management.azure.com/subscriptions/**subscription ID**/resourceGroups/**resource groups**/providers/Microsoft.Web/sites/**web app name**/config/web?api-version=2018-02-01
 
 The JSON syntax for the earlier example is:
-
-    {
-      "properties": {
-        "ipSecurityRestrictions": [
-          {
-            "ipAddress": "122.133.144.0/24",
-            "action": "Allow",
-            "tag": "Default",
-            "priority": 100,
-            "name": "IP example rule"
-          }
-        ]
+```json
+{
+  "properties": {
+    "ipSecurityRestrictions": [
+      {
+        "ipAddress": "122.133.144.0/24",
+        "action": "Allow",
+        "priority": 100,
+        "name": "IP example rule"
       }
-    }
+    ]
+  }
+}
+```
 
-## Function App IP Restrictions
+## Azure Function App Access Restrictions
 
-IP restrictions are available for both Function Apps with the same functionality as App Service plans. Enabling IP restrictions will disable the portal code editor for any disallowed IPs.
+Access restrictions are available for both Function Apps with the same functionality as App Service plans. Enabling access restrictions will disable the portal code editor for any disallowed IPs.
 
-[Learn more here](../azure-functions/functions-networking-options.md#inbound-ip-restrictions)
+## Next steps
+[Access restrictions for Azure Function Apps](../azure-functions/functions-networking-options.md#inbound-ip-restrictions)
 
+[Application Gateway integration with service endpoints](networking/app-gateway-with-service-endpoints.md)
 
 <!--Links-->
 [serviceendpoints]: https://docs.microsoft.com/azure/virtual-network/virtual-network-service-endpoints-overview

articles/app-service/app-service-ip-restrictions.md

@@ -5,7 +5,7 @@ author: stefsch
 
 ms.assetid: 1d1d85f3-6cc6-4d57-ae1a-5b37c642d812
 ms.topic: tutorial
-ms.date: 01/16/2018
+ms.date: 12/19/2019
 ms.author: stefsch
 ms.custom: mvc
 ms.custom: seodec18
@@ -53,6 +53,19 @@ Alternatively, you can update the App Service Environment by using [Azure Resour
 However you submit the change, it takes roughly 30 minutes multiplied by the number of front ends in the App Service Environment for the change to take effect.
 For example, if an App Service Environment has four front ends, it will take roughly two hours for the configuration update to finish. While the configuration change is being rolled out, no other scaling operations or configuration change operations can take place in the App Service Environment.
 
+## Enable Internal Encryption
+
+The App Service Environment operates as a black box system where you cannot see the internal components or the communication within the system. To enable higher throughput, encryption is not enabled by default between internal components. The system is secure as the traffic is completely inaccessible to being monitored or accessed. If you have a compliance requirement though that requires complete encryption of the data path from end to end, there is a way to enable this with a clusterSetting.  
+
+        "clusterSettings": [
+            {
+                "name": "InternalEncryption",
+                "value": "1"
+            }
+        ],
+ 
+After the InternalEncryption clusterSetting is enabled, there can be an impact to your system performance. When you make the change to enable InternalEncryption, your ASE will be in an unstable state until the change is fully propagated. Complete propagation of the change can take a few hours to complete, depending on how many instances you have in your ASE. We highly recommend that you do not enable this on an ASE while it is in use. If you need to enable this on an actively used ASE, we highly recommend that you divert traffic to a backup environment until the operation completes. 
+
 ## Disable TLS 1.0 and TLS 1.1
 
 If you want to manage TLS settings on an app by app basis, then you can use the guidance provided with the [Enforce TLS settings](../configure-ssl-bindings.md#enforce-tls-versions) documentation. 

articles/app-service/environment/app-service-app-service-environment-custom-settings.md

@@ -163,7 +163,7 @@
         href: configure-authentication-provider-twitter.md
     - name: Advanced auth
       href: app-service-authentication-how-to.md
-    - name: Restrict IPs
+    - name: Restrict access
       href: app-service-ip-restrictions.md
     - name: Use a managed identity
       href: overview-managed-identity.md

articles/app-service/toc.yml

@@ -2,7 +2,7 @@
 title: Bindings for Durable Functions - Azure
 description: How to use triggers and bindings for the Durable Functions extension for Azure Functions.
 ms.topic: conceptual
-ms.date: 11/02/2019
+ms.date: 12/17/2019
 ms.author: azfuncdf
 ---
 
@@ -393,7 +393,7 @@ Every entity function has a parameter type of `IDurableEntityContext`, which has
 * **DeleteState()**: deletes the state of the entity. 
 * **GetInput\<TInput>()**: gets the input for the current operation. The `TInput` type parameter must be a primitive or JSON-serializeable type.
 * **Return(arg)**: returns a value to the orchestration that called the operation. The `arg` parameter must be a primitive or JSON-serializeable object.
-* **SignalEntity(EntityId, operation, input)**: sends a one-way message to an entity. The `operation` parameter must be a non-null string, and the `input` parameter must be a primitive or JSON-serializeable object.
+* **SignalEntity(EntityId, scheduledTimeUtc, operation, input)**: sends a one-way message to an entity. The `operation` parameter must be a non-null string, the optional `scheduledTimeUtc` must be a UTC datetime at which to invoke the operation, and the `input` parameter must be a primitive or JSON-serializeable object.
 * **CreateNewOrchestration(orchestratorFunctionName, input)**: starts a new orchestration. The `input` parameter must be a primitive or JSON-serializeable object.
 
 The `IDurableEntityContext` object passed to the entity function can be accessed using the `Entity.Current` async-local property. This approach is convenient when using the class-based programming model.
@@ -530,6 +530,7 @@ In .NET functions, you typically bind to `IDurableEntityClient`, which gives you
 
 * **ReadEntityStateAsync\<T>**: reads the state of an entity. It returns a response that indicates whether the target entity exists, and if so, what its state is.
 * **SignalEntityAsync**: sends a one-way message to an entity, and waits for it to be enqueued.
+* **ListEntitiesAsync**: queries for the state of multiple entities. Entities can be queried by *name* and *last operation time*.
 
 There is no need to create the target entity before sending a signal - the entity state can be created from within the entity function that handles the signal.
 

articles/azure-functions/durable/durable-functions-bindings.md

@@ -3,7 +3,7 @@ title: Durable entities - Azure Functions
 description: Learn what durable entities are and how to use them in the Durable Functions extension for Azure Functions.
 author: cgillum
 ms.topic: overview
-ms.date: 11/02/2019
+ms.date: 12/17/2019
 ms.author: azfuncdf
 #Customer intent: As a developer, I want to learn what durable entities are and how to use them to solve distributed, stateful problems in my applications.
 ---
@@ -37,6 +37,7 @@ To invoke an operation on an entity, specify the:
 * **Entity ID** of the target entity.
 * **Operation name**, which is a string that specifies the operation to perform. For example, the `Counter` entity could support `add`, `get`, or `reset` operations.
 * **Operation input**, which is an optional input parameter for the operation. For example, the add operation can take an integer amount as the input.
+* **Scheduled time*, which is an optional parameter for specifying the delivery time of the operation. For example, an operation can be reliably scheduled to run several days in the future.
 
 Operations can return a result value or an error result, such as a JavaScript error or a .NET exception. This result or error can be observed by orchestrations that called the operation.