Another LDAP/MSCHAPv2 problem

[Phil Mayers]

On 09/02/12 16:42, Alan DeKok wrote:

>
>    The issue could be somewhere else.  From what I recall, host
> authentication is... weird.  The name in the MS-CHAP blob might *not* be
> the same as the User-Name field.  If that happens, the calculated
> response using the User-Name will be wrong.


Looking at the code in rlm_mschap, it seems clearly to be wrong for 
host-based (non ntlm_auth) cases; it basically does:

  1. Look for MS-CHAP-User-Name (this was added to make EAP-MSCHAPv2 work)
  2. Otherwise, look for User-Name; if with_ntdomain_hack is set, strip 
leading DOMAIN\

Code for converting host/name.domain to name$ is absent here.

As you've suggested, setting MS-CHAP-User-Name to name$ will probably 
make it work. Ironically, since the mschap xlat function *DOES* handle 
this case, setting:

  update request {
    MS-CHAP-User-Name := "%{mschap:User-Name}"
  }

...will work!

TBH I wonder if this code should be entirely reworked for 3.0; it might 
be better to set MS-CHAP-User-Name in the "authorize" section (unless 
already set e.g. by rlm_eap_mschapv2) so that it's ready for use in 
authenticate.

We could take the opportunity to handle user at domain too. AFAIK the 
formats we should handle are:

bareuser
DOMAIN\user
user at domain.com
host/name.domain.com

Problem being, I'm wary of fiddling with this code; it's been arrived at 
with years of testing, and it's not impossible something would break, or 
some security hole be opened up...