RE: EAP-TTLS + PAP with external script
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+vistamkt=en-USform=QBRE-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TTLS + PAP with external script
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-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TTLS + PAP with external script
As you can see there is the message:
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
So the php script for pap authorization is not even executed.
Maybe there is something i missed in configuration?
Thanx
Maccari Dario
That's what I did to make it works
I added a new script for authorization which set the auth-type for final step
and added that script in the authorize section
** radiusd.conf *
modules {
pap {
auto_header = yes
}
exec test {
wait = yes
program = /usr/local/bin/php -f /etc/raddb/radiusaccess.php
input_pairs = request
output_pairs = reply
}
exec papauth {
wait = yes
program = /usr/local/bin/php -n -f /etc/raddb/radiusauth.php
input_pairs = request
output_pairs = config
}
}
authorize {
preprocess
suffix
eap
pap
papauth
}
authenticate {
Auth-Type PAP {
test
}
eap
}
* END radiusd.conf **This is the relevant script part
* radiusauth.php **
?php
$username = getenv(USER_NAME);
$userpass = getenv (USER_PASSWORD);
if ($username!= $userpass !=)
{
echo Auth-Type = PAP\n;
}
?
* END radiusauth.php **
Does what i did have any sense?
Is it robust enough?
Bye and thanx
Dario Maccari
_
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TTLS + PAP with external script
I'm trying to use an external php script to authenticate users connecting to an
Access Point.
Protocol used is EAP-TTLS with PAP as inner authentication protocol.
The relevant parts of config file i use is:
** radiusd.conf *
modules {
pap {
auto_header = yes
}
exec test {
wait = yes
program = /usr/local/bin/php -f /etc/raddb/radiusaccess.php
input_pairs = request
output_pairs = reply
}
}
authorize {
preprocess
suffix
eap
pap
}
authenticate {
Auth-Type PAP {
test
}
eap
}
* END radiusd.conf **
When i try to connect the TTLS comunication seems to work fine but
this is the relevan ouput of radiusd -X at the final steps
radiusd -X *
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 9
rlm_eap: Request found, released from the list
rlm_eap: EAP/ttls
rlm_eap: processing type ttls
rlm_eap_ttls: Authenticate
rlm_eap_tls: processing TLS
eaptls_verify returned 7
rlm_eap_tls: Done initial handshake
eaptls_process returned 7
rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes.
TTLS: Got tunneled request
User-Name = testa
User-Password = testb
FreeRADIUS-Proxied-To = 127.0.0.1
TTLS: Sending tunneled request
User-Name = testa
User-Password = testb
FreeRADIUS-Proxied-To = 127.0.0.1
Service-Type = Framed-User
Framed-MTU = 1400
NAS-Port-Id = wlan1
Calling-Station-Id = 00-13-49-71-85-68
Called-Station-Id = 00-80-48-47-6B-E1:comune_segrate_milano_oltre
NAS-Identifier = AP2
NAS-IP-Address = 192.168.11.168
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 9
modcall[authorize]: module preprocess returns ok for request 9
rlm_realm: No '@' in User-Name = testa, looking up realm NULL
rlm_realm: No such realm NULL
modcall[authorize]: module suffix returns noop for request 9
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module eap returns noop for request 9
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.
TTLS: Got tunneled reply RADIUS code 3
TTLS: Got tunneled Access-Reject
rlm_eap: Handler failed in EAP/ttls
rlm_eap: Failed in EAP select
modcall[authenticate]: module eap returns invalid for request 9
modcall: leaving group authenticate (returns invalid) for request 9
auth: Failed to validate the user.
Delaying request 9 for 1 seconds
Finished request 9
END radiusd -X **
As you can see there is the message:
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
So the php script for pap authorization is not even executed.
Maybe there is something i missed in configuration?
Thanx
Maccari Dario
_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-TTLS + PAP with external script
Isn't pap in authorize section there to do the job? How can i authorize ANY user so that they will be authenticated by the php script? Bye Dario Maccari Hi, you're not authorising the user. theres nothing to allow them access in the authorise section. _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
