locked
802.1x on XP SP3 failed with "Identity: NULL" RRS feed

  • Question

  • Hi Everybody!

    Server: Windows 2008 sp2 with AD, DNS, DHCP, NPS roles installed.

    Client: Windows XP SP3 + KB957931 + KB960655.

    802.1x configured via Group Policy. Computer only auth, using PEAP (Smart card or other certificate). Certificates issued for all domain computers via local MS Certificate Services (Windows 2003 server).

    Problem description

    Sometimes Windows XP SP3 computer failed to complete 802.1x auth at boot. Event ID 15514 from Dot3Svc. Identity: NULL, Reason: 327685, ErrorCode -2147024846 (0x80070032 - ERROR_NOT_SUPPORTED), Text: The request is not supported.

    Second auth session had always completed successfully.

    I have noticed that ip address had changed after such a failed auth.

    So, my question is: why does it happen and how to prevent this?

     

    Friday, July 30, 2010 8:41 AM

Answers

All replies

  • Hi,

    Thanks for the post.

    This issue will occur if the computer network and components are not ready. Generally the switch detects the port status and send identity request. In this time, the computer network is not fully ready in fact. Therefore, it’s a normal scenario that the computer failed to response identity request.

    In this case, we could try to reboot the computer without network connection. Keep running a while. Then, plug in the network cable to trigger the computer authentication. Checking the network traffic it should answer the identity quickly.

    Hope this helps.

    Miles

     


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, August 2, 2010 6:42 AM
  • This issue will occur if the computer network and components are not ready. Generally the switch detects the port status and send identity request. In this time, the computer network is not fully ready in fact. Therefore, it’s a normal scenario that the computer failed to response identity request.

    In this case, we could try to reboot the computer without network connection. Keep running a while. Then, plug in the network cable to trigger the computer authentication. Checking the network traffic it should answer the identity quickly.

    Unfortunately, it's happens too often. Users shouldn't plug in/out network cables every morning.

    At NPS event logs i've found many events like this:

     

    EventID 6273 
    Provider Microsoft-Windows-Security-Auditing
    SubjectUserSid <SIDHERE> SubjectUserName host/hostname.domainname.loc SubjectDomainName DOMAINNAME FullyQualifiedSubjectUserName DOMAINNAME\HOSTNAME$ SubjectMachineSID S-1-0-0 SubjectMachineName - FullyQualifiedSubjectMachineName - MachineInventory - CalledStationID <MAC1-HERE> CallingStationID <MAC2-HERE> NASIPv4Address <IP1-HERE> NASIPv6Address - NASIdentifier - NASPortType Ethernet NASPort 50011 ClientName clientname ClientIPAddress <IP1-HERE> ProxyPolicyName Protected wired (Ethernet) NetworkPolicyName - AuthenticationProvider Windows AuthenticationServer dc1.domainname.loc AuthenticationType PEAP EAPType - AccountSessionIdentifier - ReasonCode 300 Reason No credentials are available in the security package

     

    In svchost_RASTLS.LOG:

     

    Did not find the NAK'ed Auth type in our list. Fail Auth
    At the same time on client:

     

     

     Provider Microsoft-Windows-Wired-AutoConfig 
     EventID 15505 
     InterfaceGuid {393D8E15-99E8-4975-BFE3-A940E4B8C177} 
     InterfaceDescription Realtek PCIe GBE Family Controller 
     SwitchMAC <MAC1-HERE>
     LocalMAC <MAC2-HERE>
     ConnectionID 0x2 
     Identity - 
     User - 
     Domain - 
     ReasonCode 0x70003 
     ReasonText The network does not support authentication 
     ErrorCode 0x0 
     ExplicitCredentials false 
    
    And sometimes:
     Provider Microsoft-Windows-Wired-AutoConfig 
     EventID 15514 
     InterfaceGuid {9C0C4964-80E7-4C0C-AE87-14AC580E19FB} 
     InterfaceDescription Broadcom NetLink (TM) Gigabit Ethernet - Virtual Machine Network Services Driver 
     SwitchMAC <MAC1-HERE>
     LocalMAC <MAC2-HERE>
     ConnectionID 0x1 
     Identity host/hostname.domainname.loc
     User - 
     Domain - 
     ReasonCode 0x50005 
     ReasonText Explicit Eap failure received 
     ErrorCode 0x0 
     ExplicitCredentials false 
    

     

    Any ideas?

     

     

    Monday, September 13, 2010 10:20 AM
  • Hi Mike

    Some questions:

    does this happen to all machines on the network or only some of them?

    for those machines where the problem happens, does it happen always or only sometimes?

    Some other thought: set the BlockTime value in the clients registry (after installation of KB957931) to a short value (1 min for example). Your clients will retry authentication 1 min after the 15514 event and you don't need to plug in/out network cable. This is not a solution, it's a workaround.

    Take a look at http://blogs.technet.com/b/networking/archive/2009/12/16/possible-problems-seen-after-upgrading-windows-xp-clients-to-sp3-in-an-environment-that-uses-wired-802-1x.aspx and maybe try KB969111 also.

    Hope it helps,

    Lucy

    Monday, September 13, 2010 8:17 PM
  • Hi Mike,

    The is copied from your post:

    "ReasonCode 300
    Reason No credentials are available in the security package

    In svchost_RASTLS.LOG:

    Did not find the NAK'ed Auth type in our list. Fail Auth

    "

    normally this is because of two reasons:

    1. it is the certificate issue. you should check the certificate in your machine.

    2. check if your client are also sending the PEAP-TLS packet since the server is configured to accept the PEAP-TLS.

    Regards

    Qunshu


    Clarification: Microsoft doesn't own any liability & responsibility for any of my posting.
    Thursday, May 5, 2011 10:47 PM
  • Hi Qunshu, thank you for answer!
    normally this is because of two reasons:

    As I see, the network initialization part of a boot process proceeds as follows:

    1. network adapter initialization, link up
    2. switch detected link up and started the dot1x auth process by sending "Request identity" packet
    3. computer (dot1x supplicant) respond to that request using default dot1x profile (which differs from my own) or just by sending EAPOL-Start packet (with no EAP Data encapsulated). 
    4. Group policy dot1x profile has been applied to network interface, so dot1x process was restarted.
    5. At this moment all network services of supplicant has been already started.
    6. Dot1x process completed sucessfully.

    Sometimes system loading process was too slow, so the 1-st auth process failed.

    In case of fast system startup 1-st dot1x auth process was interrupted by starting new, domain dot1x profile dot1x process, which proceed succesfully.

    So, I have two possible reasons:

    1. dot1x process using wrong (dafault) profile
    2. supplicant send EAPOL-Start packet in responce to "Request identity"packet with no data encapsulated which leads to "Identity: NULL".

    For now, I configured windows supplicant and authenticator (cisco 2960 switch) to retry auth process 2 times. Seems, problem was solved. But for me it's not a "clear" solution.

     

    • Proposed as answer by shaughnessy Monday, June 6, 2011 2:09 PM
    • Unproposed as answer by shaughnessy Monday, June 6, 2011 2:09 PM
    Friday, May 6, 2011 10:31 AM
  • hi

    I implemented 802.1x with server: AD 2008, CA 2003 , IAS 2003 and Cisco switch 3750. sometimes in windows XPsp3 and 7  i received authentication failed.(error id 15514)

    It happen only  some PCs and sometimes  with no  in regular interval

    how can I prevent this? should i change switch config or supplicant config?

     

     


    Friday, July 15, 2011 9:11 AM
  • Hello Mike,

    I have exactly the same problem. In my case this occurs with W7 and specific model of PC (but not always).

    For now, i solved with "dot1x timeout quiet-period" command in my Cisco 2960, but I think that this is not a clear solution.

    Is there any way to wait for the complete Windows network and certificate startup process before switch dot1x request? Any ideas?

    Thanks.

    Wednesday, August 24, 2011 11:25 AM
  • In W7, I solved with KB2481614 http://support.microsoft.com/kb/2481614/en-us
    • Marked as answer by Mike Shishkin Thursday, September 29, 2011 7:21 AM
    Wednesday, September 28, 2011 3:20 PM
  • In W7, I solved with KB2481614 http://support.microsoft.com/kb/2481614/en-us

    Thank you very much!

    About a year ago I have a ticket at microsoft support on this problem. But it was closed with the message: "It's by design". Now it's fixed. hehe.

    Thursday, September 29, 2011 7:30 AM
  • Hi Mike,

    I am a little  unclear  did you get a Hotfix  for  this  under  XP or  did you just  upgrade  to  Windows7 and apply  that  Hotfix.

    We  are  currently  experinceing the  issue  and  we have  a fleet  of  2000 XP  machines  that will  be migrated to Wiin7,  but are  currently  considering  rolling back  802.1 x  authentication  over  this  issue.

    your assistance is  appreciated

    Monday, May 27, 2013 9:27 PM
  • Yes, we have mostly upgraded to Windows 7 (~90%). Windows XP SP3 sometimes still have this issue.
    Tuesday, May 28, 2013 5:03 AM