We're using ACS 1113 Appliance with ACS version 220.127.116.11. via the RADIUS attributes, clients are re-authenticated every 16 hours. The machine cache is set to 12 hours. This means that, if the user doesn't log off within 16 hours, he will be denied network access because of Machine Access Restriction (which is normal).
The problem is, at this point, the SSC client keeps trying and trying to authenticate. It never stops trying until the user logs off or reboots (sometimes this can takes days to weeks (f.e. on vacation). This results in a log entry, every 4 seconds (because of timeout tx-period settings), for every user that is in the MAR. Now you can imagine that, in an environment with 4000 users that the loggings become unusable because of the enormous amount of (unnecessary) failed attempts logs.
I've tried the following dot1x attributes on the switchport but they don't seem to work:
dot1x max-req 3
dot1x max-reauth-req 3
I was hoping they would stop the authentication attempts after 3 unsuccesfull tries, but it doesn't help.
Then I thought I found a solution: the auth-fail vlan. Then we have only 3 logs before the port falls into auth-fail, which is much better.
But, once he is into the auth-fail vlan, he never gets out! I tought that, if the user logs off, the network connection is closed, so at that point the machine authentication would be triggered. But he just stays in the auth-fail vlan until rebooted or the cable is removed. Isn't there any way to trigger the authentication when the user is logged off?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...