Passing variables from inner tunnel
Hi, I'm trying to pass the value of LDAP-UserDn from the inner-tunnel to the default server. I have read unlang and also tried many combinations including update outer.control from the inner tunnel and nothing worked... Here is a debug output where we can see that the User-Dn get expanded correctly in the tunnel but is empty in the default server. ++[eap] returns ok +- entering group post-auth {...} expand: %{control:LDAP-UserDn} -> cn=aruba,ou=etudiant,o=org Exec-Program output: etudiant Exec-Program-Wait: plaintext: etudiant Exec-Program: returned: 0 ++[reply] returns noop ++[outer.control] returns noop } # server inner-tunnel .... .... [eap] Freeing handler ++[eap] returns ok +- entering group post-auth {...} ++[exec] returns noop expand: %{control:LDAP-UserDn} -> PHP Notice: Undefined offset: 0 in /etc/freeradius/scripts/php3 on line 4 Exec-Program output: dewor Exec-Program-Wait: plaintext: dewor Exec-Program: returned: 0 Thanks Jean -- View this message in context: http://old.nabble.com/Passing-variables-from-inner-tunnel-tp29279811p2927981... Sent from the FreeRadius - User mailing list archive at Nabble.com.
Hi, newtownz <jean466@sympatico.ca> wrote:
I'm trying to pass the value of LDAP-UserDn from the inner-tunnel to the default server. I have read unlang and also tried many combinations including update outer.control from the inner tunnel and nothing worked...
I'm pretty sure I saw this too and (was some time back) a glance over the source code gave me the impression that anything in the FreeRADIUS internal dictionary gets lost.
Here is a debug output where we can see that the User-Dn get expanded correctly in the tunnel but is empty in the default server.
Just return User-Name in the reply and do a repeat LDAP query on your outer layer; doing a 'cn' lookup should be instantaneous...if it is not you have other bigger problems[1]. Cheers [1] obviously scalability and transaction time is not a problem as you are Exec-Program-Wait'ing a PHP script ;) -- Alexander Clouter .sigmonster says: Pretend to spank me -- I'm a pseudo-masochist!
Hi, Thank your for your answer.
Just return User-Name in the reply and do a repeat LDAP query on your outer layer; doing a 'cn' lookup should be instantaneous...
I'm a little puzzled on how to accomplish this! Regards Jean -- View this message in context: http://old.nabble.com/Passing-variables-from-inner-tunnel-tp29279811p2928693... Sent from the FreeRadius - User mailing list archive at Nabble.com.
After spending some more time on our FreeRadius2 project it managed once again to leave me clueless. The error message: WARNING: Possible DoS attack from host 196.25.xxx.xx: Too many attributes in request (received 201, max 200 are allowed). Googleing showed that it most likely is the result of a mis-configuration in proxy.conf. This is our proxy.conf without comments: proxy server { default_fallback = no } home_server copy-acct-to-home-server-B { type = acct ipaddr = 196.25.xxx.xx port = 1646 secret = xxxxxxxxxx } home_server_pool my_acct_failover { type = fail-over home_server = copy-acct-to-home-server-B } realm DEFAULT { acct_pool = my_acct_failover } realm LOCAL { } Might look a bit odd because we played around for quite a bit. Who can spot the fatal error? Thanks Marius
Marius Pesé wrote:
After spending some more time on our FreeRadius2 project it managed once again to leave me clueless. The error message:
WARNING: Possible DoS attack from host 196.25.xxx.xx: Too many attributes in request (received 201, max 200 are allowed).
See the "security" section of radiusd.conf.
Googleing showed that it most likely is the result of a mis-configuration in proxy.conf.
You are very likely proxying packets FROM the server TO itself, in an infinite loop. Stop that.
This is our proxy.conf without comments:
Have you tried running the server in debugging mode? Do you see it proxying packets to itself in an endless loop? Does the debug log show WHY the packets were proxied? If the packets really do have more than 200 real attributes, edit radiusd.conf to allow this. If the packets have dozens of "Proxy-State" attributes, you've misconfigured the server and broken it. Configure to proxy packets to *other* RADIUS servers, not to itself. Alan DeKok.
Hi Alan, Managed to get that one right, but now its stripping off the realm despite me having set nostrip, and the second server then complains about not knowing the user. Where else can a realm get stripped except for proxy.conf and sites-enabled/default? -----Original Message----- From: freeradius-users-bounces+marius=mindspring.co.za@lists.freeradius.org [mailto:freeradius-users-bounces+marius=mindspring.co.za@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Wednesday, July 28, 2010 5:04 PM To: FreeRadius users mailing list Subject: Re: Proxying creates 200 Attributes resulting in DoS warning Marius Pesé wrote:
After spending some more time on our FreeRadius2 project it managed once again to leave me clueless. The error message:
WARNING: Possible DoS attack from host 196.25.xxx.xx: Too many attributes in request (received 201, max 200 are allowed).
See the "security" section of radiusd.conf.
Googleing showed that it most likely is the result of a mis-configuration in proxy.conf.
You are very likely proxying packets FROM the server TO itself, in an infinite loop. Stop that.
This is our proxy.conf without comments:
Have you tried running the server in debugging mode? Do you see it proxying packets to itself in an endless loop? Does the debug log show WHY the packets were proxied? If the packets really do have more than 200 real attributes, edit radiusd.conf to allow this. If the packets have dozens of "Proxy-State" attributes, you've misconfigured the server and broken it. Configure to proxy packets to *other* RADIUS servers, not to itself. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Marius Pesé wrote:
Hi Alan,
Managed to get that one right, but now its stripping off the realm despite me having set nostrip,
Well... it doesn't strip the realms if the "nostrip" is set. Are you SURE you did it correctly? And what does the debug log say? It's really not that hard to run the server in debug mode, and post the output to the list. Alan DeKok.
newtownz wrote:
Hi,
Thank your for your answer.
Just return User-Name in the reply and do a repeat LDAP query on your outer layer; doing a 'cn' lookup should be instantaneous...
I'm a little puzzled on how to accomplish this!
In the "inner-tunnel" virtual server: authorize { ... update reply { User-Name = "foo" } ... } Also, be aware that EAP does multiple round trips. If you update "outer.control" in one packet, that value is *not* available to the next packet in the stream. Alan DeKok.
Hi, I think I understand the problem here, there are multiple request done to freeradius in the process of authenticating the user and since I'm trying to access the variable that was set in the previous request it is simply empty... Jean -- View this message in context: http://old.nabble.com/Passing-variables-from-inner-tunnel-tp29279811p2928768... Sent from the FreeRadius - User mailing list archive at Nabble.com.
newtownz wrote:
I think I understand the problem here, there are multiple request done to freeradius in the process of authenticating the user and since I'm trying to access the variable that was set in the previous request it is simply empty...
Yes. If you want to store information across multiple packets, use a database. Alan DeKok.
HI, Since I need to have the LDAP-UserDn in the post-auth section of the default-server is there a way to execute a LDAP query in this part? Jean -- View this message in context: http://old.nabble.com/Passing-variables-from-inner-tunnel-tp29279811p2928778... Sent from the FreeRadius - User mailing list archive at Nabble.com.
participants (4)
-
Alan DeKok -
Alexander Clouter -
Marius Pesé -
newtownz