Ondrej Žilinec – IT Blog

I have deployed WPA2-Enterprise authentication on network. Computer should use computer certificate to authenticate to Wireless network. I deployed NPS server, configured all requirements. Windows 10 didn’t have problem to connect to Wifi network. Windows 7 computers have problem.

Problem

In eventviewer (Applications and Services Logs\Microsoft\Windows\WLAN-AutoConfig) I found following error:

Network Adapter: Intel(R) Centrino(R) Advanced-N 6205
Interface GUID: {c2c428cb-76cc-4474-a043-33ce2bfe9f0d}
Local MAC Address: 60:67:20:a6:42:63
Network SSID: SECURE_WIFI
BSS Type: Infrastructure
Peer MAC Address: 34:1F:a2:AF:C8:1E
Identity: DOMAN\USER1
User: USER1
Domain: DOMAIN
Reason: Explicit Eap failure received
Error: 0x80074005
EAP Reason: 0x4005
EAP Root cause String:
EAP Error: 0x4005

Solution

Problem is very weird. When you install NPS server, NPS server will use certificate to proof of identity. By default it uses certificate created from Windows CA Template called Kerberos Authentication. This certificate has empty attribute called Subject.

Windows 7 has problem that it doesn’t accept certificate with empty Subject attribute. Other OS’s worked fine. Solution to make it work is to populate this attribute into certificate. You can do it following way:

• Go to Certificate Template console (use MMC, add snap in –> Certificate Templates) and change template called Kerberos Authentication.
• Open properties of this template
• Go to Subject Name tab
• Change Subject name format to DNS name

Now go to NPS server. Open the Certificates MMC (Computer), go to Personal / Certificates and right click in the details pane – All Tasks / request New Certificate. Request new certificate from template Kerberos Authentication for computer account:

After new certificate is installed under computer certification store, you can find attribute Subject populated with DNS name of NPS server:

When certificate is OK, you can change certificate which should be used to proof identity.

Let’s make new certificate work on NPS server. Open NPS console. Go to Network Policies and open up your policy which handles 802.1x requests. Go to the Constraint tab, Authentication Methods / PEAP and click on Edit.

The certificate expiry date now shown should tie in to the one you just created:

Now also Windows 7 will connect to wireless network with no problem and not error event 🙂

That’s all fokls,

Imagine you have DHCP server on network. You have all Windows XP and older clients. When DHCP server was not accessible on network during client’s startup, client computer couldn’t get IP address and it assigned APIPA address. This was a problem. So let’s look what’s new since Windows 7.

I prepared following scenario:

• One DHCP server Windows Server 2012 – 192.168.0.10
• One DHCP server Windows Server 2012 acting as default gateway – 192.168.0.11
• One Windows 8 client – DHCP assigned
• One Windows 7 client – DHCP assigned

When I client wants to get TCP/IP settings from DHCP server, there are four DHCP packets (DISCOVER, OFFER, REQUEST and ACK) going on network. Network dump on DHCP server:

This is normal behaviour even in old clients. Now I shutdown client and stop DHCP server. When I started client computer I found out that client computer has IP address it received from DHCP server before reboot.

So let’s restart client again and see what happends. Client computer has same TCP/IP settings, it had before reboot (TCP/IP settings received from DHCP server before I stopped DHCP server). Client computer keeps asking DHCP server to renew TCP/IP settings (using DHCP REQUEST):

So how client computer knows if it has to set cached TCP/IP settings before DHCP server stopped to respond? I assume it depends on gateway and its IP or MAC address. So let’s disconnect gateway from network and reboot client computer. Now client has APIPA TCP/IP settings and it looks for DHCP server by DHCP DISCOVERY:

It means it depends on health of gateway if client keeps TCP/IP settings assigned by DHCP or not. I haven’t seen any ICMP packet to check network healt of gateway so I assume it check MAC address. So let’s look for ARP packets from client to gateway. Looks like client asks for MAC address of saved default gateway IP address. When it received answer, it sets TCP/IP settings to cached TCP/IP settings:

Question is if client computer compares MAC address to some saved one or it just waits for ARP response and doesn’t care of MAC address. Let’s change MAC address of default gateway. Client keeps asking via ARP for MAC address. MAC address is different and client doesn’t set its saved TCP/IP settings (it sets APIPA settings):

So where client computer saves MAC address of default gateway?

Yes, in registry. 🙂 It’s saved under registry key:

and there are subkeys for each interface and under this key there is binary value called DhcpGatewayHardware which contains MAC address:

When client starts it checks for MAC address of its saved default gateway IP address. Then it compares to saved MAC address from registry. If these two MAC addresses don’t match, client deletes all saved TCP/IP settings from registries and uses APIPA (if there is not Alternate Configuration). In background it still looks for DHCP server by sending DHCP DISCOVER packets.

So now we have smaller problem on Mondays when DHCP server is down (of course by accident 🙂 ) and everyone is trying to get to network resources 🙂

I haven’t find any article about this new behaviour on oficial Microsoft websites.

That’s all folks,