...

authorize { preprocess suffix eap pap papauth }

pap really should go at the end - i believe the default config mentions this...with maybe exclaimation marks or capital letters?

alan

How is this supposed to help me in any way to configure FR to do PAP authentication? Accordingly to documentation, PAP should be listed last in authorize section becouse need to check passwords added by previous modules and normalize them. In my case none previus modules (preprocess, suffix, eap) gives any known good password (and this is intended since i don't want the RADIUS server to "know" the real user password) su pap just give back NOOP. I can even comment out pap in authorize section since just respond noop in any case. Here are the log from radiusd -X in any case **************** radiusd -X with pap and not papauth ****************** rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 9 modcall: leaving group authorize (returns ok) for request 9 auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. ************************************************************** Since eap is over (final step of ttls) and no modules are adding a "known good" password for the user, pap respond noop and there is no Auth-Type configured. **************** radiusd -X with pap after papauth ****************** Exec-Program output: Auth-Type = PAP Exec-Program-Wait: value-pairs: Auth-Type = PAP Exec-Program: returned: 0 modcall[authorize]: module "papauth" returns ok for request 4 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 4 rad_check_password: Found Auth-Type PAP auth: type "PAP" ************************************************************ The script set the Auth-Type and pap just answer noop. **************** radiusd -X with pap before papauth ****************** rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 9 Exec-Program output: Auth-Type = PAP Exec-Program-Wait: value-pairs: Auth-Type = PAP Exec-Program: returned: 0 modcall[authorize]: module "papauth" returns ok for request 9 modcall: leaving group authorize (returns ok) for request 9 rad_check_password: Found Auth-Type PAP auth: type "PAP" ************************************************************** Pap still answer with noop and do not set the Auth-Type but the script do the job setting the Auth-Type and letting the second script check the credentials. **************** radiusd -X without pap in authorize ****************** Exec-Program output: Auth-Type = PAP Exec-Program-Wait: value-pairs: Auth-Type = PAP Exec-Program: returned: 0 modcall[authorize]: module "papauth" returns ok for request 9 modcall: leaving group authorize (returns ok) for request 9 rad_check_password: Found Auth-Type PAP auth: type "PAP" ************************************************************ My question is which is the best way to correctly accomplish pap authentication WITHOUT using authorization checks. My solution was to "force" Auth-Type to PAP in case we have username and password in radius attributes. Another way is, i think, using a users file with "DEFAULT Auth-Type = PAP" but i read in many place NOT TO DO THAT. Another way could be to check if is present the Auth-Type and set it to PAP if os not set and list that script as last on authorize section. Which is the best solution? Btw, in config i see: ******************* radiusd.conf ************* # As of 1.1.4, you should list "pap" last in this section. # See "man rlm_pap" for more information. ***************************************** So no exclamations and capitals, just a "should". And i do read the man page to understand a little more about what i was going to do. Thanks in advance Bye Maccari Dario _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

If you are configured the *server* to do PAP authentication, then the default configuration files should be used. Your module (exec/whatever) should supply a "known good" password. The server then uses that to authenticate the user.

I configured the CLIENT to do EAP-TTLS with inner PAP. The server needs to "fit" inside a more complex structure in wich no "known good" password is available. User data are stored outside the radius server and can't be accessed in any other way than the ones that are given to me. Actually i can't ask for the password of a user so to provide this password to pap module. All i can do is to check if the pair username/password is correct and there is nothing i can do about that. That's why i can't provide a known good password to pap module and that's why pap module for authorization can not be used.

If *your module* is doing PAP authentication, then you need to list *your module* in the "authenticate" section. You need to force Auth-Type to be *your module*. And all other authentication types will fail.

That's very interesting and is something i haven't found in documentations (my fault). You mean that using a userfile file with DEFAULT Auth-Type = DONALDUCK and in radiusd.conf have something like (cutting out default stuff): ********************************** modules { exec myauth { wait = yes program = "/path/to/my/script" input_pairs = request output_pairs = reply } } authorize { eap file } authenticate { Auth-Type DONALDUCK { myauth } } ********************************* Will work?.

i.e. you haven't told the server what the "known good" password is, and you haven't told the server how to authenticate the user.

Right, i can't provide the known good password as stated before

Huh? You're setting Auth-Type to PAP in your script?

That was my solution to force the pap authentication module to do the authentication.

I've deleted the other attempts at "let's make random changes to see if it works".

It wasn't a "let's make random changes to see if it works", it works since the beginning. I have even provided other possible solutions too. The tests where just there to point out that the response that "pap really should go at the end" with other annoing comments about exclaimation marks and capital letters were plain inappropriate.

Stop making changes until you understand how the server works. Start with the default configuration, and then do this in the "inner-tunnel" virtual server. (i.e. also use 2.0.4)

Unfortunatly even this is not an aoption. I can't switch to 2.0.4 and am forced to use 1.1.7 untill my company in cludev 2.0 in accepted software. It's not my fault and can't do much about it.

The script should use the username to look up the "known good" password, and then print it to STDOUT. e.g. "echo hello" would be a good start.

EAP-TTLS + PAP will then WORK. And YES, you will be giving the server the "real user password". This is NOT a problem. If you think it's a problem, then you need to change your opinion. It's NOT a problem.

It IS a problem for me since the external server owner will NOT give me any access other then the ability to check if the pair username/password is valid. And all it is now working, just asking what is the best solution between using a script to "force" Auth-Type, use a users file. Don't care if other authentication methods will not work. Bye and thanks again Maccari Dario _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

<sigh> That is NOT what you said before.

Sorry, probably a language barrier. I think my english is not good enough to really explain what i was trying to accomplish. Thanks for your patience.

It should.

I'll try that solution than wich will lead at, at least, less misunderstanding with pap client-side and pap server-side. Thanks again for your help Bye Dario Maccari

So why do you bother with radius and EAP for authentication when you are not going to use them? Use captive portal and run that php script from the login page. If you need accounting use radius for that.

I need to insert a wpa/wpa2 enterprise wlan, which do need eap and radius, side by side a prexisting unencrypted wlan wich authenticate with a captive portal. That's why that php script. It's basically the same used by the captive portal to authenticate the unencrypted wlan users with the externale server. Maybe i can port it in perl or even c/c++ to make it a real module and gain more control over its behaviuor and better performance but for now is just something more than a "proof of concept" ;) If all goes as it should i can even convince the external holder of the user database to setup a radius server where to proxy requests but this is a future project. The accounting is not made with radius too since it need to be "hardware independant" and unfortunatly not all access points used support radius accounting even if they do support wpa/wpa2 enterprise. I know, it's a wierd configuration but i have to deal with it :( Thanx Dario Maccari