Microsoft Intune

Categories:

• Class-1

  38 minute read  

Version History

This integration is implemented through ClearPass Extensions which run independent of the ClearPass platform version. Hence extensions can be updated and released outside of ClearPass release cycles.

What’s new in ClearPass Intune Extension v6.3

Support for Strong Mapping

With Intune extension version 6.3.3, we have made changes to align with Microsoft’s Strong Mapping requirements detailed below.

https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-implementing-strong-mapping-in-microsoft-intune/ba-p/4053376

https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

With the introduction of Strong Mapping feature the SAN URI field is now also used by Microsoft to insert a security identifier (SID) value for Microsoft Entra hybrid joined users/devices. This means that Intune managed clients in a Microsoft Entra hybrid joined environment when provisioned with a certificate using the Intune SCEP certificate profile will have SID tag in the SAN URI field of the certificate. This means that the Intune attribute used for real time lookups now comes in the SAN URI field of the certificate along with the Strong Mapping SID attribute as comma seperated strings in ClearPass. It is therfore important for us to be able to extract only the Intune Device ID attribute from this field to make API calls for real time lookups.

This release supports parsing of the Intune Device ID attribute from the comma seperated string that comes in the SAN URI field to make API calls for real time lookups on Intune. Therfore, all customers adopting the Strong Mapping feature are required to upgrade to this release of the Intune extension. Starting Jan 2025 the Strong Mapping adoption is expected to be enforced on the overall windows ecosystem after which the key distribution system (KDC) will check if certificates have the security identifier during certificate-based authentications.Upgrading to this extension release will therefore not be optional once Microsoft enforces Strong Mapping for Microsoft Entra hybrid joined users/devices.

The URI attribute “{{OnPremisesSecurityIdentifier}}” is required on the Intune SCEP certificate profile to add the Strong Mapping SID value in the SAN URI field once Strong Mapping is enabled for the Intune tenant by Microsoft.

New Recommendation around using alternate Intune ID to support Device / User Group Lookups

For customers using Intune extension as real-time AuthZ source to do user and device group lookups, we use the Intune Device ID from the SAN URI field of the certificate to fetch the Intune attributes and parse the User ID / AAD_Device_ID to then make another call to fetch either the user or device group information. This adds an additional API call for getting the User ID / AAD_Device_ID as part of Intune attributes (Using Intune Device ID) first and then using that information to do the user or device group lookup. However, if the AAD_Device_ID and the UserPrincipalName if already present in the SAN / CN field of certificate we can save an API call for better performance in high client density environments to directly parse them from the certificate and make the API call to fetch the user or device group lookup directly without having to make that extra API call to first fetch those attributes as Intune attributes (Using Intune Device ID) first then make the second call.

To address this we have added support for KEY:VALUE pair when more than one ID is included in the SAN URI field or when using AAD_Device_ID. AAD_Device_ID can fetch both Intune attributes and device group information. UserPrincipalName fetches the user group information and Intune Device ID only fetches the Intune attributes. Given below are the examples to setup Intune SCEP certificate profile to use KEY:VALUE pairs for different ID’s. Note that making changes in the below fields would require the configured Certificate Authority to re-sign / issue new certificates for the clients.

Supported KEY:VALUE pairs are as follows. The KEY names used are same as the variable names that Intune supports in the SCEP profile. Please refer the below link from Micrsoft for details.

https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep

1. DeviceId:{{DeviceId}} - Used for Intune attributes lookup.
2. AAD_Device_ID:{{AAD_Device_ID}} - Used for both Intune attributes and Device group membership lookup.
3. UserPrincipalName:{{UserPrincipalName}} - Used for User group lookup only when user group lookup using extension is enabled.

The order of priority for querying Intune using these attributes during real-time AuthZ is DeviceId, AAD_Device_ID and finally the standalone value. Any attribute value in the SAN URI that does not have any one of the above KEYs before them is considered as a standalone value and is considered as DeviceId by default to maintain backward compatibility for environments that are already setup with DeviceId in the SAN URI field of the client certificates for real-time lookpus against Intune or environments that have Strong Mapping enabled. These recommendations as noted above are optional and environments that use only the DeviceId value (wthout the KEY:VALUE pair) in the SAN URI field is still supported for both Microsoft Entra hybrid joined users/devices and Microsoft Entra only joined users/devices.

For more information on how to use the extension in HTTP Authorization Mode please refer to the Configuring ClearPass Policy Manager as an HTTP authZ source section of this document.

What’s new in ClearPass Intune Extension v6

Microsoft released the Compliance Retrieval service with the Intune June 2021 service release. This new service is intended to replace the Intune NAC service, and includes changes to improve the security, reliability, and privacy of the NAC service. For example, it uses lookup by Intune device ID only, which removes the dependency on internal identifiers, such as serial numbers, which are not consistently accessible. It also eliminates MAC address identifiers, which are problematic because devices can have multiple or randomized MAC addresses. The new service is also streamlined to return only enrollment and compliance data from Intune. Any other device data not related to access control is eliminated from this service.

Intune Extension v6 adheres to the main requirement to use certificate-based authentication (e.g. EAP-TLS) with the new service. In conjunction with this, it is required to include the Intune device ID in the subject alternative name (SAN) of your certificate profiles. Please refer to Appendix E for more details on SCEP certificate profile configuration.

As noted below, Intune Extension v5 made a major move to use Microsoft GraphAPI. However, we encountered an issue with GraphAPI when syncing with Intune to retrieve device attributes as it did not support pulling the Ethernet MAC address attribute (wired interface). We addressed this with a workaround that utilizes real-time lookup by Intune device ID to pull the Ethernet MAC address attribute and have it stored in the endpoint DB. Please refer to the section “Utilizing HTTP Authorization Mode to Retrieve Specific Device Attributes” for more details.

