Endpoint Compliance

• 1: Tanium
• 2: BigFix
• 3: CrowdStrike Falcon

1 - Tanium

Introduction and Overview

Tanium platform provides unified endpoint security and management with modules that can discover and inventory assets, manage endpoints, track risk and compliance and help investigate and remediate threats. The endpoint context from Tanium is leveraged by ClearPass Policy Manager to make network access decisions.

This integration guide covers the deployment and configuration of a ClearPass Extension to interface with both cloud and on-prem instances of Tanium. The Extension integrates with Tanium Gateway which provides API access to endpoint attributes including risk and compliance obtained from scan results.

Extension uses APIs that query data stored in Tanium Data Service (TDS). TDS is a near real-time cached data store that maintains historical query results for both online and offline machines. This enables users to get precise, near real-time visibility on all machines in their environment, regardless of whether an endpoint is online or not.

Tanium APIs allow the Extension to provide the following integration capabilities.

• Poll Tanium periodically for endpoint information which is then added to ClearPass endpoint repository

• Real time query against Tanium to fetch endpoint attributes at the time of authentication which can then be used as part of policy evaluation

Pictorial view of the Integration

The diagram below shows a pictorial overview of the components and how they interact with each other.

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

Configuration Steps

These are the main steps involved in configuring this integration:

1. Create custom role in Tanium with required permissions

2. Create Tanium API Token

3. Install Tanium extension on ClearPass

4. Configure extension to fetch information from Tanium Data Service

Create Tanium Custom Role

It is recommended to create a custom role and a service account for the integration so that the API token is created using an account that has the minimum permissions required for syncing endpoint attributes. Navigate to Administration > Permissions > Roles and click on “New Role”

Assign “read” permissions for Asset and “execute” permissions for Gateway as shown below:

Scroll down to Sensor permissions, click on the orange button, and watch it turn green to enable the sensors as shown below. Once this is done you can proceed to add appropriate content sets.

Under Content Sets, click on “Apply Content Sets” and select “Interact” and “Tanium Data Service”. In one of the examples described later, we will be fetching risk scores which requires selecting the “Risk” content set as well. If you wish to fetch additional attributes or sensor readings, appropriate content sets must be enabled under the role.

Next, the role should be mapped to the appropriate service account created for ClearPass integration from Administration > Permissions > Users as shown below:

The user should also be given permissions to appropriate Computer Groups as shown below:

Create Tanium API token

ClearPass uses APIs to fetch endpoint attributes from Tanium Data Service. The Tanium Gateway solution must be at a minimum version of 1.8 and an API token must be created for API Authentication.

Log into Tanium using the service account and navigate to Administration > Permissions > API Tokens and click on “New API Token” button.

Create API token by entering ClearPass IP addresses or subnets. Tanium supports using 0.0.0.0/0 as allow all IPs. For production setups, it is strongly recommended to lock down access to the specific ClearPass IP addresses.

Click “Save”, copy the token displayed and store it in a safe location to be used later while configuring the extension on ClearPass.

By default, the token is valid for 7 days. ClearPass will rotate the tokens automatically. If you have to re-install the extension after 7 days, the original token would have expired, and you would have to rotate the old token manually and use the new one.

Installing Tanium Extension

A Graphical User Interface (GUI) is available to make the process of interacting with the extension framework easier. To access the extension GUI, from the Guest System, under Administration find the Extension user interface as shown below.

From here, click on ‘Install Extension’, and the search box below appears. Enter the keyword “Tanium” and click on Search.

Click on the Extension and then the Install option.

Set a specific IP address for the extension if required. It will automatically pick an IP address if not assigned.

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

Table 1: Tanium Extension-specific configuration parameters

Attribute	Description	Values/Examples
taniumHost	FQDN / IP to access tanium instance	https://tanium.nacsecurity.net
taniumApiToken	API token from Tanium	token-c5hsdxxxxxxxxxxxxxx
taniumEndpointAttributes	Additional endpoint attributes to be fetched from Tanium. Supports fetching nested attributes.	[ "lastLoggedInUser", { "os": [ "language", "name" ] }, "ipAddresses", { "risk": [ "riskLevel", "totalScore" ] } ]
taniumEndpointNameValuesSensors	List of sensors that return a single name and value	[ "Username", "Tanium Client Version", "Total Memory", "Free Memory", "Logged In Users", "Last Logged In User", "USB Storage Devices" ]
ignoreEndpointDifferences	List of attributes, changes to which are not considered true delta	EID Last Seen

Mandatory fields are: taniumHost and taniumApiToken

Table 2: 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 will 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
attributePrefix	Prefix added to attributes to identify from which MDM the attribute was fetched	Leave empty for default “Tanium”. Enter any custom string for a custom value.

Configuration of syncAllSchedule 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. 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 attributes enableEndpointCache and endpointCacheTimeSeconds are specifically used in the extension to retrieve real-time data for a known endpoint. Then these switches will ensure that if the extension is asked to refresh data, it will check the endpointCacheTimeSeconds to decide if the data currently held is fresh or stale.

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

An example of Tanium 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 Tanium credentials, you should see something like shown below:

Use Cases

The extension can serve multiple use cases as described in the Introduction section as well as the Pictorial. Each use case would require some further configuration based on the requirement. Some example configurations are shown below for each use case.

Periodic Poll

This is a commonly used method where the extension is configured to sync all the endpoints to begin with. Once finished, the extension is configured to periodically gather updated data at fixed intervals based on the configuration parameters as discussed in the table in previous section.

Below is the list of attributes fetched by the default extension configuration:

Additional attributes and sensor values can be fetched by editing “taniumEndpointAttributes” and “taniumEndpointNameValuesSensors” in the extension configuration. Following is a sample configuration used to fetch additional attributes like lastLoggedInUser, ipAddresses, os.language, os.name and additional sensor readings like “USB Storage Devices”, “Username” etc.

Note that the example below fetches risk attributes like riskLevel and totalScore. This requires Benchmark module in Tanium. If you wish to fetch additional attributes or sensor values, ensure that the appropriate solutions are enabled in Tanium.

