802.1x with ACS (NT SAM reference) & Windows supplicants

[pkapoor]

Testing 802.1x. I have Windows supplicants that authenticate against an ACS server that is tied into the Windows domain user/groups database.

I notice that at times the switch (Catalyst 2950 EIs running IOS) puts the port into the guest vlan. I have to shut/no shut the port to get it authorized into the right VLAN.

Also, some of these ports have VoIP phones. As such, I have the port in a multi-host mode for dot1x.

Any ideas how I can fine tune the configuration (which I think is the issue) so that ports do not get dropped into a guest vlan shortly after the user logs into the workstation?

[jafrazie]

A supplicant being placed in the Guest-VLAN should represent a symptom .. not exactly the problem. IF you upgrade to latest code on the 2950, you should see the ports NOT going into the Guest-VLNA in this type of scenario. The problem itself may be why auth isn't working. Is it failing or timing out?

Also, you should not need multi-host mode to support VoIP.

Hope this helps,

[pkapoor]

Thanks for your time to respond to the post.

I have since made some changes and it seems to have fixed the issue.

1. I removed the guest vlan from the port configuration.

2. I also changed some values on the dot1x config. I increased the max-req and the tx-period.

Your thoughts on this?

Regarding the multi-host option, if it is not required for VoIP, then does it mean that the option is only required when there are more than 1 non-VoIP hosts hooked into the port?

I am next going to try removing the multi-host option and see how it works.

[pkapoor]

An update:

I've observed that if the supplicant is left idle for some amount of time (20 minutes or so), the switch port goes into an unauthorized state. When the user gets back to working, the port will stay in an unauthorized state.

I even tried doing a shut/no shut on the switch port, which should send the EAPOL logon frame and re-establish authentication. No good. Still the port stays in an unauthorized state.

[jafrazie]

If you increase max-req, you are increasing the number of times that an authenticator will re-transmit to a supplicant.

If you increase tx-period, you are increasing the amount of time the switch waits until it may need to retransmit a frame it might not get a response for.

If this increases the amount of time a port takes to be deployed in the guest-vlan and this is the behavior you desire, then OK.

Honestly, it looks like timer-tweaking on the switch has helped you possibly mask an authentication problem, b/c this should work perfectly fine with default timers. See if the supplicant is misbehaving. With other misbehaving supplicants, tweaking timers could make things worse .. not better.

WRT VoIP. Yes, that would be for any other non-VoIP hosts plugged into the same port. Technically, it's anything not speaking CDP to let a port know it's a phone, so it needs to be exempt from 802.1x.

Hope this helps,

[jafrazie]

IS thie 2k or XP?

Do any client logs give any indication of why it's decided to quit doing EAPOL?

[pkapoor]

We're testing with XP.

Since the last post, there has been further progress. I entered the Windows registry hack for SupplicantMode=3 and that seemed to resolve the issue. "Seemed" is the keyword here because I need several tests and scenarios before I can say that it's fixed.

My next step is to set the timeouts and numbers to default. This will tell me whether it was just the guest VLAN and registry hack that did the job for me.

FYI: I do not want the ports to go into a guest vlan - well, at least not so soon after the authentication process has initiated.

[pkapoor]

Here's what I note.

I have configured the registry hack for SupplicantMode=3. If the supplicant host goes into any kind of a standby/sleep mode after an idle time, the user needs to log off and on. Else the supplicant will not initiate any EAPOL start frame and the switch will put the port into an unauthorized state (and not initialize the authentication with an EAPOL frame either).

Looks like this is a Windows supplicant issue. Is there any registry setting that will take care of this?