Aruba ClearPass: AI assistant (LLM)

Paste this into your AI assistant to have it help configure Aruba ClearPass so the RTA is admitted onto the network. It still pauses for your confirmation and for anything your version does differently.

Configuration prompt

You are helping me configure Aruba ClearPass Policy Manager so the Sophos Remote
Testing Appliance (RTA) is admitted onto the network and can reach its endpoint.
Work through the steps in order and show me the pending change before I save
anything.

CONTEXT:
- This is Network Access Control, not a firewall. ClearPass admits the appliance's
  switch port / MAC address and authorizes it onto a VLAN or role. It does not do
  TLS decryption.
- The RTA is a headless Linux appliance with no 802.1X supplicant, no domain
  membership, and no NAC agent. Under 802.1X or MAB an unknown device like this is
  rejected or dropped into a quarantine / remediation VLAN with no egress.
- The goal is to land the RTA's port / MAC in a segment that has outbound TCP/443
  to connect.remotetesting.secureworks.com (static IPs 3.33.194.251 and
  15.197.255.2). Some appliances also register over HTTPS to
  get.remotetesting.secureworks.com; allow that one by FQDN, since its IPs are not
  static.

STEPS:
1. Get the appliance MAC address the upstream switch will actually learn, from the
   hypervisor / cloud console NIC settings or the DHCP lease. On Hyper-V the NIC has
   MAC spoofing enabled, so confirm the MAC on the switch (show mac address-table)
   rather than trusting the VM settings. Note it as <RTA_MAC> in the format ClearPass
   expects (aa:bb:cc:dd:ee:ff or aabbccddeeff; ClearPass accepts both).
2. Allowlist the MAC. Either add <RTA_MAC> to a Static Host List
   (Configuration > Identity > Static Host Lists > Add, Format = MAC Address), or
   add / update the endpoint record (Configuration > Identity > Endpoints) and set
   Status to Known. Pick one and keep it consistent with the enforcement rule in
   step 3.
3. Confirm the MAC Authentication service and set enforcement.
   - Under Configuration > Services, confirm a service of Type: MAC Authentication
     is active and ordered to match requests from the switch (NAS) the RTA connects
     to.
   - Under Configuration > Enforcement > Policies, open the policy that service uses
     and add a rule that matches the appliance: either Endpoint Status EQUALS Known,
     or Host Name MEMBER OF <RTA_STATIC_HOST_LIST> if I used a Static Host List.
   - Map that rule to an Enforcement Profile that returns the authorized VLAN:
       Tunnel-Type = VLAN
       Tunnel-Medium-Type = IEEE-802
       Tunnel-Private-Group-ID = <VLAN_ID>
     Optionally add the Aruba-User-Role VSA if my controller enforces roles instead
     of or in addition to VLAN tags. That VLAN / role must have the outbound egress
     described in CONTEXT.
4. Bypass posture. The RTA runs no OnGuard agent and cannot pass a health check.
   Confirm the MAC Authentication service has no Posture Compliance configured, and
   that no posture-health condition in the enforcement policy would redirect the
   device to a quarantine or remediation VLAN. If a posture fallback profile exists,
   make sure the MAC / endpoint match rule takes precedence and returns the
   authorized profile first.
5. When the pending configuration is ready, show it to me. After I confirm, trigger
   a fresh authentication (bounce the RTA switch port, or on an Aruba/HPE switch run
   aaa port-access re-authenticate <PORT>) so the change takes effect.

VERIFY:
- In ClearPass Access Tracker (Monitoring > Live Monitoring > Access Tracker), the
  latest request for <RTA_MAC> shows ACCEPT with the expected enforcement profile
  applied.
- The switch port is assigned to the authorized VLAN (show vlan port <PORT> or
  equivalent), and the appliance gets a DHCP lease in the expected subnet.
- From a host on that segment, run:
  nc -vz connect.remotetesting.secureworks.com 443
  A success looks like: Connection to connect.remotetesting.secureworks.com port
  443 [tcp/https] succeeded!

RULES YOU MUST FOLLOW:
- These steps are authoritative. If a menu, command, or option does not match what
  is written here (versions differ), STOP and show me what you actually see. Do not
  guess at equivalent settings or invent CLI syntax.
- Make the narrowest change that allows this one destination. Do not broaden an
  existing rule to "any", and do not disable, bypass, or pause the firewall, TLS/SSL
  decryption, or threat inspection globally to make it work.
- Allowlist connect.remotetesting.secureworks.com. Its two IPs (3.33.194.251 and
  15.197.255.2) are static, but get.remotetesting.secureworks.com (used on some
  platforms) is not, so allow that one BY FQDN, never by a hardcoded IP.
- Do not apply, commit, or deploy the change until I confirm. Show me the pending
  configuration first.
- Change only what these steps describe. Do not alter unrelated rules, objects, or
  policy, and do not touch anything outside allowing this destination.