Authentication Problem on a 802.1x Wireless Network

1. Introduction

 

The years working on Platforms and Networking were essential for me to build the foundation prior to migrate to the Security area. Regardless of the technology that I worked, most of the time I was dealing with situations where the customer wants to be secure while allowing access to the core network resources.

 

The scenario that I’m going to describe on this post was related to a really trick situation where only six users were having authentication problem on the 802.1x Wireless Network. Here the topology that was used on that case:

 

Figure 1 – Wireless Network.

 

As you can see, we have an unsupported operating system (Windows NT) on the environment which shows how heterogeneous the scenario was. On the infrastructure side, customer was using a Cisco and the servers were using Cisco Secure ACS for Windows. Those six users belong to the Windows Server 2003 Domain and all of them were located on the same OU. On that same OU we also had users that were not having problem at all.

 

To enhance the security on the network customer was using the 802.1x technology for wireless network. This technology comes originally from the 802.1x for wired network. The IEEE 802.1x is used to guarantee authentication on the link level (layer 2). This way the switch port where the computer is connected will stay in blocking state until the authentication is successfully completed.

 

For more information on 802.1x network review the article Understanding 802.1X authentication for wireless networks.

 

2. Collecting Data

Since we just have six users that were having problem, the first step was to use the LDIFDE command to dump the user’s properties. The idea behind this is to dump the properties of a user that works and the one that doesn’t work. Then compare the attributes and values. To do that the following command was used:

 

ldifde -f C:\User.ldf -d "DN" -p base

 

The DN (Distinguished Name) is the location of the user on the Active Directory. To find out this attribute you can use the ADSIEdit Tool.

 

After compare both accounts I couldn’t find any problem on the attributes and values that could lead to an authentication issue. The next step was to start a netmon capture and see what was going in the wire. The following steps were done:

 

· Installed Netmon on the Windows XP (Client), on the Windows Server 2003 DC and on the Windows 2000 Member Server.

· Enabled the RRAS Logging using the command netsh ras set tracing * enable. The logs will be added to the %systemroot%\tracing folder.

· Configured the switch that was connected to the access point to do a port mirror for one workstation.

· The CTEST\Bob user performed the logon on the Windows XP workstation.

 

Note: The same steps were done for a user that could successfully authenticate.

 

3. Analyzing

Here the traffic for a user that could successfully logon:

1. CiscoAP WindowsXPMAC EAP Request, Identity

2.  WindowsXPMAC CiscoAP EAP Response, Identity

3.  CiscoAP WindowsXPMAC EAP Request, PEAP

4.  WindowsXPMAC CiscoAP TLS Client Hello

5.  CiscoAP WindowsXPMAC TLS Server Hello

6.  WindowsXPMAC CiscoAP TLS Change Cipher Spec

7.  CiscoAP WindowsXPMAC EAP Success

8.  CiscoAP WindowsXPMAC TLS Application Data

 

Opening the EAP header (frame 2) it is possible to verify that the user sends the credential:

802.1X Authentication

    Version: 1

    Type: EAP Packet (0)

    Length: 22

    Extensible Authentication Protocol

        Code: Response (2)

        Id: 1

        Length: 22

        Type: Identity [RFC3748] (1)

        Identity (17 bytes): CTEST\Will

 

On the EAP header (frame 7) we have the successfully negotiation message:

802.1X Authentication

    Version: 1

    Type: EAP Packet (0)

    Length: 4

    Extensible Authentication Protocol

        Code: Success (3)

        Id: 233

        Length: 4

 

Now, let’s see the traffic for a user that was not working:

1.  CiscoAP WindowsXPMAC EAP Request, Identity

2.  WindowsXPMAC CiscoAP EAP Response, Identity

3.  CiscoAP WindowsXPMAC EAP Request, PEAP

4.  WindowsXPMAC CiscoAP TLS Client Hello

5.  CiscoAP WindowsXPMAC TLS Server Hello

6.  WindowsXPMAC CiscoAP TLS Change Cipher Spec

7.  CiscoAP WindowsXPMAC EAP Request, Identity

8.  WindowsXPMAC CiscoAP EAP Response, Identity

9.  CiscoAP WindowsXPMAC EAP Request, PEAP

10. WindowsXPMAC CiscoAP TLS Client Hello

11. CiscoAP WindowsXPMAC TLS Server Hello

