03-18-2019 09:27 PM - edited 02-21-2020 11:03 AM
Hi there
I am after some best practice advice please - excuse my novice question here but I have tried to cobble together a wired 802.1X policy for a Cat9300 switch for a customer who needs the following logic:
Priority should be 802.1X over MAB (if the client sends EAPOL then perform 802.1X auth)
Start switch auth with MAB first (not 802.1X - this is due to some phones that give up on DHCP)
If MAB failed then try 802.1X
If MAB fails then drop into a fixed VLAN
I thought the requirements were pretty straighforward, but I cannot get my head around the "control policy language" - and in particular, in which cases does one terminate and stop, and when does one terminate and then restart in x seconds?
I think a flow chart for this would explain it all.
If anyone can shed some light on this I would be very grateful
My current config below
show policy-map type control subscriber PORT-AUTH-POLICY-I PORT-AUTH-POLICY-I event session-started match-all 10 class always do-until-failure 10 authenticate using mab priority 10 20 authenticate using dot1x priority 20 event authentication-failure match-first 10 class MAB_FAILED do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 20 class DOT1X_FAILED do-until-failure 10 terminate dot1x 30 class AAA_SVR_DOWN_UNAUTHD_HOST do-until-failure 10 clear-authenticated-data-hosts-on-port 20 activate service-template CRITICAL_AUTH_ACCESS 30 authorize 40 pause reauthentication 40 class AAA_SVR_DOWN_AUTHD_HOST do-until-failure 10 pause reauthentication 20 authorize 50 class DOT1X_NO_RESP do-until-failure 10 terminate dot1x 20 authentication-restart 60 60 class MAB_FAILED do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 70 class always do-until-failure 10 terminate dot1x 20 terminate mab 30 authentication-restart 60 event agent-found match-all 10 class always do-until-failure 10 terminate mab 20 authenticate using dot1x priority 10 event aaa-available match-all 10 class IN_CRITICAL_AUTH do-until-failure 10 clear-session 20 class NOT_IN_CRITICAL_AUTH do-until-failure 10 resume reauthentication event inactivity-timeout match-all 10 class always do-until-failure 10 clear-session event authentication-success match-all 10 class always do-until-failure 10 activate service-template DEFAULT_LINKSEC_POLICY_SHOULD_SECURE
03-19-2019 02:36 AM - edited 03-19-2019 02:39 AM
Hi Arne,
I am also testing ibns v2.0 due to the fact that in Cisco documents they say that you have concurrent Flexauth which should be very helpful to avoid DHCP and PXE timeout.
But i am performing order dot1x and priority dot1x
What i noticed is the fact that dot1x failure time-out is related to the same formula of (dot1x timeout x (max-reauth-req)+1) !!
Which makes me wonder what is the benefit of using IBNS v2.0 other than it's complexity.
Also i noticed that when you have successful authentication it takes around 15 to 20 sec to ping the endpoint !
now back to your question, we have the following class-map:
class-map type control subscriber match-all DOT1X_FAILED
match method dot1x
match result-type method dot1x authoritative (can someone explain what is the meaning of this word?)
I presume it says that dot1x failed because same word is used into the MAB Failure class-map.
Also i found this discussion in the cisco forum which says don't use concurrent flexauth!!
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy05270/?rfs=iqvred
Maybe this link is helpful:
I am really interested in comments from members who already tested and have deep knowledge for IBNS v2.0 because like Arne i am new in this topic.
So any help would be appreciated.
03-19-2019 02:51 PM - edited 03-19-2019 03:33 PM
Hey @bern81 - thanks for the feedback. I am glad I am not alone in this boat. There will always be someone (like us) who is new to the party - but IBNS is not new and I found a nice Cisco Live presentation from Hari Hola (BRKSEC-2691) that goes a little in the right direction. It's a great intro into the subject (just what I needed)
https://www.ciscolive.com/global/on-demand-library.html?search=IBNS#/session/1467135309591001h5tu
But I am still stuck on the actual execution. And yes concurrent auth sounds great but have a look at the LiveLogs as a result - messy. Hari says that it will only create one session in ISE (I guess that means two success auths == one license count? - keep an eye on that too - I didn't even think of that).
What is needed here is a state machine diagram that explains all the possible states and their transitions. It would explain it graphically instead of with words (which can make things confusing). When I see looping constructs like "do-until-failure" then it implies there is a state machine in play. I am sure Cisco has documented this somewhere.
Once I understand what state changes there are, and how to handle them, then building the IBNS 2.0 syntax for "policy-map type control subscriber" should make more sense.
I suppose most folks just use dot1x first because that is the preferred use case. But when you have devices like Avaya/Mitel phones that boot up and stop doing DHCP soon after, then having dot1x mab order can cause issues.
I will try dot1x mab concurrent today to see if that works well for the Phone (MAB), PC (EAP-TLS), Printer(MAB) and AP (EAP-FAST) use cases. I don't like the fact that if I put MAB first, then I can also fill my LiveLog with lots of Failed auths because the devices that connect are not in the MAB Endpoint Group ... 5 seconds later they send an EAPOL and connect.
Thanks for the links. The more I look at this stuff the more questions I have. It's anything but intuitive. If it were done in a structured procedural language (like Python or whatever) then it would make sense to me. When I read these statements I don't know what the switch will do next. Will it stop? Will it repeat? Where does the processing end/stop/repeat? It's giving me a headache now.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide