This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

ClearPass Extension

ClearPass Extensions are self-contained micro-services that run on the ClearPass platform and provide access to some advanced features that are not yet part of the ClearPass platform. Extensions run in its own environment and is isolated from the underlying system as well as any other extensions that may be present. They are primarily used to build integrations with 3rd party systems without having to make changes to ClearPass platform. Due to its self contained nature, extensions can be built and released independent of the ClearPass release cycles. These micro-services enable Aruba to deliver new features outside of the main software release cycle and facilitate a faster time to market for specific features.

1: Common Appendices for Extensions

2: Common Extension Attributes

3: Installing Extensions

4: List of active ClearPass Extensions

5: Skyhook Introduction

6: Skyhook Self Service Portal

7: Skyhook Token Refresh

1 - Common Appendices for Extensions

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>

function reloadPage() {

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

window.location.href = locHref;

}

</script>

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

INFO

For this reason its good practice to fix the IP address of the extension at installation time such that it doesn’t change over time and break the application controls.

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:

INFO

extensions.clearpassbeta.com
registry-1.docker.io
index.docker.io
auth.docker.io
production.cloudflare.docker.com

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

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,
```

WARNING

Having the extension installed on all the cluster nodes with enableSyncAll set to true would cause each cluster node to independently poll the external system and update endpoint repository. This could impact the performance of ClearPass. Hence it is strongly recommended to enable endpoint sync only on the extension installed on the publisher and on another cluster node for redundancy.

Some 3rd party systems support fetching delta updates vs fetching all of the device information every polling cycle. The extensions that support fetching delta updates are: Workspace ONE Crowdstrike Falcon Microsoft Intune Mosyle SentinelOne Service Now

For these extensions, the syncUpdatedOnly attribute should be set to true in extension config so that the number of DB updates in ClearPass is minimized
```
  "syncUpdatedOnly": true,
```
For extensions that do not support syncUpdatedOnly, ensure that the sync interval is not aggressive. We recommend syncing at most twice a day and that too during off peak hours whenever a full sync is performed.
Some 3rd party systems can be very noisy in terms of attribute updates. There could be certain attributes that keep changing every sync interval like “Free Memory in Bytes”, “Last Check in Time” etc. There is no value in updating endpoints when such trivial attributes change for the device. Hence it is recommended to use “ignoreEndpointDifferences” attribute in extension configuration to ignore change in attributes that you do not care about in terms of ClearPass policies.

You can review the Audit Viewer in ClearPass under Monitoring > Audit Viewer to see what attributes are being updated for endpoints to check if there are unnecessary updates.

Sample for JAMF extension:
```
  "ignoreEndpointDifferences": "Last Update, Report Date UTC, Last Contact Time UTC, Last Inventory Update UTC, Last Reported IP, IP Address",
```
Default for Microsoft Intune extension:
```
  "ignoreEndpointDifferences": "Last Sync Date Time, Free Storage Space in Bytes",
```
To further optimize the number of endpoints being updated in ClearPass, you can specify which attributes are being used in the ClearPass policies so that only changes to those attributes would trigger an update to the endpoint. This is done by listing out the specific attributes under endpointAttributes in extension configuration.

Sample for JAMF extension:
```
  "endpointAttributes": "Group names, MDM Enabled, Managed, Remote Managed, Supervised, Serial Number",