{

“logLevel”: “INFO”,

“verifySSLCerts”: false,

“taniumHost”: “tanium.nacsecurity.net”,

“taniumApiToken”: “********”,

“taniumEndpointAttributes”: [

“lastLoggedInUser”,

{

“os”: [

“language”,

“name”

]

},

“ipAddresses”,

{

“risk”: [

“riskLevel”,

“totalScore”

]

}

],

“taniumEndpointNameValuesSensors”: [

“Username”,

“Tanium Client Version”,

“Total Memory”,

“Free Memory”,

“Logged In Users”,

“Last Logged In User”,

“USB Storage Devices”

],

“endpointCacheTimeSeconds”: 300,

“enableSyncAll”: true,

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

“syncPageSize”: 100,

“syncAllOnStart”: true,

“syncUpdatedOnly”: true,

“syncUpdatedField”: “lastLoggedInUser,ipAddresses,Client Version,risk.riskLevel,risk.totalScore”,

“syncUpdatedSensor”: “Last Logged In User”,

“ignoreEndpointDifferences”: “EID Last Seen”,

“enableEndpointLookupCache”: false,

“macAddressSeparator”: “:”,

“bypassProxy”: false,

“enableStats”: false,

“statsUsername”: “statsadmin”,

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

}

The above configuration enables periodic sync every 30 minutes. This could be aggressive and should be configured based on the requirement for each scenario to ensure that Tanium is not inundated with requests and to manage the resource utilization on ClearPass Policy Manager.

A parameter that further helps with optimization is syncUpdatedOnly. Set this value to true to get updates only if there is a change associated with the endpoint. The value of pageSize should not be changed unless recommended by customer support.

Validation of the endpoint context being updated after the initial sync can be done by navigating to Configuration > Identity > Endpoints. Filter using the attribute Source = Tanium as shown below.

Shown below is a sample of parameters obtained from Tanium for an endpoint, these attributes can be evaluated by the enforcement policy within ClearPass Policy Manager. The full list of endpoint attributes is documented in Appendix C.

A sample enforcement policy leveraging the endpoint attributes which can be used in a service is shown below.

Tanium as an Authorization Source

With Tanium as an Authorization Source, ClearPass Policy Manager can query Tanium Data Service in real time to determine if the endpoint is managed by Tanium at the time of Authorization and grant access. It can leverage other endpoint attributes returned by Tanium within the enforcement policy. For example, a device with high-risk score can be denied access, a device with Last Update or EID Last Seen timestamps lower than the expected value can be quarantined etc.

This use case requires further configuration which includes an addition of Authentication Source which will be used for Authorization. It also necessitates modification of a service to use this new source for Authorization and a modification of role mapping to use this Authorization source which will be covered below.

To add Tanium as an Authorization source can be done under Configuration > Authentication > Sources, click “Add”.

Click on Next. This will advance to the Primary Tab which requires connection details. First an internal POST is made to the extension. The extension then calls Tanium APIs to retrieve the attributes associated with the endpoint.

The Base URL is http://<Extension IP>. The extension IP is highlighted in extension installation section. The Login Username and Login Password are mandatory fields but never used here since the contents are posted internally to an extension. Please use dummy values for username and password.

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 Tanium extension asking for context about the endpoint. The query can be indexed off the mac-address or any other endpoint attribute like serial number, UUID etc. of the authenticating endpoint using the following syntax:

/{Tanium attribute name}/%{ClearPass attribute name}

For completeness, few sample filter queries are provided below.

To lookup based on MAC Address in RADIUS request:

/macAddresses/%{Connection:Client-Mac-Address-Colon}

To lookup based on device serial number embedded in client certificate attribute like Subject-AltName-DirName-OnboardDeviceSerial

/serialNumber/%{Certificate:Subject-AltName-DirName-OnboardDeviceSerial}

To lookup based on device UUID embedded in client certificate attribute like Subject-AltName-DirName-OnboardDeviceUDID

/systemUUID/%{Certificate:Subject-AltName-DirName-OnboardDeviceUDID}

Next build out the definitions of the attributes that will be returned from the Filter Query. These attributes will subsequently be used within policy-evaluation and ultimately the enforcement policy applied.

Once the HTTP authorization source is defined, the returned attributes can be leveraged in a service using an enforcement policy or role mapping. A sample role mapping is shown below. Remember to add the newly added Authorization Source under the Authorization tab of the service.

The above policy assigns appropriate role to an endpoint based on the attributes fetched real time from Tanium.

A point to note is that ClearPass Policy Manager would query the Authorization Source every time the client authenticates. The downside with this approach is that if there is a latency in the response from Tanium, it would result in a delay in authentication and if the delay was beyond an acceptable limit, it would result in timeouts. For best performance it is always recommended to leverage the ability of ClearPass to cache the attributes for a configurable time. This is particularly useful in scenarios where clients roam frequently triggering frequent authentication requests. Use these parameters in customer environment based on their requirements.

The parameters of interest are enableEndpointLookupCache and enableCacheTimeSeconds. The values are explained in the table under the section “Configuration Steps”.

{

“logLevel”: “INFO”,

“verifySSLCerts”: true,

“taniumHost”: “”,

“taniumApiToken”: “********”,

“taniumEndpointAttributes”: null,

“taniumEndpointNameValuesSensors”: null,

“ignoreEndpointDifferences”: “EID Last Seen”,

“enableEndpointLookupCache”: true,

“endpointCacheTimeSeconds”: 300,

“enableSyncAll”: false,

“syncAllSchedule”: “0 3 * * *”,

“syncPageSize”: 100,

“syncAllOnStart”: false,

“syncUpdatedOnly”: false,

“syncUpdatedField”: “”,

“syncUpdatedSensor”: “”,

“macAddressSeparator”: “:”,

“bypassProxy”: false,

“enableStats”: false,

“statsUsername”: “”,

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

}

The access tracker results with the Authorization attributes are shown below.

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 – Default attributes fetched from Tanium