What’s new in ClearPass Intune Extension v5

In this MAJOR update the integration changes fundamentally how it works. You MUST read the ‘change in behaviors’ below to understand how this might affect how you use this Extension. We feel this change is for the better, we’ve constantly had customers telling us that the authN event-driven approach was not how they liked or wanted this integration to work. Previously we had been restricted to using the “Intune NAC-API”, however this version uses the Microsoft GraphAPI, this open up a list of new features and some changes.

• Batch Ingest all Tenant endpoints like other UEM vendors

• Only sync updated endpoint context after previous sync

• Send CMD’s to Intune to ‘run’ against endpoints

• Lock Screen

• Wipe Device

• Shutdown Device

v5 - Change in Behavior

It is important to note that this Extension works in a different way to the previous Intune extensions, it does not query Intune on each and every authN {or reference cached data as in previous versions} thus it’s not an authZ source like before, though an authZ use-case exists it works differently from the previous version.

This integration works by ingesting all of the endpoint with a customer’s tenant, this is inline with how every other UEM integration fundamentally works. However, because of the API changes we can’t query based upon the authenticating mac-address, more on this later. With the v5 we have to use the EndpointDb as the authZ source, so depending on the sync schedule, this will determine the fresh ‘v’ stale view of the data.

There is an option to query real-time Intune, however there is an assumption that the endpoint is already managed by Intune and you’re only querying for current data. You could have an authZ rule such as Endpoint Source=Intune trigger a CSA profile for an update, and if Source != Intune trigger a different CSA profile. The reason behind this is that the query exposed in GraphAPI is based on the Azure DeviceID {AZID}, so for ClearPass to query for an endpoint update it needs the AZID, which it has from data already synced, the Extension uses the mac-address of the authenticating device, looks up the AZID in the ClearPass endpointDb before it can query Intune.

For this reason the previous process of using a real-time query based upon mac-address for found/not-found devices in Intune needs to be adjusted, perhaps validating an endpoint has an AZID attribute value.

What’s new in ClearPass Intune Extension v4

In v4, we added the capability to cache Intune attributes for a configurable time. This allows device attributes from Intune to be written to the Endpoint Repository of ClearPass. If a device authenticates within the cache period, ClearPass would not send requests to Intune Authorization source, rather use the attributes cached in the Endpoint Repository. This helps reduce the number of API calls to Intune.

What’s new in ClearPass Intune Extension v3

Enabling Intune NAC API to ingest endpoint ownership such as it can be used in Policy within ClearPass

What’s new in ClearPass Intune Extension v1

The first Intune extension for ingesting endpoint data, based upon a 1:1 API call due to limited ability in Intune to ingest ALL endpoint in a tenant.

Software Requirements

The minimum software version required for CPPM is 6.11.0 . At the time of writing, version 6.11.9 is available as the long supported release and 6.12.2 is av available as the short supported release. CPPM runs on hardware appliances with pre-installed software or as a Virtual Machine under the following hypervisors. Hypervisors that run on a client computer such as VMware Player are not supported.

• VMware vSphere Hypervisor (ESXi) 7.0 U3c and 8.0

• Windows Server 2019 with Hyper‑V and Windows Server 2022 with Hyper‑V.

• KVM on CentOS Stream 8, CentOS Stream 9, Ubuntu 20.04 LTS, and Ubuntu 22.04 LTS.

ClearPass Installation and Deployment Guide

This document assumes your ClearPass environment is already configured and operational. If you require assistance with basic deployment, refer to the following deployment guide:

https://www.arubanetworks.com/techdocs/ClearPass/6.11/Installation-Guide/Default.htm

ClearPass Extensions

The integration between ClearPass Policy Manager and external systems is driven through a ClearPass capability known as Extensions, a sub-component of the ClearPass Exchange Integration framework. ClearPass Extensions are micro-services running on top of the base ClearPass platform. These micro-services enable Aruba to deliver new features outside of the main software release cycle and facilitate a faster time to market for specific features and integrations. Configuration and control of ClearPass Extensions is accomplished through the ClearPass Guest GUI, as covered later in this document.

Installing Extension

ClearPass Extensions are easy to install from the ClearPass Extensions Store. In a cluster, ClearPass Extensions can be installed on a subscriber independently of the publisher. Multiple copies of the same extension can be installed if needed as well.

Access to the extension store

Access the Extension Store to download and install ClearPass extensions. The Extension store utilizes the same HPE Passport account credentials used to validate support entitlement in the Software Updates Por- tal. This is configured under Administration > Agents and Software Updates > Software Updates as shown below. Ensure that valid HPE Passport credentials have been entered in these fields to enable Ex- tension download capabilities.

Installing the Extension from Store

Extensions are installed from the extension page in ClearPass Guest, as shown below. Access it from Guest > Administration > Extensions

From here, click on ‘Install Extension’, and the search box below appears.

Enter “Intune” and click on ‘Search’, see the example below.

Click on the extension name and then click “Install.”

In the “Install Extension” dialog box, set the IP address if necessary, as described in section “Extensions and IP address configuration support” below. Do not check the box to start the extension at this time. Click the “Install” button.

In this example, we’ve not entered an IP address for the extension to use, if there is intent to use the extension as an authorization source set this value and ensure its set the same on all nodes where the Extension is deployed.

The extension will download and appear in a “Stopped” state. Notice the options to Start, Delete, Reinstall, Show Logs, and view Configuration. Click on “Configuration” to view settings.

