User-Name Modification Assistance

[Jeremy Lundquist]

Thxs Alan B and Alan D for the follow ups.
So the password is the issue as not only does this NAS vendor not put the
MAC in the correct format but they are also currently not sending a
password :)
In an attempt to get around this for this vendor I'm trying to manually set
the User-Password then. I'll be modifying the coding to make it based on
the specific vendors Called-Station-Id, but for now I'm just statically
setting it for testing purposes at the same time as I'm setting the
Stripped-User-Name. Ie, see here (reusing some of what's already in
policy.d/canonicalization):

rewrite_stripped_username {
        if (&User-Name && (&User-Name =~ /^${policy.mac-addr-regexp}$/i)) {
                update request {
                        &Stripped-User-Name :=
"%{tolower:%{1}%{2}%{3}%{4}%{5}%{6}}"
                        &User-Password :=
"%{tolower:%{1}%{2}%{3}%{4}%{5}%{6}}"
                }
                updated
        }
        else {
                noop
        }
}

So this should leave username as the original, but change the
Stripped-User-Name and set User-Password (I can see/verify this in the
debug as see these values entered into the DB radauthpost table). I've also
configure the SQL queries to use Stripped-User-Name. And I've included this
into my authorization section of site-enables/default, but I'm still
getting the EAP failure as shown in the previous debug: Should I be adding
it elsewhere also or am I missing something still?

Thxs
Jeremy



On Fri, May 11, 2018 at 5:23 AM, Alan DeKok <aland at deployingradius.com>
wrote:

> On May 10, 2018, at 5:23 PM, Jeremy Lundquist <pmudan01 at gmail.com> wrote:
> > Currently using freeradius 3.0.13, have it installed and configured
> (using
> > mysql DB as the backend) and working fine. We are using MAC Based
> > Authentication for authenticating/authorizing our end users equipment and
> > till now working great.
> > We went out the door using a MAC format of aabbccddeeff for
> > username/password as our initial equipment passes it over this way, but
> we
> > have some new equipment going into the network that sends the MAC as the
> > username in the format aa-bb-cc-dd-ee-ff.
>
>   There is a specification (mostly) for MAC address formats in RADIUS.
> Sadly, many NAS vendors ignore that, like they ignore much else in the
> specs.
>
> > So I'm trying to figure out how
> > we can continue to use the username in the format aabbccddeeff (in the
> > radcheck DB table) but accept the new format (with dashes) in the
> > Access-Request and then modify the User-Name (or Stripped-User-Name) to
> use
> > the non-dash format during the authentication/authorization process.
>
>   Don't modify the User-Name for EAP.
>
> > I've seen in various posts that I should not modify the User-Name
> > attribute, so I'm currently trying to use the Stripped-User-Name. I've
> > defined a way to strip the dashes (-) from the User-Name and assign it to
> > the Stripped-User-Name and can see this being used.
>
>   raddb/policy.d/canonicalization contains ways of doing this.
>
>
> > But the issue I'm
> > running into is during the authentication process I hit a part that shows
> > EAP failing. I've been trying to understand why it's failing and how to
> > work around it, but no luck and thus the reason for my question to the
> list.
> > Any help or guidance would be greatly appreciated.
> >
> > See below the debug output (radiusd -X) for my radius setup.
>
>   Hmm... better debug messages would help there.
>
>   But in the end what's happening is that the EAP-MD5 calculations don't
> match.  So the user entered the wrong password.
>
>   You can test this by trying PAP authentication.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>