7260 AC + 802.1x + Win 8.1 x64 = Fail.

[SLyke]

Hello all -

Have a set of D34010WYK NUCs that I want to move to wireless. I purchased a package of 7260 AC adapters and have installed one for testing with our enterprise network.

It appears that even the latest driver (12/8/14) does not work properly with 802.1x networks. This is a Cisco WAP371 based network where many other devices work perfectly and have no problems.

In searching in appears this has been a problem in the past but no resolution appears to exist that I can find with Google.

WPA2-PSK works fine but 802.1x fails authenticating using the computer account, login credentials, and manually inputting known good credentials.

Any ideas?

Thanks.

[jbenavides]

Hello Slykens,

Please let us know if the network you are attempting to connect to is 802.11a/b/g/n or ac, is it 2.4 or 5.2 GHz?. Are you able to see the SSID and detect Wireless networks? Have you tested if the NUC is able to connect to other networks?

You might want to install driver 17.14.0, which can be downloaded in the following location:

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24656&lang=eng&ProdId=3714 https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24656&lang=eng&ProdId=3714

Also, apply the settings recommended in the following document, as they may improve the connection in most environments:

http://www.intel.com/support/wireless/sb/CS-030709.htm?wapkw=wifi+recommended+settings What are the Recommended Settings for 802.11n Connectivity?

[SLyke]

Hello Jonathan -

The network is 802.11n only in 2.4 GHz and 802.11n/ac in 5 Ghz. Same SSID in both bands. I am able to see the SSID and attempt to connect to it both with Windows managing connectivity and with the Intel software managing connectivity. I see the authentication attempt in the RADIUS server logs but it does not complete properly.

I have verified the settings as suggested by the second link in your post.

As mentioned in my first post, the system will connect to WPA2-PSK networks just fine (and sees all other SSIDs in range as well), it appears the driver fails to complete the 802.1x authentication properly. Unfortunately, our enterprise network is 802.1x so PSK is not an option for us.

The driver package you have listed above leaves me with driver version 17.13.11.5 (12/8/2014) - the same version previously tested.

Thank you for the help.

[jbenavides]

Hello slykens,

Try using the Intel® PROSet/Wireless Software and drivers for IT administrators (current version 17.14.0). It would be advised to remove the version already installed from Windows Programs and Features.

During the setup process it will let you install additional features for enterprise environments.

Also, it will give you the option to create customized profiles, so you can manage the wireless connections to match the configuration in your environment.

http://www.intel.com/support/wireless/wtech/proset-ws/sb/CS-034038.htm Intel® PROSet/Wireless Software IT Administrator Links

If the issue persists, we would like to know if you are using Windows or PROset to manager the wireless connections.

If you have created a package with Intel® PROset/wireless software, please let us know the details about the package.

[SLyke]

Hello Jonathan -

I have removed the existing toolset installation and installed from the link you provided also installing the Enterprise options.

Disappointingly, this has not solved the problem. Using PROSet to manage the wireless connections and asking it to connect to our enterprise network, it claims to only partially detect the network configuration. I verified the remaining settings match our network configuration in Network Policy Server on our Windows server. (PEAP and MS-CHAP-V2 being acceptable)

Configuring PROSet to use both manually entered credentials (with and without domain name) or Windows Login, NPS reports that the client has sent invalid credentials. In the Windows Event Log for NPS on the server, an entry is made for event 6273 as follows:

==

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:

Security ID: DOMAIN\username

Account Name: DOMAIN\username

Account Domain: DOMAIN

Fully Qualified Account Name: DOMAIN\username

Client Machine:

Security ID: NULL SID

Account Name: -

Fully Qualified Account Name: -

OS-Version: -

Called Station Identifier: wapmac

Calling Station Identifier: D8-FC-93-1B-BF-B1

NAS:

NAS IPv4 Address: 10.10.1.14

NAS IPv6 Address: -

NAS Identifier: -

NAS Port-Type: Wireless - IEEE 802.11

NAS Port: 0

RADIUS Client:

Client Friendly Name: Third Floor WAP371

Client IP Address: 10.10.1.14

Authentication Details:

Connection Request Policy Name: Wireless Network

Network Policy Name: Wireless Network

Authentication Provider: Windows

Authentication Server: windowsservername

Authentication Type: PEAP

EAP Type: -

Account Session Identifier: -

Logging Results: Accounting information was written to the local log file.

Reason Code: 16

Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

==