Following is the sample list of the attributes fetched from Tanium using the default configuration.

{

“Source”: “Tanium”

“Tanium EID First Seen”: “Thu, 09 Mar 2023 07:53:07 +0000”

“Tanium EID Last Seen”: “Sun, 26 Nov 2023 20:00:45 +0000”

“Tanium Last Update”: “2023-11-26 20:33:12”

“Tanium System Found”: true

“Tanium computerID”: 695858940

“Tanium domainName”: “tmelab.com”

“Tanium id”: 6

“Tanium ipAddress”: 172.16.10.190

“Tanium macAddresses”: “30:03:C8:49:7C:BB”

“Tanium manufacturer”: “LENOVO”

“Tanium model”: “Lenovo V14 G3 ABA”

“Tanium name”: “tme-win-11.tmelab.com”

“Tanium os.generation”: “Windows 11”

“Tanium os.name”: “Windows 11 Pro”

“Tanium os.platform”: “Windows”

“Tanium serialNumber”: “PF3TG7DQ”

“Tanium systemUUID”: “AE90C181-ED53-11EC-80F2-6C2408C2965C”

}

2 - BigFix

Introduction and Overview

BigFix is one of the leading endpoint management and security platforms. It quickly identifies and discovers information about endpoints, patches operating systems and monitors the inventory continuously to ensure compliance of endpoints in the infrastructure. BigFix aims at keeping the endpoints secure by ensuring they are patched on the network. Unpatched systems are a big threat to organizations as hackers frequently look for ways to leverage known vulnerabilities for malicious activities. It has a rich set of device attributes gathered from the agents running on an endpoint. These attributes can be used by ClearPass Policy Manager to get more context for the endpoint trying to connect onto the network. Unpatched or non-compliant systems can be sent to a Quarantine zone to ensure they do not have access to valuable assets on the network. This integration guide covers the deployment and configuration of a ClearPass Extension to interface with BigFix. The Extension leverages BigFix APIs to obtain attributes associated with an endpoint. This allows the Extension to provide the following integration capabilities.

1. Periodic Poll: enable periodic polling of endpoints in BigFix with a valid mac address. This allows Policy Manager to access a number ofendpoint attributes which can be leveraged for creating policies. For example

   a. Check if the endpoint is known to BigFix

   b. Check if the Last Update was less than 7 days

   c. Check if the endpoint has been locked by BigFix

2. Authorization source: Trigger the Extension to get the attributes for the authenticated endpoint, this query can be based upon the mac-address or the IP address of the endpoint.

Pictorial View of the Integration

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

The default configuration used for v3 of the extension is below.

{

"logLevel": "INFO",

"verifySSLCerts": true,

"bigFixHost": "",

"bigFixPort": 52311,

"bigFixUserName": "",

"bigFixPassword": "********",

"bigFixAdditionalProperties": [],

"bigFixIncludePatchSummary": false,

"enableEndpointCache": false,

"cacheExpirationMinutes": 30,

"enableCacheSync": false,

"cacheSyncSchedule": "0 5 * * 1",

"syncOnStart": false,

"cppmUserName": "",

"cppmPassword": "********",

"bypassProxy": false,

"enableStats": false

}

Each of the attributes are explained in the table below in detail.

Configuration attribute	Description	Example/Values
bigFixHost	The host name or IP address of your BigFix system.	192.168.1.10 bigfix.arubasecurity.net
bigFixPort	The port number for the BigFix API.	Default: 52311
bigFixUserName	The user name of an account in BigFix with access to Computer Properties and the Query API.	Username for account created (see Appendix E)
bigFixPassword	The password for the user entered in the bigFixUserName setting.	Password for account created (see Appendix E)
bigFixAdditional-Properties	A JSON array of additional properties to pull from BigFix. Default properties are included automatically and cannot be removed. Additional values may be added.	["Property Name", "Property Name"]
bigFix-IncludePatchSummary	Enables the extension to add patch summary information to device attributes. Patch summary is the numeric count of missing patches classified as Critical, Important, Moderate, and Low.	true / false
enableEndpointCache	Enables the endpoint cache process when performing a single MAC Address or IP Address based device lookup.	true / false
enableExpirationMinutes	The amount of time an endpoint's data is considered "valid" when using enableEndpointCache.	Default: 30
enableCacheSync	Enables the caching of all available endpoints in BigFix. Uses differential updates — only systems that checked in since the last update are refreshed.	true / false
cacheSyncSchedule	CRON-formatted schedule for updating the endpoint cache. See Appendix C for more details.	"0 5 * * 1" (Updates every Monday at 05:00)
syncOnStart	Starts a cache sync every time the extension is started or restarted.	true / false
cppmUserName	The user name of an Admin user in ClearPass. Used for device profiling.	Administrator username
cppmPassword	The password for the user entered in cppmUserName.	Administrator password
logLevel	Logging level for troubleshooting.	"DEBUG", "INFO", "WARN", "ERROR"
bypassProxy	If a proxy is configured, bypass it for API calls to BigFix.	true / false
enableStats	Enable basic extension statistics dashboard.	true / false

When leveraging the sync capabilities of the Extension to get the device attributes from BigFix, use the attribute enableCacheSync and specify cacheSyncSchedule. These 2 attributes are leveraged for periodic poll of endpoints from BigFix. The syncOnStart attribute can be leveraged as well to sync everything upon the start or re-start of the extension.

When doing single device lookups by MAC Address, if enableEndpointCache is true, the mac address will be looked up in ClearPass to see if the information for the computer is in the database and up-to-date as determined by the cacheExpirationMinutes, this being the amount of time an endpoints data will be considered "fresh" when using the enableEndpointCache option. If false, all requests will be sent to BigFix.

The bigFixUserName and bigFixPassword are credentials of the operator on BigFix which will give access to endpoints discovered by BigFix via REST APIs. A default administrator account can be used for this setup or a separate local operator can be created. For steps on creating this operator on BigFix, see next page.

