Cloud attach - Endpoint Managers silver lining - part 7 co-managing Azure AD devices

[anyweb]

Introduction

This is part 7 in a series of guides about cloud attach in Microsoft Endpoint Manager, with the aim of getting you up and running with all things cloud attach. This part will focus on enabling the compliance policies workload. This series is co-written by Niall & Paul, both of whom are Enterprise Mobility MVP’s with broad experience in the area of modern management. Paul is 4 times Enterprise Mobility MVP based in the UK and Niall is 10 times Enterprise Mobility MVP based in Sweden.

In part 1 we configured Azure AD connect to sync accounts from the on premise infrastructure to the cloud. In part 2, we prepared Azure resources for the Cloud Management Gateway, in part 3 we created the cloud management gateway and verified that everything was running smoothly. In part 4 we enabled co-management. With co-management, you retain your  existing processes for using Configuration Manager to manage PCs in your organization and you gain the additional advantage of being able to transfer workloads to the cloud via Endpoint Manager (Intune). In part 5 we enabled the compliance policies workload and reviewed how that affected a co-managed computer. In this part we will enable conditional access and see how that can be used to deny access to company resources. In part 6 we configured conditional access and used it to deny access to company resources unless the device was encrypted with BitLocker. In this part we'll show you that a device doesn't need to be hybrid Azure Ad joined in order to become co-managed and we'll show you one way to add an Azure AD joined device to co-management via a LOB (line of business) app.

Microsoft recommends joining devices to Azure AD. Internet-based devices can use Azure AD modern authentication with Configuration Manager. It also enables both device and user scenarios whether the device is on the internet or connected to the internal network.

Below you can find all parts in this series.

 

• Cloud attach - Endpoint Managers silver lining - part 1 Configuring Azure AD connect
• Cloud attach - Endpoint Managers silver lining - part 2 Prepare for a Cloud Management Gateway
• Cloud attach - Endpoint Managers silver lining - part 3 Creating a Cloud Management Gateway
• Cloud attach - Endpoint Managers silver lining - part 4 Enabling co-management
• Cloud attach - Endpoint Managers silver lining - part 5 Enabling compliance policies workload
• Cloud attach - Endpoint Managers silver lining - part 6 Enabling conditional access
• Cloud attach - Endpoint Managers silver lining - part 7 Co-managing Azure AD devices <- you are here
• Cloud attach - Endpoint Managers silver lining - part 8 Enabling tenant attach
• Cloud attach - Endpoint Managers silver lining - part 9 Renewing expiring certificates
• Cloud attach - Endpoint Managers silver lining - part 10 Using apps with tenant attach

Step 1. Identify Azure ad joined devices

To determine if a device is hybrid azure ad joined or azure ad joined let's take a look at the output of a command on two different computers, the following command will reveal this info.

dsregcmd /status

This reveals info containing lots of details, but we are mainly interested in the following properties of the device state.

• AzureADJoined
• DomainJoined

On the left we have our hybrid azure ad joined device which is joined to an on-premises domain as well as joined to Azure AD. On the right, the equivalent output is shown from an azure ad joined device, as you can see the device on the right is only joined to Azure AD and that device is the target of today's blog post. We will show you how to co-manage this azure ad joined device and the steps needed to achieve that easily.

If we look in Microsoft Endpoint Manager we can see those two devices, note that the hybrid azure ad joined device is already co-managed while the Azure AD joined device is not but it is enrolled into Intune.

 

Step 2. Create an azure ad group

Create an assigned Azure ad group called Co-managed AzureAd devices. We will use this group to target assigned devices with:

• Certificates used for communication to the on-premises infrastructure (when situated in that network)
• LOB app to deploy the Configuration Manager client

Step 3. Add needed certificates

Note: The on-premises infrastructure used for this series uses PKI (HTTPS) communication, so the client will communicate with on-premises client facing roles using HTTPS when on the same network, when it's not on the same network (or is on the internet), the CMG connection point does not need a client authentication certificate as the client uses Azure AD authentication. If we deploy the Trusted Root cert and Intermediate cert to our clients then when they roam into the on-premises network they'll flip over to 'currently intranet' in the ConfigMgr client properties, and be able to download content from the local distribution point rather than from the CMG. If you don't do this, they'll stay as 'currently internet' and download content from the CMG even when located on the same network as the on-premises Configuration Manager site servers (such as MP, SUP, DP).

Below you can see how the client behaves when it is on the same network as your on-premises infrastructure when these certificates are not deployed to it. Note the errors in ClientLocation.log and how the Connection Type is set to Currently Internet.

and below is the same client after having the Trusted Root Certificate and Intermediate Certificate installed. Note how the ClientLocation.log no longer complains about being able to talk to the local MP and the Connection Type is now set to Currently Intranet.

To resolve this (for communicating with client facing roles in the on-premises network), simply deploy the certificate used in your certificate chain within your infrastructure, we use a 2-tier chain so that means the following certs need to be deployed.

