UserPrincipalName with ntlm_auth, trying to get it "right"

[Mathieu Simon (Lists)]

Hi

Thank you Alan, that's quite good news. I was writing about what I got a
bit further done while your message arrived.

Am 14.01.2016 um 16:29 schrieb Alan DeKok:

> 
>> However in this directory the *prefix in the UPN doesn't match with the
>> sAMAccountname* (for $anyreason). ntlm_auth obviously fails there.
> 
>   Yes.
> 
>   A potential solution is to use the UPN to look up the sAMAccountname, then pass the sAMAccountname to ntlm_auth.

That's what I somewhat ended up, learning another thing or two about
FreeRADIUS: rlm_ldap is really different with 3.0 than 2.2, basically
ldap.attrmap seems gone and I was looking in the wrong place.

Alan: However even the branch for 3.1 doc/modules/ldap_howto.rst
mentions it - is that still valid?

It seems getting the value from LDAP during a request is pretty easy
after all, no need for extra scripts... hmm.

dictionary, adding a custom attribute:
ATTRIBUTE AD-Samaccountname 3003 string

mods-available/ldap:
update {
control:AD-Samaccountname := 'sAMAccountName'
[...]

user {
filter = "(userPrincipalName=%{mschap:User-Name})"

This made FR look up sAMAccountName and populate the attribute as
defined in dictionary. So far so good.

mods-available/mschap:
ntlm_auth = /usr/bin/ntlm_auth \
[...] --username=%{control:AD-Samaccountname}

Then mschap used the obtained LDAP attribute instead of User-Name. That
seemed to work after with eapol_test and some real devices.

>   But that doesn't always work.  If you're using MS-CHAP, or PEAP (which uses MS-CHAP),  the UPN is part of the MSCHAP calculations.
> Which means sending the sAMAccountname instead *guarantees* that the MS-CHAP calculations will be based on the wrong thing... and will fail.
Sounds scary, I guess I'll have to double-check with a couple of devices
and users. I don't want to spoil the success I just had :-\

"Thankfully" domain-joined Windows systems do their own thing, when
logging in with their host credentials ("host\thishostname") and users
wil just send the samaccountname

Both "needs" both ways to be accepted. Would it be better to proxy all
requests with a domain suffix to another (virtual) server and have
rlm_mschap and rlm_ldap configured there differently for this purpose?

-- Mathieu