How to delay the mac-based authentication

[difan]

I want to configure ports for 802.1x authentication with MAC based authentication as fallback. My problem is that, as soon as I plug in my laptop, the switch will use my MAC address for authentication, without giving me a chance to put in username and password on my laptop (Win7 pro) for PEAP.

My laptop is configured to prompt for username and password.. I can still put in the username and password in the popup balloon. Once provided, the switch will still do the 802.1x. However it will fail the first MAC authentication, and the laptop will be put in a wrong VLAN, with the wrong IP, before the followed 802.1x to correct the vlan and IP. 

Is there anyway to delay the MAC auth? For example, always wait for 10 seconds before trying to use MAC for authentication. I am able to tune the timers on Cisco switches. 

I have tried a few timers but none helped my case. Here is my config. Thanks!

radius-server host a.b.c.d key "xxx" acct-port 1813 auth-port 1812
aaa server-group radius "1X" host a.b.c.d
aaa accounting network start-stop radius server-group 1X
aaa authentication port-access eap-radius server-group 1X
aaa authentication mac-based chap-radius server-group 1X
aaa port-access authenticator 23
aaa port-access authenticator 23 client-limit 2
aaa port-access authenticator active
aaa port-access mac-based 23
aaa port-access mac-based 23 unauth-vid 1050

 Forgot to mention that my swith is HP J9727A 2920-24G-PoE+ with WB.16.02.0014

[difan]

Anybody know?

[BobKC]

Nope, I have the same issue and haven't found the answer yet.

The FreeRADIUS wiki page on HP does have an interesting comment that although MAC Auth and 802.1x proceeds simultaneously, the result of the 802.1x will always take precedence. So as long as you refrain from setting different VLANs for each method (which would probably cause DHCP issues - the client would take an address from one VLAN then get switched to another) it should not be an issue.

That said it would be nice to have a proper solution given that Cisco and even HP Comware support a timeout, and ProCurve has so many other timers we can configure just not this one!