802.1X Cisco 3850 Fails on Windows 7 Clients

[Sam Anderson]

Hello,

We recently upgraded our Catalyst 6500 series switch to a stack of 3850 switches. Since the upgrade our Windows 7 clients are no longer able to authenticate via 802.1X, however other switches throughout the environment are able to authenticate Windows 7 clients. It's worth noting that Windows 10 clients do authenticate on the new stack, just not windows 7. Our Radius servers are Windows server 2012 and 2016 servers. The switch is running OSPF and preforms all our internal routing. 

All ports are configured the same way. Dynamic VLAN assignment should move each PC to the correct VLAN after authentication has taken place.

When I run a debug, I get very little information back. I'm at a loss for what to try or look at next.

ROC-CORE#terminal monitor
ROC-CORE#debug dot1x all
All Dot1x debugging is on
ROC-CORE#conf t
ROC-CORE(config)#interface Gi1/0/28
ROC-CORE(config-if)#no shutdown
Sep 4 21:57:24.384: AUTH-EVENT: Host mode is SH/MH. mac_seen flag set in subblock
ROC-CORE(config-if)#
Sep 4 21:57:26.194: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/28, changed state to up
Sep 4 21:57:27.194: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/28, changed state to up
ROC-CORE(config-if)#

This identical configuration works correctly on all our other switches.

Dot1x Config:

!
!
aaa new-model
!
!
aaa group server radius ROC-RADIUS
server name roc-ad12-srv
server name roc-ad16-srv
!
aaa authentication login ActiveDirectory group ROC-RADIUS local
aaa authentication login LocalUSER local
aaa authentication dot1x default group ROC-RADIUS
aaa authorization exec default group ROC-RADIUS local if-authenticated
aaa authorization network default group ROC-RADIUS
aaa accounting dot1x default start-stop group ROC-RADIUS
aaa accounting exec default start-stop group ROC-RADIUS
aaa accounting system default start-stop group ROC-RADIUS
!
!

!
!
ip routing
!

!

dot1x system-auth-control

!

!
ip radius source-interface Vlan254
!

!

!
radius server roc-ad12-srv
address ipv4 10.0.20.5 auth-port 1812 acct-port 1813
key !!!!!!!!!!!!!!!!!!!!!!!!
!
radius server roc-ad16-srv
address ipv4 10.0.20.6 auth-port 1812 acct-port 1813
key !!!!!!!!!!!!!!!!!!!!!!!!
!
!

!
interface GigabitEthernet1/0/1

switchport access vlan 700
switchport mode access
switchport nonegotiate
switchport port-security violation restrict
switchport port-security
authentication port-control auto
authentication periodic
authentication timer reauthenticate 600
mab
dot1x pae authenticator
dot1x timeout tx-period 5
dot1x max-req 5
dot1x max-reauth-req 10
spanning-tree portfast
spanning-tree bpduguard enable

!

!

!

[Ben Walters]

I would look at the RADIUS debug (debug radius) to see what that looks like when a Win 7 client connects. That should give you more information and hopefully point towards the issue. 

The fact that Win 10 clients are authenticating on the new stack may be suggesting something on the client side rather than the switch stack. 

[thomas]

First of all you have both port-security and 802.1X enabled on the switchports which is not recommended - both processes will fight for control of the port.

I recommend you review (and use) the best practice switch configuration in the ISE Wired Access Deployment Guide even though you aren't using ISE. The switch configuration is still relevant. It also includes troubleshooting tips.

You'll want to be more explicit about "no longer able to authenticate" means. You will need to state the actual error on Windows, the switch or even your Windows NPS RADIUS server.