On Jun 26, 2018, at 3:26 PM, Anthony Stuckey <anthonystuckey@gmail.com> wrote:
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 looks new, unfortunately.
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-co...
Documentation is hard...
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.
<sigh> Microsoft finds new and interesting ways to break their software.
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.
You should be able to update the server config to: a) validate that "host/i26171.DOMAIN" is from the known DOMAIN b) set up a "realm: to strip "DOMAIN" c) use Stripped-User-Name in the LDAP queries, instead of User-Name.
Wed May 23 10:51:04 2018 : Info: [ldap] performing user authorization for host/i26171.DOMAIN
No... post the FULL debug output. Using "radiusd -X". Not "radiusd -Xx" or anything else.
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)
i.e. you didn't define a realm called "DOMAIN".
Has anyone else encountered this issue, and what did you do to fix it?
No, and use realms.
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.
The various authentication protocols do hashes based on User-Name. If you rewrite that, the hashes will use the wrong values, and authentication will fail. The real solution is to use realms. See proxy.conf. realm DOMAIN { } should be all you need.
Attempts to actually do this all seem to end in various error messages and pain.
Exactly.
Is there any known setting for Windows 10 that will cause it to act in the backwards-compatible way?
Ask Microsoft how their software works. I don't have enough time in the day to keep up. And, people don't seem to update the Wiki with this kind of information. I've been saying for many years that we accept docs from the community. If the docs are insufficient or missing things, well, don't blame *us* for it all. The people complaining about the quality of the docs usually don't update *anything* in the Wiki. Which means there's less sympathy for their complaints.
Is there any documentation of why Microsoft made this change?
Pfft... that's not going to happen.
Is this a known issue which is fixed in freeradius3/RHEL7 somehow?
It's not a FreeRADIUS issue. Everyone blames FreeRADIUS for everything, which is one reason I get cranky... Alan DeKok.