RADIUS wifi not working on Windows 8.1 and Windows 10 with domain users

Question

EDIT:

I was able to narrow down the problem. Apparently this is not an issue with the Surface but Windows 8.1 (probably 8, too) and 10. I did not catch this at first as I used a non-domain laptop and user to test with Windows 8.1 first.

When I use a local user account, connecting to the RADIUS wifi works flawlessly. As soon as I try this with a domain user account (I tried one with and one without local admin permissions), it will not connect. Please note that I'm talking about a domain and not AD, as we are still using Samba 3.

Original:

We are running a radius wifi network using a FreeRADIUS server (PEAP with MSChapv2). It works flawlessly on all machines (tested on Windows 7 & 8.1, Android 4.3, Arch Linux) except on all of our Surface Pro 3. The Windows machines use the exact same settings as the wifi setup is automated using a powershell script. I've also tried configuring it manually with different options many times. We are using a certificate signed by our company's custom certificate authority for the FreeRADIUS server. I've verified that the CA is correctly installed in Windows and also tried a connection without verification of the certificate.

This is what shows up in the FreeRADIUS logfile:

Wed Jul 15 10:32:52 2015 : Auth: Login OK: [someuser] (from client stg-wlan-core port 0 via TLS tunnel)
Wed Jul 15 10:32:55 2015 : Auth: Login incorrect: [someuser] (from client stg-wlan-core port 217 cli C0-33-5E-33-10-8F)

This is what shows up if you use debugging on FreeRADIUS:

[eap] EAP packet type response id 221 length 43
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
[peap] eaptls_verify returned 7
[peap] Done initial handshake
[peap] eaptls_process returned 7
[peap] EAPTLS_OK
[peap] Session established.  Decoding tunneled attributes.
[peap] Peap state send tlv success
[peap] Received EAP-TLV response.
[peap] Client rejected our response.  The password is probably incorrect.
[peap] We sent a success, but received something weird in return.
[eap] Handler failed in EAP/peap
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
Login incorrect: [someuser] (from client stg-wlan-core port 112 cli 50-1A-C5-F4-F6-87)
Using Post-Auth-Type Reject

It says something about an incorrect password. I'm not sure which password it is talking about as I'm certain that the user account exists and the password is correct.

Trace from the Surface:

[500] 07-15 10:19:48:898: RasEapCreateConnectionProperties, eap type id = 26
[500] 07-15 10:19:48:899: CopyXmlDoc returned: 0x0
[500] 07-15 10:19:48:899: ReadConnectionData
[500] 07-15 10:19:48:900: Setting the defaults to use win-logon
[500] 07-15 10:19:48:900: Use Winlogon credentials is set to No
[500] 07-15 10:19:48:900: Successfully generated blob for MSChapV2 Connection Properties
[500] 07-15 10:19:49:831: RasEapCreateConnectionProperties, eap type id = 26
[500] 07-15 10:19:49:831: CopyXmlDoc returned: 0x0
[500] 07-15 10:19:49:832: ReadConnectionData
[500] 07-15 10:19:49:833: Setting the defaults to use win-logon
[500] 07-15 10:19:49:833: Use Winlogon credentials is set to No
[500] 07-15 10:19:49:833: Successfully generated blob for MSChapV2 Connection Properties
[500] 07-15 10:19:49:843: RasEapCreateConnectionProperties, eap type id = 26
[500] 07-15 10:19:49:843: CopyXmlDoc returned: 0x0
[500] 07-15 10:19:49:844: ReadConnectionData
[500] 07-15 10:19:49:845: Setting the defaults to use win-logon
[500] 07-15 10:19:49:845: Use Winlogon credentials is set to No
[500] 07-15 10:19:49:845: Successfully generated blob for MSChapV2 Connection Properties
[500] 07-15 10:19:50:109: InitLSA.
[500] 07-15 10:19:50:109: InitLSA: returning 0x0
[500] 07-15 10:19:50:109: ChapInit: exit: fInitialize=0x1, g_dwRefCount = 0x1, g_hLsa = 0x1147e5d0
[500] 07-15 10:19:50:109: EapMSCHAPv2Initialize Exit: fInitizlize = 1, dwRefCount = 0x1,
[500] 07-15 10:19:50:109: EapMSCHAPv2Initialize: fInitizlize = 0, dwRefCount = 0x1,
[500] 07-15 10:19:50:109: ChapInit: fInitialize=0x0, g_dwRefCount = 0x1, g_hLsa = 0x1147e5d0
[500] 07-15 10:19:50:135: RasEapGetIdentity
[500] 07-15 10:19:50:135: ReadUserData
[500] 07-15 10:19:50:135: NULL user blob is passed, size: 0
[500] 07-15 10:19:50:135: ReadConnectionData

The only reason I can think of anymore is that it is a problem with the wifi adapter or its driver. If you have any ideas or need further information, please let me know.

Solution

The issue is that you can no longer configure Windows 8 and Windows 10 to use the desired settings from the GUI.

To solve this

You can export a configuration profile from a Windows 7 client and import it on your Windows 8 and/or 10 clients.

1. Open a command prompt on the Windows 7 client

2. Enter the following command

   netsh wlan show profiles
   

3. Choose the profile you want to export (the wifi radius one) from the list that is displayed

4. Export it using the following command

   netsh wlan export profile <profile name>
   

   This will export the profile to an xml file.

5. Locate the XML file and copy it to your Windows 8 and 10 clients

6. Import it using the following command:

   netsh wlan add profile <profile name>.xml
   

7. Enter the corresponding credentials and you're done.

Note: Sometimes I need to delete the old (invalid) profile in the Windows 8 and/or 10 clients:

netsh wlan delete profile <invalid profile>

Note: A reboot can sometimes be required

Comments

[Kinnectus]

Have you downloaded the latest drivers for the Surface Pro 3 Marvell wireless adapter? We've had a problem with some Broadcom wireless cards and the eduroam wireless (for education). The Windows 8 (and above) "in-the-box" drivers work the card but they don't work with our authentication... this may be similar to your problem... update the drivers (you may need to see if you can get the drivers not from the Microsoft website - they'll only provide ones that work with their devices and are often outdated)...

[St0rmi]

I wasn't able to find any drivers from Marvell directly. I installed the newest Intel drivers for a Windows 10 laptop with the same issue, however. It sadly didn't solve the problem.

[Kinnectus]

If you can provide the hardware IDs of the laptop wifi adapter and the currently installed driver and its version then this may be easier to help identify the problem. The Surfaces can be a pain...

[St0rmi]

It's an Intel Centrino Advanced-N 6205 wifi adapter using the Intel driver. Hardware ID: PCI\VEN_8086&DEV_0082&SUBSYS_13218086&REV_34 Driver version: 15.18.0.1

[Kinnectus]

When your users enter their username and password to connect, are they entering in domain format (domain\username)? We've experienced this before (not with FreeRADIUS, but the same should apply) where the machine name was being supplied to the RADIUS authentication rather than the correct domain name... I'm not sure if Windows 7 and earlier (being domain joined) added the domain and now Windows 8 doesn't by default..?

[Roke]

thank you for your contribution to SuperUser. Be sure to explain your answers more thoroughly in the future. Check out my edit for an example of this.

[St0rmi]

We were actually already using a small Powershell script that does just that. As described above it works with a non-domain user profile but not with a domain one.