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@domain too. AFAIK the formats we should handle are: bareuser DOMAIN\user user@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...