Windows 10 breaks Samba/LDAP/freeradius machine credentials configuration

[Anthony Stuckey]

I find it hard to believe that I'm the first person to come across this
issue, but I have been unable to find anyone else with these exact
questions or documentation that discusses this issue.

It's easy to find a Microsoft document that discusses a problem that I
don't have, it's very hard to find any document which discusses the problem
I do have.
https://support.microsoft.com/en-us/help/3121002/windows-10-devices-can-t-connect-to-an-802-1x-environment

We use a Samba domain controller with an LDAP backend to provide account
services for our organization.  We have a Cisco wireless lan controller
which uses freeradius to authenticate with Windows Machine Credentials.

Windows 10 sends different User-Names before and after it is joined to the
domain, and that causes wireless authentication to fail.  Previous versions
of Windows do not have this behavior, and wireless authentication works
perfectly.

Specifically, the User-Name attribute changes from User-Name =
"host/i26171" to User-Name = "host/i26171.DOMAIN".  The Samba server
creates an ldap entry with the password attributes under the non-domain
name, which is then not found when the credentials are presented with the
domain attached.

dn: uid=I26171$,ou=Machines,ou=SambaSAM,dc=domain,dc=edu

uid: I26171$

uid: host/i26171

sambaSID: S-1-5-21-4128435402-3538960026-4000809499-15117

displayName: i26171$

objectClass: sambaSamAccount

objectClass: account

objectClass: radiusprofile

sambaAcctFlags: [W          ]

cn: i26171

radiusFilterId: true

radiusTunnelMediumType: IEEE-802

radiusTunnelType: vlan

radiusTunnelPrivateGroupId: 630

sambaNTPassword: <<secret>>

sambaPwdLastSet: 1526590492

Wed May 23 10:51:04 2018 : Info: [ldap] performing user authorization for
host/i26171.DOMAIN

Wed May 23 10:51:04 2018 : Info: [ldap] WARNING: Deprecated conditional
expansion ":-".  See "man unlang" for details

Wed May 23 10:51:04 2018 : Info: [ldap]         ... expanding second
conditional

Wed May 23 10:51:04 2018 : Info: [ldap]         expand: %{User-Name} ->
host/i26171.DOMAIN

Wed May 23 10:51:04 2018 : Info: [ldap]         expand:
(uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=host/i26171.DOMAIN)

Wed May 23 10:51:04 2018 : Info: [ldap]         expand:
ou=sambasam,dc=domain,dc=edu -> ou=sambasam,dc=domain,dc=edu

Wed May 23 10:51:04 2018 : Debug:   [ldap] ldap_get_conn: Checking Id: 0

Wed May 23 10:51:04 2018 : Debug:   [ldap] ldap_get_conn: Got Id: 0

Wed May 23 10:51:04 2018 : Debug:   [ldap] performing search in
ou=sambasam,dc=domain,dc=edu, with filter (uid=host/i26171.DOMAIN)

Wed May 23 10:51:04 2018 : Debug:   [ldap] object not found

Wed May 23 10:51:04 2018 : Info: [ldap] search failed

Wed May 23 10:51:04 2018 : Debug:   [ldap] ldap_release_conn: Release Id: 0

Wed May 23 10:51:04 2018 : Info: ++[ldap] = notfound

Has anyone else encountered this issue, and what did you do to fix it?

The obvious solution is to rewrite the User-Name attribute in the
freeradius configuration, but this is seriously frowned upon by the
freeradius developers, for reasons which are not usually made explicit
other than vague comments that it might allow a security hole.  Attempts to
actually do this all seem to end in various error messages and pain.

Is there any known setting for Windows 10 that will cause it to act in the
backwards-compatible way?

Is there any documentation of why Microsoft made this change?

Is this a known issue which is fixed in freeradius3/RHEL7 somehow?

[root at radiusdebug /]# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.9 (Santiago)

[root at radiusdebug /]# rpm -qa | egrep -i freeradius

freeradius-2.2.6-7.el6_9.x86_64

freeradius-utils-2.2.6-7.el6_9.x86_64

freeradius-ldap-2.2.6-7.el6_9.x86_64
-------------- next part --------------
A non-text attachment was scrubbed...
Name: radius226_debug
Type: application/octet-stream
Size: 99553 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180626/c2848b84/attachment-0001.obj>