```
Setup extension to restart unless it was intentionally stopped. A restart policy can be defined in extension configuration to ensure that the extension starts up automatically after server reboots and such. Restart policy of “unless-stopped” would ensure the extension always starts up unless it was manually stopped.

“restartPolicy”: “no” — The extension will not be automatically restarted after the server is restarted.

“restartPolicy”: “always” — The extension will always be restarted after the server is restarted.

“restartPolicy”: “unless-stopped” — The extension will be restarted unless it was stopped prior to the server restart, in which case it will maintain that state.

“restartPolicy”: “on-failure:N” — If the extension fails to restart, the value for “N” specifies the number of times the extension should try to restart. If you do not provide a value for “N”, the default value will be “0”.

The “restartPolicy” parameter is not present by default in extension configurations. When it is not present, if the system is restarted a default policy is applied to the extension to maintain the state it was in before the restart. If the “restartPolicy” parameter is added to the configuration but later removed, the extension will then revert to the default restart policy.

2 - Common Extension Attributes

An extension is a microservice working on its own in a container independently from the ClearPass operating system, which is used by ClearPass to communicate with external systems.

Common extension attributes

Extension framework configuration parameters (common configuration)

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

3 - Installing Extensions

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.

INFO

Internet access is required for ClearPass Policy Manager to install the ClearPass Extensions from the Extension Store. Starting with ClearPass 6.12, extensions can be can be installed offline as well. Offline ClearPass Extension images are available on HPE networking support portal.

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

INFO

Here we are using Intune as an example. The installation steps are the same for all the extensions. For your deployment, please search for the appropriate extension like Jamf, Mosyle, Crowdstrike, etc.

All currently available extensions are listed in the page: https://www.arubanetworks.com/techdocs/NAC/clearpass/integrations/clearpass-extension/extensions-list/

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

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

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

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

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

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

INFO

Password and sensitive configuration items are obfuscated when presented in both the Extension GUI or in the Explorer configuration.

WARNING

The configuration attributes are case sensitive. It is recommended to refer the default configuration sample while editing your configuration.

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

INFO

Note that the Policy Manger web proxy configuration is ONLY read by the extension at installation time. If the web proxy configuration is changed in Policy Manager, then the extension must be re-installed so the new settings are re-read and bonded to the extension.

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

INFO

The subnet defined here for the extension framework must fall within the following subnet range 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 as defined by RFC1918. For best results, set the network address range to a subnet that does not exist in your enterprise, and restart the extension service for this change to take effect.

Never set the DATA or MGMT IP address to use an address that matches the Extension Network

Defining the base IP SUBNET and LOCALHOST for the Extensions Framework

INFO

Note that changing the extension base IP address will require the extension service to be restarted.

4 - List of active ClearPass Extensions

This page lists all the extensions that are available publicly in the extension store

List of Active ClearPass Extensions


Aruba ClearPass Universal Authentication Proxy
BlackBerry UEM
Carbon Black EDR
Certificate Enrollment Manager CEM
CrowdStrike Falcon
Cylance Authorization Source
Envoy
Google Secure LDAP Connector
goreception-cppm
HTTP AuthZ Proxy
BigFix
Intune SCEP
Jamf Pro Jamf School (formerly ZuluDesk)
Lightspeed Systems Relay
McAfee ePO
Meraki Integration
Microsoft Intune
MobileIron UEM
Mosyle
Microsoft Defender ATP
OPSWAT MetaAccess Authorization Source
Palo Alto Networks GlobalProtect
PingID MFA
privacyIDEA Authentication
rapid7-nexpose
Rapid7 InsightVM
SentinelOne
ServiceNow
Sine ClearPass Integration
Skyhook Processor
Sophos Central
SOTI MobiControl
Splunk HEC Connector
Symantec Endpoint Protection Manager
Tanium
Teem LobbyConnect
Tenable.sc
Trend Micro Apex Central
VMware Workspace ONE

5 - Skyhook Introduction

An introduction into skyhook framework and different components

Skyhook Framework

Skyhooks was developed to overcome the inability for Cloud based applications to send events [webhooks] directly into a ClearPass that was typically deployed on the Trust side of a corporate firewall. In short the service runs in AWS, ClearPass nodes running on-prem use extensions to open a persistent connection into Skyhooks to receive the events originally sent from a 3rd party cloud application specific for that customer/tenant, we’ll go into greater depth of the components. Recently the Skyhooks framework has been re-developed to ensure that security is at the heart of the framework and any concern around PII/GDPR are addressed. At this time we have over 100+ active customers utilizing this service. The new service we are moving to is internally referred to Skyhookv2, as part of the move from the original Skyhook service, the extensions currently in use will need to be re-factored to incorporate changes in the framework supporting data encryption for data-in-motion and data-at-rest.

So, what exactly is a webhook? A webhook (also called a web callback or HTTP push API) is a way for an app to provide other applications with real-time information. A webhook delivers data to other applications as it happens, meaning you get data immediately. Unlike typical APIs where you would need to poll for data very frequently in order to get it real-time. A number of the integrations we have can benefit greatly from a real-time view of other systems or certain workflows mean that without a real-time framework the integration is basically broken.

Here are two popular use-cases we have been developing recently.

Cloud based Guest/Visitor Integrations such as Envoy/SINE and soon TEEM Lobby-Connect rely on a real0-time iteration such that as events are created on the 3rd Party Guest, a webhook event is triggered to ensure the Cloud guest account is reciprocally created inside ClearPass Guest to allow the Guest to signing to the local guest WiFi.
Another workflow that benefits greatly from a webhook framework is MDM integrations. Historically CPPM has polled hourly by default, [some customer poll longer due to the size of their tenant DB], and retrieves endpoint data, ingests this data, parses it and ultimately writes this to the EndpointDb in CPPM. A number of the attributes we have are extremely relevant to the device and how the device should be treated when it access or is on the corporate network. i.e. If a user deploys a blacklisted application or they jailbreak/root the device, its appropriate to quarantine this device on the network. However if we allow a device on the network then the user installs the blacklisted application, CPPM does not know this device is now our of Corporate Security Policy, the MDM vendor know but historically has no way to let CPPM know. Having the MDM system send us a CPPM webhook notification allows us to have a real-time view on the current posture of a device and appropriate respond. The other huge benefits to this process allows a customer to effectively not POLL, as mentioned above the polling can take hours to complete for some of our largest MDM customers, utilizing webhooks to ’trickle-feed’ events through, m such as new-davie or device-retired again allows CPPM to maintain a real-time view of the tenants managed devices.

Also thats the overview and a couple of common use-cases, but what makes Skyhooks tick? So the starting point for this is the service which the 3rd party cloud applications send their webhooks to, this is a service in AWS called a lambda serverless compute, I think of it as a “service as a function”.

From AWS website:

“AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running.*

With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.”

So, thats Part1, your webhook message hits this service, then this data is written into a DB called Firebase, a product built by Google. at this stage data is stored & encrypted per application/customer. Part2 The extension that site on-prem running on ClearPass has a persistent connection to this DataBase and effectively retrieves the data per application/customer. There are per application/customer db keys that are used to encrypt the data in FireBase, these keys must be configured in the extension to allow it access, retrieve and decode the data.

6 - Skyhook Self Service Portal

Using Skyhook Self Service Portal

Skyhook Self Service Portal

The skyhook self service portal can be used to create new skyhook tenants and renew expiring dbAccessTokens for extensions that use our skyhook service. Customers can access the portal on this link https://clearpass.arubanetworks.com/webhooks/skyhook and can login using their HPE passport credentials.

This portal allows administrators to create skyhook tenants for various integrations that support webhook notifications. Upon registering for a skyhook tenant you are provided with a ‘Tenant ID’ that can be used in the “skyhookTenant” field and a DB token that goes in the “dbAccessToken” field of the extension configuration. Once a tenant is registered, the dbAccessToken for the tenant is valid for a year. For an uninterrupted service, customers are required to renew their DB token by logging in to the portal and following the renewal steps. All registered skyhook tenants are mapped under the HPE Passport used to login to the self service portal.

The portal gives a list of all registered tenants including the App name (Integration e.g Jamf, Envoy etc), the expiration date and time until expiration to let administrators choose when they want to renew the DB token as per their convenience.

Using the Skyhook Self Service Portal

Creating a new Skyhook Tenant

Go to https://clearpass.arubanetworks.com/webhooks/skyhook and click on ‘Login with HPE SSO’ option.
Enter your HPE passport credentials to login.

INFO

The HPE passport credentials used to login to the skyhook self service portal should be associated with a tenant that has a valid support license on their HPE Aruba Networking ClearPass Policy Manager. If there are no ClearPass Policy Manager appliances with valid support licenses registered under the HPE passport credentials used to login then the below error is displayed despite the credentials are valid

The landing page displays the skyhook tenants registered with the HPE Passport credentials under the ‘Your Tenants’ page.

INFO

Note that the old tenants created using the legacy manual method will not show up in the self service portal. As an initial onboarding step, a new tenant has to be created. This creates a new new tenant ID and DB Access Token. The tenant ID needs to be updated both within the extension configuration and also in the 3rd party application sending notifications to skyhook. The DB Access Token needs to be updated within the extension configuration.

To create a new tenant Click on ‘Register Tenant’.

INFO

Note that the portal reaches out to the domain “skyhook.clearpassbeta.com” for creating new tenant. The domain and the URL should be allow listed through any endpoint security or SSE solutions installed on the device you are accessing the portal from and also through firewalls that the traffic is traversing through.

https://skyhook.clearpassbeta.com/api/register/<name-of-extension>

If the portal is unable to reach the tenant registration URL, you might see an error as shown below.

Choose the integration name as needed from the ‘App’ dropdown, Enter a suitable label and click on ‘Register’.
The tenant and the DB token is displayed. Ensure to copy / download the details as the token is displayed only once. Once done, click ‘OK’ to return to the ‘Your Tenants’ page.
Once you have the SkyhookTenant and the dbAccessToken, You can continue with the further ClearPass Extension configuration as per the steps decribed in the integration guide for the extension you are installing. Existing integrations which were using legacy manually provisioned tenant ID, would have to ensure that the tenant ID is updated on the third-party application with the new one from self-service portal.

INFO

When configuring Webhook HTTP Servers in the third-party application, please use the following Target URL:

https://skyhook.arubasecurity.net/api/skyhook/{{extension-id}}/{{skyhook-tenant-id}}

Where:

{{extension-id}} can be any of the following depending upon which application you are sending webhooks from

jamf / envoy / sine / processor (for Generic Skyhook Processor) / meraki / teem / airwatch (for VMware Workspace ONE)

{{skyhook-tenant-id}} would be the new tenant ID created from the self-service portal

Example: https://skyhook.arubasecurity.net/api/skyhook/jamf/ab45xxxx-bcd4-cd45-ef34-abcde11xxxxx

TIP

For Envoy integration, ensure that the tenant ID is updated separately for each location to ensure each location is using the new tenant ID to send the notifications

Renewing the DB token

Select the Tenant that needs DB token renewal. You can use the Search box to search for Tenants based on their Tenant name or Label on the upper left corner of the page.
Click on the ‘Renew’ option under the ‘Actions’ column to proceed with the renewal of the DB token.
The tenant and the DB token is displayed. Ensure to copy / download the details as the token is displayed only once. Once done click ‘OK’ to return to the ‘Your Tenants’ page.

INFO

Once the dbAccessToken is renewed, Ensure that you update the dbAccessToken field in the extension configuration immediately to avoid longer service outages as renewing the dbAccessToken disables the existing token.

7 - Skyhook Token Refresh

Steps to update the skyhook dbAccessToken in extension configuration

Updating Skyhook Token

Navigate to ClearPass Guest > Administration > Extensions > Click on the extension for which you want to update the skyhook token > Configuration

Replace the dbAccessToken value, ensure to check the box “Restart extension after updating configuration” and click “Save Changes”

Once the extension is running, check the extension logs to confirm that connection to skyhook is working fine.

INFO

The dbAccessToken only needs to be updated on the extension configuration. You do not have to update the dbAccessToken on the third party system.