Notably here the EAP Type field should be populated with "Microsoft: Secured password (EAP-MSCHAP v2)" as it is with all other devices which connect to this network using PEAP, however, in the case of the NUC with the 7260 card, this field is empty leading me to believe that the driver is not properly sending the authentication request.

It is also disappointing that the PROSet tools can not use the machine account to connect to the wireless - we are using this configuration with several computers with success and is my preference for these workstations.

Your help is appreciated.

Thank you.

[jbenavides]

Hello slykens,

It seems that there may be something missing in the configuration of the Wireless profile. Here are the detailed steps required to create a customized profile using Intel® PROSet/Wireless Software.

When you customize the installation of Intel® PROSet/Wireless Software to include the Enterprise features, it will give you the option to create, import and export Wireless connection profiles.

After the installation, you should have the "WiFi Connection Utility" application installed in the computer.

In the main screen of the WiFi Connection Utility, click "Profiles" to manage wireless profiles.

Then, you will have the option to "Add" a new profile, or change the properties of an existing one.

When you create a profile, first you will need to enter the profile name and SSID of the network in the General Settings.

After that, you can modify the Security Settings, starting with the PEAP user configuration, in your case you will need to use Enterprise Security, then set the Authentication, Encryption and Credentials according to the settings of your network. This is where you can set 802.1X configuration.

In this same screen, you can set "Cisco Options" as required to match the network settings.

In the next step, enter the PEAP server options according to your environment.

Once you enter the Security Settings, go to the Advanced Options, here you can configure Auto Application Launch, Auto Connect, Band Selection and other options for the Wireless Profile.

After the profile is created, you will be able to connect to it, Export it to a file so you can copy it to another system and Import the profile.

[SLyke]

Jonathan -

Thank you for your help.

I have worked through the steps provided in your previous post and while the driver now appears to properly negotiate EAP according to the NPS logs, the driver fails to DHCP an address or otherwise converse on the network.

The WAP logs show:

Mar 17 2015 09:43:32debughostapd[1907]station: d8:fc:93:1b:bf:b1 deauthenticated Mar 17 2015 09:43:32infohostapd[1907]STA d8:fc:93:1b:bf:b1 deauthed from BSSID xx:xx reason 3: STA is leaving IBSS or ESS Mar 17 2015 09:43:32infohostapd[1907]Assoc request from d8:fc:93:1b:bf:b1 BSSID xx:xx SSID network Mar 17 2015 09:43:31infohostapd[1907]STA d8:fc:93:1b:bf:b1 deauthenticated for reason 16: Group key handshake timeout Mar 17 2015 09:43:31infohostapd[1907]Station d8:fc:93:1b:bf:b1 had an authentication failure, reason 17<td class="section-cell tdLastcolumn" colspan="80" style="padding: 3px 5px 3px 8px; border-left-width: 1px; bo...

[jbenavides]

Hello slykens,

We are sorry to know that there were further issues after the actions recommended.

If you require additional assistance about this matter, we would advise you to create a case with Intel and/or Cisco support.

http://www.intel.com/p/en_US/support/contactsupport Contact Intel Customer Support

http://www.cisco.com/cisco/web/support/index.html# ~shp_contact Contact Cisco Support

[SLyke]

Jonathan -

I have to apologize as it appears that ultimately the problem might not have been with the Intel drivers.

After replacing the cards I saw the same behavior. I looked deeper into the situation and it appears that now with Windows 8.1 that Windows will not properly process EAP when the server presents a wildcard certificate, even if the FQDN of the server is listed as SAN on the certificate. This appears to be unique to Windows 8.1 in that we have Windows Vista/7/8, iOS, Android, and OS X clients that happily connect to this network with either certificate (of course the self signed certificate has to be accepted on non-domain devices).

No error message is presented anywhere (client or server) that would lead a person to this conclusion or even in this direction. The server throws error 6273 in the NPS logs (invalid credentials).

After changing the server certificate to a domain signed certificate in only the server's FQDN (with the Server Authentication purpose) the Windows 8.1 clients would connect properly. Non-domain devices on other OSes will have to manually accept the certificate.

Since I no longer have the Intel cards in my possession I cannot test with them, however, I'm posting this for others who might come across this issue without any kind of explanation - check your RADIUS certificate and make sure it is not a wildcard, even if the FQDN is in the SAN field.

Thank you.

[jbenavides]

Hello Slykens,

Thank you for sharing the details of your research.

We are glad to know that you found the culprit. This will be very useful for other users facing similar issues.