Hi again -
You could also use an AuthBy MULTICAST clause instead of multiple AuthBy RADIUS
clauses.
regards
Hugh
> On 25 Apr 2015, at 09:41, Hugh Irvine <h...@open.com.au> wrote:
>
>
> Hi Jose -
>
> Right - understood.
>
> In this case I would probably use separate Radiator processes as
> intermediates between your main server and the targets that require special
> AVpair processing.
>
> You would forward the original request unchanged and then deal with whatever
> changes are required on the intermediate Radiator instances.
>
> I tend to use this architecture quite often as it makes each individual piece
> much simpler and cleaner.
>
> Something like this:
>
> …..
>
> <Handler Client-Identifier=PGW, Acct-Status-Type=Start>
>
> Identifier PGW_START
> AccountingHandled
>
> <AuthBy GROUP>
> AuthByPolicy ContinueAlways
>
> <AuthBy RADIUS>
> # Forward to intermediate instance
> Host localhost
> AcctPort 11812
> Secret secret2
> IgnoreAccountingResponse
> </AuthBy>
>
> <AuthBy RADIUS>
> # Forward to intermediate instance
> Host localhost
> AcctPort 11813
> Secret secret3
> IgnoreAccountingResponse
> </AuthBy>
>
> <AuthBy RADIUS>
> # Forward to intermediate instance
> Host localhost
> AcctPort 11814
> Secret secret4
> IgnoreAccountingResponse
> </AuthBy>
>
> <AuthBy RADIUS>
> Host 192.168.1.5
> Secret secret5
> IgnoreAccountingResponse
> </AuthBy>
>
> <AuthBy RADIUS>
> Host 192.168.1.6
> Secret secret6
> IgnoreAccountingResponse
> </AuthBy>
>
> </AuthBy>
>
> MaxSessions 0
> </Handler>
>
>
> BTW - I agree with you that a RequestHook would be a useful addition in any
> case.
>
> regards
>
> Hugh
>
>
>> On 25 Apr 2015, at 00:35, Jose Borges Ferreira <undersp...@gmail.com> wrote:
>>
>> Hi,
>>
>>
>> I have somthing similar to this:
>>
>> <Handler Client-Identifier=PGW, Acct-Status-Type=Start>
>> Identifier PGW_START
>> AccountingHandled
>>
>> <AuthBy GROUP>
>> AuthByPolicy ContinueUntilReject
>> <AuthBy RADIUS>
>> Host 192.168.1.2
>> Secret secret2
>> StripFromRequest AVP1__2,AVP2__2
>> AllowInRequest 3GPP-IMSI,
>> Acct-Session-Id, NAS-Port-Type\
>> Acct-Status-Type,
>> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
>> Framed-IP-Address, User-Name
>> </AuthBy>
>> <AuthBy RADIUS>
>> Host 192.168.1.3
>> Secret secret3
>>
>> RequestHook sub {\
>> my $p = ${$_[0]};\
>> my $fp = ${$_[1]};\
>> my $imsi = $p->get_attr('3GPP-IMSI');\
>> if ($imsi =~ /^1234/) { \
>>
>> $fp->change_attr('3GPP-RAT-Type,', 'UMTS');\
>>
>> }\
>> }
>>
>> AllowInRequest 3GPP-IMSI,
>> 3GPP-PDP-Type, 3GPP-RAT-Type, 3GPP-User-Location-Info,
>> Acct-Session-Id,NAS-Port-Type \
>> Acct-Status-Type,
>> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
>> Framed-IP-Address, User-Name
>>
>> </AuthBy>
>> <AuthBy RADIUS>
>> Host 192.168.1.4
>> Secret secret3
>> AllowInRequest 3GPP-RAT-Type,
>> 3GPP-User-Location-Info, Acct-Session-Id, NAS-Port-Type\
>> Acct-Status-Type,
>> Called-Station-Id, Calling-Station-Id, Event-Timestamp,
>> Framed-IP-Address, User-Name
>> </AuthBy>
>>
>> <AuthBy RADIUS>
>> Host 192.168.1.5
>> Secret secret4
>> </AuthBy>
>>
>> <AuthBy RADIUS>
>> Host 192.168.1.6
>> Secret secret5
>> </AuthBy>
>> </AuthBy>
>>
>>
>> MaxSessions 0
>> </Handler>
>>
>>
>> ( not exactly this but similar enough)
>>
>>
>> I want o achieve the following:
>>
>> 1.Broadcast accounting to all servers.
>> 2.Have a different set of AVPs for each destination server.
>> 3.To one server ( and only to that one) want to have a more complex
>> logic and be able to add,remove or change AVPs
>>
>> In other setups I found that changing avps on one clause it will send
>> AVP changes to the following servers, which was not intended
>>
>> I achieved the intended behaviour by enclosing a AuthBy RADIUS in a
>> GROUP between a couple of INTERNALs. The first one to change the AVP
>> and a final one to restore from original packet.
>>
>> I found a RequestHook very useful and more clean approach. It is the
>> counterpart of the Reply/NoReplyHook .
>> I thought it could be useful for other and, eventually, included in
>> next versions.
>>
>> Thanks anyway,
>>
>> Best regards,
>>
>> José Borges Ferreira
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 22, 2015 at 7:21 AM, Hugh Irvine <h...@open.com.au> wrote:
>>>
>>> Hello Jose -
>>>
>>> One way to do this is with multiple Handler clauses and an AuthBy HANDLER
>>> clause in the first one.
>>>
>>> See the example in “goodies/authhandler.cfg”.
>>>
>>> See also section 5.76 AuthBy HANDLER in the manual (“doc/ref.pdf”).
>>>
>>> You can have a different PreAuthHook in each target Handler clause, and the
>>> overall configuration will be much simpler.
>>>
>>> I would also have separate configuration files for authentication and
>>> accounting (each listening only on the corresponding ports).
>>>
>>> hope that helps
>>>
>>> regards
>>>
>>> Hugh
>>>
>>>
>>>
>>>> On 22 Apr 2015, at 01:26, Jose Borges Ferreira <undersp...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have a setup that forwards some accounting to several servers. I
>>>> need to mangle some attributes before a forward to the remote
>>>> server.One requirement is to have different mangling per host.
>>>> I couldn't found a way to change hook some code at AuthBy RADIUS, so I
>>>> implemented the attached patch.
>>>>
>>>> So , my question is :
>>>>
>>>> Is there a way to achieve what I want ?
>>>>
>>>> Does the patch makes sense ?
>>>>
>>>> Thanks in advanced,
>>>>
>>>> José Borges Ferreira
>>>> <RequestHook.patch>_______________________________________________
>>>> radiator mailing list
>>>> radiator@open.com.au
>>>> http://www.open.com.au/mailman/listinfo/radiator
>>>
>>>
>>> --
>>>
>>> Hugh Irvine
>>> 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, SIM, etc.
>>> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>>>
>
>
> --
>
> Hugh Irvine
> 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, SIM, etc.
> Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
> _______________________________________________
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Hugh Irvine
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, SIM, etc.
Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc.
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
