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