cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
639
Views
0
Helpful
7
Replies

802.1x Auth-Fail VLAN --- XP does not recognize

magurwara
Level 1
Level 1

With Auth-Fail VLAN configured on Cisco 3550 the Switch successfully configures the port to the configured auth-fail vlan upon unsuccessful authentication. The PC even gets the IP address from DHCP.

However, the Windows XP network icon on the task bar continues to display as if it is trying to configure the network. The popup text displays "Attempting to authenticate" whereas the PC is fully connected and able to communicate on the network.

Any idea...????

7 Replies 7

jafrazie
Cisco Employee
Cisco Employee

This has been fixed in the latest code. 12.2(35)SE. For the MSFT supplicant, it should be cosmetic in nature.

For my curiosity?

Are you also using workstation authentication for 802.1x. In our environment we are seeing the issue with XP;

Upon Windows startup the workstation is authenticated and the switchport is added to the switch's default VLAN and the workstation is assigned an IP address from that VLAN. Once an unauthorized user logins to the same workstation, the switchport transitions to the auth-fail mode but XP never releases/renews it?s IP address in order to get an IP address form the auth-fail vlan.

Thank You,

ET

Not sure what you're curious for ;-).

What you're also describing should not typically occur. If a machine-authenticated machine is attached to the network and then a user logs in, Kerberos actually occurs first, not 1X.

At any rate, even if it would to occur (say a machine/user was just sitting there and failed re-auth) then you are correct. There's nothing to really tell the machine that it's now on the worng subnet (which is optional mind you). After the failure, it's up to the supplicant to access the network if it needs to, and determine if it's on the right segment. There are supplicants out there that can handle this, but I don't think the MSFT supplicant is one of them.

Most of the time, the auth-fail-vlan is useful upon a new connection event. Changes in session context may not be that ubiquitous (as you're evidently experiencing).

Does this help?

This occurs if a user authenticates to the workstation using local credentials, not domain credentials.

I was surprised to hear that magurwara (first post) has DHCP working in XP when using the auth-fail option. I was interested in knowing how he/she got it working.

BTW...I have also opened a case with Microsoft.

Thank you for your help.

ET

I'm interested in that too. Unless it's a connection event (where DHCP would work normally anyway). Apologies from before BTW, I was assuming everything was a domain account ;-).

I am performing machine authentication against MS AD. It does get an ip address from the authentication VLAN but not before minor delay...(have seen up to a minutes delay in some cases).

The following is working fine in my case:

Machine Authenticaiton (S) ---> User Auth (S) then all is good.

Machine Auth (S) ---> User Auth (F) transition to Auth Fail VLAN

Machine Auth (F) ---> Machine is in AuthFail VLAN then User Auth (S) Machines transitions to correct access VLAN (or RADIUS assigned VLAN).

There are times when the behaviour is a bit variable in terms of VLAN assignment. Reading the IOS guide it makes sense if you are not assigning VLAN through RADIUS then switch sometimes tends to leave the port in the currently assigned VLAN, which depending on the port state (success/fail) could be the access VLAN or the AuthFail VLAN.

What is the "authentication vlan"? For 802.1X, there's no concepts of a VLAN until after 1X is done.

And unless you have re-auth turned on, or link doesn't go down, I'm not sure how you have your scenario3 working.

Not sure this helps, but how did you get DHCP working for scenario2?