This document describes the procedure to configure authentication on switches which use Identity-Based Networking Services (IBNS) 2.0.
IBNS2.0 is the new style of configuring dot1x , which give us flexibility on decision making at the switch level , the global switch configuration will remain the same , the changes are done under the interface level mainly , basically we are using the concepts of policy-maps and classes to apply the actions needed for specific scenarios .
Cisco reccomends that you have basic knowledge of :
AAA server such as ISE 2.x .
Cisco switch IOS/IOS-XE
ISE 2.x .
IBNS 2.0 works on Cisco Common Classification Policy Language (C3PL). Simply put, C3PL is a combination of Class-maps, Policy-maps and Service-Policies.
Class-map is a set of conditions which should be matched in order for a control policy to execute actions, the control class can contain one or more conditions, we can use 3 keywords to specify which conditions to be matched:
Match-all: all conditions must be met so the value of the class map become true
Match-any: one condition must be met so the value of the class map become true
Match-none: none of the conditions must be matched so the value of the class map become true
class-map type control subscriber match-all Critical_DOT1x_authorized Match method dot1x Match result-type aaa-timeout Match authorization-status authorized
In this example, a class map is named Critical_DOT1x_authorized and three conditions under this class must be matched in order to execute the actions. The three conditions are :
AAA timeout which means that server is not responding and there is no fallback method like LOCAL authentication
Authentication method to be dot1x and
The authorization status is authorized ,
In other words the conditions describe the situation were AAA server is dead , port is already authorized and the method used is dot1x .
Policy-map is a combination of events, classes and actions, once an event is triggered, its classes are evaluated to make a decision which actions must be executed.
The events are built in and hardcoded in the switch, in legacy modes we used some events and assigned actions if these events were triggered
IBNS 1 equivalent : authentication event server dead action authorize VLAN x
The event here is the server being marked as dead , and the action was to authorize VLAN x , the default behavior in this case was to authorize the unauthorized ports and assign this VLAN which is called “critical VLAN” , but keeping the already authorized ports when the server was alive to the assigned VLAN . Now let’s see how the configuration changed in IBNS 2.0 regarding the critical VLAN :
policy-map type control subscriber POLICY-A event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x event authentication-failure match-first 10 class Critical_DOT1x_authorized do-all 10 pause reauthentication 20 authorize 20 class Critical_DOT1x_unauthorized do-all 10 activate service-template SP_CRITICAL 20 authorize
Where class Critical_DOT1x_unauthorized is configured as below:
class-map type control subscriber match-all Critical_DOT1x_unauthorized match result-type aaa-timeout match authorization-status unauthorized
and the service template SP_CRITICAL is configured as below:
service-template SP_CRITICAL vlan 320
as per first event and its result the authentication starts with method dot1x , number 10 prior the action authenticate using dot1x is the priority number , the highest number the lower the priority .
the second event is authentication failure, and we are being more specific about the failure in the classes, for example the class Critical_DOT1x_unauthorized which has two conditions:
there must be a AAA timeout , and this can happen when all methods are timing out , including the AAA group servers and the fallback methods if they exist for example : aaa authentication dot1x default group radius local if group radius servers is not responding and fallback happens to method local and it failed then the condition will not be matched , however if instead for example another group of servers was configured with no response or if there is no fallback method then the condition will be matched .
the port in the unauthorized status.
If the request matched these two conditions then the actions will be applied , which in this case here is to activate a service template , a service template is a set of attributes and its values which we can assign to port or session , for example : access list , VLAN , inactivity timer ..etc. as well here we put the port in the authorized status using the action authorize .
The above can be modified to include an access list in the service template for example .
The action assigned to the class Critical_DOT1x_authorized is to pause re-authentication , this is because already authorized sessions reauthenticate with the AAA server based on the timers configured .
With IBNS 2.0,when the AAA server is dead endpoints can be MAB authenticated against a local list of MAC addresses on the switch, configuration will be as below :
username 000c293da43a password 0 000c293da43a username 000c293da43a aaa attribute list mab-local ! aaa local authentication default authorization mab-local aaa authorization credential-download mab-local local ! aaa attribute list mab-local attribute type tunnel-medium-type all-802 attribute type tunnel-private-group-id "150" attribute type tunnel-type vlan attribute type inacl"CRITICAL-V4" !
event authentication-failure match-first 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure 10 terminate mab 20 terminate dot1x 30 authenticate using mab aaa authc-list mab-local authz-list mab-local
this command specify how to handle authentication failures as a result of a nonresponsive host which means it is not responding to EAP packets sent by the switch , in that case this command assign a VLAN which we call guest VLAN for this host :
policy-map type control subscriber POLICY-A event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x event authentication-failure match-first 10 class Critical_DOT1x_authorized do-all 10 pause reauthentication 20 authorize 20 class Critical_DOT1x_unauthorized do-all 10 activate service-template SP_CRITICAL 20 authorize 40 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 activate service-template GUEST
Where class DOT1X_NO_RESP is configured as below:
class-map type control subscriber match-all DOT1X_NO_RESP match method dot1x match result-type method dot1x method-timeout
and the service template GUEST is configured as below:
service-template GUEST vlan 320
Imagine this scenario , a session started , as per the event class and its result, it started with the method dot1x , the switch sent EAP identity request to the client with no response , then the switch retransmitted the same EAP request yet with no response . the last try was reached with no response , EAP failure packet will be sent to the client which is caused by EAP timeout , now the event authentication failure will be triggered. The classes will be evaluated to confirm which actions should be applied : the first 2 classes have the condition aaa timeout which in this scenario will not match this condition , hence the third class which is DOT1x_NO_RESP is reached , the conditions for this class is as below : 1. Method used is dot1x 2. The method dot1x has timed out
at this case, the actions are to terminate dot1x and activate service template which has VLAN.
another action like authenticate using mab priority 20 can be used since dot1x has timed out.
Event server alive
IBNS 1 equivalent : authentication event server alive action reinitialize
this command specifies that the port should be reinitialized if it is critically authorized and RADIUS becomes available.
now how we can implement the same in IBNS 2.0 :
policy-map type control subscriber POLICY-A event session-started match-all 10 class always do-until-failure 10 authenticate using dot1x event authentication-failure match-first 10 class Critical_DOT1x_authorized do-all 10 pause reauthentication 20 authorize 20 class Critical_DOT1x_unauthorized do-all 10 activate service-template SP_CRITICAL 20 authorize 40 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 activate service-template GUEST event aaa-available match-all 10 class CRITICAL_VLAN do-all 10 clear-session 20 class NOT_CRITICAL_VLAN do-all 10 resume reauthentication
Where class CRITICAL_VLAN is configured as below:
class-map type control subscriber match-all CRITICAL_VLAN match activated-service-template SP_CRITICAL
and the class NOT_CRITICAL_VLAN is configured as below:
class-map type control subscriber match-all NOT_CRITICAL_VLAN no match activated-service-template SP_CRITICAL
If the server is dead , as per the policy, the already authenticated clients are kept with their authorization and the reauthentication is paused , while new clients and unauthenticated clients are placed in the critical VLAN , now after some time the server is alive and clients should recover from critical authentication. As per the policy, the already authenticated clients will match the class NOT_CRITICAL_VLAN as no service template is activated for these clients , the action is to resume the reauthentication as we paused it when the server was dead .
But for the clients for which the service template was activated, the session will be cleared so the clients can authenticate again with the AAA server.
Apply service templates to interfaces
The service template is a set of attributes and its values which can be assigned to a port/session .
There are multiple ways to apply a service template:
can be defined locally on the switch , used as one of the Actions per Control Policy locally defined on switch as below:
In the Legacy mode , as per the commands authentication order and authentication priority , the switch behavior was to start with the first method in the order and wait for it to fail or timeout until it proceed with next method as below :
The session manager addresses this limitation in two ways:
The session manager can attempt multiple authentication methods concurrently
The authentication is triggered on reception of a First-Sign-of-Life (FSoL) packet, which could be a DHCP/CDP/ARP or any other packet that has the MAC address of the device in it.
The inactivity timer for an access-session can be assigned in any of these three ways:
Configured on a per port basis using the "subscriber aging inactivity-timer" command
Define it under a service-template and activate it on a session event
Authorization from the RADIUS server [Idle-time-out (28), Terminate-Action (29)] along with the other attributes
Note:The inactivity timer is an indirect mechanism the switch uses to infer that an endpoint has disconnected. An expired inactivity timer cannot guarantee that an endpoint has disconnected. Therefore, a quiet endpoint that does not send traffic for long periods of time may have its session cleared.
an arp-probe can be enabled along with the inactivity-timer, so that the switch periodically sends ARP probes to endpoints in the IP Device Tracking table (which is initially populated by DHCP requests or ARP from the end point). As long as the endpoint is connected and responds to these probes, the inactivity timer is not triggered, and the endpoint is not inadvertently removed from the network.
Map the policy to be applied under the interface
below command is used to map the policy under an Interface in order to apply it :
service-policy type control subscriber <name of the service policy>
An interface template is a container of configurations or policies that can be applied to specific ports. When an interface template is applied to an access port, it impacts all traffic that is exchanged on the port. You can create an interface template using the template command in global configuration mode. In template configuration mode, enter the required commands.
Each template can be bound to a target. Template binding or sourcing can be either static or dynamic. Static binding of a template involves binding the template to a target, like an interface. Only one template can be bound at a time using static binding. Static binding of another template to the same target will unbind the previously bound template. To configure static binding, use the source template command in interface configuration mode, Any number of templates can be bound dynamically to a target.
Hence instead of changing the configuration under each interface, the interface template is used and mapped under the interface then change the template configuration which will be applied to ports which the template is mapped on .
We can assign the interface template dynamically from ISE by using the attribute “cisco-av-pair = interface-template-name=<name of the template>”