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@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@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@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@deployingradius.com> wrote:
On May 11, 2018, at 12:02 PM, Jeremy Lundquist <pmudan01@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