"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:
Concurrent Authentication
Critical ACL after AAA failures
IPv6 support
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
...
endBrief 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-styleActually 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-modeSome 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!