Skip to content

Commit e338d43

Browse files
Banani-RathBanani-Rath
committed
Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)
2 parents 183c0c1 + 17345cc commit e338d43

File tree

263 files changed

+4020
-2042
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

263 files changed

+4020
-2042
lines changed

‎articles/active-directory-b2c/deploy-custom-policies-devops.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ manager: celestedg
99
ms.service: active-directory
1010
ms.workload: identity
1111
ms.topic: how-to
12-
ms.date: 02/14/2020
12+
ms.date: 05/18/2021
1313
ms.author: mimart
1414
ms.subservice: B2C
1515
---
@@ -22,17 +22,17 @@ There are three primary steps required for enabling Azure Pipelines to manage cu
2222

2323
1. Create a web application registration in your Azure AD B2C tenant
2424
1. Configure an Azure Repo
25-
1. Configure an Azure Pipeline
25+
1. Configure Azure Pipelines
2626

2727
> [!IMPORTANT]
28-
> Managing Azure AD B2C custom policies with an Azure Pipeline currently uses **preview** operations available on the Microsoft Graph API `/beta` endpoint. Use of these APIs in production applications is not supported. For more information, see the [Microsoft Graph REST API beta endpoint reference](/graph/api/overview?toc=.%2fref%2ftoc.json&view=graph-rest-beta&preserve-view=true).
28+
> Managing Azure AD B2C custom policies with Azure Pipelines currently uses **preview** operations available on the Microsoft Graph API `/beta` endpoint. Use of these APIs in production applications is not supported. For more information, see the [Microsoft Graph REST API beta endpoint reference](/graph/api/overview?toc=.%2fref%2ftoc.json&view=graph-rest-beta&preserve-view=true).
2929
3030
## Prerequisites
3131