Clearly we can see that on this process we have multiple logon attempts without success. The interesting part of that was the customer’s revelation when he told me: if I don’t cancel this process the user account gets block on AD due the multiple bad logon attempts.

That was key information, this pretty much means that our package was going all the way up to the DC and trying to authenticate. However, for some reason that we didn’t know yet, it was failing.

 

4. Going further

Without a doubt netmon trace is something that helps a lot to understand the traffic. But, on this case we need something else to help us understand why was failing. Since we enabled the debug logs on the Windows XP we had the data that we need to figure that out. Looking to the files Wzctrace.log, Eapol.log, Netman.log and RASTLS.LOG located on the folder %systemroot%\tracing it was possible to determine that.

 

Let’s see the difference for a user that could logon for the one that could not logon in the file RASTLS.LOG:

 

- Successful logon:

[1244] 17:04:57:801: EapTlsBegin(CTEST\Will)

[1244] 17:04:57:801: State change to Initial

[1244] 17:04:57:801: EapTlsBegin: Detected 8021X authentication

[1244] 17:04:57:801: EapTlsBegin: Detected PEAP authentication

[1244] 17:04:57:801: MaxTLSMessageLength is now 16384

[1244] 17:04:57:801: EapPeapBegin done

[1244] 17:04:57:801: EapPeapMakeMessage

[1244] 17:04:57:801: EapPeapCMakeMessage

[1244] 17:04:57:801: PEAP:PEAP_STATE_INITIAL

[1244] 17:04:57:801: EapTlsCMakeMessage

[1244] 17:04:57:801: EapTlsReset

[1244] 17:04:57:801: State change to Initial

[1244] 17:04:57:801: GetCredentials

[1244] 17:04:57:801: Flag is Client and Store is Current User

[1244] 17:04:57:801: GetCachedCredentials

[1244] 17:04:57:801: PEAP GetCachedCredentials: Using cached credentials.

[1244] 17:04:57:801: MakeReplyMessage

[1244] 17:04:57:801: SecurityContextFunction

[1244] 17:04:57:801: InitializeSecurityContext returned 0x90312

[1244] 17:04:57:801: State change to SentHello

 

- Unsuccessful logon:

[2688] 16:58:02:568: EapTlsBegin(CTEST\Bob)

[2688] 16:58:02:568: State change to Initial

[2688] 16:58:02:568: EapTlsBegin: Detected 8021X authentication

[2688] 16:58:02:568: EapTlsBegin: Detected PEAP authentication

[2688] 16:58:02:568: MaxTLSMessageLength is now 16384

[2688] 16:58:02:568: EapPeapBegin done

[2688] 16:58:02:568: EapPeapMakeMessage

[2688] 16:58:02:568: EapPeapCMakeMessage

[2688] 16:58:02:568: PEAP:PEAP_STATE_INITIAL

[2688] 16:58:02:568: EapTlsCMakeMessage

[2688] 16:58:02:568: EapTlsReset

[2688] 16:58:02:568: State change to Initial

[2688] 16:58:02:568: GetCredentials

[2688] 16:58:02:568: Flag is Client and Store is Current User

[2688] 16:58:02:568: GetCachedCredentials

[2688] 16:58:02:568: FreeCachedCredentials

[2688] 16:58:02:568: No Cert Store. Guest Access requested

[2688] 16:58:02:568: No Cert Name. Guest access requested

[2688] 16:58:02:568: Will NOT validate server cert

[2688] 16:58:02:568: MakeReplyMessage

[2688] 16:58:02:568: SecurityContextFunction

[2688] 16:58:02:568: InitializeSecurityContext returned 0x90312

[2688] 16:58:02:568: State change to SentHello

[2688] 16:58:02:568: BuildPacket

 

Notice that the user is authenticating as Guest since there was no certificate available.

 

5. Conclusion

Since customer was not using user certificate to gain access to the system and using computer certificate only we could change the original behavior via registry change. What we did was to force each laptop that those users were using to use computer authentication only. The following registry key was changed:

 

HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global

Tipo: REGDWORD

Nome: AuthMode

Valor "2"

The number 2 means: Computer authentication is performed when the wireless client computer is started. User authentication is never performed. For more information on that registry key review the article Wireless LAN Support in Windows: Frequently Asked Questions.

 

On those laptops this key was configured to 1, therefore the user authentication was happening and the user’s certificate on those laptops was corrupted.