auth = yes logs too much, auth = no too little

[Alan DeKok]

On Sep 27, 2018, at 2:59 AM, Hans-Christian Esperer <hc at hcesperer.org> wrote:
> 
> I would like to log failed login attempts, so I can see the username that was
> tried. Is there a simple way to do this? Setting auth=yes in radiusd.conf also
> logs all successful attempts.

  Yes, that's the way it works, unfortunately.

> So basically, I'd like to see lines like this one:
>    Mon Sep 24 13:24:16 2018 : Auth: (34876)   Login incorrect (mschap: FAILED: No NT/LM-Password.  Cannot perform authentication): [username/<via Auth-Type = eap>] (from client unifi port 0 via TLS tunnel)
> 
> but not
>    Mon Sep 24 13:15:03 2018 : Auth: (34866) Login OK: [username] (from client unifi port 123456789 cli 00-00-11-22-33-44)
> 
> Any suggestions on how to achieve this or something similar would be much appreciated.

  Source code changes.

> Not directly related, but somewhat: When auth=no is set, and a login fails (be
> it due to a wrong username, or wrong passphrase), I get the following in the log:
> 
>    Mon Sep 24 13:24:16 2018 : Info: (34877) eap_peap:   This means you need to read the PREVIOUS messages in the debug output
>    Mon Sep 24 13:24:16 2018 : Info: (34877) eap_peap:   to find out the reason why the user was rejected
>    Mon Sep 24 13:24:16 2018 : Info: (34877) eap_peap:   Look for "reject" or "fail".  Those earlier messages will tell you
>    Mon Sep 24 13:24:16 2018 : Info: (34877) eap_peap:   what went wrong, and how to fix the problem
> 
> And that's all! There are *no previous* messages. There four lines are all that
> I get.

  Those are really debugging messages.  They shouldn't be in the log file.  I'll go fix that

> I assume this means that something on my side is misconfigured, like an
> "if all else fails, reject" kind of statement?

  No.  It means that the users password was wrong, or something else caused them to be rejected.  The PEAP state machine still continues after the *inner* session has been rejected.  This message is from a subsequent packet, and from the outer session.

  Alan DeKok.