Hello Heikki,
the solution you proposed is working fine, thanks. I had also to adjust the
AuthByPolicy parameter that must be different in the various AuthBy Groups.
Just in case it could be useful to somebody else, I am reporting here a
skeleton of my Radiator configuration file.
<Realm REALM>
AuthByPolicy ContinueWhileAccept
#Check that there are ports available
<AuthBy GROUP>
Identifier Auth1
AuthByPolicy ContinueWhileReject
<AuthBy SQL>
...
</AuthBy>
#Because of the AuthByPolicy for this group, this AuthByInternal
will be executed only
#if the previous AuthBySQL returns Rejects. Here I write error
messages
<AuthBy INTERNAL>
AuthHook sub { } #Print errors messages because of the lack of
resources
</AuthBy>
</AuthBy> #End of the Auth1 AuthBy Group
#Now check that the user is not blacklisted
<AuthBy GROUP>
Identifier Auth2
AuthByPolicy ContinueWhileReject
#Check that there are ports available
<AuthBy SQL>
...
</AuthBy>
<AuthBy INTERNAL>
AuthHook sub { } #Print errors messages because the user is
blacklisted
</AuthBy>
</AuthBy> #End of the Auth2 AuthBy Group
#Then authenticate the user in the usual manner
<AuthBy SQL>
...
</AuthBy>
</Realm>
Thanks again,
Alberto
2012/7/4 Heikki Vatiainen <h...@open.com.au>
> On 07/04/2012 04:32 PM, Alby wrote:
>
> Hello Alberto,
>
> > I am using Radiator in a Telecommunication group. I have only one REALM,
> > with 3 AuthSQL statements inside (the policy used is
> > ContinueWhileIgnore). The first one checks that the user is allowed to
> > occupy another port in the system. If the check goes OK, then the next
> > AuthSQL statement is executed, otherwise the user is rejected due to the
> > unavailability of physical resources. The second one checks that the
> > call originating form Calling-Station-ID to Called-Station-ID
> > (attributes present in the user's request packet) is not prohibited,
> > like a sort of blacklist. If also this check goes OK then the last
> > AuthSQL statement performs the real user authentication.
>
> Try pairing an AuthBY INTERNAL with each AuthBy SQL. If I understood
> correctly, you now have this:
>
> <Realm ...>
> AuthByPolicy ContinueWhileIgnore
> AuthBy SQL1
> AuthBy SQL2
> AuthBy SQL3
> </Realm>
>
> If e.g., SQL1 is now an AuthBy SQL with Identifier SQL1, you could
> change it to this:
>
> <AuthBy GROUP>
> Identifier SQL1
> # Or any other policy that suits the outcome from AuthBy SQL
> AuthByPolicy ContinueWhileIgnore
> <AuthBy SQL>
> ....
> </AuthBy>
> <AuthBy INTERNAL>
> AuthHook sub {...}
> </AuthBy>
> </AuthBy>
>
> See goodies/digipassStatic.cfg for an example where INTERNALs are used
> to run hooks between/after each "real" AuthBy.
>
> > My question is: each AuthSQL modules can add (independently to others
> > Auth modules) custom messages to the log (maybe with the function
> > &main::log) and to the reply packet? In other words, I would like that
> > if a user is rejected because of lack of resources, a string like "User
> > rejected because of lack of resources" is written on the logs and maybe
> > in the user's response with a Reply-Message attribute. In a similar way,
> > if the user is rejected due to blacklist rules, a string like "User
> > rejected due to blacklist" is added to the log and to the user's
> > response packet. My first try was to do this using PostAuthHooks like
> > done in the past, but Hooks are for REALMs, not for single AuthBy
> > statements if I am not mistaken.
>
> That's true. PostAuthHook, for example, runs once when all AuthBys, as
> directed by AuthByPolicy, have run. With the above INTERNAL example, you
> can have more control when to run the hooks.
>
> > I have noticed that AuthSQL have the
> > PostAuthSelectHook, but this is executed before Radiator performs the
> > authentication operations. This force me to understand if the user is
> > blocked twice, one time in the Hook and another time by Radiator and
> > this does not make very sense I think. Maybe there is a better way to
> > reach my goal, but I really can't see how to do that.
>
> Please get back to us and tell if the above works.
>
> Thanks,
> 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
>
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
