Filter-ID reply with Raritan KVMs

Alan DeKok aland at deployingradius.com
Mon Aug 30 22:20:16 CEST 2021


On Aug 30, 2021, at 3:53 PM, Jonathan Davis <jonathan at prioritycolo.com> wrote:
> 
> I'm trying to setup Radius with Raritan KVMs. Authentication works, Access-Accept is sent, but I'm having trouble with the Filter-Id.

  In short, the Filter-Id just a bit of text.  The NAS is supposed to interpret it.

> The Raritan documentaion states:
> 
> When a RADIUS authentication attempt succeeds, the Dominion KX II
> device determines the permissions for a given user based on the
> permissions of the user's group.
> Your remote RADIUS server can provide these user group names by
> returning an attribute, implemented as a RADIUS FILTER-ID. The
> FILTER-ID should be formatted as follows:
> Raritan:G{GROUP_NAME}
> where GROUP_NAME is a string, denoting the name of the group to
> which the user belongs.

  I'm not sure I understand that.  It's a rather opaque way to describe something.  And a very opaque way to design something.  There's just no need for this kind of complexity.

>         post-auth {
>                 exec
>                 update reply {
>                         &Filter-Id = "Raritan:G{Admin}"

  That does sound like it follows their documentation.

> Admin user exists on the Raritan, and is part of the Admin group (defaults on the device). I feel like I'm missing something obvious, but I've been looking at https://freeradius.org/rfc/rfc2865.html#Filter-Id and it doesn't seem like there is really all that much to mess with?

  Yup.

  If it doesn't work, ask Raritan what's supposed to happen.  FreeRADIUS is sending the right thing (apparently).

  Generally speaking, if the NAS ignores the attributes sent from FreeRADIUS, then you have to debug the NAS.  No amount of poking FreeRADIUS will fix a problem on the NAS.

  Alan DeKok.




More information about the Freeradius-Users mailing list