Blocked user not disconnected for 12+ hours
I'm using WPA2-EAP-TLS to verify certificates, and matching certificates to accounts in LDAP to verify accounts are in good standing. This morning around 7AM local time I blocked an offending user from the wifi network by adding their account to the disabled-users group in the ldap directory. Until 7PM, I got no entries in my log specifying Login incorrect for the offending host until approximately 7PM. The client was able to connect and continue to access the network successfully the entire time. I also effectively kicked the user at the access point after setting the account to disabled. For over 12 hours the user account was able to continue to connect unhindered. Is there a setting in FreeRadius that would allow me to limit this time period, or is it a setting in my access point I would need to set? If no clear answer is available, I can attempt to determine an answer experimentally, but I'd prefer to have an absolute answer from someone knowledgeable.
Christ Schlacta wrote:
This morning around 7AM local time I blocked an offending user from the wifi network by adding their account to the disabled-users group in the ldap directory. Until 7PM, I got no entries in my log specifying Login incorrect for the offending host until approximately 7PM. The client was able to connect and continue to access the network successfully the entire time. I also effectively kicked the user at the access point after setting the account to disabled. For over 12 hours the user account was able to continue to connect unhindered.
Did the user *reconnect* during that time? Or did the user stay connected? Setting a user to blocked simply stops them from connecting the *next* time that they connect. It doesn't kick the off of the network now. If they continued to re-connect during that time, run the server in debug mode to see why. Odds are you made a mistake, and were returning Access-Accept. If the server returns Access-Reject, the user *will not* be able to log in. Alan DeKok.
On Feb 9, 2012 8:03 AM, "Christ Schlacta" <lists@aarcane.org> wrote:
I'm using WPA2-EAP-TLS
This morning around 7AM local time I blocked an offending user from the wifi network by adding their account to the disabled-users group in the ldap directory. Until 7PM, I got no entries in my log specifying Login incorrect for the offending host until approximately 7PM. The client was able to connect and continue to access the network successfully the entire time. I also effectively kicked the user at the access point after setting the account to disabled. For over 12 hours the user account was able to continue to connect unhindered.
How did you disconnect the user from the AP? Did that clear the PMKSA cache entry on the AP? If not, the user could probably continue to use the old PMK until it expired without having to go through EAP authentication. - Jouni
That's actually what ended up happening. The AP's kick functionality does NOT properly clear the PMKSA cache entry, as I discovered through empirical testing, and summarily filed a bug report. On 2/9/2012 06:04, Jouni Malinen wrote:
On Feb 9, 2012 8:03 AM, "Christ Schlacta" <lists@aarcane.org <mailto:lists@aarcane.org>> wrote:
I'm using WPA2-EAP-TLS
This morning around 7AM local time I blocked an offending user from the wifi network by adding their account to the disabled-users group in the ldap directory. Until 7PM, I got no entries in my log specifying Login incorrect for the offending host until approximately 7PM. The client was able to connect and continue to access the network successfully the entire time. I also effectively kicked the user at the access point after setting the account to disabled. For over 12 hours the user account was able to continue to connect unhindered.
How did you disconnect the user from the AP? Did that clear the PMKSA cache entry on the AP? If not, the user could probably continue to use the old PMK until it expired without having to go through EAP authentication.
- Jouni
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 9 Feb 2012, at 22:02, Christ Schlacta wrote:
That's actually what ended up happening. The AP's kick functionality does NOT properly clear the PMKSA cache entry, as I discovered through empirical testing, and summarily filed a bug report.
Which APs exhibit this behaviour? Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
In fact it's the Ubiquiti PicoStation M2. I'd suspect all their AirOS V products exhibit similar behavior, but this is a mostly homogenous environment, and I can't confirm my suspicions. On 2/9/2012 13:31, Arran Cudbard-Bell wrote:
On 9 Feb 2012, at 22:02, Christ Schlacta wrote:
That's actually what ended up happening. The AP's kick functionality does NOT properly clear the PMKSA cache entry, as I discovered through empirical testing, and summarily filed a bug report.
Which APs exhibit this behaviour?
Arran Cudbard-Bell a.cudbardb@freeradius.org <mailto:a.cudbardb@freeradius.org>
Betelwiki, Betelwiki, Betelwiki....http://wiki.freeradius.org/ !
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Christ Schlacta -
Jouni Malinen