Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into jammart-storage-cmk-auto-update-key-impact

Author: jimmart-dev

articles/active-directory/conditional-access/TOC.yml

@@ -39,6 +39,8 @@
     href: service-dependencies.md
   - name: Filter for applications
     href: concept-filter-for-applications.md
+  - name: Token protection
+    href: concept-token-protection.md
   - name: Location conditions
     href: location-condition.md
   - name: Workload identities

articles/active-directory/conditional-access/concept-token-protection.md

@@ -0,0 +1,177 @@
+---
+title: Token protection in Azure AD Conditional Access
+description: Learn how to use token protection in Conditional Access policies.
+ms.service: active-directory
+ms.subservice: conditional-access
+ms.topic: conceptual
+ms.date: 03/09/2023
+
+ms.author: joflore
+author: MicrosoftGuyJFlo
+manager: amycolannino
+ms.reviewer: paulgarn
+
+ms.collection: M365-identity-device-management
+---
+# Conditional Access: Token protection (preview)
+
+Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant. 
+
+Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Azure AD, their primary identity is [bound to the device](../devices/concept-primary-refresh-token.md#how-is-the-prt-protected). This connection means that any issued sign-in token is tied to the device significantly reducing the chance of theft and replay attacks. These sign-in tokens are specifically the session cookies in Microsoft Edge and most Microsoft product refresh tokens in this preview release. 
+
+With this preview, we're giving you the ability to create a Conditional Access policy to require token protection for sign-in tokens for specific services. We support token protection for sign-in tokens in Conditional Access for Exchange Online and SharePoint Online on Windows devices.
+
+:::image type="content" source="media/concept-token-protection/complete-policy-components-session.png" alt-text="Screenshot showing a Conditional Access policy requiring token protection as the session control":::
+
+## Requirements
+
+This preview supports the following configurations:
+
+* Windows 10 or newer devices that are Azure AD joined, hybrid Azure AD joined, or Azure AD registered.
+* OneDrive sync client version 22.217 or later
+* Teams native client version 1.6.00.1331 or later 
+* Office Perpetual clients aren't supported
+
+### Known limitations
+
+- External users (Azure AD B2B) aren't supported and shouldn't be included in your Conditional Access policy.
+- The following applications don't support signing in using protected token flows and users are blocked when accessing Exchange and SharePoint:
+   - Power BI Desktop client 
+   - PowerShell modules accessing Exchange, SharePoint, or Microsoft Graph scopes that are served by Exchange or SharePoint
+   - PowerQuery extension for Excel
+   - Extensions to Visual Studio Code which access Exchange or SharePoint
+   - Visual Studio
+- The following Windows client devices aren't supported:
+   - Windows Server 
+   - Surface Hub
+
+## Deployment
+
+For users, the deployment of a Conditional Access policy to enforce token protection should be invisible when using compatible client platforms on registered devices and compatible applications.    
+
+To minimize the likelihood of user disruption due to app or device incompatibility, we highly recommend: 
+
+- Start with a pilot group of users, and expand over time. 
+- Create a Conditional Access policy in [report-only mode](concept-conditional-access-report-only.md) before moving to enforcement of token protection. 
+- Capture both Interactive and Non-interactive sign in logs. 
+- Analyze these logs for long enough to cover normal application use.
+- Add known good users to an enforcement policy. 
+
+This process helps to assess your users’ client and app compatibility for token protection enforcement. 
+
+### Create a Conditional Access policy
+
+Users who perform specialized roles like those described in [Privileged access security levels](/security/compass/privileged-access-security-levels#specialized) are possible targets for this functionality. We recommend piloting with a small subset to begin. 
+
+:::image type="content" source="media/concept-token-protection/exposed-policy-attributes.png" alt-text="Screenshot of a configured Conditional Access policy and its components." lightbox="media/concept-token-protection/exposed-policy-attributes.png":::
+
+The steps that follow help create a Conditional Access policy to require token protection for Exchange Online and SharePoint Online on Windows devices.
+
+1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.
+1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
+1. Select **New policy**.
+1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
+1. Under **Assignments**, select **Users or workload identities**.
+   1. Under **Include**, select the users or groups who are testing this policy.
+   1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts. 
+1. Under **Cloud apps or actions** > **Include**, select **Select apps**.
+   1. Under **Select**, select the following applications supported by the preview:
+       1. Office 365 Exchange Online
+       1. Office 365 SharePoint Online
+       
+       > [!WARNING]
+       > Your Conditional Access policy should only be configured for these applications. Selecting the **Office 365** application group may result in unintended failures. This is an exception to the general rule that the **Office 365** application group should be selected in a Conditional Access policy. 
+
+    1. Choose **Select**.
+1. Under **Conditions**:
+    1. Under **Device platforms**:
+       1. Set **Configure** to **Yes**.
+       1. **Include** > **Select device platforms** > **Windows**.
+       1. Select **Done**.
+    1. Under **Client apps**:
+       1. Set **Configure** to **Yes**.
+       1. Under Modern authentication clients, only select **Mobile apps and desktop clients**. Leave other items unchecked.
+       1. Select **Done**.
+1. Under **Access controls** > **Session**, select **Require token protection for sign-in sessions** and select **Select**.
+1. Confirm your settings and set **Enable policy** to **Report-only**.
+1. Select **Create** to create to enable your policy.
+
+After confirming your settings using [report-only mode](howto-conditional-access-insights-reporting.md), an administrator can move the **Enable policy** toggle from **Report-only** to **On**.
+
+### Capture logs and analyze
+
+Monitoring Conditional Access enforcement of token protection before and after enforcement.
+
+#### Sign-in logs 
+
+Use Azure AD sign-in log to verify the outcome of a token protection enforcement policy in report only mode or in enabled mode. 
+
+1. Sign in to the **Azure portal** as a Conditional Access Administrator, Security Administrator, or Global Administrator.
+1. Browse to **Azure Active Directory** > **Sign-in logs**.
+1. Select a specific request to determine if the policy is applied or not.
+1. Go to the **Conditional Access** or **Report-Only** pane depending on its state and select the name of your policy requiring token protection.
+1. Under **Session Controls** check to see if the policy requirements were satisfied or not.
+
+:::image type="content" source="media/concept-token-protection/sign-in-log-sample.png" alt-text="Screenshot showing an example of a policy not being satisfied." lightbox="media/concept-token-protection/sign-in-log-sample.png":::
+
+#### Log Analytics  
+
+You can also use [Log Analytics](../reports-monitoring/tutorial-log-analytics-wizard.md) to query the sign-in logs (interactive and non-interactive) for blocked requests due to token protection enforcement failure.
+
+Here's a sample Log Analytics query searching the non-interactive sign-in logs for the last seven days, highlighting **Blocked** versus **Allowed** requests by **Application**. 
+
+```kusto
+//Per Apps query 
+// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
+//SigninLogs 
+AADNonInteractiveUserSignInLogs 
+// Adjust the time range below 
+| where TimeGenerated > ago(7d) 
+| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
+| where ConditionalAccessPolicies != "[]" 
+| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
+//Add userPrinicpalName if you want to filter  
+// | where UserPrincipalName =="<user_principal_Name>" 
+| mv-expand todynamic(ConditionalAccessPolicies) 
+| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Protection"]' 
+| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
+| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
+| extend Result = case (SessionNotSatisfyResult contains 'Protection', 'Block','Allow') 
+| summarize by Id,UserPrincipalName, AppDisplayName, Result 
+| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
+| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
+| sort by Requests desc 
+```
+
+The result of the previous query should be similar to the following screenshot:
+
+:::image type="content" source="media/concept-token-protection/log-analytics-results.png" alt-text="Screenshot showing example results of a Log Analytics query looking for token protection policies" lightbox="media/concept-token-protection/log-analytics-results.png":::
+
+The following query example looks at the non-interactive sign-in log for the last seven days, highlighting **Blocked** versus **Allowed** requests by **User**. 
+ 
+```kusto
+//Per users query 
+// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
+//SigninLogs 
+AADNonInteractiveUserSignInLogs 
+// Adjust the time range below 
+| where TimeGenerated > ago(7d) 
+| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
+| where ConditionalAccessPolicies != "[]" 
+| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
+//Add userPrincipalName if you want to filter  
+// | where UserPrincipalName =="<user_principal_Name>" 
+| mv-expand todynamic(ConditionalAccessPolicies) 
+| where ConditionalAccessPolicies.enforcedSessionControls contains '["Protection"]' 
+| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
+| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
+| extend Result = case (SessionNotSatisfyResult contains 'Protection', 'Block','Allow') 
+| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
+| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
+| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
+| sort by UserPrincipalName asc   
+```
+
+## Next steps
+
+- [What is a Primary Refresh Token?](../devices/concept-primary-refresh-token.md)

articles/active-directory/conditional-access/media/concept-token-protection/complete-policy-components-session.png

@@ -92,9 +92,8 @@ Use the traditional VNet option when:
 
 ## Limitations with Azure CNI Overlay
 
-The overlay solution has the following limitations:
+Azure CNI Overlay has the following limitations:
 
-* Overlay can be enabled only for new clusters. Existing (already deployed) clusters can't be configured to use overlay.
 * You can't use Application Gateway as an Ingress Controller (AGIC) for an overlay cluster.
 * Windows Server 2019 node pools are not supported for overlay.
 
@@ -150,9 +149,10 @@ az aks create -n $clusterName -g $resourceGroup --location $location --network-p
 
 To update an existing cluster to use Azure CNI overlay, there are a couple prerequisites:
 
-1. The cluster must use Azure CNI without the pod subnet feature.
-1. The cluster is _not_ using network policies.
-1. The Overlay Pod CIDR needs to be an address range that _does not_ overlap with the existing cluster's VNet.
+* The cluster must use Azure CNI without the pod subnet feature.
+* The cluster is _not_ using network policies.
+* The Overlay Pod CIDR needs to be an address range that _does not_ overlap with the existing cluster's VNet.
+* If you have subnet Network Security Group rules, they must allow traffic to and from the Pod CIDR (refer to the [network security groups](#network-security-groups) section in this document for more information).
 
 To update a cluster, run the following Azure CLI command. 
 

articles/active-directory/conditional-access/media/concept-token-protection/exposed-policy-attributes.png

@@ -3,7 +3,7 @@ title: Create an App Service Environment
 description: Learn how to create an App Service Environment.
 author: madsd
 ms.topic: article
-ms.date: 11/15/2021
+ms.date: 03/09/2023
 ms.author: madsd
 ---
 
@@ -34,7 +34,7 @@ Before you deploy your App Service Environment, think about the virtual IP (VIP)
 
 With an *internal VIP*, an address in your App Service Environment subnet reaches your apps. Your apps aren't on a public DNS. When you create your App Service Environment in the Azure portal, you have an option to create an Azure private DNS zone for your App Service Environment. With an *external VIP*, your apps are on an address facing the public internet, and they're in a public DNS.  For both *internal VIP* and *external VIP* you can specify *Inbound IP address*, you can select *Automatic* or *Manual* options. If you want to use the *Manual* option for an *external VIP*, you must first create a standard *Public IP address* in Azure. 
 
-For the deployment type, you can choose *single zone*, *zone redundant*, or *host group*. The single zone is available in all regions where App Service Environment v3 is available. With the single zone deployment type, you have a minimum charge in your App Service plan of one instance of Windows Isolated v2. As soon as you've one or more instances, then that charge goes away. It isn't an additive charge.
+For the deployment type, you can choose *single zone*, *zone redundant*, or *host group*. The single zone is available in all regions where App Service Environment v3 is available. With the single zone deployment type, you have a minimum charge in your App Service plan of one instance of Windows Isolated v2. As soon as you use one or more instances, then that charge goes away. It isn't an additive charge.
 
 In a zone redundant App Service Environment, your apps spread across three zones in the same region. Zone redundant is available in regions that support availability zones. With this deployment type, the smallest size for your App Service plan is three instances. That ensures that there's an instance in each availability zone. App Service plans can be scaled up one or more instances at a time. Scaling doesn't need to be in units of three, but the app is only balanced across all availability zones when the total instances are multiples of three.
 
@@ -54,7 +54,7 @@ Here's how:
 
     ![Screenshot that shows the App Service Environment basics tab.](./media/creation/creation-basics.png)
 
-3. From the **Hosting** tab, for **Physical hardware isolation**, select **Enabled** or **Disabled**. If you enable this option, you can deploy onto dedicated hardware. With a dedicated host deployment, you're charged for two dedicated hosts per our pricing when you create the App Service Environment v3 and then, as you scale, you're charged a specialized Isolated v2 rate per vCore. I1v2 uses two vCores, I2v2 uses four vCores, and I3v2 uses eight vCores per instance.
+3. From the **Hosting** tab, for **Physical hardware isolation**, select **Enabled** or **Disabled**. If you enable this option, you can deploy onto dedicated hardware. With a dedicated host deployment, you're charged for two dedicated hosts per our pricing when you create the App Service Environment v3 and then, as you scale, you're charged a specialized Isolated v2 rate per vCore. I1v2 uses two vCores, I2v2 uses four vCores, and I3v2 uses eight vCores per instance. For **Zone redundancy**, select **Enabled** or **Disabled**.
 
     ![Screenshot that shows the App Service Environment hosting selections.](./media/creation/creation-hosting.png)
 
@@ -70,6 +70,8 @@ If you're creating an App Service Environment with an external VIP, you can sele
 
 When your App Service Environment has been successfully created, you can select it as a location when you're creating your apps.
 
+To learn how to create an App Service Environment from an ARM template, see [Create an App Service Environment by using an Azure Resource Manager template](how-to-create-from-template.md).
+
 <!--Links-->
 [Intro]: ./overview.md
 [UsingASE]: ./using.md

articles/active-directory/conditional-access/media/concept-token-protection/log-analytics-results.png

@@ -3,7 +3,7 @@ title: Create an App Service Environment (ASE) v3 with Azure Resource Manager
 description: Learn how to create an external or ILB App Service Environment v3 by using an Azure Resource Manager template.
 author: madsd
 ms.topic: how-to
-ms.date: 01/20/2023
+ms.date: 03/09/2023
 ms.author: madsd
 ---
 # Create an App Service Environment by using an Azure Resource Manager template
@@ -57,7 +57,7 @@ In addition to the core properties, there are other configuration options that y
 * *name*: Required. This parameter defines a unique App Service Environment name. The name must be no more than 36 characters.
 * *virtualNetwork -> id*: Required. Specifies the resource ID of the subnet. Subnet must be empty and delegated to Microsoft.Web/hostingEnvironments
 * *internalLoadBalancingMode*: Required. In most cases, set this property to "Web, Publishing", which means both HTTP/HTTPS traffic and FTP traffic is on an internal VIP (Internal Load Balancer). If this property is set to "None", all traffic remains on the public VIP (External Load Balancer).
-* *zoneRedundant*: Optional. Defines with true/false if the App Service Environment will be deployed into Availability Zones (AZ). For more information, see [zone redundancy](./zone-redundancy.md).
+* *zoneRedundant*: Optional. Defines with true/false if the App Service Environment will be deployed into Availability Zones (AZ). For more information, see [Regions and availability zones](./overview-zone-redundancy.md).
 * *dedicatedHostCount*: Optional. In most cases, set this property to 0 or left out. You can set it to 2 if you want to deploy your App Service Environment with physical hardware isolation on dedicated hosts. 
 * *upgradePreference*: Optional. Defines if upgrade is started automatically or a 15 day windows to start the deployment is given. Valid values are "None", "Early", "Late", "Manual". More information [about upgrade preference](./how-to-upgrade-preference.md).
 * *clusterSettings*: Optional. For more information, see [cluster settings](./app-service-app-service-environment-custom-settings.md).