Another LDAP/MSCHAPv2 problem

[Francois Gaudreault]

Doing the MS-CHAP-User-Name change got me this error :

mschapv2] # Executing group from file 
/etc/raddb/sites-enabled/packetfence-tunnel
[mschapv2] +- entering group MS-CHAP {...}
[mschap] Found NT-Password
[mschap] ERROR: User-Name (host/dti-dahport) is not the same as MS-CHAP 
Name (dti-dahport$) from EAP-MSCHAPv2

On 12-02-09 12:32 PM, Francois Gaudreault wrote:
> Interesting. Let me give it a shot and see how it goes.
>
> Thanks!
>
> On 12-02-09 12:19 PM, Phil Mayers wrote:
>> 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...
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>


-- 
Francois Gaudreault, ing. jr
fgaudreault at inverse.ca  ::  +1.514.447.4918 (x130) ::  www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence 
(www.packetfence.org)