Logging mschap error when send_error=yes

[Alan DeKok]

On Nov 2, 2015, at 1:12 PM, Brian Julin <BJulin at clarku.edu> wrote:
> Currently I'm configuring new servers for an eventual 3.0.x migration,
> and decided to take a look at password-change.  I have not got that far yet,
> just as far as playing around with the server behavior when EAP-MCHAPv2 is set
> to send_error = yes, which is a prerequisite for that.  As soon as this is turned on
> we seem to lose the ability to log the exact error code returned by ntlm_auth, and
> this is actually one of the more critical log messages we need to detect locked
> accounts.
> 
> With send_error=yes the flow out of the inner tunnel after a bad ntlm auth is as follows:
...
> ... and there seems to be pretty much no toehold by which to get an unlang statement
> into that to store or log MSCHAP-Error or Module-Failure-Message.

Just put a statement into the eduroam_idpi_inner virtual server.  You will need to to catch the "handled" return code from the EAP module.  That code says to stop processing the section, and retune.

  So..

server eduroam_idpi_inner {
...
authenticate {
	...

	Auth-Type EAP {
		eap {
			handled = 1	# don't return right away
		}

		if (reply:MS-CHAP-Error) {
			# do logging of MS-CHAP-Error
		}

		handled # which is what EAP tried to return above.
	}

}

> The second thing is that, since the failure seems to promulgate down to the EAP layer in
> a different fashion (a new challenge seems to always be issued and the failure delayed
> until later packets, even when retries are not allowed) the normal logs get filled with
> the usual "The users session was previously rejected" stanza, which in this particular
> case is not very helpful since there's not much to read above them (and it's a lot of syslog
> bulk for a common logon failure.)

  That message was changed to be a debug-only message.  It's available now in the v3.0.x branch in git, or wait for 3.0.1..

> The third thing is, while looking further into this I noticed the current code for dealing
> with locked accounts appears to be entirely based off SMB-Account-CTRL, which does not
> seem to exist when authing against an actual AD server rather than a local Samba setup.

  OK.

> For password changes there is code to use the text returned from ntlm_auth instead, but locked
> or disabled accounts just end up sending 691/"Authentication failed" instead
> of the actual error.  So I quick-hacked the C code to pass on the code/message for
> locks and disables.

  Do you have a patch?

> Second question: is there any particular reason why the code is the way it is, or is
> it just a not-implemented-yet situation?

  Not done yet.

  As always, patches are welcome.

  Alan DeKok.