rlm_exec and proxy request paradox

Nathan M locu.lists at gmail.com
Wed Jun 22 00:25:54 CEST 2011


So I've done a little more digging and also updated my installation to
2.1.11.  I admittedly am not a C programmer; so please pardon any
misunderstandings (or bad suggestions) may have.  My hope is this
research might help somebody help me with the issue at hand.

Beginning on line 209 of src/main/auth.c is the following snippet of
code triggering the access-accept.

        /*
         *      This means we have a proxy reply or an accept
         *  and it wasn't rejected in the above loop.  So
         *  that means it is accepted and we do no further
         *  authentication
         */
        if ((auth_type == PW_AUTHTYPE_ACCEPT)
#ifdef WITH_PROXY
            || (request->proxy)
#endif
            ) {
                RDEBUG2("Auth-Type = Accept, accepting the user");
                return 0;
        }

If I comment out the return 0; line, all works well for me although it
does trigger a warning.  Even if the proxied request is accepted by
the destination radius server, my exec script exits code 1 and the
request is ultimately rejected.  Given my understanding of the
rlm_exec module, I believe it should be rejecting the proxied request
in my original email.  Would it make sense here to extend this section
of code so it acknowledges the response from rlm_exec before accepting
the user?  Or having the rlm_exec code unset auth_type from being
PW_AUTHTYPE_ACCEPT so this section never fires?

- N


On Fri, Jun 17, 2011 at 3:11 PM, Nathan M <locu.lists at gmail.com> wrote:
> Hello,
>
> I'm in the process of updating old 1.x freeradius servers to 2.1.10.
> We have scripts which fire to verify some local verifications and
> return some attributes which get passed along with the response to the
> NAS.  The old method used Exec-Program-Wait in the users file;
> however, per recommendation in docs and list I'm converting things
> over to use the newer rlm_exec method.
>
> The new method works great for local authentication; however, I'm
> getting stumped on requests which are proxied to another radius server
> which accepts the request.  Process of events:
>
> 1. Auth request is proxied to 3rd party server, which returns an Access-Accept
>
> rad_recv: Access-Accept packet from host 10.0.0.243 port 1645, id=184, length=37
>        Framed-Protocol = PPP
>        Framed-Compression = Van-Jacobson-TCP-IP
>        Proxy-State = 0x313238
>
> 2. As configured in post-proxy, visp_proxyauth is run.  For the sake
> of simplicity visp_proxyauth executes a script which simply responds
> with exit 1 to mimic a failed local verification.
>
> # Executing section post-proxy from file
> /usr/local/etc/raddb/sites-enabled/default
> +- entering group post-proxy {...}
> Exec-Program output:
> Exec-Program: returned: 1
> ++[visp_proxyauth] returns reject
> Found Auth-Type = Accept
> Auth-Type = Accept, accepting the user
>
> Problem, even though visp_proxyauth returns reject with exit 1, I
> believe the earlier Auth-Type = Accept from the response of the 3rd
> party radius server the request was proxied to is being used to accept
> the login.
>
> This differs from how 1.x acted in that if exec-program-wait returned
> exit 1 it would fail the request.  My new install of 2.1.10 accepts
> the request which is not the desired behavior.  I'm definitely open to
> modifying my config or exit codes to accommodate any differences
> introduced in 2.x.
>
> I've seemingly tried too many different configuration options and
> different tactics to try to make this work but seem to be stumped and
> looking for some outside perspective.  My goal would be to ultimately
> reject the request if visp_proxyauth exits with return value 1 (user
> reject).  Any assistance is greatly appreciated.
>
> - N
>




More information about the Freeradius-Users mailing list