Meraki System Manager

  27 minute read  

Introduction

This TechNote covers how to deploy and configure the ClearPass Extension to interface with Meraki System Manager. In this TechNote we will cover the complete installation, configuration and integration between the Extension and ClearPass Policy Manager. The Extension effectively becomes an authorization source to service policies.

With Meraki System Manager hosted in the cloud and ClearPass sitting primarily on-prem, there are challenges in making these two applications communicate in real time on device posture status. Traditionally the apps would communicate using APIs where an application would request information which is usually followed by a response. Hence in order to get real-time information you must poll or request as often as possible which is not scalable. The answer or the solution is a webhook which does not wait for a request to send information but sends the data as soon as it is available.

Before we proceed with the flow, we need to understand the concept of webhooks and skyhook.

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

What is skyhook?

Skyhook 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, it is a service that runs in the Cloud, deployed, developed and managed by Aruba. ClearPass nodes running onprem, use extensions to open a persistent connection into Skyhook to receive the events originally sent from a 3rd party cloud application specific for that customer/tenant. As an overview, Meraki System Manager running in the cloud will send a webhook upon an alert notification. This will communicate with Skyhook. The ClearPass extension configured and installed will maintain a persistent connection with Skyhook awaiting an event.

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

Pictorial View of the Integration

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

Periodic Sync Mode

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

Ingress Event Processing (IEE):

In this mode we configure an IEE source that results in real time alert notifications from Meraki System Manager. Information in this case is more up to date, but there is the higher overhead of an API call during endpoint authorization. A view of this process is below.

Register and Request for a Skyhook Tenant ID

Skyhook Tenant ID’s can be registered in the skyhook self-service portal by accessing the following link https://clearpass.arubanetworks.com/webhooks/skyhook and instructions on using the skyhook self-service portal is available here: https://arubanetworking.hpe.com/techdocs/NAC/clearpass/integrations/clearpass-extension/skyhook-self-service-portal/

Meraki System Manager Configuration

The ClearPass Meraki System Manager extension communicates with your Meraki System Manager tenant via REST API calls. By default, your Meraki System Manager tenant is not enabled to receive and respond to API calls, so you will need to create a Meraki System Manager API Key to enable API access. In this process an API key should be collected as it will be required to configure the ClearPass Meraki System Manager Extension.

Meraki System Manager API Tenant Configuration

Follow the below steps to configure and collect the data from your Meraki System Manager tenant.

After login, go to Your login name > My profile on the upper right nav-bar as shown below.

Then from under My profile options, scroll down to API Access and click “Generate new API key”.

At this time you will be shown the API key and you will need to copy it for later user in ClearPass, click “I have stored my new API Key” and then “Done”, as shown below.

Meraki System Manager Alert Webhook Configuration

Follow the below steps to configure and collect the data from your Meraki System Manager tenant.

After login, go to System Manager -> Alerts on the left nav-bar as shown below.

Then scroll down to Webhooks and click “Add an HTTP server”. Fill in the “Name” field to anything you prefer. The “URL” field will be “https://skyhook.clearpassbeta.com/api/skyhook/meraki-sm/put-yourskyhook-tenant-id-here” where “put-your-skyhook-tenant-id-here” will be replace with the skyhook tenant ID you received after enrollment. “Shared secret” is a password you specify that is optionally used within the extension to validate the authenticity of the webhook, this needs to be referenced later in the extension configuration. Then click “Save”.

In “Default recipients” add the Webhook alias you created earlier and then create/modify a “Security Alert” that you want to be notified on.

Meraki System Manager Extension Configuration

After installing the Extension, the default configuration will need to be updated.

Edit the three configuration value pairs from the previous steps with your saved values.

Below is an explanation of all of the configuration value pairs. The logLevel, verifySSLCerts and merakiHost should be left as their default settings unless advised by ClearPass TAC or your Aruba SE/Partner. Once you configure these parameters, you can start your extension. Any subsequent reconfiguration requires a restart of the extension.

Extension Configuration options

Configuration attribute	Description	Example/Values
logLevel	Logging level for troubleshooting	"DEBUG", "INFO", "WARN", "ERROR"
verifySSLCerts	Specifies whether SSL certificates should be validated when making requests	true or false
merakiHost	URL for API calls to Meraki	api.meraki.com
merakiApiKey	The API Key from Meraki System Manager configuration	—
endpointSyncSchedule	The CRON schedule used for the sync process	10 3 * * *
endpointSyncOnStart	Specifies whether to run the endpoint sync immediately when the extension starts	true or false
enableSyslogEvents	Enables the processing of syslog events from Meraki System Manager alerts	true or false
syslogServers	Host: IP of the extension gateway; Port: syslog port (usually 514); useTCP: true or false	—
enableSkyhook	Enables or disables the endpoint sync scheduler	true or false
skyhookTenant	The Tenant ID for Skyhook from registration	965abd48-zzzz-aaaa-8164-xxxxxxxxxx
dbAccessToken	The access token for Skyhook (sent from Skyhook registration)	—
sharedSecret	The Meraki System Manager Webhook Secret from alert settings	—
cppmUserName	A ClearPass username used for device profiling	—
cppmPassword	Password for the above ClearPass user	—
bypassProxy	Enable extension to bypass web proxy	true or false

Additional Configuration Notes

If you only want the extension to sync device information to the endpoint database, set the endpointSyncSchedule attributes, and optionally the endpointSyncOnStart attribute.

