Radiator 4.12.1 patches now have changes affecting handling unknown
attributes and proxying them.

Unknown attributes are now always accepted. A single warning, not error,
is logged for each unknown attribute per sender. This will reduce the
number of log messages but allows to keep an eye on unknown attributes.

The unknown attributes are available with the other attributes. For example:

...
        Calling-Station-Id = "987654321"
        NAS-Port-Type = Async
        User-Password = Q<129><14><213>+<191><30>C<215><145>+]<15>T<204><25>
        Unknown-9048-120 = <0><0><0><2>
        Unknown-0-93 = an example

The first number is the vendor id (0 for IANA and e.g., 9048 for OSC)
and the second number is the vendor assigned type.

A new global option flag is available for controlling proxying
behaviour. When ProxyUnknownAttributes is turned on, unknown attributes
sent by clients will be proxied to next hop servers. If the responses
from the next hop servers have unknown attributes, these too are
returned back to the requesting clients.

Attribute names starting with 'Unknown' are now reserved. Any attribute
names starting with Unknown are ignored when loading dictionaries and a
warning is logged.

Please let us know how it goes,
Heikki

-- 
Heikki Vatiainen <h...@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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Reply via email to