Cisco Firepower Management Centre (FMC) integrates with Cisco Identity Services Engine (ISE) via pxGrid to enable dynamic, identity-based security. Through pxGrid, FMC receives rich contextual information from ISE, including:
- Session Information: username, IP address
- Device Identity & Profiling Data: device type and other profiling attributes
- TrustSec Information (SGTs): security groups, SGT-to-IP mappings, SGT names, and related metadata
Security Groups (TrustSec SGTs) are role-based security labels assigned by ISE to users and devices. By leveraging SGTs within Access Control Policies (ACPs), FMC can enforce identity-based, role-driven access control instead of relying on static IP addresses. The SGT/IP address information is stored in a mappings database on the FTD, which is used to ensure the FTD can associate traffic with the correct SSGT and apply SGT based access control rules.
FMC can also take advantage of device type information gathered by ISE’s profiling engine. This adds another layer of context to ACPs, allowing you to create policies for different types of endpoints—for example, treating devices profiled as a Windows workstation, iPad, printers, cameras or IoT devices differently based on their function and risk level.
This post walks through how to configure the integration between ISE and FMC so that FMC can receive and use this contextual information from ISE in Access Control rules.
Software
The information in this post is based on software versions: –
- Cisco FMC/FTD 7.7
- Cisco ISE 3.4 patch 4
ISE Configuration
To prepare ISE for pxGrid integration, you need to enable the pxGrid persona, turn on the ERS API service, and allow new certificate-based accounts to be automatically approved.
- Navigate to Administration > Deployment
- Edit the ISE node and add the pxGrid persona.
- Click Save
- Navigate to Administration > Settings > API Settings
- Click API Service Settings
- Ensure ERS (Read/Write) is selected
- Click Save
- Navigate to Administration > pxGrid Services > Settings
- Tick Automatically approve new certificate-based accounts
This will ensure that the FMC and other pxGrid integrations will automatically be approved, rather than the administrator approving the pending requests.
Verification
When a device connects via Wired, Wireless or VPN, ISE will profile the device using one of the profiling policies and assign an Endpoint Profile. ISE will pass this profiling Device Type information to the FMC.
- From ISE GUI, navigate to Policy > Profiling > Profiling Policies
Observe all the configured policies, these can be Cisco provided or Administrator created policies, when a device is profiled by ISE it is assigned one of these Endpoint Profiles.
Confirm the Endpoint Profile of an endpoint.
- Navigate to Context Visibility > Endpoints and select the MAC address of a test device
From the screenshot below, we can determine the Endpoint Profile Windows10-Workstation has been applied to the endpoint.
ISE will also transmit the Security Group (SGT) information to the FMC; the SGT are assigned to a connection via the authorisation rules. Confirm the TrustSec Security Groups: –
- Navigate to Work Centers > TrustSec > Components
Observe the defined SGTs, these will be transmitted via pxGrid to the FMC.
FMC Configuration
From FMC version 7.6 or newer, you can now configure the ISE integration using two methods; the old method by importing the ISE PAN/pxGrid CA certificates or the new method by entering the ISE username and password, then the FMC will login to the PAN and download the certificates.
In this scenario, we shall use the new method to establish pxGrid connectivity to ISE.
- Navigate to Integration > Other Integrations
- Select Identity Services Engine
- Select Quick Configuration (New)
- Enter the Primary PAN FQDN/IP Address
- Enter the ISE Username and Password
- Tick Subscribe to Session Directory Topic to receive ISE user session information from the ISE server and SXP topic (optional) to receive updates to SGT-to-IP mappings, used when destination SGT tagging in access control rules.
- Click Test
If the pxGrid certificate on ISE is untrusted it will prompt and require you to Accept or Decline.
- Press Accept
Further tests will be run to ensure pxGrid connectivity to ISE.
- When the test is successful, click Close
- Click Save
Tests will be run again, establishing trust to ISE, testing pxGrid connection, fetching the client certificates and saving the pxGrid connection.
- Click Close
Create Access Control Rules
With the pxGrid integration established between the FMC and ISE, the Endpoint Profile and Security Group information learnt by the FMC and can be used in policies for rule enforcement.
- Login to the FMC and navigate to Policies > Access Control and edit a policy.
- Edit or create a new rule
- Click Dynamic Attributes
Filter by Device Type and you will see the ISE profiles learnt by the FMC.
You can also filter ISE Security Group Tags and use the SGTs in the Access Control Policy.
NOTE – the numerical value of the Employees SGT is 4, the CLI output will use the numerical value rather than the SGT name.
The endpoint used for testing has been profiled by ISE as a Windows10-Workstation and the user connected to that device has been assigned the Employees SGT.
For testing purposes, we shall create two rules: –
- “Device Type” to match on Windows10-Workstation to allow ICMP traffic
- “SGT Rule” to match on Security Group Employees to allow ALL other traffic
Testing/Verification
For testing purposes, we will authenticate Remote Access VPN users connecting from a Windows 10 device and assign the Employees SGT.
From the screenshot below, we can confirm the device has been assigned the Endpoint Profile as a Windows10-Workstation and the Employees Security Group (SGT).
View the CLI Event Logs
- Login to the CLI of the FTD
- Run the command system support firewall-engine-debug and filter on the source IP address of the test client.
From the output below we can see the ICMP connection request matched rule 1 Device Type which is the name of the Access Control rule created to match the device type Windows10-Workstation.
> system support firewall-engine-debug Caution: This could result in high CPU usage and lower throughput. Use filters to mitigate the impact Please specify an IP protocol: icmp Please specify a client IP address: 192.168.21.1 Please specify a server IP address: Monitoring firewall engine debug messages 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 flow setup event 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 New firewall session 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 Starting with minimum 1, 'Device Type', and src network first with zones 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 4, src sgt type: session_directory, dst sgt: 0, dst sgt type: unknown, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 match rule order 1, 'Device Type', action Allow 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 MidRecovery data sent for rule id: 268435458, rule_action:2, rev id:3870562665, rule_match flag:0x1 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 allow action 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 app event with client no change, service changed, payload no change, referred no change, misc no change, url no change, tls host no change, bits 0x5 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 flow first bidirectional event 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 Deleting Firewall session flags=0x11000, logFlags=0x2101 192.168.21.1 8 -> 8.8.8.8 0 1 AS=0 ID=0 GR=1-1 Generating an EOF event with rule_id = 268435458 ruleAction = 2 ruleReason = 0
Generate some HTTPS traffic will not match the “Device Type” rule. From the output below we can confirm HTTPS (443) traffic was transmitted and we can confirm the src sgt: 4 (this is the numerical value of the Employees SGT), we can confirm this traffic matched the rule named SGT RULE and was allowed.
> system support firewall-engine-debug Caution: This could result in high CPU usage and lower throughput. Use filters to mitigate the impact Please specify an IP protocol: Please specify a client IP address: 192.168.21.1 Please specify a client port: Please specify a server IP address: Please specify a server port: Monitoring firewall engine debug messages 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 flow setup event 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 New firewall session 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 Starting with minimum 2, 'SGT RULE', and IPProto first with zones 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 4, src sgt type: session_directory, dst sgt: 0, dst sgt type: unknown, svc 0, payload 0, client 0, misc 0, user 9999997 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 match rule order 2, 'SGT RULE', action Allow 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 MidRecovery data sent for rule id: 268435460, rule_action:2, rev id:3870562665, rule_match flag:0x1 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 allow action 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 InsightDnsListEventHandler: No active DNS entries 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 InsightUrlListActiveHandler: No active URL entries 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 app event with client no change, service changed, payload no change, referred no change, misc no change, url no change, tls host no change, bits 0x5 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 flow tcp established event 192.168.21.1 58710 -> 8.8.8.8 443 6 AS=0 ID=0 GR=1-1 Starting with minimum 2, 'SGT RULE', and IPProto first with zones 2 -> 1, geo 0 -> 0, vlan 0, src sgt: 4, src sgt type: session_directory, dst sgt: 0, dst sgt type: unknown, svc 4624, payload 0, client 2000004624, misc 0, user 9999997
View the GUI Event Logs
- From the FMC GUI navigate to Analysis > Connection > Events
From the screenshot below we can confirm the connection request correctly identifies the Source SGT and Endpoint Profile, which was learnt from ISE. We can also confirm the traffic matched the correct rules.
Verify SGT/IP Mappings on FTD
When an endpoint authenticates through ISE, its IP address and assigned SGT are automatically sent to the FMC. FMC updates its SGT/IP mapping database and then pushes these mappings down to the FTD devices. Without this database, the FTD would have no way to associate incoming traffic with the correct SGT, and SGT-based access control would not function.
- From the CLI of the FTD run the command system support firewall-engine-dump-user-identity-data
- Connect to expert, run the command expert
- Run the command sudo cat /ngfw/var/sf/user_enforcement/user_identity.dump to view the SGT/IP bindings
admin@FTD77:~$ $ sudo cat /ngfw/var/sf/user_enforcement/user_identity.dump We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. For security reasons, the password you type will not be visible. Password: ------------------- Memory totals: ------------------- total available (bytes): 20000000 total used (bytes): 741054 ------------------- IP cache: ------------------- num hosts: 1 num ip/user mappings: 3 num shared users: 0 num ip sxp bindings: 0 num ip abp bindings: 0 host_hash (bytes): 532030 user_ip_hash (bytes): 0 fqdn_to_ips (bytes): 72 ------------------- Subnet cache: ------------------- num subnet sxp bindings: 0 num subnet abp bindings: 0 sxp tree size (bytes): 32 ------------------- User/Group cache: ------------------- num groups: 0 num user/group mappings: 0 group_bit_hash (bytes): 69640 user_group_hash (bytes): 69640 ------------------- Full User/Group cache: ------------------- num user/group mappings: 0 full_user_group_hash (bytes): 69640 ------------------- DNS cache: ------------------- dns_cache_grace_period (seconds): 2 ---------------- IP:USER ---------------- ---------------- Host ::ffff:192.168.21.1 ---------------- ::ffff:192.168.21.1:10000006 realm 0 type 5, username user1 ::ffff:192.168.21.1:10000006 realm 0 type 1, username user1 ::ffff:192.168.21.1:10000007 realm 1 type 5, username user1 ::ffff:192.168.21.1: initialized 1 sgt 4, device_type 446, location_ip ::ffff:192.168.10.41 ::ffff:192.168.21.1: SXP initialized 0 sgt 0 ABP values: None Oid value: None ------------------
As we can see from the output above, we can confirm the IP (192.168.21.1) and SGT (4) binding. For each endpoint connecting, there will be an IP/SGT binding in the mapping database.
Verify FMC receives bindings
When the endpoints are authenticated by ISE, ISE will near instantaneously send the information to the FMC. You can confirm these connection events are received by the FMC.
- From the CLI of the FMC connect to expert mode
- Run the command sudo adi_cli session
> expert admin@FMC77:~$ sudo adi_cli session Password: press 'Ctrl-c' to quit received user session: username user2, ip ::ffff:192.168.21.2, location_ip ::ffff:192.168.10.41, realm_id 0, domain lab.local, type Delete, identity Passive. received user session: username user1, ip ::ffff:192.168.21.1, location_ip ::ffff:192.168.10.41, realm_id 0, domain lab.local, type Add, identity Passive.
From the output above, we can see the delete and add session information received by the FMC for the connection events.