none
NPS 802.1X wireless PEAP audit failures in droves from failed iPhone authentication RRS feed

  • Question

  • I am seeing the following error when an iPhone/iPod Touch fails a login with a bad password.  I do not see this behavior when a Windows system fails a wireless logon; nor with any non-Apple systems (verified by checking the offending MAC addresses against oui.txt) .  With a Windows wireless client failed attempt, I see the failed authentication, but I do not see internal errors immediately following like I do with an iPhone/iPod Touch. (see below).  The same event is logged 6 times successively.

    The NPS server's system log does not contain any additional details, despite the suggestion from this event. I noted a similar forum article where the problem centered around a switch's firmware and dynamic VLANs, but the infrastructure is not configured to use dynamic VLANs.

    The only other time I have seen this error is when a lengthy RADIUS preshared key contained a typo at the very end.  I have already verified that the preshared key is correct. I asked my network administrator to migrate the wireless network to a unique wireless network definition (and a new SSID) along with a different (Cisco) wireless controller, yet the problem persists -- only with Apples, presumably only with iPhones/iPod Touch.  At the moment, one co-worker has a OS X laptop that never produces this error with a failed logon, yet his iPod Touch does.  Another co-worker's iPod touch reproduced the same error.  Lastly, another co-worker's iPhone reproduces the same error.  Yet when the password is correct, no such errors are generated -- (and that is quite accetable!)

    Here's the error:


    Network Policy Server discarded the request for a user.

    Contact the Network Policy Server administrator for more information.

    User:
     Security ID:   AD\testuser
     Account Name:   testuser
     Account Domain:   AD
     Fully Qualified Account Name: ad.domain/accounts/users/staff/testuser

    Client Machine:
     Security ID:   NULL SID
     Account Name:   -
     Fully Qualified Account Name: -
     OS-Version:   -
     Called Station Identifier:  00-17-DF-AB-E3-70:peapTEST
     Calling Station Identifier:  00-1D-4F-C1-2B-01

    NAS:
     NAS IPv4 Address:  172.17.255.1
     NAS IPv6 Address:  -
     NAS Identifier:   ITB-wism-8A
     NAS Port-Type:   Wireless - IEEE 802.11
     NAS Port:   29

    RADIUS Client:
     Client Friendly Name:  172.17.255.1
     Client IP Address:   172.17.255.1

    Authentication Details:
     Proxy Policy Name:  AD Wireless Connection Request Policy
     Network Policy Name:  AD Wireless Network Policy
     Authentication Provider:  Windows
     Authentication Server:  DEV-ITS-NPS-02.ad.domain
     Authentication Type:  EAP
     EAP Type:   -
     Account Session Identifier:  -
     Reason Code:   1
     Reason:    An internal error occurred. Check the system event log for additional information.

     

    Saturday, February 13, 2010 5:01 AM

Answers

  • I have a support case open with both Apple and Microsoft on this issue.

    The underlying cause is that Mac OS X and iOS does not increment the packet sequence ID when it attempts to retry.

    The problem manifests itself most on iPhones, iPods and iPads - where the likelihood of an initial authentication failure is much higher due to the interaction that the user has with the device

    If you enable RAS tracing, the following is logged:

    RASCHAP.LOG
    [3164] 06-17 18:23:14:040: CS_Retry...
    [3164] 06-17 18:23:14:040: Got ID 10 when expecting 11
    [3164] 06-17 18:23:14:040: Received packet is invalid. So silently discarding it

    RASTLS.LOG
    [3164] 06-17 18:23:14:040: PEAP inner method returned EAPACTION_NoAction. Discarding packet

    http://www.faqs.org/rfcs/rfc2759.html#ixzz0r8TDGISQ says:

    "9.1.4. Successful authentication after retry

    <- Authenticator Challenge
    Peer Response/Challenge ->
    <- Failure (E=691 R=1), disable short timeout
    Response (++ID) to challenge in failure message ->
    <- Success/Authenticator Response (Authenticator Response verification succeeds, call continues)"

    and

    "The packet sequence ID is incremented on each authentication retry response and on the change password response. All cases where the packet sequence ID is updated are noted below."

    The cause is therefore a bug in Apple's implementation.

    Nick

    • Proposed as answer by Nick Lowe Wednesday, June 23, 2010 9:55 AM
    • Marked as answer by Michael Kelsey Wednesday, June 23, 2010 9:18 PM
    Wednesday, June 23, 2010 9:30 AM

