Merge pull request #230154 from MicrosoftDocs/main

3/09 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: troubleshooting
-ms.date: 01/29/2023
+ms.date: 03/02/2023
 ms.author: justinha
 
 ---
@@ -237,6 +237,27 @@ To check for applied policies on the Azure AD DS components and update them, com
 1. For each of the managed domain's network components in your resource group, such as virtual network, NIC, or public IP address, check the operation logs in the Azure portal. These operation logs should indicate why an operation is failing and where a restrictive policy is applied.
 1. Select the resource where a policy is applied, then under **Policies**, select and edit the policy so it's less restrictive.
 
+## AADDS120: The managed domain has encountered an error onboarding one or more custom attributes
+
+### Alert message
+
+*The following Azure AD extension properties have not successfully onboarded as a custom attribute for synchronization. This may happen if a property conflicts with the built-in schema: \[extensions]*
+
+### Resolution
+
+>[!WARNING]
+>If a custom attribute's LDAPName conflicts with an existing AD built-in schema attribute, it can't be onboarded and results in an error. Contact Microsoft Support if your scenario is blocked. For more information, see [Onboarding Custom Attributes](https://aka.ms/aadds-customattr).
+
+Review the [Azure AD DS Health](check-health.md) alert and see which Azure AD extension properties failed to onboard successfully. Navigate to the **Custom Attributes** page to find the expected Azure AD DS LDAPName of the extension. Make sure the LDAPName doesn't conflict with another AD schema attribute, or that it's one of the allowed built-in AD attributes. 
+
+Then follow these steps to retry onboarding the custom attribute in the **Custom Attributes** page:
+
+1. Select the attributes that were unsuccessful, then click **Remove** and **Save**.
+1. Wait for the health alert to be removed, or verify that the corresponding attributes have been removed from the **AADDSCustomAttributes** OU from a domain-joined VM.
+1. Select **Add** and choose the desired attributes again, then click **Save**.
+
+Upon successful onboarding, Azure AD DS will back fill synchronized users and groups with the onboarded custom attribute values. The custom attribute values appear gradually, depending on the size of the tenant. To check the backfill status, go to [Azure AD DS Health](check-health.md) and verify the **Synchronization with Azure AD** monitor timestamp has updated within the last hour.
+
 ## AADDS500: Synchronization has not completed in a while
 
 ### Alert message

articles/active-directory-domain-services/troubleshoot-alerts.md

@@ -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/TOC.yml

@@ -119,7 +119,7 @@ The following device attributes can be used with the filter for devices conditio
 | model | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.model -notContains "Surface") |
 | operatingSystem | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system (like Windows, iOS, or Android) | (device.operatingSystem -eq "Windows") |
 | operatingSystemVersion | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system version (like 6.1 for Windows 7, 6.2 for Windows 8, or 10.0 for Windows 10 and Windows 11) | (device.operatingSystemVersion -in ["10.0.18363", "10.0.19041", "10.0.19042", "10.0.22000"]) |
-| physicalIds | Contains, NotContains | As an example all Windows Autopilot devices store ZTDId (a unique value assigned to all imported Windows Autopilot devices) in device physicalIds property. | (device.devicePhysicalIDs -contains "[ZTDId]:value") |
+| physicalIds | Contains, NotContains | As an example all Windows Autopilot devices store ZTDId (a unique value assigned to all imported Windows Autopilot devices) in device physicalIds property. | (device.physicalIds -contains "[ZTDId]:value") |
 | profileType | Equals, NotEquals | A valid profile type set for a device. Supported values are: RegisteredDevice (default), SecureVM (used for Windows VMs in Azure enabled with Azure AD sign in.), Printer (used for printers), Shared (used for shared devices), IoT (used for IoT devices) | (device.profileType -eq "Printer") |
 | systemLabels | Contains, NotContains | List of labels applied to the device by the system. Some of the supported values are: AzureResource (used for Windows VMs in Azure enabled with Azure AD sign in), M365Managed (used for devices managed using Microsoft Managed Desktop), MultiUser (used for shared devices) | (device.systemLabels -contains "M365Managed") |
 | trustType | Equals, NotEquals | A valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices) | (device.trustType -eq "ServerAD") |

articles/active-directory/conditional-access/concept-condition-filters-for-devices.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/concept-token-protection.md

@@ -374,6 +374,9 @@ You can configure a Conditional Access policy for the Microsoft Intune Enrollmen
 > [!NOTE]
 > The Intune Enrollment app is not supported for [Per-device terms of use](#per-device-terms-of-use).
 
+> [!NOTE]
+> For iOS/iPadOS Automated device enrollment, adding a custom URL to the Azure AD Terms of Use policy doesn't allow for users to open the policy from the URL in Setup Assistant to read it. The policy can be read by the user after Setup Assistant is completed from the Company Portal website, or in the Company Portal app. 
+
 ## Frequently asked questions
 
 **Q: I cannot sign in using PowerShell when terms of use is enabled.**<br />