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 <[email protected]> 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:[email protected]]
Sent: den 20 februari 2017 23:31
To: Patrik Forsberg <[email protected]>
Cc: [email protected]
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 <[email protected]>
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
[email protected]
http://lists.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
[email protected]
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
[email protected]
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
[email protected]
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
_______________________________________________
radiator mailing list
[email protected]
http://lists.open.com.au/mailman/listinfo/radiator