"[eap] = reject" after "Calling eap_md5 to process EAP data"

[Kris Armstrong]

I tried uncommenting the line nostrip from the proxy.con.  that didn’t work. 


> On Jul 7, 2015, at 7:09 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Jul 8, 2015, at 6:25 PM, Zeus Panchenko <zeus at ibs.dn.ua> wrote:
>> what am I missing then, please? in my case Access-Accept succeeded only
>> when I changed the password to the value of User-Name attribute ...
>> 
>> isn't "MAC auth" mean login=password=MAC ?
> 
>  For some systems, yes.
> 
>>>> so, now I wonder, can I somehow rewrite User-Name value to use
>>>> normalized MAC?
>>> 
>>> Don't do that.
>> 
>> why? if not, then what is the way to achieve the desired? to store
>> login/password as FR normalized MAC address and eap_md5 understand that
>> (while User-Name differs)?
> 
>  In general, mangling the User-Name is a bad idea.  It means that the authentication and accounting may have different views of what the user name is.  It means that EAP may not work correctly.  It means that proxying may break.
> 
>  You're better off using a temporary attribute for the "mangled" user name, and leaving User-Name alone.  But in the end it's your system...
> 
>>> In v3, see raddb/policy.d/canonicalization It has policies to
>>> normalize MAC addresses in Calling-Station-Id.  The same policies
>>> can be applied to other attributes, too.
>> 
>> does it mean I can transform original User-Name value like a1b2c3d4e5f6
>> to A1-B2-C3-D4-E5-F6 ?
> 
>  That's what the policy tries to do.
> 
>  Alan DeKok.
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html