Auth-Fail Feature and Windows 802.1x Supplicant Compatibility

[tironevi]

As per Cisco IOS design when authentication fails the switch sends a simulated EAP-Success message to the client so that DHCP can be implemented by the client. Taking into consideration the dot1x auth-fail command is configured.

However we have noticed that when using the built-in Windows XP SP2 802.1x supplicant and authentication fails, the Windows supplicant does not like this Cisco simulated EAP-Success message and drops the packet, therefore never re-initiating the DHCP process.

I have attached the Microsoft supplicant log indicating the dropped EAP-Success.

We are using catalyst 3750 with IOS 12.2(25)SEE. We have also tried release 12.2(35)xxx but issue persists.

Your suggestions would be appreciated.

Thank You,

ET

[jafrazie]

An EAP-Success is not sent with 12.2(35)SE so please double-check this.

At any rate, the MSFT supplicant does not service the notion of a controlled port, since it's up to the authenticator to grant/deny network access. Also, the status of 802.1X is not married to DHCP either. If it were, it would take forever for machines to get IPs in a non-1X envionment if 1X is enabled on the machine and not upstream on a switch.

Hope this helps,

[tironevi]

A network trace showed an EAP-Failure when using the auth-fail feature on the 12.2(35) IOS. Is this by design or is it a bug?

Here is our issue...Once a workstation is authorized on the network it is put into the default vlan. However if a user logins to the workstation who?s credentials are NOT recognized by the ACS server the port automatically moves to the auth-fail vlan (this is what we want). The issue is that the XP supplicant does not release it?s current IP and try to get an IP from the auth-fail vlan. If we initiate this process manually it works fine.

Also, when we initiate a logoff from the Windows session of the unauthorized user, the vlan the port is assigned to remains associated to the auth-fail vlan. Once the restricted user logs off shouldn?t the vlan associated to the port change back to the default vlan?

Thank you once again for your help,

ET

[pplsi]

Are you in OOB? If so I was told that it will not release without a reboot. They are working on a log off script that is supposed to fix that but the eta isn't til 3Q 2007.

However, IB is suppose to work correctly.

[jafrazie]

An EAP-Failure is by design. This occurs on all failures. The session fails rather normally. After the third (default but configurable) successive failure, the port is conditionally enabled (and placed in the auth-fail-vlan) even though 1X is configured and operating.

At this point, it's up to the supplicant to access the network if it wants to, since the port has been enabled. Without the notion of a controlled port on a supplicant, there's no reason it shouldn't try and access the network ;-).

Once a workstation is authorized on the network, and then subsequently fails for whatever reason, and put on the auth-fail vlan then it's also up to the machine to renew it's IP if it needs to. Optionally, you can configure the auth-fail-vlan to be the same as your default vlan. I guess it's worth pointing out, that you'd have this problem without 802.1X (changing VLANs on the fly for example). Some supplicants can deal with this though.

If an EAPOL-Logoff does not come from a supplicant (and it doesn't by default with Windows-XP) then there's nothing to get the port out of the Auth-Fail-VLAN either (short of link down). You can configure this through registry though. So the answer to your earlier question was no .. it shouldn't.

I'm not sure I understand the "IB" and "OOB" references here though.

Hope this helps,

[tironevi]

What do you mean by out-of-band? The issue occurs when the switchport is authorized by machine authentication and then transitions to auth-fail do to an unauthorized user login. Once the unauthorized user logs-out the port becomes authorized again because machine authentication takes place. However, the port never transitions out of the auth-fail vlan.

Also, who is working on the Out-of-Band fix?

Thanks,

ET

[a.worthington]

Can you please tell me which supplicants can handle the VLAN change and force the network interface to do an ipconfig release/renew? I know the Windows-XP one does not but I don't think the Cisco Secure Services Client does either (unless it's been fixed in recent versions).

This is a question to jafrazie following the Jam 17 post.

[tironevi]

I got it to work with Odyssey Access Manager version 4.6. I did not try the Cisco Client since I am already using Odyssey for Wifi. If you need more info on the Odyssey configuration let me know.

ET

[jafrazie]

CSSC should work for this and is based on RFC 4436.

If your isssue is "getting out" of the Auth-Fail-VLAN, then you need to either configure re-authentication on the port, or unplug the device and plug it back in.

Hope this helps,