[RADIATOR] Adding vendor identifier from sql/file ?

[Hartmaier Alexander]

Hi Patrik,

we're doing that to enrich the requests mostly for improved logging and
use the OSC- VSAs for that:

<ClientListSQL>
     # NASIDENTIFIER: ipaddr or fqdn
     # SECRET: hardcoded
     # Identifier field: hostname
     #   gets copied to the Client-Identifier attribute to know
     #   the real client for proxied requests from the collectors
     # AddToRequest: supportgroup, customer

    GetClientQuery SELECT NVL(device.ipaddr, device.name), \
         'foobar', \
         NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, \
         # extract the hostname from fqdn
         REGEXP_SUBSTR(name, '^[^.]*'), \
         NULL, NULL, NULL, NULL, NULL, NULL, NULL, \
         'TACACSPLUSKey=foobar,' || \
         'OSC-Group-Identifier=' || hsup || ',' || \
         'OSC-Customer-Identifier=' || mcust \
         FROM device

You need to count correctly, the 22nd column holds all AddToRequest
attributes, the 24th the AddToRequestIfNotExist attributes (which we
don't use).

Best regards, Alex


On 2017-02-21 09:45, Hugh Irvine wrote:
> Hello Patrik -
>
> Nice to hear from you btw…
>
> If you already have the IP addresses and the corresponding device type to be used as the Identifier in an SQL database, it would be trivial to generate the list of Client devices with a ClientListSQL statement to instantiate them at run time.
>
> See section 5.10 in the Radiator 4.16 reference manual (“doc/ref.pdf”).
>
> And yes the Identifier is available for both RADIUS and TACACS (you should do some tests though of course).
>
> See the corresponding sections in the manual.
>
> Otherwise, yes there is a PreClientHook, and a ClientHook. Note that a global ClientHook will be run by all Client’s.
>
> cheers
>
> Hugh
>
>
>> On 21 Feb 2017, at 19:03, Patrik Forsberg <patrik.forsberg at ip-only.se> wrote:
>>
>> Hi,
>>
>> Then I'd need to add a client clause for a couple of thousand devices and their respective secret instead of the current setup where most use "default" and only a couple of exceptions. I'm guessing it would be quicker to use "default" for most and add an extra step that just inject a identification of some kind ? I could be wrong ofc!
>> I'm already using sql for "exception" clients so if that is "quick enough" then I guess then implementation is pretty straightforward .. but is the client identifier transferred even when a tacacs client is connecting or only for radius requests ?
>>
>> Regards,
>> Patrik Forsberg
>>
>>> -----Original Message-----
>>> From: Hugh Irvine [mailto:hugh at open.com.au]
>>> Sent: den 20 februari 2017 23:31
>>> To: Patrik Forsberg <patrik.forsberg at ip-only.se>
>>> Cc: radiator at lists.open.com.au
>>> Subject: Re: [RADIATOR] Adding vendor identifier from sql/file ?
>>>
>>>
>>> Hi Patrik -
>>>
>>> Why would you not just use an Identifier in the Client clauses?
>>>
>>> cheers
>>>
>>> Hugh
>>>
>>>
>>>> On 21 Feb 2017, at 02:53, Patrik Forsberg <patrik.forsberg at ip-only.se>
>>> wrote:
>>>> Hello,
>>>>
>>>> Is there a "simple" way to add an attribute to Tacacs/Radius requests from
>>> a sql/file containing for example <ip> and <identifier> ?
>>>> Say for example
>>>> ip = 192.0.2.1
>>>> vendor = Extreme
>>>>
>>>> ?
>>>>
>>>> Preferably without modifying the client clause .. perhaps a pre/post-client
>>> hook or something ? important is that it has to be working for both tacacs and
>>> radius .. so I can use it as handler trigger..
>>>> Regards,
>>>> Patrik Forsberg
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> radiator mailing list
>>>> radiator at lists.open.com.au
>>>> http://lists.open.com.au/mailman/listinfo/radiator
>>>
>>> --
>>>
>>> Hugh Irvine
>>> hugh at open.com.au
>>>
>>> Radiator: the most portable, flexible and configurable RADIUS server
>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
>>> DIAMETER, SIM, etc.
>>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
> --
>
> Hugh Irvine
> hugh at open.com.au
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER, SIM, etc.
> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> http://lists.open.com.au/mailman/listinfo/radiator



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*