Le 12/06/12, Alan DeKok <aland@deployingradius.com> a écrit :
Emmanuel BILLOT wrote:
Could you explain what is the difference between the default file and the inner-tunnel file in /etc/raddb/site-enabled ?
This is documented in the comments at the top of the files.
The "default" virtual server handles normal RADIUS traffic. However, some EAP types set up a TLS tunnel between the PC and the RADIUS server. The data *inside* of the TLS tunnel has to be authenticated.
So... it's run through the "inner-tunnel" virtual server.
Hi, Ok that's what i read from you on another post.
When running in debug mode, i see sometimes # Executing section authorize from file /etc/raddb/sites-enabled/default and sometimes # Executing section authorize from file /etc/raddb/sites-enabled/inner-tunnel
Not "sometimes". That is a very bad way to think about it. The debug log shows *exactly* what the server is doing. Read it slowly, it will make sense.
Sorry i didn't use correct words. I tried to follow each line in a radiusd -X output. It begins with a a complete request, and the authorize section. Parsing each authorize mechanism, only eap doesn't return "noops". A first question : the default file says eap { return ok } EAP request comes with EAP message and is so captured by the eap authorize section, right ? It returns an update of the original request with Auth-Type = EAP I can't understand why there is then one second authorize check.
Is there any docs about the complete processing of EAP authentication ?
Nope.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57
Billot wrote:
A first question : the default file says
eap { return ok }
EAP request comes with EAP message and is so captured by the eap authorize section, right ? It returns an update of the original request with Auth-Type = EAP
Yes.
I can't understand why there is then one second authorize check.
I explained. See my previous message. The "inner-tunnel" server is run. This means a second authorize check. It's not that complicated. Read the debug output. It tells you what's going on. There's no magic. Alan DeKok.
On Tue, Jun 12, 2012 at 08:11:17PM +0200, Billot wrote:
It begins with a a complete request, and the authorize section. Parsing each authorize mechanism, only eap doesn't return "noops".
A first question : the default file says
eap { return ok }
EAP request comes with EAP message and is so captured by the eap authorize section, right ? It returns an update of the original request with Auth-Type = EAP
I can't understand why there is then one second authorize check.
You seem to be misunderstanding two things. EAP (in the case of PEAP/TTLS anyway) sets up an encrypted tunnel, within which a *second* EAP session happens. So you get the first EAP, which does not authenticate the user, it just encrypts data. Then the decrypted data is a second, "inner", EAP session, which actually has the authentication. In the case of PEAP/MS-CHAPv2, it's actually two EAP sessions with different types - EAP-PEAP, which is the "outer", and EAP-MS-CHAP-V2, which is the "inner". So you have the outer "default" file, which calls the EAP module to set up the encrypted tunnel. That then passes the data from inside the tunnel to the "inner-tunnel" configuration, which runs through in a similar way but authenticates the user. Depending on the outcome of the inner-tunnel, the outer "default" then returns Accept or Reject. The other thing is that EAP has multiple round trips of packets going backwards and forwards between the client and the server. The "eap { return ok }" bit is for saving time - it means that the server quits processing the rest of the other modules when the eap module is setting up the tunnel. For example, if you're doing LDAP lookups, you don't want them happening every time the EAP module sends another challenge to the client - it's a complete waste of time and resources. This config stops that happening. In short, you generally just need to leave it alone and not worry about it. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (3)
-
Alan DeKok -
Billot -
Matthew Newton