User-Name Modification Assistance

[Jeremy Lundquist]

So I figured it out. The value of User-Name (MAC) in the Access-Request is
also used as the EAP Password (determined through trial and error testing).
So going back to my original reason for doing this work. I'd like to be
able to have in my DB the username/password to be the MAC of the new HW and
without dashes. Currently I have working the following - the username (MAC)
without dashes but the password (MAC) still with dashes, as the EAP
password is this value also. Thus I'm wondering, as the NAS passes over the
EAP password with dashes, is there a way I can store in my Radius DB the
password without dashes, but when EAP needs to query it for the hash
comparison it does so but inserts dashes before using it?

This all goes without saying I'm trying to work with the vendor to
implement things differently on their end, but need to get this working now
as we are using them in network.

Thxs
Jeremy



On Fri, May 11, 2018 at 10:53 AM, Jeremy Lundquist <pmudan01 at gmail.com>
wrote:

> So by " you need to add to your SQL DB the value that the NAS is sending
> in its EAP-MD5 auth request ", I'll need to contact the NAS vendor and get
> the value as I believe in the auth request it's a hash value, correct?
>
> Jeremy
>
>
> On Fri, May 11, 2018 at 10:36 AM, Alan Buxey <alan.buxey at gmail.com> wrote:
>
>> there IS a password...its not a plain PAP user-Password though - its in
>> that EAP-Message that you can see.
>> so, you need to add to your SQL DB the value that the NAS is sending in
>> its
>> EAP-MD5 auth request
>>
>> you cannot just Access-Accept an EAP request, there needs to be a full,
>> correct response.
>>
>> alan
>>
>> On 11 May 2018 at 18:22, Jeremy Lundquist <pmudan01 at gmail.com> wrote:
>>
>> > Here is the username/password from the mysql DB - note no password
>> (blank).
>> >
>> > MariaDB [radiusdb]> select * from radcheck where
>> username='107b44c186e0';
>> > +------+--------------+--------------------+----+-------+
>> > | id   | username     | attribute          | op | value |
>> > +------+--------------+--------------------+----+-------+
>> > | 2308 | 107b44c186e0 | Cleartext-Password | := |       |
>> > +------+--------------+--------------------+----+-------+
>> > 1 row in set (0.00 sec)
>> >
>> >
>> > So when I tested using radclient (sending just username, no password)
>> > without adding the following to my authorize section in
>> > sites-enabled/default it failed (which I believe is expected? ).
>> >                 update control {
>> >                         Auth-Type := Accept
>> >                 }
>> >
>> > Debug snippet:
>> > .
>> > .
>> > rlm_sql (sql): Released connection (2)
>> > (0)     [sql] = ok
>> > (0)     [expiration] = noop
>> > (0)     [logintime] = noop
>> > (0) pap: No User-Password attribute in the request.  Cannot do PAP
>> > (0)     [pap] = noop
>> > (0)   } # authorize = updated
>> > (0) WARNING: Please update your configuration, and remove 'Auth-Type =
>> > Local'
>> > (0) WARNING: Use the PAP or CHAP modules instead
>> > (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type =
>> > Reject
>> > (0) Failed to authenticate the user
>> > (0) Using Post-Auth-Type Reject
>> > (0) # Executing group from file /etc/raddb/sites-enabled/default
>> > (0)   Post-Auth-Type REJECT {
>> > (0) sql: EXPAND .query
>> > .
>> > .
>> >
>> > NOTE - I verified in my configs, I have not set "Auth-Type = Local"
>> > anywhere.
>> >
>> > But when I added it, it passed (again, expected per one of your
>> > instructions in previous email).
>> >
>> > Debug snippet:
>> > .
>> > .
>> > (0)     [sql] = ok
>> > (0)     [expiration] = noop
>> > (0)     [logintime] = noop
>> > (0) pap: WARNING: Auth-Type already set.  Not setting to PAP
>> > (0)     [pap] = noop
>> > (0)   } # authorize = updated
>> > (0) Found Auth-Type = Accept
>> > (0) Auth-Type = Accept, accepting the user
>> > (0) # Executing section post-auth from file /etc/raddb/sites-enabled/
>> > default
>> > (0)   post-auth {
>> > (0)     update {
>> > (0)       No attributes updated
>> > (0)     } # update = noop
>> > .
>> > .
>> >
>> > So going back to my using the test HW, you are saying even without a
>> > password it should work as long as what's in the DB and what's passed
>> via
>> > the HW is the same. But there is no password passed in the
>> Access-Request
>> > and there is none in the DB, thus it should work, but it's not? That's
>> were
>> > I'm getting hung up. I'd expect it to work as both are the same
>> (nothing),
>> > but it's not, unless I'm not understanding properly what you are saying.
>> >
>> > Jeremy
>> >
>> >
>> > On Fri, May 11, 2018 at 9:07 AM, Alan DeKok <aland at deployingradius.com>
>> > wrote:
>> >
>> > > On May 11, 2018, at 12:02 PM, Jeremy Lundquist <pmudan01 at gmail.com>
>> > wrote:
>> > > >
>> > > > Let me add an updated Debug output to be thorough:
>> > >
>> > >   Reading it, and my messages would help.
>> > >
>> > >   The reason there's no User-Password in the request is because the
>> NAS
>> > is
>> > > doing EAP.
>> > >
>> > >   As I said before, it's doing EAP-MD5.  And EAP-MD5 is failing
>> because
>> > > the password is wrong.
>> > >
>> > >   Stop trying to create a User-Password.  It's not necessary.  Test
>> PAP
>> > > with radclient.  It should work.
>> > >
>> > >   EAP-MD5 is basically CHAP.  So if the user enters the same password
>> as
>> > > what's in the DB, it *will* work.
>> > >
>> > >   The only reason it won't work is that the passwords *are not the
>> same*.
>> > >
>> > >   Alan DeKok.
>> > >
>> > >
>> > > -
>> > > List info/subscribe/unsubscribe? See http://www.freeradius.org/
>> > > list/users.html
>> > >
>> > -
>> > List info/subscribe/unsubscribe? See http://www.freeradius.org/
>> > list/users.html
>> >
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list
>> /users.html
>>
>
>