04-18-2024 09:43 AM - edited 04-21-2024 07:56 AM
One of the first steps to designing and deploying ISE is to gain visibility and understand what is actually out there connecting to the network, so you can design your policy and understand the impact of enacting it.
For some types of endpoints, this is relatively easy (i.e. Windows laptops), but for other, less active/more sensitive endpoints, this can be trickier. Adding authentication commands to enable MAB or 802.1X to your switchport interfaces is one way to force some endpoint interaction with ISE; however, in some environments, this can be overly intrusive and risk downtime if done incorrectly.
The configuration below is an IBNS2.0-based config that puts all access-mode switch interfaces into an authorized state, with no MAB or 802.1X needed, to pull device-sensor information and ship it to ISE for profiling non-intrusively. It is a nice option to use early in a wired deployment to gain visibility without needing to worry about MAB or 802.1X supplicant behavior. You may adapt the sensor filter lists as needed for your environment.
The key/notable commands are access-session monitor, which creates an access session for ALL ports on the switch, and the language of the policy-map which essentially says "immediately authorize the port if a session exists," which it will thanks to the access-session monitor command. This results in all access interfaces having an up session, in an authorized state, without having to interact with the end station at all, and the switch can gather data and send to ISE via device-sensor and RADIUS accounting messages.
The config is distilled from real-world implementation as well as the profiling design guide here - https://community.cisco.com/t5/security-knowledge-base/ise-profiling-design-guide/ta-p/3739456
! *************************************
! *IBNS2.0 visibility config template *
! *************************************
!define a test username for RADIUS
!
username radtest secret <yourSecret>
!
!convert config to IBNS2.0
!
authentication convert-to new-style
!accept by typing yes
!
!
!Define ISE PSNs and add to group
!
radius server PSN1
address ipv4 10.0.0.1 auth-port 1812 acct-port 1813
automate-tester username radtest probe-on
key <yourKey>
!
radius server PSN2
address ipv4 10.0.0.2 auth-port 1812 acct-port 1813
automate-tester username radtest probe-on
key 7<yourKey>
!
aaa group server radius ISE-RADIUS
server name PSN1
server name PSN2
deadtime 15
!
!Define additional RADIUS attributes to send
!
radius-server vsa send accounting
radius-server vsa send authentication
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 10 tries 3
!
!enable PSNs for CoA
!
aaa server radius dynamic-author
client 10.0.0.1 server-key <yourKey>
client 10.0.0.2 server-key <yourKey>
!
!enable AAA method lists
!
aaa authentication dot1x default group ISE-RADIUS
aaa authorization network default group ISE-RADIUS
aaa accounting update newinfo periodic 2880
aaa accounting identity default start-stop group ISE-RADIUS
aaa accounting network default start-stop group ISE-RADIUS
!
!
!configure device-sensor protocol filters
!you can add additional lists like cdp here too as needed, follow the profiling design guide
!
device-sensor filter-list lldp list lldp_list
tlv name port-id
tlv name system-name
tlv name system-description
!
device-sensor filter-list dhcp list dhcp_list
option name host-name
option name interface-mtu
option name parameter-request-list
option name class-identifier
option name client-identifier
!
device-sensor filter-spec dhcp include list dhcp_list
device-sensor filter-spec lldp include list lldp_list
!
!configure device-sensor accounting
!
device-sensor accounting
device-sensor notify all-changes
!
!configure device-tracking
!
device-tracking tracking auto-source
!
!configure IPDT policies for upstream trunk and downstream access ports
!
device-tracking policy Disable_DT_Trunk
trusted-port
device-role switch
!
device-tracking policy IP-Tracking
limit address-count 10
security-level glean
tracking enable
!
!
!enable device-sensor accounting based on the lists created above
!
access-session attributes filter-list list sensor_list
lldp
dhcp
!
access-session authentication attributes filter-spec include list sensor_list
access-session monitor
access-session acl default passthrough
!
!enable dot1x globally
!
dot1x system-auth-control
dot1x critical eapol
!
!configure visibility policy
!
policy-map type control subscriber ISE_VISIBILITY
event session-started match-all
10 class always do-until-failure
10 authorize
!
!enable http captures securely
!
ip http server
ip http secure-server
ip http secure-active-session-modules none
ip http max-connections 40
ip http active-session-modules none
!
!configure Monitor Mode ACLs
!
ip access-list extended AAA-Down
permit ip any any
ip access-list extended ACL_Default
permit ip any any
!
!define RADIUS sourceIF
!
ip radius source-interface Loopback123
!
!enable PSN logging if desired
!
logging host 10.0.0.1 transport udp port 20514
logging host 10.0.0.2 transport udp port 20514
epm logging
!
!enable mac-move SNMP
!
mac address-table notification change
mac address-table notification mac-move
!
!configure visibility on user ports
!
interface range GigabitEthernetx/y/z-zz
service-policy type control subscriber ISE_VISIBILITY
device-tracking attach-policy IP-Tracking
!
!
Verify:
Show access-session
Show device-sensor cache all
I hope this is helpful, please let me know if there are any questions.
Hello Matt,
I'm assuming this article is still relevant with current versions of ISE, even though it's a year and a half old. A question, if I could. We're deploying NAC at our campus and found that Mac OS endpoints will prompt the user for a certificate/identity as soon as open-mode is turned on for their wired port. Presumably this is because 802.1x is enabled by default on Mac OS, whereas it's not on Windows endpoints.
My question is, would the configuration in your post eliminate the prompt on Mac OS? This has been a big sticking point for us because we have a very mixed (heterogeneous) endpoint environment (we're a university) so lot's of Mac's, Windows, Linux, etc. And we have a very mixed endpoint management environment with each college on the campus basically doing their own thing for endpoint management. Point being, we don't have the luxury of pushing configuration profiles to all the Mac OS devices so we can stop the user prompt. The prompt for the users would be very confusing for people and we don't want to cause a huge disruption for users.
Thanks for any thoughts you might have on this.
Sincerely,
Earl Lewis, IT Project Manager
thanks for this info!
@earl.lewis1 the short answer to your question is yes, this should avoid that.
Since we aren’t applying 802.1X config in the ports, EAPoL isn’t even involved and as such the endpoint supplicant shouldn’t detect any auth requirement. It solves this same issue on Windows endpoints as well, which is useful particularly when you have “dumb” endpoints running as kiosk mode and the like. As powerful as the phase 1 Monitor Mode setup is in an 802.1X deployment, EAP/oL is still involved and as such you may still see supplicant interactions that you don’t want - this visibility config avoids that and is a better way to go into a pre-monitor mode state.
Hope that helps.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: