IMC
cancel
Showing results for 
Search instead for 
Did you mean: 

802/MAC authentication test resultsThe attached

 
NeilR
Respected Contributor

802/MAC authentication test resultsThe attached

In one of my previous posts we ended up discussing the behaviors of expiration, cancel, kick out. I decided to test these out as I move to migrate my existing 802 user base and also accomodate guests, wired and wireless.  I wanted to be sure I could deactivate visitors and keep them offline.

 

All my access switches are procurve models. I tested on a 2915-8G running A.15.14.0007 firmware which is recent. 

 

My test clients are an 802.1x user registered via LDAP (MS AD 2008) and a MAC client, created from the authentication failure log.

 

The switch was set for 802 and MAC auth with a reauth period of 10 mins. I have an unauth vlan set for connecitivty for failed authentication.

 

The attached spreadsheet has a table of the results. Comments provide some extra detail

 

Enable or disable at the port level is clear - the switch and imc are consistent.

 

A user can't be canceled or temproarily canceled while on line so they must be disconnected first. 

 

Kick out seems like a logical choice - it sends a disconnect command to the switch, and the users do show as disconnected at the switch  Pings are interupted. And they are removed from online list in IMC. Temporarily.

 

They will reauthenticate to the switch and then back in imc as well. Time it takes varies, but 802 is quicker than MAC.

 

I tried using that offline interval to cancel a user after kicking them out. The interval is long enough for the MAC client but too short for the 802 client. Doesn't help that Kick out and cancel or temp cancel are not on the same page - the time it takes to navigate between them, find and select the user is too long.

 

Blacklisting was next. Blacklist by itself sets the status for the next change, but by itself won't take any further action, so a kick out is required to activate the blacklist setting. This works for both types of authentication and persists. Yeah!

 

Unblacklisting also depends on activation. The reauth period timer successfully reopened the port and connected the clients.

 

Expiration was also tested. I set the client accounts to expire at a specific time. At that time the clients were still authenticated and connected, both at the switch and imc. Waiting for a couple of reauth periods did not change that. So expiration is only functional if the port or client interface are disabled and subsequently re-eanbled.

 

Once an account was expired then re-inspired, and the ports closed from authentication failure, I waited to see what would happen with the reauth timer.

 

Both the switch and IMC did reauthenticate after the timer expired, however the MAC client did not successfully send out/respond to dhcp to move from the unauth vlan to auth vlan provsioned by the service. Not sure if this is related to the switch or the client.

 

The granularity of the state changes is dependent on the reauth timer if you want a quick response to changes. I have set these times much higher in my current implementation to reduce authentication traffic. But may need to use a shorter interval.

 

Some of these functions did not behave as I would have expected. Expiration should respond after the reauth period expires. Cancel and temp cancel are not functional until the user is off line. Blacklist combined with kick out is the most useful. 

 

Its hard to tell from the docs exactly how these are supposed to behave, so I needed this to sort it out - hopefully helps some one else as well.

 

Now to figure out the best way to register the guest MACs...

 

1 REPLY
Lynn-Marie
Neighborhood Admin

Re: 802/MAC authentication test resultsThe attached

Thanks for sharing!