Apparent caching of 802.11x access

  • 1
  • Question
  • Updated 3 years ago
When using 802.11x access, system randomly seems to "cache" users...

I have AP setup as a radius server using Active Directory to authenticate....  This works (almost) as intended....(almost means I can't get it to honor ONLY a specific AD OU)...

The part that's not cooperating is when a user logs in...
User connects and is authenticated...
Then the user disconnects and "forgets" their settings
We remove them from the AD OU in question, confirm they're not there....
User reconnects...and is authenticated.... BUT, they're not in the authorized group anymore.

Is this information held some place?

I was able to duplicate this with both a Android and a iPAD device....   

Interestingly enough, another test user -- we tested before adding them to group --- blocked.   Added them to group --- authenticated..... removed them from group.....blocked....

Hence the random part.

I'm wondering if there's something I've missed....   I only use a single AD group, and a single SSID, and for testing it has it's own everything.   Has it's own network policy, it's own SSID, it's own user profile....

It doesn't matter though if I use the same process to our production system... same random memory issue of user that shouldn't be able to log in....
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes

Posted 3 years ago

  • 1
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
Wondering if you ssh into the AP and 'clear auth local-cache|roaming-cache|station|username', do they have to re-authenticate?  If the problem is suspected to be in Microsoft NPS, you might want to turn on logging/accounting to legacy/IAS file (not database) then pull up the log and interpret the csv entries at http://iso.csusb.edu/tools/nps-log-interpreter
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Clearing cache does make the user re-authenticate.

So, then what's doing the caching? Microsoft side?    If so, why would it cache some but not others?

I'll adjust IAS logging and see what comes of that.
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
It sounds like the Aerohive's doing the caching since you're saying that clearing it there makes them re-authenticate.  There's nothing on the NPS side or radius rfc that addresses cache or don't cache.  You'll see an NPS entry for the initial authentication then another when they have to re-authenticate after clearing the user on the AP.  If NPS is sending the same information every time (access-accept vs. access-reject + attributes), the problem's not in NPS.  You could do 'show user' on the AP to see if the uncached ones vs. the cached ones are in the list...
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Actually -- I did do the "show users", and it shows NO users at all...   Realizing this is till in pre-production, I logged in so I knew there should be at least that one user... but nothing listed.

Wondering -- if the caching is happening at the "actual" AP I'm connected to, not the one with Radius config.
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Nope -- not there...     Hmmm...
Photo of Dianne Dunlap

Dianne Dunlap

  • 75 Posts
  • 15 Reply Likes
Well, if you don't see an additional query going to NPS, the caching is happening somewhere in the Aerohives...
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Do you have credential caching disabled?

Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
It is not enabled
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Brian,

You said:

"I have AP setup as a radius server using Active Directory to authenticate.... "

...yet:

"I'll adjust IAS logging and see what comes of that."

The two are mutually exclusive. Just to clear things up, are you using IAS/NPS or the built-in RADIUS server?
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Now that you point it out ---   I am using Active Directory ---   But it's setup in AP as radius on the configs...

We already attempted Radius instead, and there's no means to get back OU attributes that way, so we switched....

Clear as mud?      Not using built-in Radius of Microsoft, even though there is a path to it.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Why do you want to get OU attributes back? You can use either the Tunnel-Private-Group-Id attribute or the Filter-Id attribute to apply a user profile to the connection.

See the discussion here for what attributes to return:

https://community.aerohive.com/aerohive/topics/radius-nps-server-configurations

I would recommend using NPS rather than the built-in RADIUS server.
(Edited)
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Because there's no other way to use AD OU's.

I have now confirmed this with an AH engineer -- (as opposed to tech support itself).

Also, we also cannot use RADIUS this way because it doesn't send attributes back to Aerohive.

We cannot use "user profiles" the way you suggest, because we need a very specific group of users to work.   it would work if we wanted to apply it en-masse....

Not sure exactly what you mean by built-in Radius server -- since it's installed and configured on our AD Server under IAS, I would call that external.  It may just be naming semantics on our part.

In the end, we DO have this working using AD OU's, but "something" is caching credentials because we have several clients that we know were removed from the OU, and they're still working...  With credential caching not enabled, we're not clear what it is that's making it still retained.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Brian,

I was only suggesting something that could potentially circumvent your apparent caching issue.

It should still be looked in to to find out the root cause of the behaviour that you are observing.

Sorry if I didn't make this clear enough - the salient, fundamental point is that there should be no need to use AD OUs.

Rather, from an IAS/NPS perspective, group membership for accounts (user or machine) would instead be used to match an appropriate Network Policy and thus decide which attributes to return when auth occurs, and thus the user profile that is applied to a client's connection.

It can be as granular and specific as you want it to be therefore:

  • You create the appropriate set of security groups and make your users and/or machines members of these as appropriate.
  • You create the appropriate set of Network Policies that check for membership of the appropriate group as a condition for matching the policy.
  • You return the appropriate RADIUS attributes to apply the user profile that you wish to the connection.

When you are using HiveOS's built-in RADIUS server, it binds to a directory directly, IAS/NPS will not be touched - it becomes a completely redundant, unused role/service in Windows at that point.

IAS/NPS implements the RADIUS protocol, it is not a directory server. In a Windows domain, that's what Active Directory is.

It is generally better to deploy in larger environments using RADIUS servers rather than using one that is built-in to access layer equipment such as APs and switches.

Having a RADIUS server in the AP's firmware is a convenience feature, designed to meet the needs of smaller users with simple use cases as it is one less separate thing to understand and manage.

Note that IAS last shipped with Windows Server 2003 that is just about to go EOL, devoid of all support from Microsoft. With Server 2008, it became NPS.

Cheers,

Nick
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Brian,

Just following up on this. If the issue isn't resolved and this hasn't already been suggested by support, do the following commands give you anything?
show aaa radius-server cache
show log buff | include cache
Cheers,

Nick
(Edited)
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
The "radius-server cache" shows my user....  which has not been logged in since Friday's testing...Radius cache shows as "disabled", maximum lifetime=86400, maximum number = 512

Client was able to authenticate --- working as expected...  The "lifetime" number now increments....

Removed user from authentication group....   User remains working....  user disconnected.... I wait until cache should expire ---

Shows user, but "0" lifetime, and not incremented or decremented during any refresh...

Shortly after that, it shows nothing --- like the "0" entry had been removed, and no users were connected at all.... OK, I can buy that...

BUT....  Reconnect user -- and they're in --- AND they no longer show up as active user either.


What I did find was if I manually "deauth" and "clear cache", the user is summarily disconnected, and because they're no longer in authenticated group, they can also not re-connect...  THIS is what I am expecting to occur....without my manual help.


So -- For me the question now is --- IF I manually de-auth a client that was removed from the authorized group, why can't the system do it?  At least, why can't it do it when the cache expires and one would think that would force a re-authentication to occur -- but from everything I can tell, it does not.

Yes, I can de-auth users manually.... that's not the end of the world, but I'm puzzled why this isn't occurring on its own.

Of course, the other caveat to the "manual" method is that I would have to train an entire department that could potentially terminate an employee, how to also terminate their wireless access.....while also indicating that their regular network account when terminated (disabled) stops them from getting into anything on network...   Seems counter....   perhaps there's just something that's getting missed....
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
Forgot to mention ---  For tests, I enabled the caching for 3600 seconds --- so I could tell it was really timing out...

The effect is the same for the client though --- they don't de-auth...
Photo of Bryan Tetlow

Bryan Tetlow

  • 78 Posts
  • 2 Reply Likes
The issue is resolved --- Caching of Local and Roaming was occurring....on the AP....    Adjustments to the SSID, Advanced settings (Inactive Client Ageout, Roaming Cache Update Interval, Roaming Cache Ageout, Local Cache Timeout.

Also, under Advanced Access Security Settings, the Reauth Interval should be unchecked...for whatever reason on this one it was enabled and had a 5 min timing, while all others in use had none.  Also, un-checking non-strict.

Now --- I am sure --- that some of these are not necessary, however in working with support, we just stepped down and up until we got one that worked.  As of this point, if you're removed from the AD group, within 40 minutes of your next disconnection, you're cleared out....  I'm ok with that...  Usually it's someone that's terminated, and unless they're of the disgruntled group, they leave the building, n'er to return....

The one that support indicated we had to be careful with was the "Roaming Cache" settings --- they affect the client's roaming between AP's.... Make it too short and roaming for them will break.

Also,  there is a multiplication factor involved with the roaming cache numbers.... the default settings compute to be 1 hour before the client falls off the roaming list..... At least, that was the explanation.

I can now put this one to rest....   and try to figure out why I have a single user that can't log in using their AD credentials....yet they're valid....   
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Thanks for posting an update, and I'm glad you were finally able to make progress on this.