After the extension has been installed, proceed to configure the extension

A copy of the default Extension configuration is shown above, this will need to be modified for your deployment.

Extensions and web proxy support

Extensions support communications with 3^rd parties via a web proxy. This adds incremental proxy functionality. If a proxy is defined in ClearPass Policy Manager, then an extension will inherit that configuration. See later in the document on how to disable the proxy inherited configuration.

Extensions and IP address configuration support

ClearPass uses a non-externally routed IP address range to communicate with the Extension. The default is 172.17.0.0/16. You may configure a different range, if desired. This is especially useful when deploying extensions across nodes within a cluster where there is the requirement for a fixed consistent IP address for the extension across the cluster.

Changing the “Extensions Network Address” range is only necessary if either the ClearPass MGMT or DATA interface are using an IP address in the extension default range of 172.17.x.x/12, or if ClearPass needs to communicate with some external device in that range.

To Configure the base Extension IP subnet within Policy Manager navigate to Administration > Server Manager > Server Configuration [chose your node] Service Parameters [ClearPass system service].

Installation of Extension on Subscribers

If you are installing the extension on a ClearPass cluster, please see Appendix B – Considerations for Installing in a Cluster

Pictorial View of the Integration

The extension can be configured for two different modes of operation.

Periodic Sync Mode:

In this mode ClearPass polls Intune periodically and updates the ClearPass Endpoint database with attributes obtained from Intune. These attributes can be utilized in ClearPass during endpoint Authorization. This mode has a simpler configuration demand, however, the data provided may not be completely up to date at authentication time.

HTTP Authorization Source Mode:

In this mode we configure an HTTP Auth source that results in a real time API call to Intune during endpoint authorization. Information in this case is more up to date, but there is a higher overhead of an API call during endpoint authorization, remember we only query for already known/ingested endpoint context. A view of this process is below.

Configurations Steps

There are primarily 4 steps involved in getting this Integration configured.

1. Configuring and Collecting Information from Microsoft to Configure Intune extension

2. Installation and Configuration of the Intune Extension

3. Configuring ClearPass Intune Extension to sync endpoint data from Intune to the EndpointDb

4. Configuring ClearPass Policy Manager to use already ingest endpoint context from Intune or configure an Authorization source for real-time updates.

Collecting Information to Configure Intune extension

It is assumed you have Intune/Azure environment already setup and configured. The setup of these environments is beyond the scope of this TechNote.

In order to complete the integration, you need to collect multiple pieces of information from Intune and the Azure platform when configuring the ‘ClearPass App’ that are required to complete the extension configuration. The goal is to collect information to complete the highlighted attributes below in red:

{

“logLevel”: “INFO”,

“verifySSLCerts”: true,

“azureADEndpoint”: “login.microsoftonline.com”,

“graphEndpoint”: “graph.microsoft.com”,

"tenantId": "xxxxxxxx",

"clientId": "xxxxxxxx",

"clientSecret": "********",

“syncPageSize”: 50,

“enableSyncAll”: true,

“syncAllSchedule”: “*/30 * * * *”,

“syncUpdatedOnly”: false,

“syncOnStart”: true,

“enableEndpointCache”: true,

“endpointCacheTimeSeconds”: 900,

“intuneAttributes”: null,

“enableUserGroups”: false,

“userGroupUpdateSchedule”: “*/5 * * * *”,

“bypassProxy”: false,

“enableStats”: true,

“statsUsername”: “whoever”,

“statsPassword”: “********”,

}

Login to https://portal.azure.com. Log in using your Intune Tenant Admin account. We assume here you have already identified and configured at least one of your Intune accounts with Administrator rights.

Once logged in, open “Azure Active Directory” and select “App Registrations”. In “App Registrations”, click on “New registration” menu. Provide a name to identify this application, something like “Aruba ClearPass Intune Integration”. Use all the default values when defining the new application, click on ‘Register’.

After clicking on Register, in the next screen for the application previously created, record the clientId and the tenantdID as highlighted below. Collect these string as they will be required later to complete the Extension configuration.

Next the permissions must be configured for the new application. To the left on the navigation tree, click on ‘API permissions’ followed by ‘Add a Permission’

Next, click on ‘Microsoft Graph > Application permission’, add the permissions listed below. Next click on ‘Intune > Application permission’ add the permissions listed below.

At this stage all of the permission should be added, but show as ‘Not granted for…..’ Click on ‘Grant admin consent for XXX’

Confirm on the request for granting consent for the requested permissions.

Ensure you see a successful confirmation of this process, as the below two screen images indicate.

One final step in this section, create a secret. From the navigation pane on the left side, click on ‘Certificates & secrets’, then under ‘Client secret’ add a ‘New client secret’, provide a descriptive description, choose the expiration and be sure to make a note of the expiration date. Depending on your sensitivity to password rotation and corporate policy, this is ultimately your decision. You can configure a new password at any time, change its duration accordingly as long as you match this to the secret configured in the Extension.

Before you leave this screen record the client-secret shown below as this is also required to complete the configuration of the Intune extension.

Configuring ClearPass Intune Extension to sync endpoint data

It’s important to set the configuration within the Extension to meet your needs. The extension can be configured to sync data in multiple ways as well as be used as a “real-time” authZ to Intune. Not all configuration settings need to be set but some are mandatory. We have divided the parameters into two tables, one for Intune Extension-specific configuration parameters and the other for extension framework configuration parameters that are common across multiple vendor Extensions.

Table 1: Intune Extension-specific configuration parameters