All replies

  • I think this is related to this http://support.microsoft.com/kb/974318. Please install the KB in IAS server and try again. thanks.

    Regards
    Qunshu


    Sorry. My posting is my personal suggestion, Microsoft won't take any responsibilities for my posting. But I am more than happy to try my best to help you.
    Monday, February 15, 2010 5:58 PM
  • That was worth a shot.  KB974318 is installed and all three NPS servers on which I see this error, and has been installed since it's release.

    Inspecting Wireshark captures reveal that the NPS server is sending an access-challenge request back to the NAS (and presumably back to the clients - iPhones and Apple Laptops).  I don't see any access-challenge replies with Windows systems that fail authentication.

    I will continue inspecting the Wireshark captures to see what might be different about the incoming Apple client authentication requests.

    Monday, February 15, 2010 8:01 PM
  • I have narrowed the problem to any Apple client with 10.5 - 10.6 or the iPhone/iPod OS.  I noted that the internal errors do not occur when I change the number of PEAP MSCHAPv2 retries to 0 on the NPS server.  After this change, Apple clients behave exactly like Windows clients.  This has the unfortunate side effect that a single bad logon causes a wireless authentication failure on the client; requiring the user to restart the wireless connection.  This provides a work around, but it is certainly not an ideal configuration.



    Friday, March 5, 2010 5:09 PM
  • I have a support case open with both Apple and Microsoft on this issue.

    The underlying cause is that Mac OS X and iOS does not increment the packet sequence ID when it attempts to retry.

    The problem manifests itself most on iPhones, iPods and iPads - where the likelihood of an initial authentication failure is much higher due to the interaction that the user has with the device

    If you enable RAS tracing, the following is logged:

    RASCHAP.LOG
    [3164] 06-17 18:23:14:040: CS_Retry...
    [3164] 06-17 18:23:14:040: Got ID 10 when expecting 11
    [3164] 06-17 18:23:14:040: Received packet is invalid. So silently discarding it

    RASTLS.LOG
    [3164] 06-17 18:23:14:040: PEAP inner method returned EAPACTION_NoAction. Discarding packet

    http://www.faqs.org/rfcs/rfc2759.html#ixzz0r8TDGISQ says:

    "9.1.4. Successful authentication after retry

    <- Authenticator Challenge
    Peer Response/Challenge ->
    <- Failure (E=691 R=1), disable short timeout
    Response (++ID) to challenge in failure message ->
    <- Success/Authenticator Response (Authenticator Response verification succeeds, call continues)"

    and

    "The packet sequence ID is incremented on each authentication retry response and on the change password response. All cases where the packet sequence ID is updated are noted below."

    The cause is therefore a bug in Apple's implementation.

    Nick

    • Proposed as answer by Nick Lowe Wednesday, June 23, 2010 9:55 AM
    • Marked as answer by Michael Kelsey Wednesday, June 23, 2010 9:18 PM
    Wednesday, June 23, 2010 9:30 AM
  • Like you, I had opened a case with Apple, and they admitted the problem was in their client implementation.  The reason was never fully described, so it's wonderful you were able to drive it down to the packet SequenceID.

    Wednesday, June 23, 2010 9:19 PM
  • We are experiencing the same issue.  In our environment, we are using Aruba 6000 wireless controllers with Bradford Campus Manager NAC and Windows Server 2003 IAS on the backend.  Thanks so much for posting this information, as it is the only source on the net I have found that talks about this issue.  Any word from Apple on when a fix will be coming?  Since it impacts so many different devices, I am guessing that it may take a while :(
    Thursday, September 16, 2010 9:50 PM
  •  

    The last that I heard back from Apple was on September 8th and as follows:

    "Hello Nick,

    This is a follow up to Bug ID# 8112557.  After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering.  This issue has been filed in our bug database under the original Bug ID# 4544606. The original bug number being used to track this duplicate issue can be found in the State column, in this format:  Duplicate/OrigBug#.

    Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs.

    Best Regards,

    Developer Support

    Apple Worldwide Developer Relations"


    While Microsoft Support were incredibly responsive and helpful, Apple really were a world apart.

    While being almost impossible to interact with, they ultimately took the bug report have have swallowed it.

    They have given no advice what-so-ever as to when they plan to fix this bug, if at all. And I have asked and chased - repeatedly - and have now given up and moved on. Considering the difference between the two Bug IDs, I don't have much faith that it will be. I would love to be proven wrong.

    What I take from this experience is that they only target the enterprise as an begrudged afterthought. Prima facie, they just do not give it the attention or priority that I think it deserves.

     

    Please accept my apologies for the late reply - I have only just seen your message!

     

    Monday, October 4, 2010 6:47 PM
  •  

    The last that I heard back from Apple was on September 8th and as follows:

    "Hello Nick,

    This is a follow up to Bug ID# 8112557.  After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering.  This issue has been filed in our bug database under the original Bug ID# 4544606. The original bug number being used to track this duplicate issue can be found in the State column, in this format:  Duplicate/OrigBug#.

    Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs.

    Best Regards,

    Developer Support

    Apple Worldwide Developer Relations"


    While Microsoft Support were incredibly responsive and helpful, Apple really were a world apart.

    While being almost impossible to interact with, they ultimately took the bug report have have swallowed it.

    They have given no advice what-so-ever as to when they plan to fix this bug, if at all. And I have asked and chased - repeatedly - and have now given up and moved on. Considering the difference between the two Bug IDs, I don't have much faith that it will be. I would love to be proven wrong.

    What I take from this experience is that they only target the enterprise as an begrudged afterthought. Prima facie, they just do not give it the attention or priority that I think it deserves.

     

    Please accept my apologies for the late reply - I have only just seen your message!

     

    Hi Nick,

    First thanks for your work on this problem.

    Our environment is a bit different - we have freeradius server which authenticates against Novel NDSLDAP - we use peap and Ms-Chapv2.  We observe that with the wrong password the mac clients do not see dialogue message - the log on the mac shows "EAP Failure".

    The freeradius server appears to always send back (E-691 R=1).  I don't know what it does with the invalid id sent back on re-try with from the client.

    We may try rebuilding the freeradius server to send back (E-691 R=0) to see if this changes the behavior like it did in your setting.

    We have Marue(sp) and Bradford also involved in the process.

    There was a different bug with the suplicant which was introduced in 10.5.8 and resolved in 10.6.3 which prevented many users from being able to authenticate at all in wpa.

    I see that in Sept 8th apple still had the bug.  Have you observed the bug in 10.6.3 or later?  How does one see what progress apple has made?

    johnh...

    Thursday, March 3, 2011 6:12 PM