The cppmUserName and cppmPassword should be for an Administrator account. The device profiling attributes obtained from BigFix need to be written into the endpoint repository leveraging a profiling APIs which requires an Administrator account.

A ClearPass Network Administrator account can be created under Administration > Users and Privileges > Admin Users. Click on Add. A user with the following Privilege Level needs to be created.

A Network Administrator privilege level is sufficient for the action of adding device profiling information into the endpoint database of ClearPass.

A copy of the BigFix Extension with the desired configuration is shown below, this has to be modified for your as a minimum. Include the bigFixHost, bigFixPort, bigFixUserName, bigFixPassword, cppmUserName and cppmPassword that will be specific to your environment.

Change or include any other values based on the description of each in the above table as necessary to your deployment. Select Restart and click on Save Changes to restart the extension.

An optional but extremely powerful parameter to note is bigFixAdditionalProperties. By default, the parameter has the value of [] which basically indicates that the sync would only get the default attributes.

However, BigFix includes an extensive list of attributes from an endpoint. Some of these attributes might not be very useful or relevant for ClearPass and would increase the payload to be ingested from BigFix. Customization options are available with this parameter so that an administrator can identify and pull values apart from the default which are important in their environment. Navigate to the BigFix Extension and click on Show Details as shown below.

Click on the Extension URL under the details. This gives a list of all the attributes that can be fetched from BigFix. If the information is available for the endpoint on BigFix, ClearPass can pull it.

The URL above gives a long list of available attributes. The ones marked in bold are mandatory and fetched by default. If any of the other properties are useful in a particular environment, they can be fetched using the bigFixAdditionalProperties parameter. They can be then be leveraged in ClearPass Policy.

For example, here we have added BIOS and Client Settings to the list of additional attributes that need to be fetched from BigFix.

Following is the change in the Extension configuration. Remember this change is only required if additional attributes need to be fetched from BigFix. This can be totally skipped for the basic setup of this integration.

{ "bigFixHost": "10.2.98.40",

"bigFixPort": 52311,

"bigFixUserName": "admin",

"bigFixPassword": "********",

"bigFixAdditionalProperties": [

"Client Settings", "BIOS"

],

"bigFixIncludePatchSummary": true,

"enableEndpointCache": true,

"enableCacheSync": true,

"cacheSyncSchedule": "0 5 * * 1",

"syncOnStart": true,

"cppmUserName": "admin",

"cppmPassword": "********",

"verifySSLCerts": false,

"logLevel": "INFO",

"bypassProxy": false,

"enableStats": false

}

Ensure the Extension is restarted upon a configuration change. After the restart of the extension, click on Show Logs.

The above log states that the Extension has sync’d the endpoint data from BigFix. The above steps sync endpoint details at the time of starting the Extension and then regular updates are fetched at the interval specified by cacheSyncSchedule, see Appendix C for more information on configuring this value. Please note the IP address of the Extension. This will be used in the next section where we leverage BigFix Extension as an Authorization source. A sample of attributes fetched for an endpoint is shown below.

Configure ClearPass Policy Manager

Multiple methods exist for how ClearPass can utilize the returned data from HCL BigFix, such as:

Ensure that the endpoint is managed by BigFix. If not, perhaps restrict access for the device on the

Corporate Network with a role that only allows the user to remediate and install the BigFix endpoint agent. This provides a controlled environment where all endpoints are known to be in line with corporate security policy, around patching and OS updates.

Check if the endpoint has the latest BigFix agent installed. If not, perhaps quarantine the device with the option to remediate and install an updated client.

More importantly validate whether the endpoint is missing any patches, subdivided into Critical, Important, Low and Moderate, separate policy can be written against any of the counts.

Additionally, policy can be written against a wealth of additional endpoint attributes that are important to you, if for example you wanted to check the BiOS version of devices connecting, you can have BigFix return that data which can then be compared in policy to decide if an endpoint maybe vulnerable to a BiOS exploit.

As mentioned previously, the extension can be run in two modes.

Periodic Sync Mode: Using stored attributes

The Extension can sync data from BigFix periodically, write this data into the ClearPass EndpointDB, then use the EndpointDB as an authorization source. Be aware that this data will not be completely ‘real-time,’ but may be adequate for many if not all use cases.

Here’s an example of a ClearPass Role Mapping Policy that utilizes these BigFix Endpoint Attributes.

HTTP Authorization Source Mode: A Real-Time authorization check

In this mode we build an HTTP authorization source, add it to an existing Service Policy, then process the returned data from BigFix, typically utilizing a role-mapping or an enforcement profile action. Note that with an HTTP authorization source configured in a Service, ClearPass will make a call to BigFix every time an authenticating device matches this Service, unless the cacheExpirationMinutes timer for the endpoint is still qualifying the data as “fresh”. Making real-time API calls to BigFix every time a device authenticates may not be scalable if there are network delay constraints or you have a high number of authentications/sec.

The HTTP Authorization source is the conduit between the extension and ClearPass Policy Manager. It’s through the authorization source that we expose the BigFix endpoint attributes to Policy Manager so they can be used to perform role-mapping or an enforcement policy action.

Defining a BigFix HTTP Authorization Source

The first step is to add the authorization source. Under Configuration > Authentication > Sources, click Add and choose type HTTP.

Provide a Name for the Authentication Source and click Next. On the Primary Tab, provide the IP Address of the extension as discussed earlier. Ensure a trailing ‘/mac/’ is added after the extension IP address.

Click on Next. This will advance to the Attributes Tab where you must configure at least one attribute. Click on Add More Filters. Provide a Name for the filter and then a Filter Query. The query is indexed off the MAC Address of the endpoint. Copy the line below and paste into the Filter Query box.

%{Connection:Client-Mac-Address-Hyphen}

The data returned from BigFix can be extensive, but not all the data is relevant to making a security policy decision about the endpoint. Choose which attributes are required for your enforcement profile. As an example, the filter shown below has eleven attributes configured. Your filter may differ depending on the use-cases you are trying to meet. Remember if you want to check additional attributes via the HTTP authZ then they need to be added in the array un the extension under bigFixAdditionalProperties.