Attribute	Description	Values/Examples
tenantId	Azure Tenant ID for the instance, as previously recorded.	XXXXXXXXX-b3e5-12ab-34cd-ZZZZZZZZZZZ
clientId	The API Client ID configured for the Intune instance, as previously recorded.	123abcde-45fg-67hi-jk89-1234567890a
clientSecret	The Client Secret that corresponds to the clientId, as previously recorded.	XyzYZ123456-aabbccddeeff123-abcfgh12=
syncPageSize	The page size used when puling data from Graph.	50
intuneAttributes {See below for a more detailed explanation of this field}	This setting allows the user to restrict the requested attributes from Intune. The setting requires an array of strings, each string being an attribute to include.	Example:  ["complianceState", "deviceEnrollmentType", "jailBroken"]

Common extension attributes

Extension framework configuration parameters (common configuration)

Attribute	Description	Default Values
logLevel	Logging level for troubleshooting	“INFO”
verifySSLCerts	Should SSL certificates be validated when communicating with external context sources	true
enableEndpointCache	Cache endpoint attributes to optimize authorization queries, avoid repeated DB queries and reduce API calls to external context sources	true
endpointCacheTimeSeconds	The duration in seconds to cache the endpoint attributes	300
syncUpdatedOnly	If this option is set to true, only the endpoints updated after the previous sync would be fetched from the context source. Note that this option only works for the third-party context sources that have APIs to support this functionality. If this option is set to false, all endpoints are fetched at every sync interval.	true
syncAllOnStart	If this option is set to true, when the extension starts, the system will attempt to sync all endpoints in the external context source to ClearPass. Note that if you have a large number device context to be fetched, it would take a long time for the initial sync to complete. When used along with syncUpdatedOnly, the subsequent syncs should be faster.	true
enableSyncAll	Enable periodic sync of all endpoints	true
syncAllSchedule	The schedule for when the Sync All Endpoints process should run. Note: This uses CRON type scheduling.	0 2 * * 6
enableStats	Enable display of extension statistics	false
statsUsername	Create a username to access the extension statistics page	Give any username you want to use
statsPassword	Create a password to access the extension statistics page	Give any password you want to use
bypassProxy	Bypass the web proxy configured on ClearPass Policy Manager	false

Mandatory fields are; tenantId, clientId, clientSecret obtained earlier.

Configuration of syncSchedule is covered in more detail in Appendix D at the end of this documentation, this is used to control the frequency of when the sync process runs. syncUpdatedOnly when set to true, will only ingest changes for managed endpoints. syncOnStart determines if when the extension is started or restarted should it immediately run the sync process, or wait until the syncSchedule job is run.

The two values of enableEndpointCache and cacheTimeInSeconds are specifically used in conjunction with the extension is used as an Authorization source to retrieve real-time data for a known endpoint. If using the Extension in combination as discussed later with a HTTP authZ source which needs to do lookup based on Intune Device ID as following:

• GET /device/info/id/:intuneId

Then these switches will ensure that if the extension is asked to refresh data, it will check the cacheTimeInSeconds to decide if the data current held is fresh or stale.

intuneAttributes is used to filter the returned data back from Intune, this can be used if there are large amounts of tenants or you just want to reduce the number of attributes returned and updated. This setting allows the user to restrict the requested attributes from Intune.

The setting requires an array of strings, each string being an attribute to include.

Example: 

["complianceState", "deviceEnrollmentType", "jailBroken"]

When blank, which is the default value when the extension is initailly installed, it will say null, all attributes from Intune will be returned and added to the endpoint database. If you populate a filter the following fields will always be included, ‘id’, ‘wiFiMacAddress’, ‘deviceName’, ‘model’, ‘osVersion’, ‘operatingSystem’.

The following values are valid optional attributes:

id, userId, deviceName, managedDeviceOwnerType enrolledDateTime, lastSyncDateTime, operatingSystem, complianceState, jailBroken, managementAgent, osVersion, easActivated, easDeviceId, easActivationDateTime, azureADRegistered, deviceEnrollmentType, activationLockBypassCode, emailAddress, azureADDeviceId, deviceRegistrationState, deviceCategoryDisplayName, isSupervised, exchangeLastSuccessfulSyncDateTime, exchangeAccessState, exchangeAccessStateReason, remoteAssistanceSessionUrl, remoteAssistanceSessionErrorDetails, isEncrypted, userPrincipalName, model, manufacturer, imei, complianceGracePeriodExpirationDateTime, serialNumber, phoneNumber, androidSecurityPatchLevel, userDisplayName, configurationManagerClientEnabledFeatures, wiFiMacAddress, deviceHealthAttestationState, subscriberCarrier, meid, totalStorageSpaceInBytes, freeStorageSpaceInBytes, managedDeviceName, partnerReportedThreatState

Leave dataPageSize, verifySSLCerts and logLevel at their default else otherwise advised.

An example of an Intune extension configuration is below. Include appropriate values for your environment based on the information gathered before, select Restart and click on Save Changes to start the extension.

Following the restart, click on “Show Logs”. If contact is made, and access is granted based upon the configuration above with your Intune tenant, you should see something similar to the below.

Configuring ClearPass Policy Manager as an HTTP authZ source

Endpoint Sync Mode

After configuring the syncSchedule and starting the Extension, data should immediately start to appear in the EndpointDb, especially if syncOnStart is set as true, you can see this by filtering data as shown below.

Filter=Attribute equals Source contains Intune

After the initial sync is complete, it’s a simple process of utilizing the data in the EndpointDb inside Role-Mapping/Enforcement-Policy.

HTTP Authorization Mode