3232
* [Azure AD B2C tenant](tutorial-create-tenant.md), and credentials for a user in the directory with the [B2C IEF Policy Administrator](../active-directory/roles/permissions-reference.md#b2c-ief-policy-administrator) role
3333
* [Custom policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy) uploaded to your tenant
3434
* [Management app](microsoft-graph-get-started.md) registered in your tenant with the Microsoft Graph API permission *Policy.ReadWrite.TrustFramework*
35-
* [Azure Pipeline](https://azure.microsoft.com/services/devops/pipelines/), and access to an [Azure DevOps Services project][devops-create-project]
35+
* [Azure Pipelines](https://azure.microsoft.com/services/devops/pipelines/), and access to an [Azure DevOps Services project][devops-create-project]
3636

3737
## Client credentials grant flow
3838

@@ -103,7 +103,7 @@ With a management application registered, you're ready to configure a repository
103103
exit 0
104104
```
105105
106-
## Configure your Azure pipeline
106+
## Configure Azure Pipelines
107107
108108
With your repository initialized and populated with your custom policy files, you're ready to set up the release pipeline.
109109

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

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -39,6 +39,8 @@
3939
href: service-dependencies.md
4040
- name: Location conditions
4141
href: location-condition.md
42+
- name: Filters for devices
43+
href: concept-condition-filters-for-devices.md
4244
- name: What if tool
4345
href: what-if-tool.md
4446
- name: Continuous access evaluation

‎articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,147 @@
1+
---
2+
title: Filters for devices as a condition in Conditional Access policy - Azure Active Directory
3+
description: Use device filters in Conditional Access to enhance security posture
4+
5+
services: active-directory
6+
ms.service: active-directory
7+
ms.subservice: conditional-access
8+
ms.topic: conceptual
9+
ms.date: 05/18/2021
10+
11+
ms.author: joflore
12+
author: MicrosoftGuyJFlo
13+
manager: daveba
14+
ms.reviewer: calebb
15+
16+
ms.collection: M365-identity-device-management
17+
---
18+
# Conditional Access: Filters for devices (preview)
19+
20+
When creating Conditional Access policies, administrators have asked for the ability to target or exclude specific devices in their environment. The preview condition filters for devices give administrators this capability. Now you can target specific devices using [supported operators and device properties for filters](#supported-operators-and-device-properties-for-filters) and the other available assignment conditions in your Conditional Access policies.
21+
22+
:::image type="content" source="media/concept-condition-filters-for-devices/create-filter-for-devices-condition.png" alt-text="Creating a filter for device in Conditional Access policy conditions":::
23+
24+
> [!IMPORTANT]
25+
> Filters for devices is currently in public preview. This preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
26+
> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
27+
28+
## Common scenarios
29+
30+
There are multiple scenarios that organizations can now enable using filters for devices condition. Below are some core scenarios with examples of how to use this new condition.
31+
32+
- Restrict access to privileged resources like Microsoft Azure Management, to privileged users, accessing from [privileged or secure admin workstations](/security/compass/privileged-access-devices). For this scenario, organizations would create two Conditional Access policies:
33+
- Policy 1: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multi-factor authentication and require device to be marked as compliant.
34+
- Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding filters for devices using rule expression device.extensionAttribute1 equals SAW and for Access controls, Block.
35+
- Block access to organization resources from devices running an unsupported Operating System version like Windows 7. For this scenario, organizations would create the following two Conditional Access policies:
36+
- Policy 1: All users, accessing all cloud apps and for Access controls, Grant access, but require device to be marked as compliant or require device to be hybrid Azure AD joined.
37+
- Policy 2: All users, accessing all cloud apps, including filters for devices using rule expression device.operatingSystem equals Windows and device.operatingSystemVersion startsWith "6.1" and for Access controls, Block.
38+
- Do not require multi-factor authentication for specific accounts like service accounts when used on specific devices like Teams phones or Surface Hub devices. For this scenario, organizations would create the following two Conditional Access policies:
39+
- Policy 1: All users excluding service accounts, accessing all cloud apps, and for Access controls, Grant access, but require multi-factor authentication.
40+
- Policy 2: Select users and groups and include group that contains service accounts only, accessing all cloud apps, excluding filters for devices using rule expression device.extensionAttribute2 not equals TeamsPhoneDevice and for Access controls, Block.
41+
42+
## Create a Conditional Access policy
43+
44+
Filters for devices are an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
45+
46+
> [!IMPORTANT]
47+
> Device state and filters for devices cannot be used together in Conditional Access policy. Filters for devices provides more granular targeting including support for targeting device state information through the `trustType` and `isCompliant` property.
48+
49+
The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios).
50+
51+
Policy 1: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multi-factor authentication and require device to be marked as compliant.
52+
53+
1. Sign in to the **Azure portal** as a global administrator, security administrator, or Conditional Access administrator.
54+
1. Browse to **Azure Active Directory** > **Security** > **Conditional Access**.
55+
1. Select **New policy**.
56+
1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
57+
1. Under **Assignments**, select **Users and groups**.
58+
1. Under **Include**, select **Directory roles** and choose **Global administrator**.
59+
60+
> [!WARNING]
61+
> Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including [administrative unit-scoped](../roles/admin-units-assign-roles.md) or [custom roles](../roles/custom-create.md).
62+
63+
1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
64+
1. Select **Done**.
65+
1. Under **Cloud apps or actions** > **Include**, select **Select apps**, and select **Microsoft Azure Management**.
66+
1. Under **Access controls** > **Grant**, select **Grant access**, **Require multi-factor authentication**, and **Require device to be marked as compliant**, then select **Select**.
67+
1. Confirm your settings and set **Enable policy** to **On**.
68+
1. Select **Create** to create to enable your policy.
69+
70+
Policy 2: All users with the directory role of Global administrator, accessing the Microsoft Azure Management cloud app, excluding filters for devices using rule expression device.extensionAttribute1 not equals SAW and for Access controls, Block.
71+
72+
1. Select **New policy**.
73+
1. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
74+
1. Under **Assignments**, select **Users and groups**.
75+
1. Under **Include**, select **Directory roles** and choose **Global administrator**.
76+
77+
> [!WARNING]
78+
> Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including [administrative unit-scoped](../roles/admin-units-assign-roles.md) or [custom roles](../roles/custom-create.md).
79+
80+
1. Under **Exclude**, select **Users and groups** and choose your organization's emergency access or break-glass accounts.
81+
1. Select **Done**.
82+
1. Under **Cloud apps or actions** > **Include**, select **Select apps**, and select **Microsoft Azure Management**.
83+
1. Under **Conditions**, **Filters for devices (Preview)**.
84+
1. Toggle **Configure** to **Yes**.
85+
1. Set **Devices matching the rule** to **Exclude filtered devices from policy**.
86+
1. Set the property to `ExtensionAttribute1`, the operator to `Equals` and the value to `SAW`.
87+
1. Select **Done**.
88+
1. Under **Access controls** > **Grant**, select **Block access**, then select **Select**.
89+
1. Confirm your settings and set **Enable policy** to **On**.
90+
1. Select **Create** to create to enable your policy.
91+
92+
### Filters for devices Graph API
93+
94+
The filters for devices API is currently available in Microsoft Graph beta endpoint and can be accessed using https://graph.microsoft.com/beta/identity/conditionalaccess/policies/. You can configure filters for devices when creating a new Conditional Access policy or you can update an existing policy to configure filters for devices condition. To update an existing policy, you can do a patch call on the Microsoft Graph beta endpoint mentioned above by appending the policy ID of an existing policy and executing the following request body. The example here shows configuring a filters for devices condition excluding device that are not marked as SAW devices. The rule syntax can consist of more than one single expression. To learn more about the syntax, see rules with multiple expressions.
95+
96+
```json
97+
{
98+
"conditions": {
99+
"devices": {
100+
"deviceFilter": {
101+
"mode": "exclude",
102+
"rule": "device.extensionAttribute1 -ne \"SAW\""
103+
}
104+
}
105+
}
106+
}
107+
```
108+
109+
## Supported operators and device properties for filters
110+
111+
The following device attributes can be used with filters for devices condition in Conditional Access.
112+
113+
| Supported device attributes | Supported operators | Supported values | Example |
114+
| --- | --- | --- | --- |
115+
| deviceId | Equals, NotEquals, In, NotIn | A valid deviceId that is a GUID | (device.deviceid -eq “498c4de7-1aee-4ded-8d5d-000000000000”) |
116+
| displayName | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.displayName -contains “ABC”) |
117+
| manufacturer | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.manufacturer -startsWith “Microsoft”) |
118+
| mdmAppId | Equals, NotEquals, In, NotIn | A valid MDM application ID | (device.mdmAppId -in [“0000000a-0000-0000-c000-000000000000”] |
119+
| model | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.model -notContains “Surface”) |
120+
| operatingSystem | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system (like Windows, iOS, or Android) | (device.operatingSystem -eq “Windows”) |
121+
| 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) | (device.operatingSystemVersion -in [“10.0.18363”, “10.0.19041”, “10.0.19042”]) |
122+
| pyhsicalIds | 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]") |
123+
| 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 -notIn [“Printer”, “Shared”, “IoT”] |
124+
| 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") |
125+
| 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 -notIn ‘ServerAD, Workplace’) |
126+
| extensionAttribute1-15 | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | extensionAttributes1-15 are attributes that customers can use for device objects. Customers can update any of the extensionAttributes1 through 15 with custom values and use them in filters for devices condition in Conditional Access. Any string value can be used. | (device.extensionAttribute1 -eq ‘SAW’) |
127+
128+
## Policy behavior with filters for devices
129+
130+
Filters for devices (preview) condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it is important to understand under what circumstances the policy is applied or not applied. The table below illustrates the behavior when filters for devices condition are configured.
131+
132+
| Filters for devices condition | Device registration state | Device filter Applied
133+
| --- | --- | --- |
134+
| Include/exclude mode with positive operators (Equals, StartsWith, EndsWith, Contains, In) and use of any attributes | Unregistered device | No |
135+
| Include/exclude mode with positive operators (Equals, StartsWith, EndsWith, Contains, In) and use of attributes excluding extensionAttributes1-15 | Registered device | Yes, if criteria are met |
136+
| Include/exclude mode with positive operators (Equals, StartsWith, EndsWith, Contains, In) and use of attributes including extensionAttributes1-15 | Registered device managed by Intune | Yes, if criteria are met |
137+
| Include/exclude mode with positive operators (Equals, StartsWith, EndsWith, Contains, In) and use of attributes including extensionAttributes1-15 | Registered device not managed by Intune | Yes, if criteria are met and if device is compliant or Hybrid Azure AD joined |
138+
| Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes | Unregistered device | Yes |
139+
| Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes excluding extensionAttributes1-15 | Registered device | Yes, if criteria are met |
140+
| Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes including extensionAttributes1-15 | Registered device managed by Intune | Yes, if criteria are met |
141+
| Include/exclude mode with negative operators (NotEquals, NotStartsWith, NotEndsWith, NotContains, NotIn) and use of any attributes including extensionAttributes1-15 | Registered device not managed by Intune | Yes, if criteria are met and if device is compliant or Hybrid Azure AD joined |
142+
143+
## Next steps
144+
145+
- [Conditional Access: Conditions](concept-conditional-access-conditions.md)
146+
- [Common Conditional Access policies](concept-conditional-access-policy-common.md)
147+
- [Securing devices as part of the privileged access story](/security/compass/privileged-access-devices)

0 commit comments

Comments
 (0)