Tracking Down Failed Authentication Requests of Wireless Clients

  • 1
  • Question
  • Updated 3 years ago
  • Answered
I'll start off by saying I know nothing about our Aerohive setup nor am I an admin here.  I was tapped for a seemingly unrelated issue which, after much research, brought me here.

One of our users in one of our offices changed their password and ever since, their account has been getting locked out periodically.  After tracking it down as far as I could from the Microsoft side of things, even opening a ticket, we're convinced the lockouts are being caused by a wireless client attempting to authenticate with the old credentials.  Although we've removed the wireless network from the user's iPhone, they're account still gets locked out periodically, and they don't remember ever setting up a connection on another device.

My understanding is that the buffer log (`show log buff`) will show both successful and failed connection attempts, and the log entries will also include the MAC address of the device and the username used in the failed connection attempt.

Once we've figured out what kind of device is connecting (e.g.: android tablet vs iPad vs Dell laptop etc.) it will help us narrow the search scope a bit as we put boots on the ground.


Has anyone gone through a similar exercise or have any suggestions/guidance on how to handle situation like this?

Many thanks!
Photo of JuliusPIV

JuliusPIV

  • 4 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Are you using the built-in RADIUS server or a separate one such as NPS, FreeRADIUS, RADIATOR etc?

I would attempt to review logs at that point in the process to determine any decides with saved credentials that are doing this.

Honestly though, I would solve your problem in a different way...

Have you instead considered enforcing password complexity on users and not using an account lockout after n attempts policy?

Passwords of sufficient complexity are fully resistant to brute force attacks and tools exist to autonomously monitor/audit and flag failed attempts to authenticate.

It is a high impact DoS security vulnerability to enable this type of account lockout where the accounts can be used to attempt to authenticate to a wireless network.

Anybody can maliciously attempt to authenticate with invalid credentials, surgically locking out accounts.

Imagine, for example, if all the high privileged users, such as domain administrators, were subject to this policy and their accounts were locked out.

It is nearly always a mistake therefore to enable this 'feature' in a Windows domain.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
*determine any devices, not decides! Thanks autocorrect.
(Edited)
Photo of JuliusPIV

JuliusPIV

  • 4 Posts
  • 0 Reply Likes
Thanks for the reply Nick - much appreciated!

Yeah, I'm familiar with that strategy too; have read a few compelling articles and several well crafted arguments for that over the years.  However I'm fairly new here so I'm [still] cautious about suggesting things that fall outside my scope of work, even if I was a full blown system engineer for a number of years, managing that exact policy, before stepping into this role.

As to your first question, the short answer is "I don't know" but I've already pinged the team who manages the Aerohives and am waiting for their next update.
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
I'd recommend using the client monitor and keeping an eye on the specific client that's failing, it's an easier way of tracking what's happening to a specific client rather than trying to pick through the full log file.
Photo of JuliusPIV

JuliusPIV

  • 4 Posts
  • 0 Reply Likes
Morning J. Goodnough - thanks for the reply!

Will the Client Monitor show clients that attempt to connect but fail authentication?  As far as we can tell, that's exactly what's happening based on the following:
  1. The user changed their password earlier this year.

  2. Since then, their account has been getting locked out periodically: Sometimes several times a day, sometimes just twice a week, sometimes once or twice over a 3 week period.
    It varies greatly.

  3. They don't have a laptop to begin with, and aside from their iPhone, they haven't attempted to connect any other device to our BYOD network. 

  4. They changed their password again, we issued them a fresh machine just in case it was some service or mapped drive with faulty credentials.
In that situation, how do we go about locating or even blocking the device?
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Client Monitor will indeed show clients attempting to connect but failing auth. Client Monitor will also show you which AP they are trying to auth to, which should help you locate the device. You do need to know the MAC address of the device in order to use Client Monitor, though.
Photo of JuliusPIV

JuliusPIV

  • 4 Posts
  • 0 Reply Likes
Client Monitor will indeed show clients attempting to connect but failing auth.  Client Monitor will also show you which AP they are trying to auth to, which should help you locate the device.
Oh excellent!  That's some good news!  I missed that when calling support or that wasn't made clear.  Either way, that's big.

You do need to know the MAC address of the device in order to use Client Monitor, though.
Therein lies the problem: We don't know what device is failing to authenticate.

These may seem like silly easy questions but I gotta ask since I know nothing about Client Monitor (don't have access to the AP's or Hivemanager) etc.:
  • How long do clients remain in the list?
  • How does one distinguish between clients that failed to auth and those that succeeded?
(Edited)
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Client Monitor will remain active as long as the session to HiveManager is open unless it's stopped earlier. With HMOL, you can only monitor one client at a time.

The answer to your second question is: it's obvious when using the tool, you'll see either auth failure or auth success messages.

--

Given that you said you've opened a Microsoft ticket, I'm going to assume that you're using a Microsoft NPS server to do your RADIUS authentication. In that case, you'll want to examine the event log on that server and look for failed authentications belonging to that user (probably event ID 6273). The event contains a Calling Station Identifier field, which will provide the MAC address of the device in question.

(Edited)