• Trusted Root Certificate
• Intermediate Certificate

To deploy the certs, you'll need to export them first on a client computer that has the certificates in its' certificate store.

Exporting certificates

To export the certificates you can do as follows. On a client computer that has the certificates installed, open CertLM.msc and select the Trusted Root Certification section, select Certificates and browse to your Trusted Root Certificate.

Right click the chosen certificate and choose Export.

The Certificate Export Wizard appears, click Next.

For Export File Format, choose the default option DER encoded binary x.509 (.CER) and click Next.

Next specify the name of the file to export, we recommend naming it after the actual certificate function and click Save.

and click OK and then click Finish at the summary.

Note: Repeat the above exercise for each certificate in your chain.

Deploy the Certificates using MEM

Open Microsoft Endpoint Manager and select Devices, select Configuration Profiles, select Windows 10 or later, and then select Templates.

In Templates, scroll down to Trusted certificate.

and click Create.

Fill in some details about the certificate profile you are creating and then click Next.

then point it to the related certificate file exported above and make sure to select the correct destination store for the certificate. Below is how the Trusted Root Certificate is deployed, note the destination store is Computer certificate store - Root

 

Next, assign the profile to the Azure AD group created in Step 2, in this case it's the Co-managed AzureAD devices group.

 

Continue through the wizard until completion.

Note: Repeat the above exercise for each certificate in your chain. Below you can see both the Trusted root certificate and the Intermediate certificate are assigned.

 

Step 4. Create a line of business application

Next we'll deploy a line-of-business (LOB) application to install the ConfigMgr client agent on our Azure AD joined devices.

A line-of-business (LOB) app is one that you add from an app installation file. This kind of app is typically written in-house. The following steps provide guidance to help you add a Windows LOB app to Microsoft Intune. Source

Create the cmdline

To do so however we'll first need to gather some info for our cmdline, the first part of that cmdline is already present in the Enablement tab of the Co-management node as shown here.

Copy and paste that cmdline into notepad.

CCMSETUPCMD="CCMHOSTNAME=CLOUDATTACHCMG.AZURENOOB.COM/CCM_Proxy_MutualAuth/72057594037927954 SMSSiteCode=P01"

We do have to fill in some additional values however, as per the documentation, we are adding the SMSMP property as our clients will roam back to the intranet, if yours do not, then that property is not needed.

Quote

If a device uses Azure AD for client authentication and also has a PKI-based client authentication certificate, specify the following properties to use Azure AD:

AADCLIENTAPPID
AADRESOURCEURI

If the client roams back to the intranet, use the following property:

SMSMP

so let's figure out the values for these properties

• AADCLIENTAPPID
• AADRESOURCEURI
• SMSMP

To retrieve some of this data you can query SQL directly with the following command:

select * from proxy_settings

Some data will be returned.

highlight the AADConfig Version column, right click and choose Copy.

Paste the results into notepad, the following values can be retrieved from the data

• AADCLIENTAPPID
• AADRESOURCEURI

 

You can even confirm the AADCLIENTAPPID in Enterprise Applications in Azure using the Application ID column.

So now we have those values, the remaining value is for the following setting SMSMP, and that's easy to fill in, so in our case that would be SMSMP=https://cm01.windowsnoob.lab.local

OK, now we've got all the properties populated, here is the finished cmdline

CCMSETUPCMD="CCMHOSTNAME=CLOUDATTACHCMG.AZURENOOB.COM/CCM_Proxy_MutualAuth/72057594037927954 SMSSiteCode=P01 AADCLIENTAPPID=1bdebebf-8f5a-468c-90ae-2c046b25c077 AADRESOURCEURI=https://ConfigMgrService SMSMP=https://cm01.windowsnoob.lab.local"

Deploy the LOB app

In Microsoft Endpoint Manager, select Apps, select All apps, scroll down to Other and choose Create Line-of-business app. Click on Select.

In the App information screen, point the App package file to the ccmsetup.msi file available in <ConfigMgr installation directory>\bin\i386

Fill in information as required and paste in the cmdline you've just created above.

Click Next and assign the app to the Co-managed Azure AD devices group

 

and that's it.

Now all you need to do is deploy an Azure AD Joined device (an example of that could be a Windows Autopilot Intune managed device), then add that device to the co-managed Azure AD devices group and wait until it has received the policy, once done, you'll have a co-managed Azure AD  joined device as shown below.

 

Job done !

Please join us in the part 8 where we'll take a look at enabling Tenant Attach.

Recommended reading

How to prepare internet-based devices for co-management - https://docs.microsoft.com/en-us/mem/configmgr/comanage/how-to-prepare-win10

Configure client authentication for cloud management gateway - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/configure-authentication

Configure client authentication for cloud management gateway - https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/configure-authentication#bkmk_cmgcp