diff --git a/articles/active-directory/active-directory-conditional-access-automatic-device-registration-setup.md b/articles/active-directory/active-directory-conditional-access-automatic-device-registration-setup.md new file mode 100644 index 00000000000..ba592e99567 --- /dev/null +++ b/articles/active-directory/active-directory-conditional-access-automatic-device-registration-setup.md @@ -0,0 +1,274 @@ + + + + + + +# How to setup automatic registration of Windows domain joined devices with Azure Active Directory + +Registration of Windows domain joined computers with Azure AD is required to enable Device-based Conditional Access (link: Securing access to Office 365 and other apps connected to Azure AD) and additional user experiences in Windows 10 Anniversary. + +Update like allowing the use of the work or school account to get an enhanced SSO experience to Azure AD apps, enterprise roaming of settings across devices, use of the Windows Store for Business and have a stronger authentication and convenient sign-in with Windows Hello. + +> [AZURE.NOTE] Windows 10 November 2015 Update supports some of the enhanced user experiences, however it is the Anniversary Update which has full support for Device-based Conditional Access. +For more information on Conditional Access please see [Azure Active Directory Conditional Access](active-directory-conditional-access.md). +For more information on Windows 10 devices in the workplace and the experiences users get when registered with Azure AD please see [Windows 10 for the enterprise: Ways to use devices for work](active-directory-azureadjoin-windows10-devices-overview.md). + + +Registration is supported in previous versions of Windows including: + +- Windows 8.1 + +- Windows 8.0 + +- Windows 7 + +For the use case of Windows Server computers used as a desktop (for example, a developer using a Windows Server as the primary computer) the following platforms can be registered: + +- Windows Server 2016 + +- Windows Server 2012 R2 + +- Windows Server 2012 + +- Windows Server 2008 R2 + +Below, you find what you need to do in your environment to enable registration of Windows domain joined devices with Azure AD in your organization. You will see: + +1. Prerequisites + +2. Deployment and roll-out + +3. Troubleshooting + +4. FAQ + + + +## Prerequisites + +The main requirement to enable automatic registration of domain joined devices with Azure AD is to have an up to date version of Azure AD Connect. + +Depending on how you deployed Azure AD Connect, whether Express or Custom installation or an in-place upgrade, the following prerequisites may have been configured automatically: + +1. Service Connection Point (SCP) in on-premises Active Directory for discovery of Azure AD tenant information by computers registering to Azure AD. + +2. AD FS Issuance Transform Rules for computer authentication upon registration (applicable to federated configurations). + +If you have non-Windows 10 domain joined computers in your organization, you need the following: + +1. Ensure that the policy for allowing users to register devices is enabled in Azure AD. + +2. Ensure Windows Integrated authentication (WIA) is set as a valid alternative to Multifactor authentication (MFA) in AD FS. + + + +## Service Connection Point for discovery of Azure AD tenant + +An SCP object that holds discovery information about the Azure AD tenant where computers will register, must exist in the Configuration Naming Context partition of the forest of the domain where computers are joined to. In a multi-forest configuration of Active Directory, the SCP must exist in all forests where computers have joined. + +The SCP should be found at the following location in Active Directory: + + CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,[Configuration Naming Context] + +> [AZURE.NOTE] For a forest with an Active Directory domain name of example.com the Configuration Naming Context is CN=Configuration,DC=example,DC=com + +You can check the existence of the object and the values for discovery of the Azure AD tenant using the following PowerShell script (replace the Configuration Naming Context in the example with yours): + + $scp = New-Object System.DirectoryServices.DirectoryEntry; + + $scp.Path = "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=example,DC=com"; + + $scp.Keywords; + +The output of $scp.Keywords shows the Azure AD tenant information like follows: + + azureADName:microsoft.com + + azureADId:72f988bf-86f1-41af-91ab-2d7cd011db47 + +If the SCP doesn’t exist, you can create it by running the following PowerShell script on the Azure AD Connect server: + + Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"; + + $aadAdminCred = Get-Credential; + + Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred; + + +> [AZURE.NOTE] When running $aadAdminCred = Get-Credential, use the format user@example.com for the user name of the credential that's entered when the Get-Credential pop-up appears. +> When running the cmdlet Initialize-ADSyncDomainJoinedComputerSync, replace [connector account name] with the domain account that's used as the Active Directory connector account. +> The cmdlet above uses the Active Directory PowerShell module which relies on Active Directory Web Services (ADWS) in domain controllers (DCs). ADWS is supported in Windows Server 2008 R2 or above DCs. If you only have Windows Server 2008 DCs or below you can use System.DirectoryServices API via PowerShell to create the SCP and assign the appropriate Keywords values. + +## AD FS rules for instant computer registration (federated orgs) + +On a federated configuration of Azure AD, computers will rely on AD FS (or the on-premises federation server) to authenticate to Azure AD for registration against the Azure Device Registration Service (Azure DRS). + +> [AZURE.NOTE] On a non-federated configuration (i.e. user password hashes sync’ed to Azure AD), Windows 10 and Windows Server 2016 domain joined computers authenticate against Azure DRS using a credential they write into their computer accounts on-premises which is taken up to Azure AD via Azure AD Connect. For non-Windows 10/Windows Server 2016 computers on a non-federated configuration see the section Windows Installer package for registration of non-Windows 10/Windows Server 2016 domain joined computers under Deployment and roll-out below in this document for options you have to enable Device-based CA in your organization. + +For Windows 10 and Windows Server 2016 computers, Azure AD Connect associates the device object in Azure AD with the computer account object on-premises. For this to work, the following claims must exist during authentication for Azure DRS to complete registration and create the device object in the first place: + +- `http://schemas.microsoft.com/ws/2012/01/accounttype` - containing the value of “DJ” which identifies the principal authenticating as a domain joined computer. +- `http://schemas.microsoft.com/identity/claims/onpremobjectguid` - containing the value of the objectGUID attribute of the computer account on-premises. +- `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid` - containing the computer primary SID, corresponding to the value of the objectSid attribute of the computer account on-premises. +- `http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid` - containing the appropriate value that allows Azure AD to trust the token issued from AD FS or the on-premises STS. This is important on a multi-forest Active Directory configuration where computers may be joined to a different forest than the one that connects to Azure AD where the AD FS or on-premises STS is. For the AD FS case the value should be `http:///adfs/services/trust/` where “\” is the validated domain name in Azure AD. + +To create these rules manually, in AD FS you can use the following PowerShell script on session connected to your server. Please note that the first line needs to be replaced with the validated domain name in Azure AD for your organization. + +> [AZURE.NOTE] If you don’t have AD FS as your on-premises federation server, follow the instructions of your vendor to create the appropriate rules to issue these claims. + + $validatedDomain = "example.com" # Replace example.com with your validated domain name in Azure AD + + $rule1 = '@RuleName = "Issue object GUID" + + c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] && + + c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] + + => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid"), query = ";objectguid;{0}", param = c2.Value);' + + $rule2 = '@RuleName = "Issue account type for domain joined computers" + + c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] + + => issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Value = "DJ");' + + $rule3 = '@RuleName = "Pass through primary SID" + + c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] && + + c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] + + => issue(claim = c2);' + + $rule4 = '@RuleName = "Issue AccountType with the value User when it’s not a computer account" + + NOT EXISTS([Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "DJ"]) + + => add(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype", Value = "User");' + + $rule5 = '@RuleName = "Capture UPN when AccountType is User and issue the IssuerID" + + c1:[Type == "http://schemas.xmlsoap.org/claims/UPN"] && + + c2:[Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "User"] + + => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c1.Value, ".+@(?.+)", "http://${domain}/adfs/services/trust/"));' + + $rule6 = '@RuleName = "Update issuer for DJ computer auth" + + c1:[Type == "http://schemas.microsoft.com/ws/2012/01/accounttype", Value == "DJ"] + + => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = "http://$validatedDomain/adfs/services/trust/");' + + $existingRules = (Get-ADFSRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline).IssuanceTransformRules + + $updatedRules = $existingRules + $rule1 + $rule2 + $rule3 + $rule4 + $rule5 + $rule6 + + $crSet = New-ADFSClaimRuleSet -ClaimRule $updatedRules + + Set-AdfsRelyingPartyTrust -TargetIdentifier urn:federation:MicrosoftOnline -IssuanceTransformRules $crSet.ClaimRulesString + +> [AZURE.NOTE] Windows 10 and Windows Server 2016 domain joined computers will authenticate using Windows Integrated authentication to an active WS-Trust endpoint hosted by AD FS. Ensure that this endpoint is enabled. If you are using the Web Authentication Proxy, also ensure that this endpoint is published through the proxy. The end-point is adfs/services/trust/13/windowstransport. It should show as enabled in the AD FS management console under Service > Endpoints. If you don’t have AD FS as your on-premises federation server, follow the instructions of your vendor to make sure the corresponding end-point is enabled. + + + +## Ensure AD FS is set up to support authentication of device for registration + +You need to make sure that Windows Integrated authentication (WIA) is set as a valid alternative to multi-factor authentication (MFA) in AD FS for device registration. + +For this you need to have an issuance transform rule that passes on the auth method. + +1. Open the AD FS management console and navigate to **AD FS > Trust Relationships > Relying Party Trusts**. + +2. Right-click on the Microsoft Office 365 Identity Platform relying party trust object, and then select **Edit Claim Rules**. + +2. On the **Issuance Transform Rules** tab, select **Add Rule**. + +3. Select **Send Claims Using a Custom Rule** from the **Claim rule** template list. + +4. Select **Next**. + +4. In the **Claim rule name** textbox, type **Auth Method Claim Rule**. + +5. In the **Claim rule** textbox, type `c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"] +=> issue(claim = c);` + +6. On your federation server, open Windows PowerShell. + +7. Type the following command: + + `Set-AdfsRelyingPartyTrust -TargetName -AllowedAuthenticationClassReferences wiaormultiauthn` + +The **\\** is the relying party object name for your Azure Active Directory relying party trust object. This object is typically named Microsoft Office 365 Identity Platform.` + + + + + + +## Deployment and roll-out + +Once the prerequisites are complete domain joined computers are ready to register with Azure AD. + +Windows 10 Anniversary Update and Windows Server 2016 domain joined computers will automatically register to Azure AD in the next reboot or user sign-in to Windows. New computers that are joined to the domain will register with Azure AD in the reboot following the domain join operation. + +> [AZURE.NOTE] Windows 10 November 2015 Update domain joined computers will automatically register with Azure AD only if the roll-out Group Policy Object is set. For more information, please see the following section. + +To control roll-out of automatic registration of Windows 10/Windows Server 2016 domain joined computers there is a Group Policy object you can use for that purpose. Roll-out of automatic registration of non-Windows 10 domain joined computers there is a Windows Installer package that you can deploy to selected computers. + +> [AZURE.NOTE] The Group Policy for roll-out control also triggers registration of Windows 8.1 domain joined computers. You may choose to use the policy for registration of Windows 8.1 domain joined computers or if you have a mix of versions of Windows including 7 or 8.0, or Windows Server versions, you may choose to enable registration of all your non-Windows 10/Windows Server 2016 computers using the Windows Installer package. + +### Group Policy Object to control roll-out of automatic registration + +To control roll-out of automatic registration of domain joined computers with Azure AD you can deploy the Group Policy Register domain joined computers as devices to the computers you want to register e.g. you can deploy the policy based on a security group or to an organizational unit (OU). + +To set the policy, perform the following steps: + +1. Open Server Manager and navigate to **Tools > Group Policy Management**. + +2. From Group Policy Management, navigate to the domain node that corresponds to the domain in which you would like to enable auto-registration of Windows 10 or Windows Server 2016 computers. + +3. Right-click **Group Policy Objects**, and then select **New**. + +4. Enter your group policy object a name, for example, *Automatic Registration to Azure AD*. Click OK. + +4. Right-click your new group policy object, and then select **Edit**. + +5. Navigate to **Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration**, right-click **Register domain joined computers as devices**, and then select **Edit**. + + > [AZURE.NOTE] This Group Policy template has been renamed from previous versions of the Group Policy Management console. If you are running a previous version of the console the policy will be under Computer Configuration > Policies > Administrative Templates > Windows Components > Workplace Join with the name Automatically workplace join client computers. + +6. Select the **Enabled** option button, and then click **Apply**. + +7. Click **OK**. + +7. Link the group policy object to a location of your choice. For example, a specific organizational unit (OU) were computers are located or a specific security group containing computers that will automatically register with Azure AD. To enable this policy for all of the domain joined Windows 10 and Windows Server 2016 computers at your organization, link the Group Policy object to the domain. + +## MSI package for non-Windows 10 computers + +To register domain joined computers running Windows 7, Windows 8.0, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 or Windows Server 2012 R2 a Windows Installer package (.msi) is available for you to download under the following location. + +You should deploy this package using a software distribution system such as System Center Configuration Manager. The package supports the standard silent install options using the /quiet parameter. If you use System Center Configuration Manager 2016 you will enjoy additional benefits like the ability to track completed registrations. For more information, please see [System Center 2016](https://www.microsoft.com/cloud-platform/system-center-2016). + +The installer creates a Scheduled Task on the system that runs in the user’s context and is triggered on user sign-in to Windows. The task silently registers the device with Azure AD with the user credentials after authenticating using Windows Integrated authentication. The Scheduled Task can be found in the Task Scheduler Library under **Microsoft > Workplace Join**. + + + +## Additional topics + +- [Azure Active Directory Conditional Access](active-directory-conditional-access.md) diff --git a/articles/active-directory/active-directory-conditional-access-policy-connected-applications.md b/articles/active-directory/active-directory-conditional-access-policy-connected-applications.md new file mode 100644 index 00000000000..6ecf7f07441 --- /dev/null +++ b/articles/active-directory/active-directory-conditional-access-policy-connected-applications.md @@ -0,0 +1,175 @@ + + + + + +# How to set Azure Active Directory device-based conditional access policy for access control to Azure Active Directory connected applications + + +Azure Active Directory device-based conditional access is the ability you have to protect organizational resources from: + +- Access made from unknown / unmanaged devices +- From devices that don’t meet security policies as defined by your organization. + +For an overview on conditional access, see [Azure Active Directory conditional access](active-directory-conditional-access.md). + +You can set device-based conditional access policies to protect the following: + +- Office 365 SharePoint Online to protect organizational sites and documents. + +- Office 365 Exchange Online to protect organizational email. + +- SaaS applications connected to Azure AD for authentication. + +- On-premises applications published through the Azure AD Application Proxy. + + +In the Azure management portal, you can set this policy by going to the specific application in the directory. + + + ![Applications](./media/active-directory-conditional-access-policy-connected-applications/01.png "Applications") + + +After selecting the application, click the **Configure** tab to set the Conditional Access policy. + + + ![Device based access rules](./media/active-directory-conditional-access-policy-connected-applications/02.png "Device based access rules") + + + + +To enable a device-based conditional access policy, in the **Device based access rules** section, for **Enable Access Rules**, select **On**. + +This policy consist of three components: + +1. **Apply To** - The scope of users this policy applies to when accessing the application. + +2. **Device Rules** - The required conditions devices must meet before accessing the application. + +3. **Application Enforcement** - The client applications (native vs. browser) the policy should be evaluated for. + + ![Device based access rules](./media/active-directory-conditional-access-policy-connected-applications/03.png "Device based access rules") + + +## Selecting the users the policy applies to + +In the **Apply To** section, you can select the scope of users this policy applies to. + +You have two options for the scope: + +- **All Users** - For everyone accessing the application + +- **Groups** - To limit the scope to users that are a member of a group or groups. + +![Apply to](./media/active-directory-conditional-access-policy-connected-applications/11.png "Apply to") + + +By selecting **Except**, you can exclude users from this policy while accessing the application. This is helpful when you need to enable specific users to access the application temporarily. Select this option, for example, if some of your users have devices that are not ready for conditional access (not yet registered, coming out of compliance, etc.). + + +## Selecting the conditions devices must meet + +With **Device Rules**, you set the conditions for devices to be able to access the application. + +For Device-based Conditional Access, the following devices are supported: + +- Windows 10 Anniversary Update, Windows 7 and Windows 8.1. + +- Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 and Windows Server 2008 R2 + +- iOS devices (iPad, iPhone) + +- Android devices + +Support for Mac is coming soon. + + ![Devices](./media/active-directory-conditional-access-policy-connected-applications/04.png "Applications") + + + + >[AZURE.NOTE] For information about differences between Domain Join and Azure AD Join please see [Using Windows 10 devices in your workplace](active-directory-azureadjoin-windows10-devices.md). + + +You have two options for device rules: + +- **All devices must be compliant** - This requires all device platforms accessing the application to be compliant. For platforms that don't support Device-based Conditional Access, the devices are denied access. + +- **Only selected devices must be compliant** - This requires only selected device platforms to be compliant. Non-selected platforms or other platforms accessing the application are allowed access.” + + ![Applications](./media/active-directory-conditional-access-policy-connected-applications/05.png "Applications") + + + +Azure AD joined devices are compliant if they are marked as **compliant** in the directory by Microsoft Intune or a 3rd party Mobile Device Management (MDM) system that integrates with Azure AD. + +Domain joined devices are compliant in one of two ways: + +- If they are registered with Azure AD, the fact that they are domain joined many organizations treat them as trusted devices. + +- If they are marked as ‘compliant’ in the Azure AD by System Center Configuration Manager 2016. + + ![Device Rules](./media/active-directory-conditional-access-policy-connected-applications/06.png "Device Rules") + + +Windows personal devices are compliant if they are marked as **compliant** in the directory by Microsoft Intune or a 3rd party Mobile Device Management (MDM) system that integrates with Azure AD. + +Non-Windows devices are compliant if they are marked as **compliant** in the directory by Microsoft Intune. + + >[AZURE.NOTE] For more information on how to setup Azure AD for device compliance by management system, see [Azure Active Directory Conditional Access](active-directory-conditional-access.md). + + +When you select specific device platforms, you can select one or multiple options including Android, iOS, Windows Mobile (Windows 8.1 phones and tablets) and Windows (all other Windows devices including all Windows 10 devices). +With this option, the policy evaluation only occurs on the selected platforms. If access is attempted from a device that is not part of the selection, no device policy is evaluated and the device is allowed if the user is. + +![Device Rules](./media/active-directory-conditional-access-policy-connected-applications/07.png "Device Rules") + + +## Selecting the type of client applications under which policy will be evaluated + +In the **Application Enforcement** section, you set the type of applications the policy must be evaluated for. + + +You have two options for applications: + +- For browser and native applications +- For only native applications. + + +![Applications](./media/active-directory-conditional-access-policy-connected-applications/08.png "Applications") + + +Selecting **For browser and native applications** enforces the policy on access to applications by: + +- Browsers (e.g. Edge in Windows 10, Safari in iOS, etc.) +- Applications using the Active Directory Application Library (ADAL) in any platform or the Web Account Manager (WAM) API in Windows 10 + +>[AZURE.NOTE] For more information about browser support and other considerations for the end-user accessing device-based CA protected applications see, [Azure Active Directory Conditional Access](active-directory-conditional-access.md). + + + +## Protecting email access from Exchange Active Sync based applications + +In Office 365 Exchange Online applications, you have an additional section called **Exchange Activesync**. This section enables you to block email access to Exchange Active Sync based mail applications. + +![Applications](./media/active-directory-conditional-access-policy-connected-applications/09.png "Applications") + +![Applications](./media/active-directory-conditional-access-policy-connected-applications/10.png "Applications") + + +## Additional topics + +- [Azure Active Directory Conditional Access](active-directory-conditional-access.md) diff --git a/articles/active-directory/active-directory-conditional-access.md b/articles/active-directory/active-directory-conditional-access.md index f6710ee0ba5..d1401ecc52f 100644 --- a/articles/active-directory/active-directory-conditional-access.md +++ b/articles/active-directory/active-directory-conditional-access.md @@ -1,5 +1,5 @@ -# Azure Active Directory Conditional Access +# Azure Active Directory conditional access Securing access to company resources is important to every organization. With the advent of cloud services and mobile devices, the way in which users access company resources has significantly changed. This requires a new approach to security. @@ -28,7 +28,7 @@ The conditional access control capabilities in Azure Active Directory offers sim -## Licensing Requirements +## Licensing requirements Conditional access is a feature of [Azure AD Premium](http://www.microsoft.com/identity). All users who access an application with conditional access policy applied, must have an Azure AD Premium license. You can learn more about usage with the [Unlicensed User report](https://aka.ms/utc5ix). @@ -61,7 +61,7 @@ With conditional access control, Azure Active Directory checks the specific cond - **Block**: Access may be applied under conditions like user location. For example, blocking access when a user is not on a trusted network. -- **Enrolled / Compliant devices**: At the device level, you can set policies that enforce that only Mobile Device Management (MDM) enrolled and compliant devices are allowed access. Microsoft Intune is used to validate the device is enrolled and compliant. The device level conditional access then ensures that only devices that are compliant with MDM policy are allowed access. +- **Compliant devices**: At the device level, you can set policies that enforce that only computers that are domain joined or mobile devices that are enrolled into the Mobile Device Management (MDM) and meet compliance, are allowed access. Microsoft Intune is used to check compliance on devices and report it back to Azure Active Directory for enforcement during application access. ## Applications @@ -69,27 +69,57 @@ With conditional access control, Azure Active Directory checks the specific cond - The level of access that you can set using these policies can be applied to applications and services in the cloud or on-premises. Policy is directly applied to the web site or service. The policy is then enforced for browser access as well as applications accessing the service. The list of services policy can be applied to can be found here. +## Device-based conditional access + +You can also restrict access to applications from devices that are registered with Azure AD that meet specific conditions. This is useful to protect organizational resources from valid users accessing these resources from: + +- Unknown / unmanaged devices +- Devices that don’t meet security policies as defined by your organization. + +Policies can be set based on the following requirements: + +- **Domain joined devices** - You can set a policy to restrict access to devices that are joined to an on-premises Active Directory domain and are also registered with Azure AD. This policy applies to Windows desktops, laptops or enterprise tablets that belong to an on-premises Active Directory domain which have registered with Azure AD. +For more information on how to setup automatic registration of domain joined devices with Azure AD, see [How to setup automatic Registration of Windows domain joined devices with Azure Active Directory](active-directory-conditional-access-automatic-device-registration-setup.md). + +- **Compliant devices** - You can set a policy to restrict access to devices that are marked **compliant** in the directory by the management system. This policy ensures that only devices that meet security policies such as enforcing file encryption on a device are allowed access. This policy can be used to restrict access from the following devices: + + - **Windows domain joined devices** that are managed by System Center Configuration Manager 2016 deployed in a hybrid configuration. + + - **Windows 10 mobile work or personal devices** that are managed by Microsoft Intune or a supported 3rd party Mobile Device Management (MDM) system. + + - **iOS and Android devices** that are managed by Microsoft Intune. + + +Users accessing applications that are protected by Device-based CA policy need to do this from devices that meet this policy. Access is denied if it is made from a device that doesn’t meet the policy. + +For information on how to configure Device-based CA policy in Azure AD, see [How to configure Device-based Conditional Access policy for access control to Azure Active Directory connected applications](active-directory-conditional-access-policy-connected-applications.md). + +## Article index for Azure Active Directory conditional access -## Conditional access - a content map The following content map lists documents that you need to refer to learn more about enabling conditional access in your current deployment -### MFA and Location policies +### MFA and location policies - [Getting started with conditional access to Azure AD connected apps based on group, location, and MFA policies](active-directory-conditional-access-azuread-connected-apps.md) + - [What kind of applications are supported](active-directory-conditional-access-supported-apps.md) ### Device policies -[Help protect your data requiring Microsoft Intune](https://docs.microsoft.com/intune/deploy-use/use-remote-wipe-to-help-protect-data-using-microsoft-intune) +- [How to set Device-based Conditional Access policy for access control to Azure Active Directory connected applications](active-directory-conditional-access-policy-connected-applications.md) + +- [How to setup automatic registration of Windows domain joined devices with Azure Active Directory](active-directory-conditional-access-automatic-device-registration-setup.md) + +- [Help protect your data requiring Microsoft Intune](https://docs.microsoft.com/intune/deploy-use/use-remote-wipe-to-help-protect-data-using-microsoft-intune) ### Protecting resources based on sign-in risk [Azure AD Identity Protection](active-directory-identityprotection.md) -### Additional Info +### Additional info - [Conditional Access FAQs](active-directory-conditional-faqs.md) - [Technical reference](active-directory-conditional-access-technical-reference.md) diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/01.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/01.png new file mode 100644 index 00000000000..2eaba93d80d Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/01.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/02.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/02.png new file mode 100644 index 00000000000..d067893ceff Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/02.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/03.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/03.png new file mode 100644 index 00000000000..078ea8781e2 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/03.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/04.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/04.png new file mode 100644 index 00000000000..4b666033f38 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/04.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/05.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/05.png new file mode 100644 index 00000000000..8e586a86e80 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/05.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/06.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/06.png new file mode 100644 index 00000000000..a369f969599 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/06.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/07.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/07.png new file mode 100644 index 00000000000..e211555b636 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/07.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/08.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/08.png new file mode 100644 index 00000000000..ecb39dfcf4c Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/08.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/09.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/09.png new file mode 100644 index 00000000000..a0606e0eb74 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/09.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/10.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/10.png new file mode 100644 index 00000000000..8a1c17842fd Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/10.png differ diff --git a/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/11.png b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/11.png new file mode 100644 index 00000000000..cae7751a9a2 Binary files /dev/null and b/articles/active-directory/media/active-directory-conditional-access-policy-connected-applications/11.png differ