Question regarding external script authentication
Hi all, I am currently using exec to authenticate users through an external script. When all criteria match I return the correct access-accept pairs and the users authenticate successfully. When the criteria are NOT met, I exit(1) my php script to hand control back to the freeradius server. This seems to be causing authentication requests to time out, as I guess I am not sending anything back... My question is this: Would it be correct to return Auth-Type="Reject" in the cases where I want the user to be rejected? TIA! Patrick ---------------------------------------------------------------------- Free pop3 email with a spam filter. http://www.bluebottle.com
Patric wrote:
I am currently using exec to authenticate users through an external script. When all criteria match I return the correct access-accept pairs and the users authenticate successfully. When the criteria are NOT met, I exit(1) my php script to hand control back to the freeradius server. This seems to be causing authentication requests to time out, as I guess I am not sending anything back...
Set "reject_delay = 0" in radiusd.conf. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi Alan, Thanks for ur response. Alan DeKok wrote:
Set "reject_delay = 0" in radiusd.conf.
I just want to clarify, if I set the reject_delay to 0, and in my external script the only thing I do is "exit(1);", then freeradius will return a reject response to the NAS? Or will it simply not respond? Because the complaint my NAS maintainer has is that he is getting no response. Thanks a stack! Patrick ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com
Patric wrote:
I just want to clarify, if I set the reject_delay to 0, and in my external script the only thing I do is "exit(1);", then freeradius will return a reject response to the NAS?
It will send a reject to the NAS.
Or will it simply not respond? Because the complaint my NAS maintainer has is that he is getting no response.
Yes, I understood that from your previous message. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Patric wrote:
I just want to clarify, if I set the reject_delay to 0, and in my external script the only thing I do is "exit(1);", then freeradius will return a reject response to the NAS?
It will send a reject to the NAS.
Thanks Alan, you're an absolute gem! Patrick ---------------------------------------------------------------------- Free pop3 email with a spam filter. http://www.bluebottle.com
Alan DeKok wrote:
Patric wrote:
I just want to clarify, if I set the reject_delay to 0, and in my external script the only thing I do is "exit(1);", then freeradius will return a reject response to the NAS?
It will send a reject to the NAS.
Sorry if Im flogging a dead horse here... I furthered my investigation and found the following interesting results: After making reject_delay = 0, I ran the freeradius in debug mode on my test environment to see what happens, and indeed it does return an Access-Reject : ... rad_recv: Access-Request packet from host 127.0.0.1:32770, id=12, length=95 User-Name = "test@realm.com" User-Password = "TestUser" NAS-IP-Address = 255.255.255.255 NAS-Port = 100 NAS-Port-Type = Virtual Exec-Program: /usr/local/freeradius/radauth.php -- u:test@realm.com p:TestUser n:100 t:Virtual Exec-Program: returned: 1 rlm_exec (exec-radauth): External script failed Sending Access-Reject of id 12 to 127.0.0.1 port 32770 ... All of the above is spot on! Now riddle me this: When I make the same changes to my production server and run it in debug mode it does all of the above *except* return the Access-Reject! ... rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:1820, id=83, length=140 Framed-Protocol = PPP User-Name = "test@realm.com" User-Password = "TestUser" NAS-Port-Type = Virtual NAS-Port = 1010101010 NAS-Port-Id = "x/x/x/xx.xxx" Connect-Info = "AutoShapedVC" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x323037 Exec-Program: /usr/local/freeradius/radauth.php -- u:test@realm.com p:TestUser n:1010101010 t:Virtual Exec-Program: returned: 1 rlm_exec (exec-radauth): External script failed rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:1820, id=170, length=140 ... As you can see it goes onto the next access request. I did let the debug run longer, but after a minute there was still no Access-Reject. Test environment is running : CentOS release 4.4 (Final) 2.6.16.33-xen_3.0.4.1 #1 SMP Fri Jan 5 10:40:15 EST 2007 i686 i686 i386 GNU/Linux radiusd: FreeRADIUS Version 1.1.3, for host i686-pc-linux-gnu, built on Oct 5 2006 at 10:52:23 Production environment is running : Red Hat Enterprise Linux ES release 3 (Taroon Update 8) 2.4.21-40.EL #1 Wed Mar 15 14:30:04 EST 2006 i686 i686 i386 GNU/Linux radiusd: FreeRADIUS Version 1.1.3, for host i686-redhat-linux-gnu, built on Sep 20 2006 at 14:13:13 I have searched through the conf file and docs and googled this but I cant find any reason why the server is not returning the Access-Reject Any ideas? Thanks again Patrick ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
Hi,
Framed-Protocol = PPP User-Name = "test@realm.com" User-Password = "TestUser" NAS-Port-Type = Virtual NAS-Port = 1010101010 NAS-Port-Id = "x/x/x/xx.xxx" Connect-Info = "AutoShapedVC" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x323037
you have various other attributes in your real production system - perhaps you have matching DEFAULT values (eg in users file) which are aiding the access accept? alan
A.L.M.Buxey@lboro.ac.uk wrote:
you have various other attributes in your real production system - perhaps you have matching DEFAULT values (eg in users file) which are aiding the access accept?
If that were the case, then wouldnt this eliminate the problem: My radiusd.conf authorize section contains only this : authorize { files exec-radauth } My users file contains only this : DEFAULT Auth-Type = Accept If I understand it correctly this would mean that the only authentication done is by my script. I did the above on the production server, but I am still not returning an access-reject... I have now also upgrading freeradius on the production server to 1.1.6, also with the same result - no access-reject returned... I am now at a loss as to where else to look, but I suspect its some kind of config setting. Where? I dont know :[ Thanks guys Patrick ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
As per my ramblings below, I ran the server in debug level 3, and one can see that it is the correct DEFAULT entry that it is picking up : rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:1820, id=80, length=139 Framed-Protocol = PPP User-Name = "test@realm.com" User-Password = "TestUser" NAS-Port-Type = Virtual NAS-Port = 1234567890 NAS-Port-Id = "1/1/1/1.1" Connect-Info = "AutoShapedVC" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x3439 Fri May 18 13:39:07 2007 : Debug: Processing the authorize section of radiusd.conf Fri May 18 13:39:07 2007 : Debug: modcall: entering group authorize for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "preprocess" returns ok for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling chap (rlm_chap) for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from chap (rlm_chap) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "chap" returns noop for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "mschap" returns noop for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling suffix (rlm_realm) for request 21 Fri May 18 13:39:07 2007 : Debug: rlm_realm: Looking up realm "realm.com" for User-Name = "test@realm.com" Fri May 18 13:39:07 2007 : Debug: rlm_realm: No such realm "realm.com" Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from suffix (rlm_realm) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "suffix" returns noop for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 21 Fri May 18 13:39:07 2007 : Debug: rlm_eap: No EAP-Message, not doing EAP Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "eap" returns noop for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling files (rlm_files) for request 21 *Fri May 18 13:39:07 2007 : Debug: users: Matched entry DEFAULT at line 54* Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from files (rlm_files) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "files" returns ok for request 21 Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: calling exec-radauth (rlm_exec) for request 21 Fri May 18 13:39:07 2007 : Debug: radius_xlat: 'u:test@realm.com' Fri May 18 13:39:07 2007 : Debug: radius_xlat: 'p:TestUser' Fri May 18 13:39:07 2007 : Debug: radius_xlat: 'n:1234567890' Fri May 18 13:39:07 2007 : Debug: radius_xlat: 't:Virtual' Fri May 18 13:39:07 2007 : Debug: Exec-Program output: Fri May 18 13:39:07 2007 : Debug: Exec-Program: returned: 1 Fri May 18 13:39:07 2007 : Error: rlm_exec (exec-radauth): External script failed Fri May 18 13:39:07 2007 : Debug: modsingle[authorize]: returned from exec-radauth (rlm_exec) for request 21 Fri May 18 13:39:07 2007 : Debug: modcall[authorize]: module "exec-radauth" returns fail for request 21 Fri May 18 13:39:07 2007 : Debug: modcall: leaving group authorize (returns fail) for request 21 Fri May 18 13:39:07 2007 : Debug: Finished request 21 Fri May 18 13:39:07 2007 : Debug: Going to the next request Fri May 18 13:39:07 2007 : Debug: --- Walking the entire request list --- Fri May 18 13:39:07 2007 : Debug: Waking up in 3 seconds... Line 54 of my users file contains : DEFAULT Auth-Type = Accept I dont know if that helps at all, but this one has me well and truly stumped... :~[ Patrick Patric wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
you have various other attributes in your real production system - perhaps you have matching DEFAULT values (eg in users file) which are aiding the access accept?
If that were the case, then wouldnt this eliminate the problem:
My radiusd.conf authorize section contains only this :
authorize { files exec-radauth }
My users file contains only this :
DEFAULT Auth-Type = Accept
If I understand it correctly this would mean that the only authentication done is by my script. I did the above on the production server, but I am still not returning an access-reject...
I have now also upgrading freeradius on the production server to 1.1.6, also with the same result - no access-reject returned...
I am now at a loss as to where else to look, but I suspect its some kind of config setting. Where? I dont know :[
Thanks guys Patrick
---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com
Appears virtual modules can't be used with dynamic expansion. WARNING: Unknown module "redundant_sql_clients" in string expansion "%{redundant_sql_clients:SELECT EXPORT_SET(master.nas_flags,'1','0','',20) FROM `master` WHERE ip1 = '%{1}' AND ip2 = '%{2}' AND ip3 = '%{3}' AND ip4 = '%{4}' LIMIT 0,1}" radius_xlat: '' Unfortunately I can't test on latest CVS... Debug is also peppered with ERROR: Cannot find a configuration entry for module "redundant_sql". ERROR: Cannot find a configuration entry for module "redundant_ldap". etc ... --- Arran
Arran Cudbard-Bell wrote:
Appears virtual modules can't be used with dynamic expansion.
They can't. They're just used to avoid repetitive cut & paste, nothing more. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Appears virtual modules can't be used with dynamic expansion.
They can't. They're just used to avoid repetitive cut & paste, nothing more.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
In that case it would be really useful to be able to use conditionals in instantiate... Otherwise you have *no* redundancy when attempting to load sql clients list.. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
In that case it would be really useful to be able to use conditionals in instantiate...
As always, patches are welcome. i.e. there are higher priority items before 2.0.0 comes out. Maybe for 2.0.1. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
In that case it would be really useful to be able to use conditionals in instantiate...
As always, patches are welcome.
And there will be ! Though that is dependent on me getting time to learn c *properly*. Unfortunately most of my time at the moment is developing scripts to automate the role out of 802.1x to several thousand devices... and testing and benchmarking... Still confused as to why the G5s score so low..
i.e. there are higher priority items before 2.0.0 comes out. Maybe for 2.0.1.
Ok, we'll probably end up doing ip address fail-over with wackamole for the time being. And use the redundant virtual modules for LDAP... *sigh* What Wiki are you using ? Least I can contribute some documentation...
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Patric wrote:
Now riddle me this: When I make the same changes to my production server and run it in debug mode it does all of the above *except* return the Access-Reject! ... I have searched through the conf file and docs and googled this but I cant find any reason why the server is not returning the Access-Reject
It's a bug in 1.1.x. It's fixed in 2.0.0 Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
It's a bug in 1.1.x. It's fixed in 2.0.0
Ah great, at least that explains it! I see the latest public release is 1.1.6, is 2.0.0 available perhaps in the cvs? Would you say it is stable enough to run in production yet? If not any ETA? Otherwise can you suggest any previous version that may not have this bug, and is security safe enough to run in a production environment? It would seem the 1.1.3 build I have on my test environment does not have that bug... *shrugs* Thanks a stack Alan, you have been a great help! Patrick ---------------------------------------------------------------------- Find out how you can get spam free email. http://www.bluebottle.com
On Fri 18 May 2007, Patric wrote:
Alan DeKok wrote:
It's a bug in 1.1.x. It's fixed in 2.0.0
Ah great, at least that explains it! I see the latest public release is 1.1.6, is 2.0.0 available perhaps in the cvs? Would you say it is stable enough to run in production yet? If not any ETA?
Otherwise can you suggest any previous version that may not have this bug, and is security safe enough to run in a production environment? It would seem the 1.1.3 build I have on my test environment does not have that bug... *shrugs*
Thanks a stack Alan, you have been a great help!
ftp://ftp.freeradius.org/pub/radius/freeradius-server-2.0.0-pre1.tar.bz2 Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Patric wrote:
Ah great, at least that explains it! I see the latest public release is 1.1.6, is 2.0.0 available perhaps in the cvs? Would you say it is stable enough to run in production yet? If not any ETA?
See the main web page? It's all there...
Otherwise can you suggest any previous version that may not have this bug, and is security safe enough to run in a production environment? It would seem the 1.1.3 build I have on my test environment does not have that bug... *shrugs*
It has the bug. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Ah great, at least that explains it! I see the latest public release is 1.1.6, is 2.0.0 available perhaps in the cvs? Would you say it is stable enough to run in production yet? If not any ETA?
See the main web page? It's all there...
It seems to be in the news section on all the pages *except* the main one. Ivan Kalik Kalik Informatika ISP Dana 18/5/2007, "Alan DeKok" <aland@deployingradius.com> piše:
Patric wrote:
Ah great, at least that explains it! I see the latest public release is 1.1.6, is 2.0.0 available perhaps in the cvs? Would you say it is stable enough to run in production yet? If not any ETA?
See the main web page? It's all there...
Otherwise can you suggest any previous version that may not have this bug, and is security safe enough to run in a production environment? It would seem the 1.1.3 build I have on my test environment does not have that bug... *shrugs*
It has the bug.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
tnt@kalik.co.yu wrote:
It seems to be in the news section on all the pages *except* the main one.
Your browser has cached the main page. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
tnt@kalik.co.yu wrote:
It seems to be in the news section on all the pages *except* the main one.
Your browser has cached the main page.
Alan you're gonna give us all an inferiority complex if you continue to be right all the time! ;] Cheers ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
Alan DeKok wrote:
See the main web page? It's all there...
Read, and understood :] Out of curiosity I did compile the latest snapshot, and I see that it is fixed, and even returns the correct status based on what your external script returns (1 - rejected, 4 - handled, 5 - invalid, etc...). Thats fantastic, cant wait till its ready for release!
It has the bug.
Yes, undoubtedly, but what I meant was the server still returns the access-reject... Well thanks so much, you've helped me clear up and understand a lot more of freeradius! ---------------------------------------------------------------------- Get a free email address with REAL anti-spam protection. http://www.bluebottle.com
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Patric -
Peter Nixon -
tnt＠kalik.co.yu