The last couple of weeks I was thinking about could a RDS environment be used together with Device Based Conditional Access (CA) provided by AzureAD and Microsoft Intune. With AzureAD CA you can configure this based on the user, the device of the user, the application and the risk of the request. This blogpost only covers Device Based Conditional Access. When Conditional Access for Devices is configured the devices either need to be domain joined (AD and AzureAD) or compliant to the configured compliance policies. These policies need to be configured within Microsoft Intune or System Center Configuration Manager. This blogpost will focus specific on the use of RDS 2016 Session Hosts together with Conditional Access.

Device Based Conditional Access can be used to protect data of the following services:

• Office 365 SharePoint Online, to protect your organization’s sites and documents
• Office 365 Exchange Online, to protect your organization’s email
• Software as a service (SaaS) applications that are connected to Azure AD for authentication
• On-premises applications that are published by using Azure AD Application Proxy services

Before you can configure Device Based Conditional Access you need to configure some technologies. So before you can start with this blogpost you need to configure the following:

• Azure AD Connect in-place with Windows Server Active Directory Federation Services configured;
• Azure AD Device Registration with Azure Active Directory;
• A Hybrid ConfigMgr environment connected with Microsoft Intune;
• Each user needs to have a Azure Premium License assigned before you can use Conditional Access;

When you’ve configured all the pre-requisite technologies we can start configuring Device Based Conditional Access. In this blogpost I’m focusing on securing Exchange Online data.

Device Based Conditional Access with a requirement that the device must be registered:

1. Go to the Intune Portal and go to Policy -> Conditional Access and Exchange Online Policy. Configure the policy as showed in the below screenshot:
   

2. No add your test user to the group configured in the above step;
3. Next step is to check if the RDS Sessionhosts are registered within AzureAD, for this blogpost I’m using the following servers: AV-RD2016-SH-0 and AV-RD2016-SH-1. You can check this with the AzureAD PowerShell cmdlet ‘Get-AzureADDevice’:

   
   Note: In the above screenshots only my first RDS Session Host is registered within AzureAD as device.
   

4. Let’s see what will happen when we logon to both servers:
   AV-RD2106-SH-1 (SessionHost not Registered within AzureAD)

   
   

   AV-RD2106-SH-0 (SessionHost Registered within AzureAD)
   

   
   

5. Conclusion: When you register your RDS SesisonHosts within AzureAD users can connect to Exchange Online Services with active Conditional Access

Next step is to check this with Device Based Conditional Access with a requirement that the device must be registered and the device must be compliant:

1. Go to the Intune Portal and go to Policy -> Conditional Access and Exchange Online Policy. Configure the policy as showed in the below screenshot:
   

2. No add your test user to the group configured in the above step;
3. Next step is to check if the RDS Sessionhosts are registred within AzureAD, for this blogpost I’m using the following servers: AV-RD2016-SH-0 and AV-RD2016-SH-1. You can check this with the AzureAD PowerShell cmdlet ‘Get-AzureADDevice’:

   

   Note: both devices are now registered within AzureAD
   

4. Next step is to enable the Pre-Release feature: Conditional Access for managed PCs. Go to the Administration section of SCCM and then go to Updates and Servicing and click on Features. Select the feature and click on Turn On:

   

5. Next step is to create a Compliance policy for the users logging on to the RDS Session Hosts. Since the RDS Session Hosts are managed through SCCM I configure a simple compliance policy within SCCM which checks if the Antivirus is activated. Go to Assets and Compliance, Compliance Settings and Compliance Policies. Click on Create Compliance Policy:

   
   Select ‘Compliance rules for devices managed with the ConfigMgr client’

   
   Because Windows Server 2016 is not available I checked Windows 10 instead.
   

   
   Define the policy by adding items to the list

   
   Deploy to a collection with the Conditional Access users.

6. This baseline has the following results on my RDS Session Host:

   AV-RD2016-SH-0:
   

   

   The result is that I access the Exchange Online webmail:
   

   
   Note: When checking the logs I actually see that the compliance check is not done, but still it gives me a compliant result. Based on this additional testing is needed because
   

7. Now let’s see what will happen when we we’re not compliant with the compliance policy. Then you will receive the following error:

   AV-RD2016-SH-1:
   

   
   

8. The last test was to test the same scenario with a second logged on user on the RDS Session Host. The result was that I was able to access Webmail with that user. So if the devices is compliant it works for all logged on users on that device.

Conclusion:

The results of the first test ‘Device Based Conditional Access with a requirement that the device must be registered’ were expected. So if you’re registering your RDS Sessionhosts within the Azure Active Directory through device registration you can combine Device Based Conditional Access with your RDS environment. The second test ‘Device Based Conditional Access with a requirement that the device must be registered and the device must be compliant’ resulted in unexpected behavior. The log file said that the compliance policy was not checked but the end result was that the server was compliant to the policy. I think this is unexpected behavior, since this feature is still in preview I’m going to share my results and when I’ve more information I will update this blogpost!