Ivanti MDM (formerly MobileIron)

  32 minute read  

Introduction

MobileIron Cloud is now branded as Ivanti Neurons for MDM and MobileIron Core is branded as Ivanti Endpoint Manager Mobile. ClearPass uses a single extension for both cloud and core platforms and hence the extension is named Ivanti MDM (formerly MobileIron On-Prem & Cloud).

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 v4 Extension? – Important Changes

Version 4.0 is the new publicly available version, and it will have the following additional functionality:

• Ivanti MDM extension v4 supports lookup based on Device Identifier or Device GUID, 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.

• Ivanti MDM extension v4 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 Device Identifier or Device GUID in the subject alternative name (SAN) of your certificate profiles. Please refer to Onboard Certificate Enrollment for more details on SCEP certificate profile configuration.

• Ivanti MDM extension v4 is built on a revamped underlying Extension framework which aims to standardize common configuration parameters across multiple extensions.

• Extension v4 also has updates to branding from MobileIron to IvantiMDM. The default endpoint attribute prefix will also be “IvantiMDM” starting with extension v4. Existing deployments moving from v1 to v4, please follow the guidance given under attributePrefix extension configuration if you wish to continue using MobileIron as attribute prefix.

What’s new in v1 Extension? – Important Changes

Version 1.0 of the extension provides two key features.

• Added support for MobileIron Cloud. MobileIron Cloud has not been previously supported, this extension adds support for Cloud version R50 and above.

• Support for Common Platform Services Event Notifications. This provides for a near-real-time notification feed as discussed below, to allow ClearPass to maintain an up-to-date view of the managed devices, without the need to constantly poll. This is supported in MobileIron Cloud starting in R50 and in MobileIron Core starting in 9.5.

Note that ClearPass has supported MobileIron Core for several years, our support for this does not change. This Extension however can complement an existing MobileIron Core deployment or it can possibly replace it if the version of Core in 9.5 or greater and thus supports the Common Platform Services.

API Product	MI API’s supported	Native ClearPass Polling	Native ClearPass Polling + Extension CPS API [Hybrid deployment]	MobileIron Extension CPS API
Pre-Core 9.5	V1	Yes	Yes*	No
Core 9.5 +	V1 + CPS	Yes	Yes	Yes
Cloud R50 +	CPS	No	No	Yes

As discussed, the Extension has the ability to ingest endpoint attributes (Core 9.5+ & Cloud R50+) and to receive a near real-time [typically circ. 5 seconds] feed of changes within the customer’s MobileIron tenant. There are five use-cases where ClearPass receives a real-time event notification.

1. A New Device Added

2. A Device Retired/Deleted

3. A Device changes state to “out of Compliance”

4. A Device changes state to “in Compliance”

5. A Device is Wiped

When one of the above events occurs, MobileIron places an event notification in a messages queue, all ClearPass nodes that are subscribed for that event, would then receive that message, afterwards, that message is purged from the system.

If no active ClearPass nodes are available to consume the message, the message is published to the messaging server, the message would be retained in the system for a maximum duration of 3 hours before it either gets consumed by a re-connecting ClearPass node or gets deleted out of the system.

In comparison, the legacy approach [still available] is to poll the tenant every hour and ingest all of the endpoint data, then update the delta changes into the EndpointDB. The obvious issue with the legacy approach is that if a device goes out of compliance, ClearPass won’t know of the state change until the next poll. Similarly, if a new device is added, typically the access-policy is that when a SmartDevice accesses the network, ClearPass checks to ensure it’s a known managed device. In the legacy approach access would be denied until the next poll had completed. Utilizing the full polling capabilities in conjunction with the event notifications allows a near real-time local view of all of the managed Endpoints.

Below, we cover installation and configuration of the extension, configuration within MobileIron, and finally ClearPass configuration. Additionally, we document a solution which allows a device to be ‘tagged’ as in or out of compliance. This creates an event notification and allows for testing of the end-to-end workflow.

Software Requirements

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.

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://arubanetworking.hpe.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 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.

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].

After the extension has been installed, proceed to configure Ivanti MDM and ClearPass.

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

Configuring the Ivanti MDM Extension

It is 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” authorization to Ivanti MDM. As shown on the previous page there are several parameters required to configure this version. Not all switch settings need to be set but some are mandatory. We have divided the parameters into two tables, one for Ivanti MDM Extension-specific configuration parameters and the other for Extension framework configuration parameters that are common across multiple vendor Extensions.

Ivanti MDM specific extension configuration attributes

Attribute	Description	Values/Examples
ivantiMDMUrl	URL to access the cloud / core Ivanti MDM instance	https://XXXXX.mobileiron.com
ivantiMDMUserName	Username used to make API calls against Ivanti MDM	cppm-api@XXXX.com
ivantiMDMPassword	Password corresponding to the API username	XXXXXXXXXXX
syncPageSize	The page size used when puling data from Ivanti MDM	50
enableMqtt	This setting enables processing of MQTT messages from Ivanti MDM	true
mqttUrl	URL from which Ivanti MDM would send MQTT updates (Common Platform Services Notification)	ssl://queue-XXXXX.mobileiron.com:8883
mqttUserName	Username which has Common Platform Services Notification enabled	cppm-api@XXXX.com
mqttPassword	Password corresponding to mqttUserName	XXXXXXXXXXX
toggleEndpointStatus	If a device is Wiped or Retired, toggle the endpoint status from "Known" to "Unknown"	true

