hello
> I don't understand where this restriction comes from. Once the FreeRADIUS server >gets the > password from the NAS, what prevents it from checking that password against >/etc/shadow, > PAM, another RADIUS server, or whatever? in fact, it's not a restriction of freeradius. it's a necessary restriction of the CHAP (and EAP-MD5, which is basically the same). the problem is that the client doesn't send a password which the server can check against whatever in whichever way. the client sends an authentication string (i'm not going to be very precise, it's the principal which we are talking about) produced by the user basically out of user's identity, the challenge sent before by the server, etc. and of course the password itself. what's good about this authentication string is that you can't guess whatever information has been taken to create it by just looking at the result (it's usually a cryptographic hash built using MD5, so a one-way function with rare collisions). the second good thing about it: it's very improbable, that you will be successful in producing the same result just using some crap instead of values used by the user. so, the only way to verify such an authentication string on the server side is to re-compute it the same way the client did. the only (theoretical) way to do so is to have the same input values and to process them in the same order and in the same concatenation through the same algorithm (MD5). then you compare the results. if they don't match - the user loses. if they do, the server sends the accept message. so, the server needs the unencrypted password. hope this helps. artur -- Artur Hecker Groupe Acc�s et Mobilit� [EMAIL PROTECTED] D�partement Informatique et R�seaux +33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13 http://www.infres.enst.fr ENST Paris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
