Domain-joined computer and MAB

[jcegar84]

Hello,

Structure, 

- domain network

- dynamic VLAN assignment (Microsoft NPS) but for some testing purpose in the example below is used static vlan assignment 

- Catalyst access switches (C2960X C9200)

- "local domain joined" computers (dot1x authentication via certificate works)

- "foreign domain joined" computer (dot1x authentication as expected does not work)

Requirements:

As expected "local domain joined computers" are passing authentication.

We want to label "foreign domain joined computers" as trusted and allow them to pass authentication via MAB.

Problem is that I can't see in the log on the switch that "foreign domain joined computer" MAC authentication. It seems that computer even does not try MAB authentication. As I can find in some way it is expected behavior for domain joined computers and MAB should be "triggered" by switch. 

Switch configuration: 

switchport access vlan 50
switchport mode access
switchport voice vlan 20
authentication event fail action next-method
authentication event server dead action reinitialize vlan 86
authentication event no-response action authorize vlan 86
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication timer reauthenticate 10800
authentication timer restart 10800
authentication violation replace
mab
dot1x pae authenticator
dot1x timeout quiet-period 2
dot1x timeout tx-period 3
storm-control broadcast level pps 100
storm-control action shutdown
spanning-tree portfast edge
ip dhcp snooping limit rate 50

But I can't see any try for MAB authentication:

086160: Jul 10 09:11:10 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to up
086161: Jul 10 09:11:11 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to up
086162: Jul 10 09:11:14 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to down
086163: Jul 10 09:11:15 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to down
086164: Jul 10 09:11:18 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to up
086165: Jul 10 09:11:19 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to up
086166: Jul 10 09:11:34 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B2F43ECE18
086167: Jul 10 09:11:41 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to down
086168: Jul 10 09:11:42 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to down
086169: Jul 10 09:11:45 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to up
086170: Jul 10 09:11:46 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to up
086171: Jul 10 09:11:58 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B3F43F15F7
086172: Jul 10 09:12:13 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to down
086173: Jul 10 09:12:14 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to down
086174: Jul 10 09:12:16 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B4F43F9415
086175: Jul 10 09:12:17 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to up
086176: Jul 10 09:12:18 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B4F43F9415
086177: Jul 10 09:12:18 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to up
086178: Jul 10 09:12:27 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B4F43F9415
086179: Jul 10 09:14:18 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B4F43F9415
086180: Jul 10 09:18:31 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to down
086182: Jul 10 09:18:32 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to down
086183: Jul 10 09:18:35 CEST: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/30, changed state to up
086184: Jul 10 09:18:36 CEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/30, changed state to up
086185: Jul 10 09:18:41 CEST: %DOT1X-5-FAIL: Authentication failed for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B5F4455828
086186: Jul 10 09:18:42 CEST: %DOT1X-5-RESULT_OVERRIDE: Authentication result overridden for client (c465.1609.1e2d) on Interface Gi1/0/30 AuditSessionID C0A8E51D000007B5F4455828

Changing order to mab dot1x is not solution.

Any suggestion, how to force "foreign domain joined computer" to try MAB after unsuccessful dot1x?

[Arne Bier]

Any supplicant (802.1X configured client network device) will send EAPOL Identify frames when it senses the link is up. Likewise, when the switch senses the link up, it sends EAPOL Start frames. Then the switch processes that and sends it to RADIUS server. If the 802.1X authentication fails, because you don't trust the foreign clients, and likewise, the clients can also abort the EAP conversation because they don't trust the EAP server cert, then you have authentication failure. How you treat that failure determines what happens next. if you return and Access-reject (which is the expected and obvious solution) then the switch processes that as a failed authentication and the endpoint is not authorized - in the case of Low Impact Mode, the pre-auth ACL remains in place and the port is protected, apart from the stuff your pre-auth ACL allows through. But MAB will not be triggered. Why? Because the 802.1X authentication failed and the client did not provide any other traffic on the network adapter. The endless loop begins ...

The solution is to enable the option in Windows, to failback when 802.1X fails. This tells the supplicant to abort 802.1X and send regular traffic (e.g. DHCP request)

[MHM Cisco World]

authentication event no-response action authorize vlan 86 <<- remove this since the client always not response 

debug mab <<- share this 

MHM