Security

This Question came from a class I was in so I may not be able to provide more details.

When IOS devices or Android devices get blacklisted they are locked off the network. Later when the blacklist expires the IOS devices will have to re-enter their Auth credentials. but the Android devices just pop back onto the network with no user intervention or authentication.

is this normal behaviour ? 

Why would the Android not re-authenticate to the network ?

Android devices have a built-in supplicant that could be resubmitting the credentials in the background.  Is that possible?

this could be posible

is there a way to disable this or modify the behaviour

Granted the issue would then be some admin would have to visit settings on each android device

There is not a way to override this.   That is the nature of that device..  What kind of authentication are you using?

Is there a reason why you would want a user to have to re-auth?  It would seem to me that this is working in the most efficient way possible.  Do you do 802.1x?  If the user has a valid account I would expect it to hop back on the network when the blacklist expires... If the account has been disabled or time-access changed in radius the user would obviously not be able to connect.

-Dan

The user account in the Internal DB has been removed (deleted) before the MAC address is removed from the blacklist.  As soon as the Android device is removed from the blacklist it hops back on the network even though its user account as been removed. All other devices tested (IOS IPod & IPhone, Windows laptop, Mac laptop, blackberry,...) propt the user to re-authenticate after being removed from the blacklist if their account has been removed from the Internal DB.

This has been tested in my lab on both a 651 controller with built-in AP as well as on a 650 with a 105 AP.  We are running ArubaOS 6.1 FIPS software.

I just tested this in the training class using a 620 controller with a 125 AP running ArubaOS 6.1.2.5 and do not see this behavior.  When I get back to my lab I will make sure what version  of the ArubaOS we are running, and upgrade the software to the latest version if its not already there.

OK, so I finally got back into my lab with a new 650 controller which shiped with ArubaOS 6.1.2.5 with an AP-105 and I do not have this issue with Android, but as soon as I upgrade to ArubaOS 6.1.3 FIPS with an AP-104 I once again have an issue with android devices no being forced to re-authenticate after being blacklisted. 

What you might want to do is to turn on user debugging for that device and see if it is even trying to reauthenticate.  It is the device's responsibility to attempt to reattach to the network.  User debugging will show if it is even trying, OR if the controller is still keeping it off the network.

The device IS reconneting to the network, which is the problem.  After removing the accunt from the internal db and then removing the device from the blacklist it is allowed back on the network.  I am installing the latest FIPS ArubaOS (6.1.4.3) on my controller now and will re-test with it.

---

@jacob.e.miles wrote:

The device IS reconneting to the network, which is the problem.  After removing the accunt from the internal db and then removing the device from the blacklist it is allowed back on the network.  I am installing the latest FIPS ArubaOS (6.1.4.3) on my controller now and will re-test with it.

 

---

What we still do not know is what kind of authentication you are using that requires something to be placed in the Aruba Controller's local database.  Please say what type of authentication and encryption you are using so we can narrow down your issue.

jacob.e.miles, also please only use a single account when posting to a thread to avoid confusion.

This is a standalone controller trunked into a Cisco Router.  We are using the interal db for all authentications. 

wpa2-aes authentication.

---

@jacob.e.miles wrote:

This is a standalone controller trunked into a Cisco Router.  We are using the interal db for all authentications. 

 

wpa2-aes authentication.

---

Are you using PEAP?  Is it Mac address authentication?

If you turn on user debugging, the logs will tell you what is going on while it is happening.

Yes we are uning PEAP.

As soon as I get my controller back up after installing ArubaOS 6.1.4.3 FIPS and the AP re-provisioned I will test again with user debug on.

OK, I just tested with ArubaOS 6.1.4.3 FIPS and now I am receiving a User Authentication Failed after removing the device from the blacklist and the device does not reconnect.

I reboot to the other partition that still has ArubaOS 6.1.3 FIPS and I receive aa Auth success after removing from blacklist and the device would connect even though the users account was disabled in the internal db.

Can we assume that this is closed, since it works on a later version?

I would like to test with a couple other android devices just to make sure.  I have a few older android devices in my other lab that I will be bringing over later today to test with as well.  I want to make sure this is working with most devices we would be seeing on our network before I call it closed.

Understood.  Please turn on user debug so you can have maximum visibility.

OK, lates test results.

I have a local db account that is active, an Android device connects using the account. I then send the command "local-userdb modify username <name> mode disable", then I send "stm add-blacklist-client <mac>", then 10 seconds later I remove the blacklist with "stm remove-blacklist-client <mac>".  The account is still disabled, but the device rejoins the network.

What I'm attempting to do here is to disable an account and have all devices associated with that account kick-off the network.  But, if I re-enable the account I don't want to have to attempt to find and remove the device from the black list, as I may not know the device then.  I am sending the commands to the controller using an SSH session.  Is there a better way of doin this?

even sending a "stm kick-off-sta <mac> <bssid>" the device will reconnect.

Try "aaa user delete mac <mac address of device>"

Wow, thanks that command is exactly what I was looking for!

I have test with several Android devices, a Windws XP labtop, and several iDevices (iPad, iPod touch, and iPhone).

even better is "aaa user delete name <account name>" as this disconnects all devices associated with the specified account.  As long as the account is disabled prior to the above command all devices remain disconnected and are unable to reauthenticate until the account is enabled again.

Thanks for all the help.

Excellent troubleshooting advice! Enabling user debugging and monitoring reauthentication attempts can provide crucial insights into network issues. A proactive approach to identifying and addressing potential connectivity issues. Tech-savvy solutions.Fm Whatsapp