MSCHAP Issues

[Alan DeKok]

On Jul 26, 2019, at 3:34 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
> Yes, it is, but if I'm reading this correctly, it seems to be telling me that there's no such attribute in radcheck.  Am I interpreting it correctly, because if so, I can confirm that the Cleartext-Attribute for the user does exist in radcheck.

  Nope.

> (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND %{User-Name}
> (660) Fri Jul 26 09:20:17 2019: Debug: sql:    --> 54-72-4F-69-14-B1
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: SQL-User-Name set to '54-72-4F-69-14-B1'
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id
> (660) Fri Jul 26 09:20:17 2019: Debug: sql:    --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority
> (660) Fri Jul 26 09:20:17 2019: Debug: sql:    --> SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority
> (660) Fri Jul 26 09:20:17 2019: Debug: sql: User not found in any groups
> (660) Fri Jul 26 09:20:17 2019: Debug:     [sql] = notfound

  "notfound"  means that the user wasn't found in SQL.

  Try running the SQL query manually.  That's why it's printed out in debug mode: so you can cut & paste it into an SQL command-line tool.

> Let me see if I can be a little more clear.  I'm pretty sure that, reading the debug output, the problem is that the user password is not present in the packet that FR receives from the NAS.

  No.

> We know that the instruction we send to the NAS to auth a device is correct, and does include both the username and the correct password.  We know that the NAS receives it, but when it tries the auth with FR, it appears to "lose" the password, resulting in a reject response.

  No.

> In short, I believe the problem is in the data sent by the NAS.

  No.  Sven's explanation is correct here.

> Thus, I simply want to confirm that my understanding of what I've read is correct, that FR is not the problem (and I really don't think it is), and that the NAS is the actual source of the problem. Having confirmed that, I will then hand it to the NAS vendor and tell them to find/fix what's broken in their devices.  Ultimately, I just need a second set of eyes (from someone who is far better at this than I) so I can move in the proper direction.

  The debug log is clear: the user is not found in SQL.

  I suspect what's happening is that SQL contains the user name as "54:72:4F:69:14:B1", and not as "54-72-4F-69-14-B1'".

  Alan DeKok.