Skip to content

Aruba ClearPass: CLI (REST API)

ClearPass has no configuration command line; the scriptable path is the ClearPass REST API. The API covers the identity step of this fix well: adding the appliance MAC to the Endpoints repository with Status: Known, or adding it to a Static Host List. The MAC Authentication service, enforcement policy/profile, and posture bypass are one-time Policy Manager configuration; do those steps in the GUI walkthrough and use the API to script the per-appliance MAC allowlisting below.

Before you start

You will need:

  • The appliance MAC address, <RTA_MAC> (e.g. aa:bb:cc:dd:ee:ff); see step 1 of the GUI walkthrough for where to find it.
  • An API client on your ClearPass server. In ClearPass Guest, go to Administration > API Services > API Clients, create a client with the client_credentials grant type and an operator profile that can manage endpoints and identity, and note the client ID and secret.
  • Your server's own interactive API reference is at https://<CLEARPASS_FQDN>/api-docs; field names below are from ClearPass 6.x and are worth confirming there for your version.

1. Get an access token

curl -sk -X POST "https://<CLEARPASS_FQDN>/api/oauth" \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "<CLIENT_ID>",
    "client_secret": "<CLIENT_SECRET>"
  }'

The response contains an access_token. Export it for the calls that follow:

export TOKEN="<ACCESS_TOKEN>"

2. Allowlist the MAC address

Use whichever option your enforcement policy matches against (see the GUI walkthrough, step 3): the Endpoints repository or a Static Host List.

Option A: Endpoints repository

Create the endpoint record with Status: Known:

curl -sk -X POST "https://<CLEARPASS_FQDN>/api/endpoint" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "mac_address": "<RTA_MAC>",
    "status": "Known",
    "description": "Sophos RTA (engagement <ENGAGEMENT_ID>)"
  }'

If ClearPass has already profiled the appliance (the MAC exists in the repository), update the existing record instead:

curl -sk -X PATCH "https://<CLEARPASS_FQDN>/api/endpoint/mac-address/<RTA_MAC>" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "Known",
    "description": "Sophos RTA (engagement <ENGAGEMENT_ID>)"
  }'

Option B: Static Host List

PATCH submits the whole entry list

host_entries is updated as a single field: the array you send becomes the list's full contents. Always read the current entries first and include them alongside the new MAC, or you will drop every other host in the list.

Read the current entries of your list:

curl -sk "https://<CLEARPASS_FQDN>/api/static-host-list/name/<LIST_NAME>" \
  -H "Authorization: Bearer ${TOKEN}"

Then submit the existing entries plus the appliance MAC:

curl -sk -X PATCH "https://<CLEARPASS_FQDN>/api/static-host-list/name/<LIST_NAME>" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "host_entries": [
      <EXISTING_ENTRIES>,
      {
        "host_address": "<RTA_MAC>",
        "host_address_desc": "Sophos RTA (engagement <ENGAGEMENT_ID>)"
      }
    ]
  }'

If no suitable list exists yet, create one:

curl -sk -X POST "https://<CLEARPASS_FQDN>/api/static-host-list" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "<LIST_NAME>",
    "description": "Sophos RTA allowlist",
    "host_format": "list",
    "host_type": "MACAddress",
    "host_entries": [
      {
        "host_address": "<RTA_MAC>",
        "host_address_desc": "Sophos RTA (engagement <ENGAGEMENT_ID>)"
      }
    ]
  }'

A new list is not enforced by itself

A newly created Static Host List does nothing until an enforcement policy rule references it (Host Name MEMBER OF <LIST_NAME>). Wire that rule in Policy Manager per step 3 of the GUI walkthrough.

3. Service, enforcement, and posture: GUI only

The remaining steps are Policy Manager configuration, not per-appliance data, so this guide keeps them in the GUI where the service/policy editors show the full rule context:

If these are already in place from a previous appliance, the API calls above are the only change needed per RTA.

4. Verify

Confirm the write landed:

curl -sk "https://<CLEARPASS_FQDN>/api/endpoint/mac-address/<RTA_MAC>" \
  -H "Authorization: Bearer ${TOKEN}"

The record should show "status": "Known" (or GET the static host list again and confirm the MAC is present).

The change takes effect on the next authentication event. Bounce the switch port or force a re-authentication:

# On Aruba/HPE switch: force re-auth on the port the RTA is connected to
aaa port-access re-authenticate <port>

Then confirm the ACCEPT in Access Tracker, the port VLAN, the DHCP lease, and egress exactly as in step 5 of the GUI walkthrough.

Remove the entry when the engagement ends

MAB is based solely on MAC address, which can be spoofed. When the engagement ends, reverse the change via the same API: set the endpoint "status": "Disabled" with the PATCH call above, or PATCH the static host list with the appliance MAC removed from host_entries.