44 minute read
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.
Support for HTTP caching for User and Device Group queries
In this release, support for HTTP caching is added for User and Device group queries to the Intune extension. ClearPass policies that use Intune extension as the authorization source for real time User and Device group queries can now be cached with a configurable TTL cache timeout. This avoids frequent HTTP real-time calls from the Intune extension to the Entra ID tenant for User and Device group queries improving the performace of the overall integration components.
The following configuration knobs are added to the extension which are hidden by default. Adding these knobs with the below settings on the extension configuration will enable the HTTP caching for User and Device group real time queries.
“httpCacheTtlInSeconds”: 30, - HTTP Cache TLL in seconds defines the cache timeout. E.g 30 seconds
“httpCacheMaxEntries”: 100, - HTTP Cache Max Entries should not exceed 100 for optimal performance.
Sample Configuration:
{
“logLevel”: “INFO”,
“verifySSLCerts”: true,
“httpCacheTtlInSeconds”: 30,
“httpCacheMaxEntries”: 100,
“azureADEndpoint”: “login.microsoftonline.com”,
“graphEndpoint”: “graph.microsoft.com”,
“tenantId”: “xxxxxxxx”,
“clientId”: “xxxxxxxx”,
“clientSecret”: “xxxxxxxx”,
“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”: “********”,
}
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.
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
INFO
The following are only recommendations and not mandatory settings. They also only apply to environments that need device or user group lookups using Intune extension. With ClearPass release 6.12 Device group lookups against Entra ID is also supported natively along with 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
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.
INFO
Supported special characters in the KEY variable names are “_” and “-”. KEYS can be set in any case as required but it is strongly recommended to use the same variable names that Intune supports in the SCEP profile. Supported variables can be found in the following Microsoft Intune documentation https://learn.microsoft.com/en-us/intune/intune-service/protect/certificates-profile-scep#create-a-scep-certificate-profile
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.
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.
INFO
The following are recent changes done by Google that impact Android devices in Intune: (1) Removal of serial number, IMEI, and MEID on personally-owned work profile devices [running Android 12] and (2) Removal of Wi-Fi MAC address on newly-enrolled device administrator and personally-owned work profile devices [running Android 9 and above]. For more information, see the Android Day Zero Support with Microsoft Endpoint Manager blog post.
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
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.
INFO
As/If you move to this v5 you must carefully consider the adjustments that may be need in your work flow and configuration and how you use the Intune data ingested into the endpointDb repo.
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.
Enabling Intune NAC API to ingest endpoint ownership such as it can be used in Policy within ClearPass
INFO
Intune v2 was never released publicly
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.
The minimum software version required for CPPM is 6.11.0 . At the time of writing, version 6.11.10 is available as the long supported release and 6.12.4 is 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.
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://arubanetworking.hpe.com/techdocs/ClearPass/6.11/Installation-Guide/Default.htm
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 HPE Aruba Networking 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.
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.
INFO
Internet access is required for ClearPass Policy Manager to install the ClearPass Extensions from the Extension Store. Starting with ClearPass 6.12, extensions can be can be installed offline as well. Offline ClearPass Extension images are available on HPE networking support portal.
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.
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.
INFO
Here we are using Intune as an example. The installation steps are the same for all the extensions. For your deployment, please search for the appropriate extension like Jamf, Mosyle, Crowdstrike, etc.
All currently available extensions are listed in the page: https://www.arubanetworks.com/techdocs/NAC/clearpass/integrations/clearpass-extension/extensions-list/
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.
INFO
Password and sensitive configuration items are obfuscated when presented in both the Extension GUI or in the Explorer configuration.
WARNING
The configuration attributes are case sensitive. It is recommended to refer the default configuration sample while editing your configuration.
Extensions support communications with 3rd 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.
INFO
Note that the Policy Manger web proxy configuration is ONLY read by the extension at installation time. If the web proxy configuration is changed in Policy Manager, then the extension must be re-installed so the new settings are re-read and bonded to the extension.
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].
INFO
The subnet defined here for the extension framework must fall within the following subnet range 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 as defined by RFC1918. For best results, set the network address range to a subnet that does not exist in your enterprise, and restart the extension service for this change to take effect.
Never set the DATA or MGMT IP address to use an address that matches the Extension Network
INFO
Note that changing the extension base IP address will require the extension service to be restarted.
The extension can be configured for two different modes of operation.
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.
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.
There are primarily 4 steps involved in getting this Integration configured.
Configuring and Collecting Information from Microsoft to Configure Intune extension
Installation and Configuration of the Intune Extension
Configuring ClearPass Intune Extension to sync endpoint data from Intune to the EndpointDb
Configuring ClearPass Policy Manager to use already ingest endpoint context from Intune or configure an Authorization source for real-time updates.
INFO
Below we cover the process of adding a ‘ClearPass App’ into Azure as an application and enabling the necessary application level permissions. Think of this as the gateway between ClearPass and Microsoft Intune.
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 “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.
TIP
Check Appendix F for details about permissions required for the application. We have a detailed breakdown of permissions needed for each use case. Only enable the appropriate permissions as required by your setup.
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.
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:
|
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:
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
INFO
Note: If something is incorrect or a field that Intune doesn’t like to limit, it will cause errors. If this happens check or remove the configured values. A sample of this error is, “Parsing OData Select and Expand failed: Could not find a property named ‘XXXXX’ on type ‘microsoft.graph.managedDevice’.”
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.
INFO
IP address assigned to the extension is “172.17.0.4”. This will be used when configuring Intune as an HTTP Authorization source within ClearPass Policy Manager. It’s likely the IP address of your Extension will differ.
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.
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:
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:
INFO
It is important that “enableEndpointCache” is set to true in the Extension configuration.
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.
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:
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.
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.
If the device is not in compliance then we will apply a Quarantine role.
If the device is running an OS that is not 13.6 [assume iOS] then we flag it as an old-OS.
If the device is running an OS that begins with 13.6 [assume iOS] then we flag it as an approved-OS.
If the device is running Android OS then we attach a label of Android.
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.
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.
TIP
Check Appendix F for details about permissions required for the application. We have a detailed breakdown of permissions needed for each use case. Only enable the appropriate permissions as required by your setup.
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.
INFO
Based on customer feedback, if the NAD device deployed is not sending the framed IP address in the accounting packets, the “Post_Authentication Type” based enforcement profile does not get triggered/applied for the endpoint. A workaround for this to remove the dependency on the framed IP address in accounting is to use “HTTP Type” based enforcement profile instead to trigger the post authentication.
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.
Here we list some basic troubleshooting steps. If you need any help beyond this, please reach out to HPE Aruba Networking Support.
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
INFO
For this reason its good practice to fix the IP address of the extension at installation time such that it doesn’t change over time and break the application controls.
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.
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:
INFO
extensions.clearpassbeta.com
registry-1.docker.io
index.docker.io
auth.docker.io
production.cloudflare.docker.com
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).
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.
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.
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:
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]….
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.
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.
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.
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.
Extensions are a critical part of ClearPass deployments today and with the increased dependency on extension interactions that involve periodic polling or real-time lookups, here are some of the best practice recommendations around optimizing overall performance when using extensions:
If the extension is used to periodically poll external systems and populate endpoint repository, ensure that it is not installed in all the nodes in the cluster. Ideally these type of extensions should only be installed on the publisher node since only publisher node can add endpoint entries to the database. For redundancy, it can be installed on another additional node but it is recommended to stagger the polling interval so that both do not attempt to poll and update endpoint database at the same time.
Example: 0 * * * *, This cron job runs at minute 0 of every hour (e.g., 00:00, 01:00, 02:00, etc.).
30 * * * *, This cron job runs at minute 30 of every hour (e.g., 00:30, 01:30, 02:30, etc.).
If the extension is used for looking up attributes from external systems in real time during authentication, it should be installed in all the nodes handling authentication. Note that the context server config is replicated from the publisher. When using extension for real time lookup, ensure that the extension has the same IP address in all the cluster nodes.
If the extension is expected to do both real-time lookup and periodic polling, ensure that polling is enabled only on the publisher while the extension in subscribers can have the polling disabled by setting the “enableSyncAll” attribute to false.
"enableSyncAll": false,
WARNING
Having the extension installed on all the cluster nodes with enableSyncAll set to true would cause each cluster node to independently poll the external system and update endpoint repository. This could impact the performance of ClearPass. Hence it is strongly recommended to enable endpoint sync only on the extension installed on the publisher and on another cluster node for redundancy.
Some 3rd party systems support fetching delta updates vs fetching all of the device information every polling cycle. The extensions that support fetching delta updates are: Workspace ONE Crowdstrike Falcon Microsoft Intune Mosyle SentinelOne Service Now
For these extensions, the syncUpdatedOnly attribute should be set to true in extension config so that the number of DB updates in ClearPass is minimized
"syncUpdatedOnly": true,
For extensions that do not support syncUpdatedOnly, ensure that the sync interval is not aggressive. We recommend syncing at most twice a day and that too during off peak hours whenever a full sync is performed.
Some 3rd party systems can be very noisy in terms of attribute updates. There could be certain attributes that keep changing every sync interval like “Free Memory in Bytes”, “Last Check in Time” etc. There is no value in updating endpoints when such trivial attributes change for the device. Hence it is recommended to use “ignoreEndpointDifferences” attribute in extension configuration to ignore change in attributes that you do not care about in terms of ClearPass policies.
You can review the Audit Viewer in ClearPass under Monitoring > Audit Viewer to see what attributes are being updated for endpoints to check if there are unnecessary updates.
Sample for JAMF extension:
"ignoreEndpointDifferences": "Last Update, Report Date UTC, Last Contact Time UTC, Last Inventory Update UTC, Last Reported IP, IP Address",
Default for Microsoft Intune extension:
"ignoreEndpointDifferences": "Last Sync Date Time, Free Storage Space in Bytes",
To further optimize the number of endpoints being updated in ClearPass, you can specify which attributes are being used in the ClearPass policies so that only changes to those attributes would trigger an update to the endpoint. This is done by listing out the specific attributes under endpointAttributes in extension configuration.
Sample for JAMF extension:
"endpointAttributes": "Group names, MDM Enabled, Managed, Remote Managed, Supervised, Serial Number",
Setup extension to restart unless it was intentionally stopped. A restart policy can be defined in extension configuration to ensure that the extension starts up automatically after server reboots and such. Restart policy of “unless-stopped” would ensure the extension always starts up unless it was manually stopped.
“restartPolicy”: “no” — The extension will not be automatically restarted after the server is restarted.
“restartPolicy”: “always” — The extension will always be restarted after the server is restarted.
“restartPolicy”: “unless-stopped” — The extension will be restarted unless it was stopped prior to the server restart, in which case it will maintain that state.
“restartPolicy”: “on-failure:N” — If the extension fails to restart, the value for “N” specifies the number of times the extension should try to restart. If you do not provide a value for “N”, the default value will be “0”.
The “restartPolicy” parameter is not present by default in extension configurations. When it is not present, if the system is restarted a default policy is applied to the extension to maintain the state it was in before the restart. If the “restartPolicy” parameter is added to the configuration but later removed, the extension will then revert to the default restart policy.
“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”
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.
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
INFO
Note that depending upon your use case and workflows, you might only need a subset of these permissions. The table listed below breaks down the permissions required by different use cases. Please enable only the ones required in your setup.
| Use Case | Usage | Permission | URL |
|---|---|---|---|
| Fetch Intune user group membership | 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 |
| Real time call to fetch Intune user group membership | 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 |
| Real time call to fetch Intune user transitive group membership | GET '/realtimeTransitiveGroupsByUserId/:userIdOrSanUri' | User.Read.All | https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0&tabs=http |
| Real time call to fetch Intune user group membership | GET /realtimeGroupsById/:id | Device.Read.All | https://learn.microsoft.com/en-us/graph/api/device-list-memberof?view=graph-rest-1.0&tabs=http |
| Real time call to fetch Intune device group membership | 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 |
| Real time call to fetch Intune device transitive group membership | GET '/realtimeTransitiveGroupsById/:id' | Device.Read.All | https://learn.microsoft.com/en-us/graph/api/device-list-transitivememberof?view=graph-rest-1.0&tabs=http |
| Real time call to fetch Intune device transitive group membership | 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 |
| Trigger action from ClearPass to Intune | 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 |
| Trigger action from ClearPass to Intune | 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 |
| Fetch information about a specific device from Intune | 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 |
| Fetch information about a specific device from Intune using Entra Device ID | 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 |
| Fetch list of devices periodically | config.enableSyncAll GET '/realtimeManagedDevices' |
DeviceManagementManagedDevices.Read.All | https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0 |
| Fetch list of devices periodically | GET '/realtimeDevices' | Device.Read.All | https://learn.microsoft.com/en-us/graph/api/device-list?view=graph-rest-1.0&tabs=http |
The Intune-SCEP Extension for Onboard Enrollment enables seamless certificate provisioning for devices managed by Microsoft Intune by integrating ClearPass Onboard as the SCEP server and certificate authority (CA).
Feedback
Was this page helpful?
Glad to hear it!
Sorry to hear that.