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.
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.
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.
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.
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:
@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.
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):
@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
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 port-control auto
authentication timer reauthenticate server
authentication violation restrict
dot1x pae authenticator
dot1x timeout tx-period 5
spanning-tree bpduguard enable
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.