Mandatory fields are: ivantiMDMUrl, ivantiMDMUserName, ivantiMDMPassword

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

Configuration of syncAllSchedule is covered in more detail in Appendix C 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. syncAllOnStart determines if when the extension is started or restarted should it immediately run the sync process or wait until the syncAllSchedule job is run.

The two values of enableEndpointCache and endpointCacheTimeSeconds 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 authorization source which needs to do lookup based on Ivanti MDM Device ID / GUID as following:

• GET /?identifier=:identifier

• GET /?identifier=:deviceGuid&identifierType=GUID

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

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

An example of an Ivanti MDM 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.

The configuration item “attributePrefix” controls the prefix that is added to the endpoint attributes fetched from Ivanti MDM and subsequently used in policy conditions. If you already have MobileIron v1 and is looking to update to latest version of the extension, you can configure attributePrefix as “MobileIron” so that extension will continue to use the same prefix as before. If this is a new deployment or if you wish to switch to new attribute prefix, you can leave the attributePrefix empty as shown below so that ClearPass will use “Ivanti MDM” as prefix for endpoint attribute names.

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

Ivanti MDM Configuration – Common Platform Services [CPS]

Below we cover the configuration required in the Ivanti MDM environment. To aid the configuration of the extension it helps to collect several items from the Ivanti MDM tenant. Within the configuration, there are two username/password combinations required. They are covered below.

Account Creation

Ivanti MDM-Tenant-Credentials: The first pair [ivantiMDMUserName/ivantiMDMPassword] is used by the extension to communicate with the Ivanti MDM instance for calling API’s that allow the extension to retrieve all the endpoint data that is then populated into the ClearPass EndpointDB. For the Ivanti MDM-
Tenant-Credentials, it is suggested that an account be created in Ivanti MDM dedicated for this function. These credentials can be an Administrator account, but it’s recommended that a new account with the “Device Registration” role be used. To create the account. Users -> +Add

Then select the API User and enter username and password to create the user.

Once the user account has been created, select it to view details and ensure the user has ‘Device Registration’ role assigned.

Ivanti MDM-MQTT-Credentials: The second pair [mqttUserName/mqttPassword] is used by the extension to communicate with the Ivanti MDM Common Platform Services. This service sends the real-time-notifications. It is possible to use the same account as above or a separate account. If using the same account, ensure that the Common Platform Services role has been added to the user account. In the Roles tab, click on Actions -> Assign Roles

Next add the role to the user. Note, to add the role Common Platform Services scroll down as highlighted below to locate the role. Select the role, and Next.

Click Done to complete adding the role

Enabling CPS framework

Following the creation of the accounts If the near-real-time event notification is to be used, then there are additional configuration steps required. To configure and enable the CPS Event Notifications follow the below steps. Navigate to the Admin > System > Common Platform Services Notification. Click on Common Platform Services Notification toggle button and enable the service.

If the CPS role has not been added to an existing user, then create a new CPS user and assign CPS role to this new user.

Manually triggering an event

Here are specific instructions showing an example of how use custom attributes and compliance policy to force devices in and out of non-compliant state: This section allows for the creation of an event to test the end-to-end workflow of the system.

A good use case would be to toggle a value of a custom attribute (say, nacCompliant) for devices which have moved out of compliance from true to false and then, use the attribute to take actions on the device. There are multiple ways to force compliance actions on the device to render it non-compliant. Please refer the below steps:

1: Create a compliance action policy: Navigate to Policies on the admin portal menu bar and click on Add

2: Add policy rule/definition to determine the criteria for a device going non-compliant: Click on “Custom Policy” option to create a custom compliance action policy.

Choose a custom policy rule: Enter a policy name and create a criteria query to specify policy rule, E.g. If the device ownership is ‘User Owned’ or the device OS is type ‘Android’ mark it as non-compliant and click Next.

3: Distribute the policy to all devices and click Done

4: Perform state changes on the device to match the criteria, this would mark the device non-compliant, in which case, device_not_compliant events would be triggered e.g., Changing device ownership to ‘User Owned’ and initiate force check-in and device sync.

Change an endpoint attribute to trigger an event notification – part1

Some sample policy rules affecting large enclosure of devices at once might not be recommended.

• OS is iOS

• Last check-in is 10 hrs. ago

• Ownership Type is ‘User Owned’

5: To bring the device back to compliance, either perform reverse device state changes or delete the compliance action policy and initiate force-sync on devices.

ClearPass Policy Manager Configuration

The final part is the configuration on ClearPass Policy Manager. Depending on how you use the integration will ultimately define how you configure the interaction between Ivanti MDM and the ClearPass Extension and Policy Manager.

If you plan on using the extension to interface with Ivanti MDM, then configure the extension and its associated polling. Following this, configuring ClearPass Policy Manager configuration is no different in how you would authenticate and authorize any other device, it’s really about how you use the endpoint database attributes in your authorization policy checks.

