In a perfect world, you could authenticate your hosts onto the network with either dot1x or going through a guest portal but the reality is that not every device connected to your network will have the ability to navigate the guest flow or utilize dot1x. Unfortunately, most of us don't live in a perfect world and have to connect devices to our networks such as phones, IP cameras, printers, badge readers, access points, etc so for that reason, profiling comes in. What ISE will do is gather a series of attributes from the NADs that the endpoints are connected to and based on those collections of attributes, ISE is able to make a determination of what kind of device that endpoint is.
ISE already has a large list of pre-created profiles and since I enabled the profiler feed, it's being updated with new profiles on a schedule. ISE looks at the endpoints with a simple but effective logic: It looks at a series of endpoint attributes that it receives from probes and basically gives each matched attribute a score. In order to match a profile, it needs to meet a minimum certainty score. Profiling should also be balanced with the security controls that ISE puts in place. For example, if you have a IP camera connected and profiled and it only needs to connect to the CCTV server, it should receive a DACL to the port that limits all but the necessary access.
When we configured our wireless controller and switch, we actually configured our NADs to provide profiling information to ISE. I'm going to go ahead and run though some of the different probe types:
RADIUS Probe:
This is one of the most common probes. ISE can profile based on the RADIUS attributes collected from the RADIUS request/response messages from the RADIUS servers. The NADs must be configured for AAA for this to work. This is probably one of the more critical probes to enable if you were to choose one. I configured this on my switch when I issued the radius-server vsa, radius-server attribute, and aaa accounting dot1x commands. I did not configure it fully on the wireless controller because I chose to have our Called Station ID be AP Mac:SSID instead of System MAC Address. This is perfectly acceptable since it makes it easier to create our policies among multiple SSIDs and I have the SNMP Query probe configured (more details below). The RADIUS probe also listens to CDP, LLDP and DHCP attributes send in RADIUS accounting packets used by the Device Sensor feature. Some of the common RADIUS attributes that are collected are:
- User-Name - Name of the user being authenticated by the RADIUS server (if any)
- Calling-Station-Id - Note: This is usually the MAC address of the endpoint
- NAS-IP-Address - IP address of the network access device requesting authentication
- NAS-Port - Physical port number
- Framed-IP-Address - IP address of the endpoint
- Acct-Session-ID - The unique accounting id
- Acct-Session-Time - Indicates how many seconds the endpoint has received service
- Acct-Terminate-Cause - If a session or connection wasterminated, this will indicate the cause.
There's a lot of information that can be pulled from the RADIUS attributes. ISE can check the vendor OUI based on the MAC, provide a MAC-to-IP mapping binding, and get critical information for troubleshooting if the session terminates.
Looking at one of my profiled hosts on Administration>Identity Management>Identities>Endpoints, I can see the attributes that were collected:
Scrolling further down:
SNMP Trap:
This probe will give ISE information about endpoints connecting or disconnecting from the network. I configured it on the interface with the interface-level snmp trap mac-notification and global context mac address-table notification and snmp-server enable traps mac-notification commands. This is another way of providing MAC information to the ISE deployment. If you have the RADIUS probe configured in your network, you probably won't need to configure this but I did in our switch configuration. In a production environment, you likely would not need as many probes just to to reduce the extra traffic generated.
SNMP Query:
This probe is used to send queries to your NADs to collect endpoint data stored in the SNMP RIBs. It collects details from the NADs such as Interface, CDP, LLDP, and ARP. The NADs must be configured in ISE for SNMP. We enabled this on the switch and wireless controller by setting an SNMP community and when we created the NADs in ISE, we configured ISE to query for information. Some of the useful information that can be pulled from this probe is:
System Queries:
- Bridge, IP (ARP) - Query used to build the IP-MAC ARP Cache table in ISE. It's another way of also getting MAC address information to ISE if you don't have RADIUS probes configured or the DHCP probes couldn't provide that information
- cdpCacheEntry (Wired) - Information provided by CDP
- lldpRemoteSystemsData (Wired) - Information provided by LLDP
- cldcClientEntry (Wireless) - Provides information about clients associated to this AP. An entry is uniquely identified the client's MAC address.
Interface Queries:
- ifIndex, ifDesc, etc - Interface Data
- Port and VLAN data
- Session data if the interface type is Ethernet
- CDP data
- LLDP data
Below are some examples from our SNMP Query:
DHCP Probe:
This is where we send a copy of the DHCP request directly to the ISE server. This is a simple method of getting DHCP traffic to ISE and requires configuration of NADs to relay DHCP packets to ISE. For the WLCs, disable DHCP proxy. This is accomplished with our ip helper-address command on the SVI of the switch. Some of the things that this probe provides to ISE is the following:
- dhcp-class-identifier - This provides platform or OS information
- dhcp-user-class-id - Might be customized with some OSes to provide unique identifiers
- dhcp-client-identifier - This provides a MAC address
- dhcp-message-type - What type of DHCP message this is (i.e. DHCPREQUEST)
- dhcp-parameter-request-list - Can provide unique indicator of the device type since the values and sequence of parameters are often unique to a single or limited set of device types
- dhcp-requested-address - This will provide a IP address
- host-name - Can be used to classify certain types of devices
- domain-name - Can be used to classify certain types of devices
- client-fqdn - Can be used to classify certain types of devices
Below is an example of the DHCP attributes from one of my endpoints:
HTTP Probes:
HTTP probes provide information information from the web browsers themselves. This can include the application type, operating system, software vendor, and software revision. This information is transmitting in a request-header field called the User-Agent. The two types of ways to send HTTP probing is URL redirection or by SPAN. Another important thing about the HTTP probe is that you really need the IP-to-MAC address binding already working in ISE in order to really utilize this information so you need another probe enabled that will pull the IP and MAC address to create that binding.
We previously configured HTTP probes on both our switch and our WLC. On the switch, this was configured with our ISE-ONLY ACL and by enabling ip http server and ip http secure-server. On the WLC, we enabled HTTP and DHCP probing on the SSID itself and under the RADIUS Authentication Server configuration, we enabled support for RFC 3576.
Here is an example of the User-Agent pulling the browser type from my AD server:
DNS Probes:
This is used to acquire the DNS FQDN by doing a reverse DNS lookup from the PSN once an existing endpoint is learned. This cannot be done unless the IP address for the device is known. This was configured on our switch configuration by issuing the ip name-server command.
Netflow Probe:
I have to admit that I don't see this one used in production. You can configure it with a simple Netflow configuration on the switches and WLC. The key information it can provide to ISE is:
- Source IP address
- Destination IP address
- Source port number
- Destination port number
- Layer 3 protocol type
- ToS byte
- Input logical information (ifIndex)
I haven't configured this in my lab but if you wanted to configure it it would be an easy configuration on the switch:
mls netflow interface
mls netflow ip interface-full
mls nde sender
mls nde interface
ip flow-cache timeout active 1
ip flow-export source Vlan100
ip flow-export version 9
ip flow-export destination 10.1.100.21 9996
My recommendation would to be not to turn on this probe as it provides a lot of the same redundant information that other probes do in a less effective way.
NMAP Scan Probe:
The NMAP utility is incorporated into ISE to allow the profiler to detect new endpoints through a subnet scan and to classify endpoints based on their operating system, OS version, and services as detected by NMAP. The network scan probe is considered an "active" assessment mechanism since it communicates directly with the endpoint to obtain information from the source. The can scan also be triggered dynamically based on policy.
This probe performs the following scans of the endpoint:
- Operating system scan
- SNMP port scan
- Common port scan
- Custom port scan
- SMB scan
It will help ISE determine the OS and version of the endpoint, if SNMP ports are open and what common services are enable by what ports are open. This can help you if you'd like to classify devices based on the services they're running or the OS. You can either run the scan manually by navigating to Administration>System>Deployment>ISE-Node>Profiling Configuration and choosing Run Scan under Network Scan. Alternatively, you can run it on demand by navigating to Policy>Policy Elements>Results>Profiling>Network Scan (NMAP) Actions and look at your existing scan actions. You can also create different network scan types here if you'd like to customize it a bit.
If you'd like to assign a network scan action to profiling action, you can navigate to Policy>Profiling and choose a profile to force a NMAP action under a specific profiling policy:
- In my lab, I'm going to scan all workstations that come onto the network.
After a scan is run, there are new attributes you can see about this host:
- EndPointPolicy
- LastNmapScanCount
- NmapScanCount
- OUI
- operating-system
Active Directory Probe
This is a new probe added as of ISE 2.1. It increases the OS fidelity through detailed info extracted from AD. It leverages the AD Runtime Connector and attempts to fetch AD attributes once the computer hostname is learned from the DHCP probe and the DNS probe.
AD queries are gated by:
- Rescan interval (default 1 day)
- Profiler activity for endpoint
Some of the attributes that the AD probe can gather:
- AD-Host-Exists
- AD-Join-Point
- AD-Operating-System
- AD-OS-Version
- AD-Service-Pack
So wrapping up my overview of the probes, there's quite a bit that ISE can tell us about an endpoint that can help identify it:
- It's OUI and likely manufactuer
- What OS and version it's running
- The browser type and version
- The services running on the endpoint
- It's DNS name if there is one mapped to it
- The hostname of the endpoint
- Source and destination ports
- Protocol type
- Parameter request list that often identifies a specific type of device
- CDP/LLDP information that provides even more information
- DHCP vendor class
... and much much more. So which probes do we turn on? It might seem tempting to turn them all on but in a large environment, you might be getting a lot of chatter and redundant information. I would recommend to simply profiling with the Device Sensor that's built into many NADs. It'll have your NADs send endpoint raw data to ISE via RADIUS and some advantages include:
- Doesn't require packet redirections (DHCP Helper) and SPAN sessions for profiling
- Highly scalable and efficient
- Utilizes the RADIUS probe on ISE
The profiling for the Device Sensor is based on:
- CDP/LLDP
- DHCP
- HTTP (WLC Only)
- mDNS
- H325
- MSI-Proxy (4K switch)
To configure the Device Sensor for wired, follow the following instructions:
- Filter DHCP, CDP, and LLDP options/TLVs:
device-sensor filter-list cdp list my_cdp_list
tlv name device-name
tlv name platform-type
device-sensor filter-spec cdp include list my_cdp_list
device-sensor filter-list lldp list my_lldp_list
tlv name system-name
tlv name system-description
device-sensor filter-spec lldp include list my_lldp_list
device-sensor filter-list dhcp list my_dhcp_list
option name host-name
option name class-identifier
option name client-identifier
device-sensor filter-spec dhcp include list my_dhcp_list - Enable sensor data to be sent in RADIUS Accounting including all changes
device-sensor accounting
device-sensor notify all-changes - Disable local analyzer if sending sensor updates to ISE (central analyzer)
no macro auto monitor
access-session template monitor
To configure Device Sensor for wireless, it's configured per WLAN Enable/Disable device profiling by clicking on the Client Profiling under the SSID and checking the box for DHCP Profiling and HTTP Profiling like
Based on the identified devices, we can utilize existing profiles or create a new profile type and then build policies that grant that endpoint *only* the amount of access it needs. For example, if we have a printer profiled, we can lock down access where it only can communicate with certain ports or with a print server.
My lab isn't very complicated so I'mgoing to create a very simple policy. The first thing I'm going to do is navigate to Policy>Profiling>Profiling Policies and drill down to Cisco-Device>Cisco-Access-Point and see some of the different profiler policies for each access point:
If I view one of the profiler policies, I can view some of the checks as well as modify them:
From the above profiler policy, the certainty factor needs to be a minimum of 30 to fall into the Cisco-AP-Aironet-3600 policy. Some of the checks include the cdpCachePlatform information containing the string "cisco AIR-CAP3602" which would be an indicator that the endpoint would be this model of access point.
On the same Policy>Profiling page, I'm going to navigate to the Logical Profiles folder and click Add to create a new logical profile. I'm going to name my logical profile CiscoAP and move the top-level Cisco-Access-Point policy into the Assigned Policies column.
After saving my policy, I'm going to move onto creating a new custom profile. My WLC is a virtual machine so there's not a canned profile for it at the moment so I'm going to create one. By navigating back to Administration>Identity Management>Identities>Endpoints and clicking on my VM endpoint, I am going to focus on certain details about my vWLC even though it's not directly connected to the switch itself:
From the three things I call out above in the overall endpoint attributes, there are two that I'm going to create my profile policy on. These are attributes pulled from a particular SNMP trap:
- sysDescr - This is a value that should include a description of the entity given by the manufacturer
- sysName - This is the attribute that pulls the administratively-assigned name for this node. I'm not going to create my policy based on this but it's good to see to identify the device
- sysObjectID - This is the vendor's authoritative identification of the network management subsystem contained in the entity. It provides an easy and unambiguous means for determining "what kind of box" is this
Next, I am going to navigate to Policy>Profiling>Profiling Policies and click Add. Here I am going to create a policy based on both the sysDescr and sysObjectID:
Now I'm going to create a policy based on the profiled endpoint. Since I don't have a lot of devices connected to my switch, I'm going to create a policy for my access point. As you recall, I don't have Flexconnect enabled on my AP so everything is being tunneled back to the WLC. In this scenario, I can create and test a profile where the AP is profiled and given only the access it needs to communicate with the wireless controller.
The first thing I need to do to create this policy is to create my policy elements. I'm going to start off by navigating to Policy>Policy Elements>Authorization>Downloadable ACLs and click Add. I'm going to create the following DACL:
Name: WLC-ONLY
ACL:
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit ip any host 10.1.100.41
deny ip any any
After saving that DACL, I'll navigate to Policy>Policy Elements>Authorization>Authorization Profiles and click Add. I will create the following authorization profile:
Name: WLC-ONLY
- Check DACL Name and choose WLC-ONLY from the drop-down
- Check VLAN and type in VLAN ID 100
After saving the authorization policy, I'll navigate to Policy>Policy Sets and edit my existing Wired policy. The only thing I need to add is the following rule on top of the other rules in the Authorization Policy:
Name: CiscoAP
if: <any>
Condition(s): Endpoints:LogicalProfile EQUALS CiscoAP
Then: WLC-ONLY
After saving the policy set, I can safely move my access point to an ISE-managed port and check Operations>RADIUS Livelog. I should see the following:
On the actual switch, I can issue the show authentication sessions interface g1/0/23 details command to see what was applied to the port:
As you can see from the above output, dot1x stopped and it succeed for Authc on MAB. The endpoint was put into VLAN 100 (port was originally in VLAN 70) and the WLC-ONLY DACL was applied to the port.
Thanks for reading and that's basic profiling summed up! I hope that helped some of the readers out there.