Client attempts dot1x even if mab succeeds

[zmabika]

We are running ISE 2.2 Patch 9.  We have noticed that if a client attempts mab and native supplicant is configured for dot1x even if mab succeeds it continues to try dot1x irrespective.
I have tried different scenarios order/priority and fallback mechanisms with no real success, what would you suggest as client has lot of contractors that have dot1x enabled on their devices but we need them to use mab only so we can get them to the contractor portal.

I have shared the screenshot of the RADIUS Live Logs.

[BHAGEMANN]

Are the clients member of an authentication group for dot1X?
If not, how are the switches configured?

Try
authentication order MAB 802.1X
authentication priortiy MAB 802.1X

This should prevent the client from trying dot1X when MAB already was successful.

[zmabika]

Are the clients member of an authentication group for dot1X?

-- No (assuming you mean identity groups).

I have attached the switch config with:

authentication order mab 802.1X
authentication priority mab 802.1X

This works, however we do have machines that have to do dot1x and in this format they all go to CWA.

[hslai]

I believe the DOT1X needs either disabled on the client side or on the switch interface side. On the client side, either stopping the service Wired AutoConfig (dot3svc) or clear the option for "IEEE 802.1X authentication" in the Authentication tab of the wired network adapter connected to the switch.

[zmabika]

We have tried to disable Wired AutoConfig and this also works perfectly, but the customer refuses this option because they have many contractors and they say this won't be feasible. And on the switch side we can not because other employees still require dot1x.

[howon]

Is this result of the endpoint trying to authenticate or the switch requesting identity from the endpoint? I assume the former as MAB was successful, the switch should not request identity from the endpoint unless the customer is using odd authentication/dot1x configuration on the interface. If you share the interface config, it may help. If the endpoint is sending identity on an untrusted network, that is not common as generally the enterprise supplicants are configured not to trust any unknown RADIUS server identity certificate. I understand that in a lab setup one would trust any RADIUS server certificate for testing, but that would be an unlikely scenario. Also, generally endpoints are configured to fallback to non-802.1X network upon 802.1X failure as well.

In addition, as a default, ISE is shipped to detect mis-configured supplicants and ignore the requests so logging on the ISE should be minimal assuming the customer did not change the default RADIUS suppression settings.

Lastly, there are authentication/dot1x timers that you could try out (Bolded ones may be of interest):

3560CX(config-if)#authentication timer ?
  inactivity      Interval in seconds after which if there is no activity from the client then it will be unauthorized (default OFF)
  reauthenticate  Time in seconds after which an automatic re-authentication should be initiated (default 1 hour)
  restart         Interval in seconds after which an attempt should be made to authenticate an unauthorized port (default 60 sec)
  unauthorized    Time in seconds after which an unauthorized session will get deleted

3560CX(config-if)#dot1x timeout ?
  auth-period       Timeout for authenticator reply
  held-period       Timeout for authentication retries
  quiet-period      QuietPeriod in Seconds
  ratelimit-period  Ratelimit Period in seconds
  server-timeout    Timeout for Radius Retries
  start-period      Timeout for EAPOL-start retries
  supp-timeout      Timeout for supplicant reply
  tx-period         Timeout for supplicant retries

Bit old, but some reference of the different timers:

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html#wp387271

[hslai]

@howon, zmabika included a variation of the interface configuration SW_Config.png at her reply to BHAGEMANN. 

@zmabika, IOS platforms and versions may have difference in behaviors, and so is the Windows OS. Thus, please specify the switch model and Cisco IOS release in use, besides the Windows OS versions and editions. BTW, in your initial inquiry, the screenshot seems to show the authentications happening every few seconds. If that is correct, please show the associated switch configuration.

[howon]

Thanks, @hslai. I missed the configuration.

@zmabika Before troubleshooting further suggest removing port-security command from the interface. Also, the authentication event dead action command is incorrectly applied. Please see (port-security and fail-open sections):

https://community.cisco.com/t5/security-documents/top-ten-mis-configured-cisco-ios-switch-settings-for-ise/ta-p/3643912

[Towfique]

@howon We have tested with an interface which didnt have port security and although our authentication event dead action command worked as expected in our scenario we have since changed to the multi-auth version of authentication event with the following interface configs. We have seen positive results after testing and dot1x is not trying unconditionally.

switchport access vlan <vlan id>

switchport mode access

switchport nonegotiate

ip access-group ACL-DEFAULT in

switchport voice vlan <vlan id>

authentication control-direction in

authentication event server dead action reinitialize vlan <vlan id>

authentication event server dead action authorize voice

authentication event server alive action reinitialize

authentication host-mode multi-auth

authentication open

authentication port-control auto

authentication periodic

authentication timer reauthenticate server

authentication violation restrict

mab

dot1x pae authenticator

dot1x timeout tx-period 5

spanning-tree portfast

spanning-tree bpduguard enable

[BHAGEMANN]

I might be wrong, but doesn´t the command "authentication open" mean, that the switch/port completly ignores authenticationmethods like MAB/dot1x? (In switchconfig it does)

I am most likely a greenhorn on networking and ISE but I´d guess for your customer the cleanest solution without loosing the securityaspect is the following: 

1. On customer-side-clients make  an access-group for dot1x 

2. For the clients of the customers of your customer make an extra group with MAB or even no auhtentication and perhaps a seperate V-LAN.

[ognyan.totev]

Hi @BHAGEMANN  authentication open mean that during authentication switch port is in open mode (permit ip any any ) authentication period is about 5-10-15 ms during this authentication port is in open mode .That why ISE have open mode ,closed mode monitor mode ....