At a minimum, you’ll need to set these attributes:

• merakiApiKey

• cppmUserName

• cppmPassword

The cppmUserName and cppmPassword attributes are set, the extension can configure endpoint profiling based on data from Meraki System Manager. Create this user in ClearPass, navigate to Administration > Users and Privileges > Admin Users. Click on Add. Set the Privilege Level to Network Administrator.

Configure ClearPass Policy Manager

Multiple methods exist for how ClearPass can utilize the returned data from Meraki System Manager, such as:

• Ensure that the endpoint is managed by Meraki System Manager. If not, perhaps restrict access for the device on the Corporate Network with a role that only allows the user to remediate and enroll the device to Meraki System Manager. This provides a controlled environment where all endpoints are managed.

• Check if the endpoint is meeting compliance requirements set by your company (i.e. Firewall enable, Anti-virus installed, etc)

• Take automated actions on notifications sent from Meraki System Manager.

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

Periodic Sync Mode: Using stored attributes

The Extension can sync data from Meraki System Manager periodically, write this data into the ClearPass EndpointDB, then use the EndpointDB as an authorization source. Also, as part of this sync configuration notifications can be processed for devices that are not meeting company compliance. Why this is useful is that if a device were to fall out of compliance an event can be triggered, and a new enforcement can be processed to handle the violation.

Be aware that this data will not be completely ‘real-time,’ but may be adequate for many use cases. Here’s an example of a ClearPass Role Mapping Policy that utilizes these Meraki System Manager Endpoint Attributes.

Ingress Event Processing: A Real-Time Notification

In this scenario we configure ClearPass Policy Manager to process event notifications. For a complete and more detailed overview of Ingress Event Processing please review the technote “CPPM_TechNote__Ingress_Event_Engine_V1.0.pdf”

Ingress Event Processing uses the Ingress Event Engine [IEE] that is built-in ClearPass Policy Manager. The IEE delivers an extra dimension to the capabilities on how ClearPass Policy Manager can interoperate with Devices and Users. IEE is where an inbound syslog can be the trigger for CPPM to take action on authenticated networks devices & users.

Configuring Ingress Event Processing

Let’s check the basics first….. we need to enable the Ingress Events processing engine. Enable this under Administration-> Server Manager > Server Configuration > [Your CPPM Node] > System as below.

.

Check if Ingress Daemons are Running

As a part of the Ingress framework, we have added two new daemons, check they are running, if they are ‘Stopped’, then start them using the controls as shown below.

Check on the Configured Inbound Ingress Listening Port

As shown above there are a couple of daemons, one of these, the logger service is responsible for listening on the TCP/UDP port defined below [default 514] and ingesting the syslog records on that port, configure the TCP/UDP port from the following location **Administration > Server Manager > Server Configuration > [Your CPPM Node] > Service Parameters [select Ingress logger]… set the TCP/UDP port number required.

Configure Ingress Events Dictionary

This is the actual file which takes the structured/unstructured syslog and turns it into fields/attributes that we can reference within a Namespace. This section of the configuration requires some knowledge of Groks, especially when adding a new Vendor. We supply multiple IEE dictionaries by default and will add more over time. We have provided dictionaries for Juniper, Palo-Alto, CheckPoint and InfoBlox. As you can see below the supplied dictionaries are disabled. Only enable the required dictionaries.

Here you will want to import two new IEE dictionary for Meraki System Manager. One dictionary is used for the polling notifications that provides rich device detail to where we can trigger action on an authenticated device. The other dictionary is used for real-time Alert notification via the Meraki Webhook. Currently the Alert notifications contain very limited information.

Add an Event Source

Next we need to define the event source, go to Configuration > Network > Events Sources > [Add your node].

Add an Enforcement Profile

We need to create a policy under Configuration > Enforcement > Policies that we will use to trigger an action for notification.

Example for Notification Profile

This example is created for email notification, but different notification types can be configured. This is to handle the minimal information provided in Alerts, in some circumstances admins may want some type of notification for device policy change state.

Add an Event Enforcement Policy

Next create an Event Enforcement Policy. Create this under Configuration -> Enforcement -> Policies [add] be sure to select as highlighted below of the Enforcement Type as Event.

Based upon the Meraki System Manager Event Dictionary you enabled, it will determine what is available here in the rules definition. Then expanding the namespace ‘Name’, we see all the fields that are configured in this Ingres Event Dictionary.

In this case we do a check to demonstrate the configuration for a device policy violation notification from the Extension polling. We set the policy to trigger a session re-auth if we see the words “security_policy_violating” in the violatingPolicy field. The other one is for a real-time Alert notification generated by the Webhook. We set the policy to trigger an email if we see the words “Clients are violating” in the alertType field.

Add an Event Service

Now that all of the parsing/enforcement is completed, add the Event Service. Create this under Configuration -> Services -> [add ‘Event-based Enforcement’].

Then set the Service Rule conditions that will trigger the service.

CPPM Access Tracker Logs Examples

Below is an example of the logs that get posted in the CPPM Access Tracker when an ‘Event’ occurs. The below is filtering just on ‘Events’ in Access Tracker.

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.

Periodic Sync Mode

If you are configuring the extension to poll Meraki System Manager 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.

Ingress Event Processing

In this scenario we configure ClearPass Policy Manager to process event notifications. For a complete and more detailed overview of Ingress Event Processing and cluster consideration please review the technote “CPPM_TechNote_-_Ingress_Event_Engine_V1.0.pdf”