MSCHAP Issues

[Alan DeKok]

On Jul 26, 2019, at 12:38 PM, J Kephart <jkephart at safetynetaccess.com> wrote:
> 
> Good morning, everyone!  I'm having a challenge understanding why we're seeing the error:
> 
> authenticate {
> (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured.  Cannot create NT-Password
> (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured.  Cannot create LM-Password

  That's pretty clear.

> (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Creating challenge hash with username: 54-72-4F-69-14-B1
> (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Client is using MS-CHAPv2
> (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: FAILED: No NT/LM-Password.  Cannot perform authentication
> (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: MS-CHAP2-Response is incorrect
> (660) Fri Jul 26 09:20:17 2019: Debug:     [mschap] = reject
> (660) Fri Jul 26 09:20:17 2019: Debug:   } # authenticate = reject
> 
> We've just started providing radius services (3.0.18 on CentOS 7) to a new client, and all 14 of their properties have exhibited this behavior, to the tune of nearly 300,000 so far this month, with only about 80,000 successful auths.
> 
> In the authenticate debug above, it states that there is no Cleartext-Password, but I personally checked for this specific user, and the attribute is set in radcheck (I've checked a random sample of some others, as well, with the same result).  Still, however, we see that error, and for the life of me, although I believe I know *what* the error is, I'm unable to determine why.

  Read the debug output to see.  For ONE user.

>  We've done packet captures to ensure that the site's gateway (Nomadix) is sent the correct credential data (it is), but somehow, on arrival at the FR server, the password appears to be missing.
> 
> If someone can point me in the right direction (I'm thinking the NAS is the root of this), I would be most appreciative, as I don't want to lose any more hair! I've included the gzip'd output from raddebug, as this is a production server.
> I've had to include it as an attachment, because in raw form, it exceeded the message size limit for the list (and I apologize to the list maintainers for that error).

  There's no need to post a debug output with 600+ packets.  We're just not going to read all of that.  And the list doesn't allow large messages.  Zipping the debug output doesn't help.

  Post the debug output for *one* user.  Yes, you can edit a large debug output before posting to the list.

  Alan DeKok.