To complete the configuration to use the Extension as a ‘real-time’ authorization source, configure an HTTP authorization source within ClearPass. With Intune as an authorization source to the extension, ClearPass can receive the latest data from the Intune platform for previously ingested endpoints, presented under the authZ source. This is more real-time but consideration needs to be made relative to the number of API calls that would be made.

Click on Next. This will advance to the Primary Tab provide the connection details.

The Base URL IP address is what can be seen in figures above.

Set the Base URL as HTTP://IP_of_the_Extension/device/info/id/ and pay special attention to HTTP not HTTPS, and also the addition of “id/” in the path which is required in v6 of Extension.

It’s mandated that a Login Username/Password is entered, but it’s not used, so this can be set to anything.

Click on “Next”. This will advance you to the Attributes Tab where you need to provide the authorization attributes.

Click on “Add More Filters”. Provide a Name for the filter and then a filter query. It’s extremely important that the filter query is defined correctly. This is the query string that is sent to the Intune extension asking for context about the endpoint. The query is indexed off the Intune Device ID in the certificate of the authenticating endpoint. The Device ID can be referenced in the subject alternative name in the certificate (see Appendix E for more details).For completeness, the Filter Query is provided here, copy one of the options carefully corresponding to how the certificate is configured.

%{Certificate:Subject-AltName-URI}

Next build out the definitions of the attributes that will be returned from the Filter Query. These attributes will subsequently be used within our policy-evaluation and ultimately the enforcement policy applied. You can choose whatever attributes you want to be exposed under authZ based upon what you list here. A complete list is available in Appendix A, the first fields in BOLD listed in Appendix A translate to the fields you can enter when configuring the query results, a short example is below.

Once the HTTP authorization source is defined you can use the returned attributes in your policy processing. As an example lets view the returned attributes from the above from an authentication request in access-tracker.

Below can be see the result of a real-time query from Intune based upon the attributes configured in the above authZ source, this data has been returned and is available to the policy at authentication time.

Similarly, For fetching User group information as AuthZ attributes using the Intune extension the Base URL of the authentication source should be set as HTTP://IP_of_the_Extension//realtimeUserGroup/ and the filter query is indexed of the UserPrincipalName from the SAN field of the certificate. For the Device group information the Base URL of the authentication source should be set as HTTP://IP_of_the_Extension/realtimeDeviceGroup/ and the filter is indexed of the AAD_Device_ID from the SAN field of the certificate.

Fetching user group membership:

Fetching device group membership:

Utilizing HTTP Authorization Mode to Retrieve Specific Attributes

The HTTP authorization mode can be leveraged as a general method for retrieving specific attributes from Intune. This comes in handy when we need to overcome a limitation with GraphAPI when syncing with Intune to retrieve device attributes. One such limitation of GraphAPI is it does not support retrieving the Ethernet MAC address attribute (wired interface). In order to address this, we can add Ethernet MAC Address to the HTTP authorization source query and returned attribute as shown below:

This method utilizes real-time lookup by Intune device ID to pull the Ethernet MAC attribute and have it stored in the endpoint DB as shown below:

In the next section we cover options on how to use the results of the returned attributes from Intune in Role-Mapping or in an Enforcement-Policy.

Using data from Intune in a ClearPass Enforcement Policy

Multiple use-cases exist for how the data that is returned from Intune can be used in your policy enforcement. In the example below, we are performing multiple checks:

1. Check the device is a Corporately issued and managed device. If true then update the Palo Alto and Checkpoint corporate firewall with context about this device.

2. Check that the device is managed by Intune and that it’s compliant. In addition to allowing access for these devices, we’re also updating the endpoint with the authentication Date & Time so we can track the device’s access to the network.

3. If the device is not in compliance then we will apply a Quarantine role.

4. If the device is running an OS that is not 13.6 [assume iOS] then we flag it as an old-OS.

5. If the device is running an OS that begins with 13.6 [assume iOS] then we flag it as an approved-OS.

6. If the device is running Android OS then we attach a label of Android.

7. If the device is running Android OS then we attach a label of Apple.

The policy used in the screenshot above is just a reference. Different companies will have different enforcement profiles and policies. The key take away here is that it showcases the use of authorization attributes received from Intune to drive the policy engine into taking different enforcement actions for the device as they authenticate on the network. It is recommended to use these policies within Role-Mapping. Enforcement policies usually will not use an “Evaluate all” rules evaluation algorithm.

Sending updates and triggering actions on Azure enrolled Devices

Starting with the v5 Extension we’ve enabled some new capabilities in respect of how we can interact with the Intune managed devices. The framework adopted for v5 allows ClearPass Policy Manager to update endpoint attributes in Intune and trigger actions against managed devices.

Review this link to see a list of the possible actions; https://docs.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0

This list shows all of the supported actions that can be envoked against an Intune managed device, at this stage based upon request from customer’s we’ve implmented a small subnet of actions to gauge the need from our customers, if there are other actions required, please contact us.

• Trigger a device-sync

• Trigger a device endpoint update {very limited capabilities}

• Trigger a device shutdown

• Trigger a device wipe

• Trigger a device remote lock

From the list of commands above in the link it can be seen that via a Context Server Actions {CSA}, any actions in theory can be sent via the Extension to Intune. Below are some examples of building out the CSA’s for the action’s supported.

Before configuring the CSA, you must configure a basic Context-Server pointing to the Extension IP-Address, pay specific attention to theServer Base URl of http://Extension_IP_address . Note that it is not https, after this configure the individual CSA’s shown below. in our working example 172.17.0.4 is the IP-address of the Intune extension, your IP will likely differ.