If you plan on using the extension to complement the existing Ivanti MDM Endpoint Context Server polling, then overall this is a hybrid deployment. Using the built-in polling to ingest the endpoint details once per day in addition to using the extension to ‘trickle-feed’ changes into the endpoint-database as they happen. This hybrid deployment can remove the need for the lengthy polling; however, we still recommend a poll be run once per day.

When mac randomization is enabled, MAC address based lookups cannot be done against endpoint database. Android OS also stopped sharing MAC Address with MDM solutions like Ivanti MDM. Hence there is a need to fetch device attributes based on a unique identifier other than MAC Address. Ivanti MDM extension v4 has the ability to lookup device information based on either Device Identifier or Device GUID. This is a real time lookup by using the unique device identifier embedded within device certificate. Within the certificate, the identifier can be embedded either as CN or as one of the Subject Alt Name fields like Subject-AltName-URI.

Regardless of which deployment you configure, as noted above the power of the integration is how you use the endpoint data base attributes. Here are a few simple examples.

To add, a little more clarity, if a device is retired from within Ivanti MDM then the endpoint status flag is set accordingly. Within your enforcement policy you need to add a rule {#1} as shown above, where, when the status of the endpoint is set as RETIRED, the enforcement action would be to Deny Access. This can be adjusted to fit your own needs, as an example if you detected a device trying to access the network which has been deleted/retired from the system, you may want to have a workflow that drops the device into a captive portal role which directs the user to contact the helpdesk for assistance.

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 Ivanti MDM as an authorization source to the extension, ClearPass can receive the latest data from the Ivanti MDM platform for devices based on Device Identifier or Device GUID. 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.

Set the Base URL as http://ip_of_the_extension/ and pay special attention to HTTP not HTTPS, and also the addition of “/” in the path. It is mandated that a Login Username/Password is entered, but it is 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 Ivanti MDM extension asking for context about the endpoint. The query is indexed off either the Device Identifier or the GUID in the certificate of the authenticating endpoint. For completeness, the Filter Queries are provided here. Depending upon the type of lookup you want to do, select the appropriate filter and copy it carefully.

Device Identifier lookup	%{Certificate:Subject-CN}
Device GUID lookup	%{Certificate:Subject-CN}?identifierType=GUID

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 authorization 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 Ivanti MDM based upon the attributes configured in the authorization source above, this data has been returned and is available to the policy at authentication time.

Onboard Certificate Enrollment

Managed devices should also be configured to authenticate securely to the network. EAP-TLS is considered the most secure authentication method available due to mutual authentication using digital certificates. Ivanti MDM configuration profiles help setup fully automated enrollment workflows. ClearPass Onboard CA can be used as certificate issuing authority with provisioning done using Simple Certificate Enrollment Protocol (SCEP). The steps below show how to setup SCEP enrollment against Onboard CA. Note that Onboard CA can be setup either as root or intermediate.

First, we need to enable SCEP enrollment for ClearPass Onboard CA. Navigate to ClearPass Onboard > Certificate Authorities > Click on the CA you want to enable SCEP for > Edit > Check the box to enable SCEP server as shown below.

Select SCEP secret as validation method and add a SCEP shared secret.

After saving the changes, click on the CA again > Trust Chain > Download Bundle to download as a .pem file. We will be uploading this certificate to the SCEP profile in Ivanti MDM later.

On Ivanti MDM, navigate to Configurations and add a new profile:

Search for certificate and select “Identity Certificate” profile:

Configure SCEP profile as shown below:

Once the SCEP profile is setup, you can create a WiFi profile to use the client certificate for EAP-TLS authentication

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 Networking 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 – Extension performance optimizations

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,
  

• 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.

Appendix E – List of all available Ivanti MDM Attributes

Ivanti MDM OS: OSX

Ivanti MDM UDID: DD1A8DDE-DDD2-5041-AC94-6655A6459D98

Ivanti MDM Model: MacBookAir6,2

Ivanti MDM Status: ACTIVE

Ivanti MDM Blocked: true

Ivanti MDM User ID: matt@bbqlabs.net

Ivanti MDM Compliant: false

Ivanti MDM Ownership: Unknown

Ivanti MDM User UUID: 8d1f27a2-6341-48be-97fc-8ff85fa5ef21

Ivanti MDM OS Version: 10.13.5

Ivanti MDM Compromised: false

Ivanti MDM Device GUID: cb806490-360f-4b1b-abc6-13a07aa3c1b2

Ivanti MDM Last Update: 2022-11-02 09:47:58

Ivanti MDM MAC Address: 5c:f9:38:98:7d:2c

Ivanti MDM MDM Enabled: true

Ivanti MDM Quarantined: true

Ivanti MDM Manufacturer: Apple Inc.

Ivanti MDM Last Check In: 2022-10-14 14:59:26

Ivanti MDM Serial Number: C02LM1HMF6T6

Ivanti MDM MDM Identifier: DD1A8DDE-DDD2-5041-AC94-6655A6459D98

Ivanti MDM Registration Date: 2022-10-13 21:39:22