N2000 Mac Authentication Bypass and 802.1x

The only think I can initially see is that port 3 has no switchport mode. The user guide says it suggest to use switchport mode general. The other settings on the port look alright to me.

While setting up and troubleshooting this kind of config, you can set the switch to monitor mode. If authentication does not work the switch will log some additional information as to why, but wont deny traffic flow. Page 270 of the user guide.

http://dell.to/1H4xyD5

Here are some further show commands that might lend some additional information.

console#show dot1x clients all

console#show dot1x

console#show dot1x interface Gi1/0/3

Hope this helps find the solution.

Are there any guides for the NPS side?  After changing to switchport mode general, my existing 802.1x working computers are working now, and my MAC test devices are now giving IAS_INVALID_AUTH_TYPE

Is there any documentation on the way the N2000 acts when it is being an 802.1x supplicant instead?

Here are the up to date guides for the N-series switches.

http://dell.to/13T8tL4

I don't see one for this specific scenario. On your authentication server do you have the MAC addresses added and associated with credentials? Here is an example using server 2008.

http://bit.ly/1QZV6js

So at this point I have to tombstone this part of the project because Dell can't keep with standards throughout the industry.  The N series sends the MAC as uppercase (and the password), while the 55XX line sends the MAC and password as lowercase (which is standard with most other vendors).  Since we were forced into running both product lines and I don't have the financial resources to update all my switches, this means we can't use the MAC for authentication on these other devices.  

For those who come here looking for closure, the Dell switches use MD5-Challege for their authentication protocol with NPS.  Unfortunately this isn't enabled on newer versions of NPS.  You need to add it via the following Microsoft article:

https://support.microsoft.com/en-us/kb/922574/en-us

Once that is done, you can now use NPS for MAC authentication on your ports.  

The N-Series sends MAC addresses as username and password in all CAPS

The 55xx Powerconnect series sends MAC addresses as username and password in all lowercase

For a 55xx, the following is the code I have:

dot1x system-auth-control

aaa authentication dot1x default radius

interface vlan 1724

dot1x guest-vlan

interface gigabitethernet1/0/1

dot1x host-mode multi-sessions

dot1x guest-vlan enable

dot1x max-req 3

dot1x reauthentication

dot1x mac-authentication mac-and-802.1x

dot1x radius-attributes vlan

dot1x port-control auto

switchport access vlan none

For a N-series, we used the following:

dot1x port-control force-authorized

dot1x system-auth-control

aaa authentication dot1x default radius

dot1x dynamic-vlan enable

authentication enable

interface Gi1/0/3

description "MAB Test"

switchport mode general

dot1x port-control mac-based

dot1x reauthentication

dot1x timeout guest-vlan-period 5

dot1x max-req 3

dot1x unauth-vlan 1724

dot1x mac-auth-bypass

authentication order dot1x mab

authentication priority dot1x mab

exit

Is there any way to change the username/password sent by either an N2000 or Powerconnect 55xx when authenticating to a RADIUS server for MAC Authentication Bypass?  Currently the N2000 sends the username and password as the uppercase version of the MAC Address, which is the opposite of pretty much every other standard, including the implementation on the Powerconnect 55xx. Since we have a mixed environment with both switches, it greatly impacts the ability to allow devices to "roam freely"

Wanted to let you know I am actively researching this. I will post back up once I have any additional information/action plan.

Thanks

I have confirmed there is not a way to change how the credentials are handled by the switch. Something you could try doing, is see if you can add 2 credential entries for each roaming user's MAC address. one in lowercase and one in upper case.

Would it be possible to get this submitted as a bug request, as this is not how the rest of the industry does this.  

I apologize but this is not a bug in the networking OS, it is operating as intended. I am not sure why it was implemented in this manner, but it is not something we can change. If you call in on the phones you might be able to put in a feature request. I believe the feature request actually goes through the sales department, but the phone group will be able to explain the procedure in more detail. 1 (800) 999-3355

That would be great if it is in there.  

Are they fixing the other RADIUS auth bugs as well?

Ordovice, I wanted to chime back in. I did some further research on this. From what I can gather there should hopefully be an implementation in firmware 6.2.6 that may resolve this. I do not know when this firmware will be released. But just wanted to let you know the fix should be in the works.

That is all the information I have access to at this time.

Daniel,

Just wanted to check and see if anyone had maybe put a bug in your ear about when the firmware was going to come out.  Additionally, is there any way to become a beta tester for this?