Next create the Context-Server-Actions.

Creating the remoteLock Action CSA

Depending on the action, there are several steps to check/configure.

Firstly, ensure the required permission in Azure have been configured. The permission to run the actions is additional to the base permission required to ingest the endpoint data. For example; reviewing the remoteLock actions from the link supplied above shows that a specific GraphAPI permissions is required.

So be sure to add the permissions as necessary as per the above;

It likely after adding the new permission you’ll see a warning messages like below;

Ensure that you “Grant admin consent for XXXXX”, for the permission that was just added.

Once this above step is complete, you’ll see a message indicating success and the permission grant will change as shown below.

Following the configuration of the Context-Server and the configuration in Azure, configure the CSA in ClearPass.

Configure the CSA, chose the Context-Server previously configured {172.17.0.4 in our example}, configure as a POST, set Authentication Method equal to None and set the URL as /device/remoteLock/%{Connection:Client-Mac-Address-Hyphen}

Then the CSA needs to be added to a Enforcement Profile, configure it as the below as a post_authentication session-notification, then this can be added to an existing enforcment-policy rule.

When this is run succesfully in the Extension the following logs can be seen;

[2020-09-01T21:06:36.809] [INFO] Intune - [/device/remoteLock/:mac] request received from ::ffff:172.17.0.1.

[2020-09-01T21:06:37.023] [DEBUG] Intune - Request “GET ‘/endpoint’” took 213 ms.

[2020-09-01T21:06:38.091] [DEBUG] Intune - Request “POST ‘/deviceManagement/managedDevices/94ee89b5-55b0-4635-9f74-1f732dac8497/remoteLock’” took 1.067 Seconds.

[2020-09-01T21:06:38.091] [INFO] Intune - The action “remoteLock” was sent to Intune for device 94ee89b5-55b0-4635-9f74-1f732dac8497.

Creating the deviceShutdown Action {requires Supervised Mode on endpoint}

Configure the CSA as a POST, set Authentication Method equal to None and set the URL as /device/shutDown/%{Connection:Client-Mac-Address-Hyphen}, this CSA can then be attached to a enforcement-profile, which can then ultimatly be added to a service-policy to be triggered under certain matching conditions.

Appendix A – Troubleshooting and Support

Here we list some basic troubleshooting steps. If you need any help beyond this, please reach out to HPE Aruba Support.

Check API Access Application Control restrictions

If you’ve previously hardened your ClearPass deployment with Application Access Controls, it’s possible that the Extension will not work. Reviewing the Extension Log might show something like the following after immediately starting the Extension. This likely indicates the ClearPass Application API’s are in place.

Example of Extension authorization failure due to Policy Manager Application Control:

[2020-03-16T15:42:21.083] [INFO] Intune - Server listening on port 80.

[2020-03-16T15:42:21.243] [DEBUG] Intune - Request “GET ‘https://172.17.0.1/api/server/version’” took 51.91ms.

[2020-03-16T15:42:21.245] [DEBUG] Intune - <!DOCTYPE html><html>

<head>

<title>

Error 403 (Forbidden)

</title>

<script language=“javascript”>

function reloadPage() {

var locHref = window.location.protocol + “//” + window.location.hostname;

window.location.href = locHref;

}

</script>

To resolve this issue, add the IP address of the Extension to the list of nodes permitted to access the API by navigating to Administration > Server Manager > Server Configuration {choose your node} > Network

Checking on the Extension Service

The ClearPass Extensions are supported by a system service which must be running.

Restarting this service will affect all deployed and running extensions.

To check on the state of the Extension Service, or to restart the service, go to Administration > Server Manager > Server Configuration > [SERVER] > Service Control. By default this service is automatically started.

Extensions and web proxy / firewall whitelisting

If ClearPass Policy Manager has been configured with a proxy, it’s still possible that domain whitelists are required, the same for some datacenter firewall to allow the installation of Extensions. Some enterprise customers maintain a whitelist of domain that are allowed to transit the proxy/firewall. The underlying docker configuration process uses standard docker registry access to pull images (hosted in docker hub). In general, the following hosts are used:

This is all also geo dependent to some degree and based on various AWS services, so AWS redirects and geo location services will vary. Finally, this all runs via standard HTTPS (port 443).

Extension Logs/Enable Debugging

If you have a requirement to access and view the logs from the Extension, you can turn on different logging levels from the Extension GUI. Adjust the logLevel to ‘DEBUG’ and restart the extension as shown below.

Logs can then be viewed from the ‘Show Logs’.

Remember after changing the logging level, as with any extension configuration change the extension will need to be restarted for this change to take effect.

Accessing the extension logs using ‘Collect Logs’ system function

In addition to viewing the logs as shown above, logs can also be collected and examined via the Policy Manager Collect Logs system function (Administration > Server Manager > Server Configuration > [Select SERVER] > Collect Logs). This is extremely useful should you have a need to call for technical assistance.

If the support team needs to investigate a system issue, one of the items they regularly ask for is the system logs to aid with their diagnostic investigation. By default the “logLevel” is set to INFO, but TRACE, DEBUG, INFO, WARN, ERROR, FATAL can also be set as required. Any of the levels will display the information for the selected state and lower; if INFO is selected, it will show messages for INFO, WARN, ERROR, FATAL.

After the logs have been collected, downloaded and expanded, you can locate the extension logs in the following location in the folder structure PolicyManagerLogs > extension > your-extension-id as shown below. Note the file-name is the same as the running instance ID of the extension.

Monitoring extension statistics

