"The What?" - In this post I want to cover Identity Based Networking Services (IBNS) 2.0 to include benefits, configuration, & simply a general understanding of it. At first glance it can be a bit overwhelming so hopefully this helps.
"The Why?" - IBNS provides several benefits which include the following:
Session Management identity-based framework
Simpler way to be consistent across access methods/platforms/domains
Less interface configuration via interface template
Customizable features - ACL or assign critical SGT when AAA server is down;
Robust policy-control engine
Framework providing flexible/scalable services to secure clients
Allows separating authentication and authorization transactions between two or more AAA servers
Better way at detecting disconnects from indirectly connected hosts
IBNS main use cases are as follows:
Critical ACL after AAA failures
Radius CoA (Change of Authorization) - IBNS supports CoA requests to manage client sessions
Web Authentication - Access session managers can conduct CoA for web authentication sessions
Interface templates - user defined reusable templates for interfaces which are used to manage interface config in an easier manner
Autoconf - Simplified solution for automatic interface config
"The How?" - Let's start with a brief overview of the components used, how they integrate with each other, & what each component does. The basis of how IBNS works is via C3PL (Cisco Common Classification Policy Language). Which C3PL is composed of class maps, policy maps, & service policies. Think of the correlations like this: class map is the control class, policy maps are the control policy, & the service policies are the control service policy. Another key component used that you will see in the configuration are the service templates.
Now that we have an overview of the components that make up IBNS 2.0 let's breakdown each one.
Control Class - these are a set of conditions that must equal true for the control policy to execute actions. The options for classes can match-all, match-any, or match none.
Service Templates contain attributes that can be used/applied to subscriber sessions through control policies. Example features include ACLs/vlans/spanning-tree config/etc.
Control Policies - these consist of one or more rules which mandates how the policy rules will be evaluated. The control policies consist of a control class, event, one or many actions to take.
Control Service Policy - essentially when you apply the control policy to end user interfaces so they take effect;
Now I will breakdown each component used in an example:
Let's do a quick overview of what an IBNS 1.0 port config may look like before breaking down IBNS 2.0 so that you can see the benefits:
interface GigabitEthernet1/0/2 description Dot1x Access Port switchport access vlan XX switchport mode access ip access-group Base_ACL in authentication order dot1x mab authentication priority dot1x mab authentication port-control auto authentication periodic authentication timer reauthenticate 1800 authentication timer restart 1900 authentication timer inactivity 1700 authentication event fail action next-method mab dot1x pae authenticator dot1x timeout server-timeout 10 dot1x timeout tx-period 10 dot1x timeout supp-timeout 10 spanning-tree portfast spanning-tree bpduguard enable end
Key point here is the benefit mentioned earlier of less port configuration across all access ports! The service templates help solve this issue!
Applying a service template to interfaces:
interface TwoGigabitEthernet1/0/1 ... source template DefaultWiredDot1xClosedAuth ... end
Brief example of what a service template of interface configs may look like:
template DefaultWiredDot1xClosedAuth dot1x pae authenticator dot1x timeout supp-timeout 7 dot1x max-req 3 switchport mode access switchport voice vlan XX mab access-session closed access-session port-control auto authentication periodic authentication timer reauthenticate server service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB !
Let's breakdown the 'PMAP_DefaultWiredDot1xClosedAuth_1X_MAB' control policy. Note that this is a default Closed Auth policy from an SDA deployment; Some notes identified in green:
PMAP_DefaultWiredDot1xClosedAuth_1X_MAB event session-started match-all --event is a new session start 10 class always do-until-failure --default class; continue to execute action in class until failure; new MAC on port initiate dot1x 10 authenticate using dot1x retries 2 retry-time 0 priority 10 --dot1x higher priority than mab event authentication-failure match-first --event is auth failure 5 class DOT1X_FAILED do-until-failure --failure type is class DOT1X_FAILED 10 terminate dot1x --Action terminate dot1x 20 authenticate using mab priority 20 --Action authenticate via mab after dot1x termination 10 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure --AAA server down/unreachable 10 activate service-template DefaultCriticalAuthVlan_SRV_TEMPLATE --Activate specific critical data vlan template 20 activate service-template DefaultCriticalVoice_SRV_TEMPLATE --Activate specific critical voice vlan 30 authorize --authorize hosts 40 pause reauthentication --hold/pause reauth 20 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure 10 pause reauthentication 20 authorize 30 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 40 class MAB_FAILED do-until-failure 10 terminate mab 20 authentication-restart 60 50 class DOT1X_TIMEOUT do-until-failure 10 terminate dot1x 20 authenticate using mab priority 20 60 class always do-until-failure 10 terminate dot1x 20 terminate mab 30 authentication-restart 60 event aaa-available match-all 10 class IN_CRITICAL_AUTH_CLOSED_MODE do-until-failure 10 clear-session 20 class NOT_IN_CRITICAL_AUTH_CLOSED_MODE do-until-failure 10 resume reauthentication event agent-found match-all --If endpoint initiates EAP session, after mab authz, stop all methods, and authenticate host via dot1x 10 class always do-until-failure 10 terminate mab 20 authenticate using dot1x retries 2 retry-time 0 priority 10 event inactivity-timeout match-all --After inactivity-timeout clear authentication session 10 class always do-until-failure 10 clear-session --Clear session event authentication-success match-all event violation match-all 10 class always do-until-failure 10 restrict event authorization-failure match-all --authz failure after authc success 10 class AUTHC_SUCCESS-AUTHZ_FAIL do-until-failure 10 authentication-restart 60 --restart authc !
The service policy works from the top down. Each event has classes which are referenced below. Remember that the classes have match conditions which can be all, any, or none in order for a match result on the given class.
An overview of the control classes in the control policy (which are self explainable once you walkthrough each class). These are referenced in the above service policy under specific events:
class-map type control subscriber match-all AAA_SVR_DOWN_AUTHD_HOST match authorization-status authorized match result-type aaa-timeout ! class-map type control subscriber match-all AAA_SVR_DOWN_UNAUTHD_HOST match authorization-status unauthorized match result-type aaa-timeout ! class-map type control subscriber match-all AUTHC_SUCCESS-AUTHZ_FAIL match authorization-status unauthorized match result-type success ! class-map type control subscriber match-all DOT1X match method dot1x ! class-map type control subscriber match-all DOT1X_FAILED match method dot1x match result-type method dot1x authoritative ! class-map type control subscriber match-all DOT1X_MEDIUM_PRIO match authorizing-method-priority gt 20 ! class-map type control subscriber match-all DOT1X_NO_RESP match method dot1x match result-type method dot1x agent-not-found ! class-map type control subscriber match-all DOT1X_TIMEOUT match method dot1x match result-type method dot1x method-timeout ! class-map type control subscriber match-any IN_CRITICAL_AUTH match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE ! class-map type control subscriber match-any IN_CRITICAL_AUTH_CLOSED_MODE match activated-service-template DefaultCriticalAuthVlan_SRV_TEMPLATE match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE ! class-map type control subscriber match-all MAB match method mab ! class-map type control subscriber match-all MAB_FAILED match method mab match result-type method mab authoritative ! class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE ! class-map type control subscriber match-none NOT_IN_CRITICAL_AUTH_CLOSED_MODE match activated-service-template DefaultCriticalAuthVlan_SRV_TEMPLATE match activated-service-template DefaultCriticalVoice_SRV_TEMPLATE !
A few quick notes before we cap this post off:
If you are running what most call the legacy way (IBNS 1.0) you can actually use the tool Cisco has to convert the configurations to IBNS 2.0. This can be done via:
#authentication display new-style
Actually per Cisco, best practice for transitioning to IBNS 2.0 in the best way possible is to configure a single port using IBNS 1.0, test the transition in non-production environment to get the most accurate IBNS 2.0 configuration that meets your needs, and then deploy in production.
The only way you can transition back to using IBNS 1.0 is if there have been zero changes to the control policy, issued a wr mem, and/or any other IBNS 2.0 configuration changes. If you have performed any of these items then you will not be allowed to revert back. You can revert back via:
#authentication display legacy privileged
Here is a quick way to determine what IBNS mode the NAD is running:
#authentication display config-mode
Some global AAA/radius configurations are different between IBNS 1.0 & 2.0.
The 'aaa accounting dot1x' command is converted to 'aaa accounting identity' in IBNS 2.0 style.
The 'authentication mac-move permit' command is the default in IBNS 2.0, and therefore, the configuration does not show up in the running configuration. If you want to disable mac-move, configure 'access-session mac-move deny' explicitly in the global configuration mode.
The 'device-sensor accounting' command is replaced with the 'access-session attributes filter-list' command set in IBNS 2.0 configuration.
Lastly, once in the new style config mode, the 'show authentication' commands are replaced with show 'access-session' commands for session verification.
Ok, that wraps up this post supporting the understanding of IBNS 2.0, Cheers!