Why does HiveOS treat different ways of representing the same 802.1X user as being discrete users?

  • 2
  • Question
  • Updated 5 years ago
  • Answered
At the moment, different ways of representing the same 802.1X user are shown as being treated as being discrete users with the application visibility features. Is there are reason for this or is it just an oversight in initial implementation?

It would be great if the system could be fixed/enhanced to treat the following as being equivalent, of course without case sensitivity.

foo@domain
foo@domain.com
domain\foo
domain.com\foo
foo (where the default domain is configured somewhere)

(It would also be useful to parse the identity to always display it in a fully qualified format of foo@domain.com)

Thanks,

Nick
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes

Posted 5 years ago

  • 2
Photo of Tash Hepting

Tash Hepting

  • 55 Posts
  • 29 Reply Likes
Nick,

This wasn't in the original design, but is an interesting idea for an enhancement. We'd have to put in some more configuration to allow the administrator to define how to map the different domains... AEROHIVE\username could be username@aerohive.com or username@aerohive.local, or even something username@corp.aerohive.com depending on how the administrator wanted to handle internal + external DNS resolution.
Photo of Tash Hepting

Tash Hepting

  • 55 Posts
  • 29 Reply Likes
Nick, do you know if the username returned from RADIUS is already normalized regardless of EAP method? i.e. will it return the same name for AEROHIVE\username PEAP auths as well as username@aerohive.com EAP-TLS authentication?

If they do that would be a nice "automatic" way to unify the names without having to explicitly configure domain mappings.
Photo of Tash Hepting

Tash Hepting

  • 55 Posts
  • 29 Reply Likes
And of course, this would be dependent on the other feature request to have the name returned from RADIUS be authoritative...

I suspect that at the end of the day, the ideal way of handling this would be default automatic behavior discussed above, plus the ability to configure overrides in case the RADIUS server is inconsistent or doesn't support returning the username.

I'll chat with PLM on this to get it on their radar.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
You might be interested to know that Cisco managed to implement this in a broken way in their WLCs in earlier releases:

"As an aside to the mechanics of this, if you do this, test your NAS under
simulated user load. We found that our Cisco WLC equipment didn't like
that and leaked internal resources, which eventually ran out. We were
adding some additional information to the username, so we had many more
differences between the outer and inner IDs, and even so it took a few
days for the problem to come to a head.

This should be fixed in latest software, but we haven't re-tested that yet.

It also wouldn't hurt to sniff the resulting EAPOL and any associated packets
to ensure the NAS hasn't figured out some vendor-specific way to leak
that inner identity to the wire/wifi, and of course review your security
expectations between the AS and NAS."


Following on from the last comment, do Aerohive have any plans to implement RadSec?
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Umm, I believe we did implement RadSec between HiveOS devices and our ID Manager. Expanding that to a generic RadSec capability probably involves adding the ability for you to import your own certificates, which I am certain my peers are considering for potential inclusion in some future release.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
This is resolved from my perspective.

I have just tested in 6.1r1 and returning the User-Name AVP works as expected - the accounting User-Name and the identity shown in HiveManager is correct.

Thanks!
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Hey Nick,
Thanks for closing the loop with us, glad we were able to satisfy you!!
Photo of Tash Hepting

Tash Hepting

  • 55 Posts
  • 29 Reply Likes
Great Nick, glad to help!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
1) Here we can see the user purporting to be fakeuser in the EAPOL outer identity (could be headmaster or ceo, for example):



2) The RADIUS server knows better, authoritatively, from the EAP inner identity and returns realuser (it could at this point return the identity normalised):



3) HiveOS accounts with realuser



4) HiveManager shows realuser