Using Results from the BigFix HTTP Auth Source

Below is an example of using these attributes in a ClearPass Role Mapping Policy.

This is just a simple configuration to show what you can do with the returned attributes.

Previously we discussed about an optional parameter called bigFixAdditionalProperties. It is used to fetch more attributes than the default ones available above. In order to use that attribute with Authorization source it is necessary to add the same using the option “Add More Filters”. Without doing this, it will not be available for use with Authorization.

Let’s look at the example below where the BigFix Missing Patches-Critical attribute fetched is mapped within the Authorization source as shown below.

Let’s look at the service configuration within ClearPass to see this HTTP source being leveraged as an Authorization source within a service. Ensure to check the option for enabling Authorization.

The next step is to add this source under Authorization. The Authorization tab for the service is shown below.

Finally, the authorization source is leveraged under Enforcement for the policies to be defined. A sample Enforcement Policy for this service is shown below.

In the above policy if BigFix marks an endpoint as Locked, the endpoint is assigned a Quarantine role with restricted Access. A full access role is granted only if the Endpoint “Is Found” by BigFix. If not, a default of [Deny Access Profile] is assigned.

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 BigFix configuration

It is assumed that a working BigFix environment is leveraged for this extension. The configuration of BigFix is beyond the scope of this guide.

The Extension configuration requires a valid BigFix administrator account to leverage BigFix APIs. This account can be created on BigFix as shown below.

Go to Tools Menu on top of your screen and click on Create Operator . Add a user with credentials as shown below.

The next step involves assigning permissions for this account. It is important that the account has the permissions for Can use REST API. Also, the account should have a list of Administered Computers". In our lab, a user with restricted permissions was used and should be preferred. For details on this, please contact your local BigFix representative. Under the “Details” tab for this account, provide restricted access as shown below.

If there are permission issues when trying to fetch computers, one can check or troubleshoot by giving this account the Master Operator permission as shown below or use an administrator account for testing only.

Navigate to the “Computer Assignments” tab. Add the computers in scope for this Extension or select all computers. It is important that after the settings are saved, the “Administered Computers” tab gets updated. An empty list of Administered Computers would always result in extension fetching no computers.

Further restrictions can be assigned to this account by granting a Reader permission only to the sites within the scope.

Appendix F XMLs

The Authentication Source can be easily imported into ClearPass so that it can be leveraged to use the BigFix

Extension as an Authorization source in a service. The XML file can be downloaded from https://github.com/aruba/clearpass-exchange-snippets/tree/master/extensions/ibm-bigfix

• Download the XML profile > “clearpass-extension_tenable-securitycenter_enf-profile.xml”.

• Open this file in your favorite editor.

• Use the Find and Replace feature of the editor to replace "<BigFix Extension IP>" with the actual IP address of the BigFix Extension configured. Refer Figure 24.

• Save the file and Import.

The file can be imported from Configuration > Enforcement >Profiles.

The above action will import an ‘basic’ HTTP Authentication Source in ClearPass which can be leveraged as an Authorization source for a service, you may want to add additional fields/attributes as previously discussed.

3 - CrowdStrike Falcon

Introduction and Overview

CrowdStrike Falcon Endpoint Protection is a cloud-based security platform that combines the capabilities of a next-gen Antivirus (NGAV) and Endpoint Detection and Response (EDR) using a single cloud-delivered agent. This release of document focuses on the new SDK based CrowdStrike Falcon extension in the ClearPass Policy Manager. A few enhancements that are added with the new SDK based extension help with the efficient integration of CrowdStrike Falcon Endpoint Protection and ClearPass Policy Manager with the existing methods.

• CrowdStrike Falcon Integration with ClearPass Policy Manager with the new SDK based extension now conform with the User Agent information that is used by CrowdStrike for internal tracking.

• The syncing of endpoints from CrowdStrike Falcon now provides the CrowdStrike device ID as well as attribute along with MAC. The authentication source and context server action URL’s can now leverage both MAC and Device ID in real-time lookup for authorization and context server action-based containments.

• The new extension now also supports bypassing proxy.

ClearPass Policy Manager integrates with CrowdStrike Falcon in multiple ways;

• Perform a real-time lookup of the device attributes which can be leveraged for Authorization.

• Bulk import of all the endpoints leveraging flexible polling definition based on crontab

• Trigger containment or lift the containment for the quarantined devices using the CrowdStrike Falcon agent.

The above use-cases are covered in this integration and documented in this Integration Guide.

What’s new in CrowdStrike v2.1 Extension? -Important Changes

Deprecation of GET /devices/entities/devices/v1(GetDeviceDetails) - CrowdStrike has announced the deprecation of v1 GET host details operation. Integrations leveraging the v1 endpoint API’s must be updated to use one of the new v2 versions by February 9, 2023. This means that all earlier versions of extensions will fail collecting device details causing the integration to break. This release v2.1.0 is updated to use the v2 version of the GET host details operation and is a go to version before February 9, 2023 without fail to continue using the integration between ClearPass and CrowdStrike.

Support for Zero Trust Assessment attributes – CrowdStrike has supported Zero Trust Assessment of endpoints for a while which can be leveraged by this version of extension to fetch the risk scores of an endpoint as endpoint attributes. There are numerous assessment items that CrowdStrike evaluates to give evaluated results like OS assessment, Sensor assessment and Overall assessment scores. We have added support for following Zero Trust assessment attributes in this version of extension which can be called into ClearPass policies for profile enforcements based on CrowdStrike Zero Trust Assessment scores in addition to the existing attributes that we have from past CrowdStrike extension versions.

• “CrowdStrike Assessment OS”

• “CrowdStrike Assessment Overall”

• “CrowdStrike Assessment Sensor Config”

A new configuration knob is added to this version of extension which can be set to true to fetch the Zero Trust scores of an endpoint. This option is set to false by default.

crowdStrikeSyncZeroTrust": true,

