EAP-TTLS + PAP with external script

Dario Maccari d_maccari at hotmail.com
Thu May 15 18:37:33 CEST 2008


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080515/40d854a4/attachment.html>


More information about the Freeradius-Users mailing list