There is a way to monitor extension’s critical resource statistics with the configurable parameter added as part of the extension’s configuration. To enable extension statistics set the “enableStats” parameter to true. Remember a restart of the extension is need to activate the change anytime the config is modified.

To navigate to statistics page, click Show Details.

This will show statistics similar to the following:

Monitoring authorization performance

Since we are authorizing against an external system, it could be relevant to monitor the performance of these transactions as you setup and deploy. If you suspect there is a performance issue, ClearPass provides a way to monitor the authorization processing time. The graph below shows an example of this data, navigate to Monitoring > Live Monitor > System Monitor [click on ClearPass Tab, then select [Authorization]….

Appendix B – Considerations for Installing in a Cluster

Extensions are not synced between ClearPass cluster members, and thus must be installed on each member separately.

Some Extensions can run in two modes: Periodic Sync Mode and Authorization Source Mode.

Periodic Sync Mode

If you are configuring the extension to poll external system periodically and utilize the resulting ClearPass Endpoint database during endpoint Authorization, then you only need to install the extension on one cluster member, often the publisher.

You may wish to install the extension on a second cluster member as a backup, but remember that both extensions will individually be updating the endpoint database. You may want to stagger the updates between the two extensions, for example, Subscriber1 updates at the top of the hour and Subscriber2 updates at 30 minutes after the hour.

Also, in this mode there is no need to explicitly enter an IP address during installation. The defaults will suffice and ClearPass will select an IP in the range specified in the server configuration.

HTTP Authorization Source Mode

In this mode we configure an HTTP Auth source that results in a HTTPS call to external system during endpoint authorization. In this deployment model the extension must be installed on every cluster node that process authentications. Also in this scenario every cluster member’s extension must be set to the exact same IP address during installation time, as the HTTP Auth source configuration is propagated globally across all cluster members.

For example, if the extension IP range is 172.17.0.0/16, we would set the extension to 172.17.0.5 on every cluster member during installation of the extension.

While we normally want to avoid duplicate IP addresses in a network, this is not a concern with ClearPass extensions. Each ClearPass node communicates internally only with its own extension, and this traffic is not routed outside of ClearPass.

Subscriber nodes support the same ability as publishers to install an Extension from the Extension store.

Appendix C – endpoint sync schedule settings

The syncSchedule and similar scheduling parameters sets how often ClearPass executes certain actions like syncing or pushing endpoints. This setting is based on a slightly modified version of the CRON job scheduler found in Unix-like operating systems. It can be used to schedule jobs to run periodically at fixed times, dates or intervals.

A ‘cron’ is a job scheduler. Any scheduled task is called a ‘cron job’. The syntax for a cron job schedule is as follows:

In our use of the cron scheduler, we’ve dropped the use of the last instruction ≤command to execute> and use only the time/date functions, see below for a number of examples of scheduling a sync process.

• Schedule a sync to run at 2am daily:- 0 2 * * *

• Schedule a sync to run twice a day at 5am and 5pm:- 0 5,17 * * *

• Schedule a sync to run on every Sunday at 5pm:- 0 17 * * sun

• Schedule a sync to run every 30 minutes:- */30 * * * *

• Schedule a sync to run at 5pm on selected days:- 0 17 * * sun,fri

You can see from the above that the scheduling process is extremely flexible, alternatively https://crontab.guru/ is a great page for learning more about CRON scheduling.

Appendix D – List of all available Intune Attributes

“Source”:“Intune”,

“Intune Last Updated”:“2020-08-24 22:51:00”,

“Intune ID”:“04bbcce0-07bb-4c88-a3bb-c88a123abcb0c”,

“Intune User ID”:“abaf94ff-b6b3-1a2b-5e6f-19581de12345”,

“Intune Device Name”:“Danny’s iPhone”,

“Intune Managed Device Owner Type”:“personal”,

“Intune Enrolled Date Time”:“2019-02-06T21:33:29.6217769Z”,

“Intune Last Sync Date Time”:“2019-07-20T21:38:23.0716346Z”,

“Intune Operating System”:“iOS”,

“Intune Compliance State”:“noncompliant”,

“Intune Jail Broken”:“False”,

“Intune Management Agent”:“mdm”,

“Intune OS Version”:“12.3.1”,

“Intune Eas Activated”:true,

“Intune Eas Device ID”:“12345445XXX0B396FFF642NOG3C”,

“Intune Eas Activation Date Time”:“2019-02-06T21:34:08.5872874Z”,

“Intune Azure AD Registered”:true,

“Intune Device Enrollment Type”:“userEnrollment”,

“Intune Azure AD Device Id”:“7a80afd3-aabb-1234-9acf-83f987654321”,

“Intune Device Registration State”:“registered”,

“Intune Device Category Display Name”:"",

“Intune Is Supervised”:false,

“Intune Exchange Last Successful Sync Date Time”:“0001-01-01T00:00:00Z”,

“Intune Exchange Access State”:“none”,

“Intune Exchange Access State Reason”:“none”,

“Intune Remote Assistance Session Url”:"",

“Intune Remote Assistance Session Error Details”:"",

“Intune Is Encrypted":true,

“Intune User Principal Name”:“dannyjump@clearpassyeahbaby.onmicrosoft.com”,

“Intune Model”:“iPhone X”,

“Intune Manufacturer”:“Apple”,

“Intune IMEI”:“351234567890154321”,

“Intune Compliance Grace Period Expiration Date Time”:“2020-05-10T11:15:10.1451Z”,

“Intune Serial Number”:“G6TWXXYXYZXYZXYZ”,

“Intune Phone Number”:"+*******9748”,

“Intune User Display Name”:“Danny Jump”,

“Intune Wi Fi MAC Address”:“a056f38cc6be”,

“Intune Subscriber Carrier”:“AT&T”,

“Intune MEID”:"",

“Intune Total Storage Space in Bytes":251419164672,

“Intune Free Storage Space in Bytes":211984318464,

“Intune Managed Device Name”:“dannyjump_IPhone_2/6/2019_9:33 PM”,

“Intune Partner Reported Threat State”:“unknown”

Appendix E – SCEP Certificate Configuration Profile

This appendix provides an example of how to create a SCEP certificate configuration profile for a specific device type, such as Windows, in Intune. Configuration profiles for other device types are done in a similar fashion. For reference, Microsoft provides the following useful guides:

Create and assign SCEP certificate profiles in Intune

https://docs.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep

Configure and use PKCS certificates with Intune

https://docs.microsoft.com/en-us/mem/intune/protect/certificates-pfx-configure

Windows Device Configuration Profile

The first step is to create a “Trusted certificate” configuration profile for Windows devices with the following properties:

Upload certificate file from your own implemented CA (e.g. AD CS).

The next step is to create a “SCEP certificate” configuration profile for Windows devices with the following properties:

The configurations settings for this profile are as follows:

It is important to reference the Device ID in the Subject alternative name.

The Root certificate refers back to the “Trusted certificate” profile done in the first step.

When the endpoint authenticates with ClearPass, the Access Tracker details can be inspected to ensure that the Device ID is present in the SAN URI attribute of the certificate as shown below:

If a real-time query is being implemented via HTTP authorization source, make sure to reference the Subject alternative name URI attribute in the filter query as shown in Figure 27.

Appendix F – Permissions needed for the Entra ID Application

The complete list of permissions required by the Entra Application for Intune integration is listed below:

GroupMember.Read.All

Directory.Read.All

User.Read.All

Device.Read.All

DeviceManagementManagedDevices.ReadWrite.All (Post Auth)

DeviceManagementManagedDevices.PrivilegedOperations.All (Post Auth)

DeviceManagementManagedDevices.Read.All

Use Case	Usage	Permission	URL
getIntuneGroups	config.enableUserGroups GET '/groupsByMac/:mac' GET '/groupsByUserId/:userId'	GroupMember.Read.All	https://learn.microsoft.com/en-us/graph/api/group-list?view=graph-rest-1.0&tabs=http
getIntuneGroupMembers	config.enableUserGroups GET '/groupsByMac/:mac' GET '/groupsByUserId/:userId'	GroupMember.Read.All	https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http
getIntuneUserGroups	GET '/realtimeGroupsByUserId/:userId' GET '/realtimeGroupsByMac/:mac' GET '/realtimeUserGroup/:macOrSanUri'	Directory.Read.All	https://learn.microsoft.com/en-us/graph/api/user-list-memberof?view=graph-rest-1.0&tabs=http
getIntuneUserTransitiveGroups	GET '/realtimeTransitiveGroupsByUserId/:userIdOrSanUri'	User.Read.All	https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0&tabs=http
getIntuneDeviceGroups	GET /realtimeGroupsById/:id	Device.Read.All	https://learn.microsoft.com/en-us/graph/api/device-list-memberof?view=graph-rest-1.0&tabs=http
getIntuneDeviceGroupsByDeviceId	GET '/realtimeDeviceGroup/:sanUri' GET '/realtimeGroupsByDeviceId/:deviceId'	Device.Read.All	https://learn.microsoft.com/en-us/graph/api/device-list-memberof?view=graph-rest-1.0&tabs=http
getIntuneDeviceTransitiveGroups	GET '/realtimeTransitiveGroupsById/:id'	Device.Read.All	https://learn.microsoft.com/en-us/graph/api/device-list-transitivememberof?view=graph-rest-1.0&tabs=http
getIntuneDeviceTransitiveGroupsByDeviceId	GET '/realtimeTransitiveGroupsByDeviceId/:deviceId' GET '/realtimeTransitiveDeviceGroup/:sanUri'	Device.Read.All	https://learn.microsoft.com/en-us/graph/api/device-list-transitivememberof?view=graph-rest-1.0&tabs=http
sendIntuneAction action	POST '/device/sync/:macOrSanUri' POST '/device/shutDown/:macOrSanUri' POST '/device/wipe/:macOrSanUri' POST '/device/remoteLock/:macOrSanUri'	DeviceManagementManagedDevices.ReadWrite.All DeviceManagementManagedDevices.PrivilegedOperations.All	https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-get?view=graph-rest-1.0&tabs=http
sendIntuneAction update	POST '/device/update/:macOrSanUri'	DeviceManagementManagedDevices.ReadWrite.All	https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-update?view=graph-rest-1.0&tabs=http
getIntuneDeviceById	GET '/realtimeTransitiveDeviceGroup/:sanUri' GET '/realtimeDeviceGroup/:sanUri' GET '/device/info/:mac' GET '/device/info/id/:managedDeviceIdOrSanUri'	DeviceManagementManagedDevices.Read.All	https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-get?view=graph-rest-1.0&tabs=http
getIntuneDeviceByAzureId	GET '/device/info/:mac' GET '/device/info/id/:managedDeviceIdOrSanUri'	DeviceManagementManagedDevices.Read.All	https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0
getIntuneDeviceList	config.enableSyncAll GET '/realtimeManagedDevices'	DeviceManagementManagedDevices.Read.All	https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0
getIntuneDeviceList2	GET '/realtimeDevices'	Device.Read.All	https://learn.microsoft.com/en-us/graph/api/device-list?view=graph-rest-1.0&tabs=http