Pictorial View of the Integration

The diagram below shows a pictorial overview of the components and how they interact with each other.

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

Configuration Steps in CrowdStrike to enable API communication

There are primarily 2 steps involved in getting this integration configured.

1. Configuration of CrowdStrike for Integration

2. Installation and Configuration of CrowdStrike extension using the ClearPass Policy Manager GUI

Getting API Credentials

Login to the CrowdStrike tenant, using your administrator credentials.

Create a new API Client. Navigate to Support > API Clients and Keys. Click on “Add new API client”.

Save the API Client ID and Client Key on a notepad. Client Key is not displayed again. This will be used while configuring the Extension in ClearPass Policy Manager.

Enter a Client Name. Under API Scopes, add the following permissions

1. Read/Write permissions for Hosts

2. Read for Event streams

Check for Managed Hosts

This configuration step is optional and is only required if there are no Endpoints managed by CrowdStrike.

Go to Hosts > Host Management. Ensure there are hosts being managed by CrowdStrike. These are the hosts that will be pulled by ClearPass Policy Manager, if the sync function is enabled in the Extension configuration.

If no hosts are managed by CrowdStrike, one needs to install the Falcon Sensor on the endpoints to be managed. These steps vary based on the endpoint Operating System. The installers are available under Hosts > Sensor Downloads.

Steps for sensor installation are available under the section “Sensor Deployment and Maintenance” here https://falcon.crowdstrike.com/support/documentation

CrowdStrike Extension Installation and Configuration on ClearPass

A Graphical User Interface (GUI) is available to make the process of interacting with the extension framework easier. To access the extension GUI, from the Guest System, under Administration find the Extension user interface as shown below.

From here, click on ‘Install Extension’, and the search box below appears. Enter the keyword “CrowdStrike” and click on Search.

Click on the Extension and then the Install option.

Set a specific IP address for the extension if required. It will automatically pick an IP address if not assigned.

After the extension has been installed, review the configuration and adjust as needed. Notice the options to Start, Delete, Reinstall or Show Logs and the option to edit and set the extension configuration.

The default configuration used for the extension is shown below

{

“logLevel”: “INFO”,

“verifySSLCerts”: true,

“crowdStrikeApiHost”: “api.crowdstrike.com”,

“clientId”: “[Client ID]”,

“clientSecret”: “********”,

“crowdStrikeSyncZeroTrust”: false,

“enableEndpointCache”: false,

“endpointCacheTimeSeconds”: 300,

“syncAllOnStart”: false,

“enableSyncAll”: false,

“syncAllSchedule”: “0 2 * * 6”,

“syncUpdatedOnly”: true,

“syncPageSize”: 100,

“attributePrefix”: “”,

“bypassProxy”: false,

“enableStats”: true,

“statsUsername”: “”,

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

}

Each of the attributes are explained in the table below in detail.

Figure 12: Extension configuration parameters

Configuration attribute	Description	Default Values
logLevel	Logging level for troubleshooting	“INFO”
verifySSLCerts	Should SSL Certificates be validated	true
crowdStrikeApiHost	The hostname or IP address of the CrowdStrike API	Default: api.crowdstrike.com
clientId	The Client ID used to access the CrowdStrike Oauth API	[Client ID]
clientSecret	The Client Secret for the provided Client ID	********
enableEndpointLookupCache	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
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
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
pageSize	Used to limit the amount of data returned by each sync request in a single attempt. This prevents issues pertaining to timeouts when the dataset to be ingested is large. The value should not be changed unless recommended by customer support.	500
attributePrefix	Add prefix to endpoint attributes to be able to identify attributes synced from two different CrowdStrike extension instances for parallel systems.	Null
bypassProxy	Bypass the web proxy configured on ClearPass Policy Manager	false
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
crowdStrikeSyncZeroTrust	Enable/Disable fetching of Zero Trust score attributes	false

A copy of the CrowdStrike Falcon extension with the desired configuration is shown below, this has to be modified for your deployment. Modify the clientId, clientSecret and other options that will be specific to your environment. Change or include any other values based on the description of each in the above table

Select Restart and click on Save Changes to restart the extension.

After completing the configuration, click on ‘Save Changes’ and restart of the extension, click on Show Logs.

The above log shows that the extension has been configured and has ingested endpoints from CrowdStrike leveraging sync on start. These logs can be seen in detail if the loglevel setting is changed to DEBUG.

Use Cases

The extension can serve multiple use cases as described in the Introduction section as well as the Pictorial. Each use case would require some further configuration based on the requirement. Some example configurations are shown below for each use case.

Periodic Poll

This is a commonly used method where the extension is configured to sync all the endpoints to begin with. Once finished, the extension is configured to periodically gather updated data at fixed intervals leveraging the configuration parameters as discussed in the table in previous section. Following is the sample configuration used.

{

“logLevel”: “INFO”,

“verifySSLCerts”: true,

“crowdStrikeApiHost”: “api.crowdstrike.com”,

“clientId”: “[Client ID]”,

“clientSecret”: “********”,

“crowdStrikeSyncZeroTrust”: false,

“enableEndpointCache”: false,

“endpointCacheTimeSeconds”: 300,

“syncAllOnStart”: false,

“enableSyncAll”: false,

“syncAllSchedule”: “0 2 * * 6”,

“syncUpdatedOnly”: true,

“syncPageSize”: 100,

“attributePrefix”: “”,

“bypassProxy”: false,

“enableStats”: true,

“statsUsername”: “”,

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

}

The above configuration enables periodic sync and triggers it every 2 hours. This could be aggressive and should be changed based on the requirement in a particular scenario to ensure that CrowdStrike is not inundated with requests and also to manage the resource utilization on ClearPass Policy Manager.

A parameter that further helps with optimization is syncUpdatedOnly. Set this value to true to get updates only if there is a change associated with the endpoint. The value of pageSize should not be changed unless recommended by customer support.

Validation of the endpoint context being updated after the initial sync can be done by navigating to Configuration > Identity > Endpoints. Filter using the attribute Source = CrowdStrike as shown below.

