Freeradius + HiveManager authentication issue

  • 1
  • Question
  • Updated 3 years ago
Hi all,

We are running HiveManager 6.5r1 on premises. I am looking to authenticate admins via a FreeRADIUS 2.2 instance:

I have set up the RADIUS server on the HiveManager, and the RADIUS server sees the HiveManager as a client. The user database in which the admins are stored is in an OpenLDAP tree, which the RADIUS server (successfully) queries as its backend.

However, any time I'm trying to log in to the HiveManager GUI using an LDAP stored username, the process fails. What is troubling is that based on the debug log, the user is authenticated successfully and I do see the Access-Accept response being sent out, but the HiveManager seems to ignore it.

I understand that if that user doesn't have the AH-HM-Admin-Group-Id VSA set, they would at the very least log in as part of the "Monitor" group, but the RADIUS server even sends that out correctly:

Sending Access-Accept of id 34 to a.b.c.d port 45033 AH-HM-Admin-Group-Id = Company_RW

(Company_RW is configured on HiveManager but I also tried using one of the standard values with no luck)

Any ideas as to what might be going on?
Photo of dreamer

dreamer

  • 10 Posts
  • 1 Reply Like

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
That vendor specific attribute must be sent as an integer. You're not sending a string are you?

Friendly reminder also that FreeRADIUS 2.2.x is EOL.
(Edited)
Photo of dreamer

dreamer

  • 10 Posts
  • 1 Reply Like
Yes, it's an integer indeed. However, again per documentation I would have to at least get Monitor access, right? I understand source FreeRADIUS 2.2.x is EOL, but 2.2.5+dfsg-0.2 is cutting edge for Debian :)

This is the post-auth setting which is being evaluated and returned as TRUE:

if      (Ldap-Group == "hiveadmins") {

        update reply {

        AH-HM-Admin-Group-Id = "10"

        }

}

Proof (sanitized):

? Evaluating (Ldap-Group == "hiveadmins") -> TRUE
++? if (Ldap-Group == "hiveadmins") -> TRUE
++if (Ldap-Group == "hiveadmins") {
+++update reply {
+++} # update reply = noop
++} # if (Ldap-Group == "hiveadmins") = noop
+} # group post-auth = noop
Sending Access-Accept of id 34 to a.b.c.d port 45033
	AH-HM-Admin-Group-Id = Company_RW
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Works for me. I tested using MS-CHAP-v2:



(Edited)
Photo of dreamer

dreamer

  • 10 Posts
  • 1 Reply Like
I found the problem. The four Access-Requests should be a dead giveaway which I foolishly ignored: The HiveManager and the FreeRADIUS server reside on different VLANs which have certain ACLs applied to limit communication. Although RADIUS requests from HiveManager to FreeRADIUS were allowed, replies in the opposite direction were not: The HiveManager never got to see them.

The reason I didn't think of this earlier is that the rest of our Aerohive devices have  RADIUS communication working perfectly fine for at least a year now. However, they reside on yet another VLAN which had the correct ACLs applied, but that didn't prevent me from believing that the HiveManager belonged to that VLAN..

I hope this helps someone else and I apologize for wasting your time Nick.
(Edited)
Photo of dreamer

dreamer

  • 10 Posts
  • 1 Reply Like
As an afterthought, it would be really helpful if the HiveManager logged RADIUS communication somewhere and produced a warning that it was timing out.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
A Service-Type attribute would also be helpful.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I also don't like that the VSA is ambiguous.

HiveOS uses the same attribute differently:

ATTRIBUTE       Aerohive-User-Vlan                  1       integer