01-09-2025 01:39 PM - edited 01-09-2025 01:40 PM
I understand the fact that you cannot do Device authentication towards EntraID, and the User authentication will happen when the user logs into the laptop. I'm seeing behavior where laptops will authenticate using dot1x successfully, but then suddenly their MAC address will enter the ISE logs doing MAB, it will be profiled to some MFC and it will fail authentication.
Is there any behavior that can explain this? For example a user locking his laptop, will it still do eap-tls auth using the user cert in case of a reauth trigger or something?
01-09-2025 03:20 PM
This sounds like wired NAC.
If the switch configuration is using IBNS 2.0 and there is parallel (concurrent) MAB and 802.1X configured, then ISE will accept both simultaneously for the same endpoint and that can potentially cause issues. If on the other hand, the switch performs strict 802.1X first, then MAB, then an 802.1X authorized endpoint should never cause issues, because the endpoint is authorized on 802.1X (EAPOL frames) and every subsequent Ethernet frame that comes along, will not cause a session restart.
So either your IBNS 2.0 Policy Map needs tweaking, or the IBSN 1.0 interface config has the wrong order/priority configured. Can you share the relevant switch configs
show policy-map type control subscriber
show derived int xxxx (an example interface)
When a user locks their PC, there is no network authentication event. For EAP-PEAP and EAP-TLS, Network authentication events occur when
PC boots (machine auth)
User logs in (user auth)
User logs out (machine auth)
For EAP-TEAP, you can chain the network auths for each of the above, so that user and machine auth happens at the same time.
But none of this should cause a MAB authentication.
01-09-2025 03:34 PM - edited 01-09-2025 03:41 PM
Thank for the reply.
- IBNS1.0 and indeed wired NAC. Do need to add they are wired behind a docking station, but as far as I know it's setup to be in "bypass". (Nevertheless I don't trust docking stations...)
see the attached log below. The user authenticates using a user certificate succesfully. For filtering purposes I created a Profile "employee" (don't mind the longer string at the 11:58:19 entra, I changed the profile name at one point.). Purging happens every 30 days.
1) on 01-02 the user successfully authenticates with user certificate. I created a Profile for these kind of successful attempts together with an Identity Group. MAC is added to the "Employee" Endpoint group.
2) some days later , a MAB for that same MAC enters the logs, it gets succesfully authenticated against the Employee endpoint group.
3) some seconds later the same MAC is profiled as Dell device, which I don't have a policy for , so it's being rejected. I cannot find a reason why this change is happening regarding the profiling and why this is now entering ISE as a MAB request.
port config (open mode)
interface GigabitEthernet1/0/8
switchport access vlan 14
switchport mode access
ip access-group acl_allow_any in
authentication event fail action next-method
authentication event server dead action authorize vlan 14
authentication event server alive action reinitialize
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
storm-control broadcast level 20.00
storm-control multicast level 15.00
storm-control action shutdown
spanning-tree portfast
spanning-tree bpduguard enable
01-09-2025 04:22 PM
As a dirty hack, you could try putting the MAB Authorization Rule high enough in the processing logic, to allow it to always match, even if the endpoint gets profiled as a Dell device. I don't know what your Policy Set looks like, but that would ensure you always catch/Authorize endpoints that are in that Endpoint Identity Group.
But it still bothers me that there is a MAB event at all. It smells of a re-authentication.
What is the output for such an endpoint?
show access-session int x/y/z detail
If you are performing re-authorization (for whatever reason) then you might want to ensure that ISE is returning the following attributes (in my example, 65535 seconds is roughly 18 hours)
These settings tell the switch to NOT terminate the connection whilst a re-auth is happening - if re-auth was successful, then session is re-auth'd and the connection never dropped during that short period. And ther terminate action flag tells the switch to use the LAST SUCCESSFUL method that caused the endpoint to end up in Authorized state - in your case it was 802.1X - that means the switch won't (or should not) consider MAB henceforth. Of course if you shut no/shut or disconnect the link, then the NAC process starts again normally (802.1X first, then MAB).
Give that a try.
01-11-2025 05:06 AM - edited 01-11-2025 05:07 AM
thanks for the info, I have applied this, and will monitor the situation.
keep you posted.
in the meantime stumbled upon similar posts. The first post is also showing a used using the same type of docking with similar issues.
https://community.cisco.com/t5/network-access-control/windows-pc-s-using-mab-instead-of-dot1x-spontaneously/td-p/3928695
https://community.cisco.com/t5/network-access-control/intermittent-authentication-failures-on-wired-pc-using-native/td-p/3839705
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