Shown below is a sample of security contextual parameters obtained from CrowdStrike for an endpoint, these attributes can be evaluated by the enforcement policy within ClearPass Policy Manager. These attributes are obtained leveraging the default policy on CrowdStrike. The Falcon agent should be capable of capturing further attributes which could be leveraged as well. The full list of endpoint attributes is documented in Appendix C on Page 27.

A sample enforcement policy leveraging the endpoint attributes which can be used in a service is shown below.

Note that the common endpoint attributes related to Zero Trust Assessment would make sense in enforcement policies when they are of data-type integer. For example, if one needs to check if the overall Zero Trust Assessment score of an endpoint is greater than 20 then such policy conditions will need the attributes to be of type integer. By default, all the attributes sent by CrowdStrike get added as data-type String for an endpoint. Therefore, for certain use cases such attributes need to be deleted from the Dictionary attributes and re-added with the data-type set to integer manually.

To delete the attributes, one needs to first stop the extension, delete the existing endpoints from the ClearPass DB as the endpoints will be referencing these attributes from the dictionary preventing an administrator to delete them. After which these attributes can be added manually as shown below with the data-type set to integer.

Since the Zero Trust Assessment scores are available as endpoint attributes only starting version 2.1.0 of the extension one needs to first upgrade the extension. So, the step to delete the endpoints and dictionary attributes can be done prior to the upgrade which will prevent restarting the extension multiple times.

CrowdStrike as an Authorization Source

With CrowdStrike as an Authorization Source, ClearPass Policy Manager can query CrowdStrike Real-Time to determine if the endpoint is managed by CrowdStrike at the time of Authorization and grant access accordingly. It can leverage other security attributes returned by CrowdStrike within the enforcement policy. For example, a contained device can be denied access, a device with Last Update higher than the expected value can be quarantined etc.

This use case requires further configuration which includes an addition of Authentication Source which will be used for Authorization. It also necessitates modification of a service to use this new source for Authorization and a modification of Enforcement Policy to use this Authorization source which will be covered below.

The addition of Authentication source can be easily configured by importing the XML available on HPE Aruba Networking GitHub. Kindly refer Appendix B for details.

Adding CrowdStrike as an Authorization source can be done under Configuration > Authentication > Sources, click “Add”.

Click on Next. This will advance to the Primary Tab which requires connection details. Here an internally POST is made to the extension. The extension then calls CrowdStrike APIs to retrieve the security attributes associated with the endpoint.

The Base URL is http://<Extension IP>. The extension IP is highlighted in Figure 14. The Login Username and Login Password are mandatory fields but never used here since the contents are posted internally to an extension. This value has to be defined and could be 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 CrowdStrike extension asking for context about the endpoint. The query is indexed off the mac-address of the authenticating endpoint. For completeness, the filter query is provided here, copy it carefully.

/%{Connection:Client-Mac-Address-NoDelim}

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.

For. Zero Trust Assessment Score attributes below are the definitions of the attributes from a second query that needs to be added.

/zero-trust/%{Endpoint:CrowdStrike Device ID}

Further attributes can be added here if necessary for the policy. Appendix C has a list of attributes captured by the extension.

Once the HTTP authorization source is defined, the returned attributes can be leveraged in a service using an enforcement policy or role mapping. A sample enforcement policy is shown below. Remember to add the newly added Authorization Source under the Authorization tab of the service.

The above policy grants full access to an endpoint if it is provisioned with a CrowdStrike Falcon agent and the agent has not contained the endpoint and the Zero Trust Overall Assessment score is greater than 20.

Let’s revisit the configuration parameters of the extension. The parameters of interest are enableEndpointLookupCache and enableCacheTimeSeconds. The values are explained in the table under the section “Configuration Steps”.

{

“logLevel”: “INFO”,

“verifySSLCerts”: true,

“crowdStrikeApiHost”: “api.crowdstrike.com”,

“clientId”: “[Client ID]”,

“clientSecret”: “********”,

“crowdStrikeSyncZeroTrust”: false,

“enableEndpointCache”: false,

“endpointCacheTimeSeconds”: 300,

“syncAllOnStart”: false,

“enableSyncAll”: false,

“syncAllSchedule”: “0 2 * * 6”,

“syncUpdatedOnly”: true,

“syncPageSize”: 100,

“attributePrefix”: “”,

“bypassProxy”: false,

“enableStats”: true,

“statsUsername”: “”,

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

}

The access tracker results with the Authorization attributes are shown below.

Leverage the benefits of caching the attributes for faster authentication results. This is particularly useful in scenarios where clients roam frequently triggering frequent authentication requests. Use these parameters best suited in a customer environment based on their requirements.

Contain an endpoint using CrowdStrike APIs

ClearPass Policy Manager extension can call the CrowdStrike APIs to trigger containment on the endpoint leveraging the Falcon agent. APIs can also be leveraged to lift the containment.

Configuration for containment includes 3 steps on ClearPass Policy Manager. These steps can be ignored if the Enforcement Policies are exported directly as an XML. The steps are available in Appendix B.

1. Define Endpoint Context Server

2. Add Context Server Action

3. Create an Enforcement Profile to trigger the action

Endpoint Context Server

The first step is to define an Endpoint Context Server. This can be added under Administration > External Servers > Endpoint Context Servers click on Add and use the extension IP address highlighted in Figure 14.

Ensure you change this to http else the internal POST fails. Please note that this is an internal post within ClearPass from the Policy Manager to the Extension.

Context Server Action

The next step is to define a Context Server Action within ClearPass Policy Manager which will internally POST to the extension. The extension will trigger an API call to CrowdStrike and fetch the information associated with it which can be used for Authorization. The context server action allows us to define the HTTP Method, the URL and the JSON contents that will be used to post the mac address to the extension.

This can be added under Administration > Dictionaries > Context Server Actions. Click on Add and use the details shown below. All the other tabs are blank.

The URL used below has to match for the API calls to be successful. Kindly copy paste the URL from below

Contain: /contain/%{Connection:Client-Mac-Address-NoDelim}

Lift Containment: /lift-containment/%{Connection:Client-Mac-Address-NoDelim}

Similarly, a Context Server Action for lifting the containment is shown below.

Enforcement Profile

The next step involves using the Context Server Action in an Enforcement Profile as below. The Enforcement Profile for containing an endpoint leveraging CrowdStrike APIs action is shown below.

The Access Tracker result is shown below. CPPM triggers an internal API call to the extension configured.

Similarly, containment can be lifted from the hosts using the Lift Containment action or Enforcement Policy within CPPM.

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 – XMLs

The following steps are required to add CrowdStrike as an Authentication Source by importing it into ClearPass Policy Manager using the XML file available in our GitHub repository

https://github.com/aruba/clearpass-exchange-snippets/tree/master/extensions/CrowdStrike

• Download the XML profile > “clearpass-extension_crowdstrike_auth-source.xml”.

• Open the XML file using a simple editor and replace X.X.X.X with your EXTENSION IP ADDRESS (Refer Figure 14).

• You can also import the XML without making any edits and then change the “Base URL:” from “http://X.X.X.X” to your extension IP address using the ClearPass Policy Manager UI. This can be changed under the Primary tab of the imported Authentication Source (Refer 0).

• The XML file can be imported into ClearPass by navigating to Configuration > Authentication > Sources. Click on Import and use the file downloaded.

The Enforcement Profile, Context Server Action and the Endpoint Context Server configured in the section “Contain an endpoint using CrowdStrike APIs” can easily be imported using the XML available on HPE Aruba Networking GitHub

https://github.com/aruba/clearpass-exchange-snippets/tree/master/extensions/CrowdStrike

• Download the XML profile > “clearpass-extension_crowdstrike_enf-profile.xml”.

• Open this file in your favorite editor. Use the Find and Replace feature of the editor to replace “<<Extension IP>>” with the actual IP address of the extension configured. Refer Figure 14.

• The XML file can be imported into ClearPass by navigating to Configuration > Enforcement > Profiles. Click on Import and use the file downloaded.

Appendix F – Attributes Fetched from CrowdStrike

Following is the sample list of the default attributes fetched from CrowdStrike using the default policy. {

“CrowdStrike Cid”: “643b2392ec494d948e9c879c4fe11f3a”,

“CrowdStrike Status”: “normal”,

“CrowdStrike Hostname”: “B07D64852C5D-BG”,

“CrowdStrike Local IP”: “10.x.x.1x”,

“CrowdStrike OS Build”: “22000”,

“CrowdStrike Policies”: “prevention-6dfa63d7790446c4babf32db50e0810e”,

“CrowdStrike Device ID”: “27b832e592ab4e739583acfba1aaa004”,

“CrowdStrike Last Seen”: “2023-01-04T16:42:31Z”,

“CrowdStrike First Seen”: “2022-12-01T07:05:21Z”,

“CrowdStrike Group Hash”: “e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855”,

“CrowdStrike OS Version”: “Windows 11”,

“CrowdStrike External IP”: “49.205.32.38”,

“CrowdStrike Last Update”: “2023-01-04 16:45:00”,

“CrowdStrike MAC Address”: “b0-7d-64-85-2c-5d”,

“CrowdStrike Platform ID”: “0”,

“CrowdStrike BIOS Version”: “X571GT.311”,

“CrowdStrike Build Number”: “22000”,

“CrowdStrike Pointer Size”: “8”,

“CrowdStrike Product Type”: “1”,

“CrowdStrike System Found”: “true”,

“CrowdStrike Agent Version”: “6.48.16205.0”,

“CrowdStrike Assessment OS”: “78”,

“CrowdStrike Connection IP”: “10.x.10.x”,

“CrowdStrike Cpu Signature”: “591594”,

“CrowdStrike Major Version”: “10”,

“CrowdStrike Minor Version”: “0”,

“CrowdStrike Platform Name”: “Windows”,

“CrowdStrike Serial Number”: “M4N0CX12R927169”,

“CrowdStrike Config ID Base”: “65994753”,

“CrowdStrike Kernel Version”: “10.0.22000.1335”,

“CrowdStrike Config ID Build”: “16205”,

“CrowdStrike Device Policies”: “Prevention-6dfa63d7790446c4babf32db50e0810e, Sensor Update-b7178b018dcb4a8d83cec39401acfb5c, Device Control-5d3813ac29c44e54b48987b25c361bda, Global Config-67643d17e357489c8d6a08d38c07f1b4, Remote Response-22b6b4e42b6b4333bdb2f8112d1f7dea, Firewall-671577970e284f019faf83d9fa690842”,

“CrowdStrike Agent Load Flags”: “1”,

“CrowdStrike Agent Local Time”: “2023-01-04T19:36:42.247Z”,

“CrowdStrike Provision Status”: “Provisioned”,

“CrowdStrike BIOS Manufacturer”: “American Megatrends Inc.”,

“CrowdStrike Product Type Desc”: “Workstation”,

“CrowdStrike Assessment Overall”: “30”,

“CrowdStrike Assessment Version”: “3.5.1”,

“CrowdStrike Config ID Platform”: “3”,

“CrowdStrike Default Gateway IP”: “10.234.1.1”,

“CrowdStrike Modified Timestamp”: “2023-01-04T16:44:16Z”,

“CrowdStrike Sensor File Status”: “not deployed”,

“CrowdStrike Service Pack Minor”: “0”,

“CrowdStrike System Manufacturer”: “ASUSTeK COMPUTER INC.”,

“CrowdStrike System Product Name”: “VivoBook_ASUSLaptop X571GT_F571GT”,

“CrowdStrike Connection MAC Address”: “b0-7d-64-85-2c-5d”,

“CrowdStrike Assessment Modified Time”: “2022-12-30T07:55:03Z”,

“CrowdStrike Assessment Sensor Config”: “5”,

“CrowdStrike Reduced Functionality Mode”: “no”

}