none
NPS IAS/RADIUS problem with Wireless Authentication RRS feed

  • Question

  • I had my 2008 R2 Server working well after configuring it for wireless authentication.  But it has suddenly stopped working.  From the logs, I can see the connection failing with Reason Code 22, which seems to indicate "The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server. "  I can see that there is no "EAP-Friendly-Name" in the failed connection log, but I do not understand why that is.

    Here are two events from a failed connection attempt:
    <Event>
    <Timestamp data_type="4">02/11/2010 08:32:27.591</Timestamp>
    <Computer-Name data_type="1">{My NPS Server}</Computer-Name>
    <Event-Source data_type="1">IAS</Event-Source>
    <User-Name data_type="1">host/HSLAPLABA-05.my.domain</User-Name>
    <NAS-IP-Address data_type="3">{IP Address of my RADIUS Client}</NAS-IP-Address>
    <Called-Station-Id data_type="1">00-20-a6-7f-90-4e:MYDOMAIN</Called-Station-Id>
    <Calling-Station-Id data_type="1">00-26-5e-63-99-d4;MYDOMAIN</Calling-Station-Id>
    <NAS-Identifier data_type="1">Wireless01</NAS-Identifier>
    <Framed-MTU data_type="0">1400</Framed-MTU>
    <NAS-Port data_type="0">9</NAS-Port>
    <NAS-Port-Type data_type="0">19</NAS-Port-Type>
    <Client-IP-Address data_type="3">{IP Address of my RADIUS Client}</Client-IP-Address>
    <Client-Vendor data_type="0">0</Client-Vendor>
    <Client-Friendly-Name data_type="1">Wireless01</Client-Friendly-Name>
    <Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name>
    <Provider-Type data_type="0">1</Provider-Type>
    <SAM-Account-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</SAM-Account-Name>
    <Fully-Qualifed-User-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</Fully-Qualifed-User-Name>
    <Class data_type="1">311 1 {IP Address of IAS Server} 02/03/2010 15:01:36 2</Class>
    <Authentication-Type data_type="0">5</Authentication-Type>
    <NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name>
    <EAP-Friendly-Name data_type="1"></EAP-Friendly-Name>
    <Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant>
    <Packet-Type data_type="0">1</Packet-Type>
    <Reason-Code data_type="0">0</Reason-Code>
    </Event>

    <Event><Timestamp data_type="4">02/11/2010 08:32:27.591</Timestamp>
    <Computer-Name data_type="1">{My NPS Server}</Computer-Name>
    <Event-Source data_type="1">IAS</Event-Source>
    <Class data_type="1">311 1 {IP Address of my IAS Server} 02/03/2010 15:01:36 2</Class>
    <EAP-Friendly-Name data_type="1"></EAP-Friendly-Name>
    <Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant>
    <Client-IP-Address data_type="3">{IP Address of my RADIUS Client}</Client-IP-Address>
    <Client-Vendor data_type="0">0</Client-Vendor>
    <Client-Friendly-Name data_type="1">Wireless01</Client-Friendly-Name>
    <Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name>
    <Provider-Type data_type="0">1</Provider-Type>
    <SAM-Account-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</SAM-Account-Name>
    <Fully-Qualifed-User-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</Fully-Qualifed-User-Name>
    <NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name>
    <Authentication-Type data_type="0">5</Authentication-Type>
    <Packet-Type data_type="0">3</Packet-Type>
    <Reason-Code data_type="0">22</Reason-Code>
    </Event>

    And here are two events from a working connection attempt.
    <Event>
    <Timestamp data_type="4">01/06/2010 11:27:59.996</Timestamp>
    <Computer-Name data_type="1">{My NPS Server}</Computer-Name>
    <Event-Source data_type="1">IAS</Event-Source>
    <NAS-IP-Address data_type="3">{IP Address of my RADIUS Client}</NAS-IP-Address>
    <Called-Station-Id data_type="1">00-20-a6-bd-56-ff:MYDOMAIN</Called-Station-Id>
    <Calling-Station-Id data_type="1">00-26-5e-63-99-d4</Calling-Station-Id>
    <NAS-Identifier data_type="1">LHSMobileAP01</NAS-Identifier>
    <Framed-MTU data_type="0">1400</Framed-MTU>
    <NAS-Port data_type="0">2</NAS-Port>
    <NAS-Port-Type data_type="0">19</NAS-Port-Type>
    <Client-IP-Address data_type="3">{IP Address of my RADIUS Client}</Client-IP-Address>
    <Client-Vendor data_type="0">0</Client-Vendor>
    <Client-Friendly-Name data_type="1">LHSMobileAP01</Client-Friendly-Name>
    <User-Name data_type="1">host/HSLAPLABA-05.my.domain</User-Name>
    <Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name>
    <Provider-Type data_type="0">1</Provider-Type>
    <SAM-Account-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</SAM-Account-Name>
    <Fully-Qualifed-User-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</Fully-Qualifed-User-Name>
    <NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name>
    <Class data_type="1">311 1 {IP Address of my IAS Server} 12/30/2009 17:05:35 1326</Class>
    <Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant>
    <EAP-Friendly-Name data_type="1">Microsoft: Secured password (EAP-MSCHAP v2)</EAP-Friendly-Name>
    <Authentication-Type data_type="0">11</Authentication-Type>
    <MS-Extended-Quarantine-State data_type="0">0</MS-Extended-Quarantine-State>
    <MS-Quarantine-State data_type="0">0</MS-Quarantine-State>
    <Packet-Type data_type="0">1</Packet-Type>
    <Reason-Code data_type="0">0</Reason-Code>
    </Event>

    <Event>
    <Timestamp data_type="4">01/06/2010 11:27:59.996</Timestamp>
    <Computer-Name data_type="1">VM-UTILITY02</Computer-Name>
    <Event-Source data_type="1">IAS</Event-Source>
    <Class data_type="1">311 1 {IP Address of my IAS Server} 12/30/2009 17:05:35 1326</Class>
    <EAP-Friendly-Name data_type="1">Microsoft: Secured password (EAP-MSCHAP v2)</EAP-Friendly-Name>
    <Authentication-Type data_type="0">11</Authentication-Type>
    <PEAP-Fast-Roamed-Session data_type="0">0</PEAP-Fast-Roamed-Session>
    <Client-IP-Address data_type="3">{IP Address of my RADIUS Client}</Client-IP-Address>
    <Client-Vendor data_type="0">0</Client-Vendor>
    <Client-Friendly-Name data_type="1">LHSMobileAP01</Client-Friendly-Name>
    <MS-CHAP-Domain data_type="2">014C5053</MS-CHAP-Domain>
    <Proxy-Policy-Name data_type="1">Secure Wireless Connections</Proxy-Policy-Name>
    <Provider-Type data_type="0">1</Provider-Type>
    <SAM-Account-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</SAM-Account-Name>
    <Fully-Qualifed-User-Name data_type="1">MYDOMAIN\HSLAPLABA-05$</Fully-Qualifed-User-Name>
    <NP-Policy-Name data_type="1">Secure Wireless Connections</NP-Policy-Name>
    <Quarantine-Update-Non-Compliant data_type="0">1</Quarantine-Update-Non-Compliant>
    <Framed-Protocol data_type="0">1</Framed-Protocol>
    <Service-Type data_type="0">2</Service-Type>
    <MS-Link-Utilization-Threshold data_type="0">50</MS-Link-Utilization-Threshold>
    <MS-Link-Drop-Time-Limit data_type="0">120</MS-Link-Drop-Time-Limit>
    <MS-MPPE-Encryption-Policy data_type="0">2</MS-MPPE-Encryption-Policy>
    <MS-MPPE-Encryption-Types data_type="0">4</MS-MPPE-Encryption-Types>
    <MS-Quarantine-State data_type="0">0</MS-Quarantine-State>
    <MS-Extended-Quarantine-State data_type="0">0</MS-Extended-Quarantine-State>
    <Packet-Type data_type="0">2</Packet-Type>
    <Reason-Code data_type="0">0</Reason-Code>
    </Event>

    Any idea why the Server can no longer negotiate an EAP type or the EAP Friendly Name isn't coming through?

    • Edited by MMB-LPS Friday, February 12, 2010 1:16 PM
    Thursday, February 11, 2010 4:35 PM

Answers

  • I just noticed from the data you posted initially, a successful auth yields:

    <Authentication-Type data_type="0">5</Authentication-Type>

    while a non-successful auth yields:

    <Authentication-Type data_type="0">11</Authentication-Type>

    5 is EAP
    11 is PEAP

    This further supports my theory that you originally configured your policies to handle EAP-MSCHAPv2 and now your client is trying to use PEAP-MSCHAPv2 which you haven't configured support for.

    PEAP-MSCHAPv2 is EAP-MSCHAPv2 inside of a protected SSL tunnel and requires a slightly different configuration. You will need a PKI infrastructure to provide the certificates necessary for PEAP if you wish to use it.

    You can configure your NPS policies to use PEAP-MSCHAPv2 by adding the EAP type "Microsoft: Protected EAP (PEAP)" to your policy constraints and edit the Protected EAP Properties to include "Secured password (EAP-MSCHAP v2)".
    This TechNet forum post is provided "AS IS" with no warranties, and confers no rights. This entry reflects my own personal views and does not necessarily reflect the view of my employer.
    Friday, February 12, 2010 11:54 PM

All replies

  • I would double check your policy configuration on the NPS server. Has anything changed recently? Double-check which EAP methods you have configured in your NP policies. Another thing to check would be your client settings. Have they switched from using EAP-MSCHAPv2 to using an EAP method not configured under your NPS policies? Has a group policy been applied to the client changing its EAP auth method used for wireless auth?
    This TechNet forum post is provided "AS IS" with no warranties, and confers no rights. This entry reflects my own personal views and does not necessarily reflect the view of my employer.
    Friday, February 12, 2010 1:00 AM
  • I've been over the policy configuration in the NPS server and I can't find any faults there.  In fact, I provisioned a new VM to act soley as a NAP server and built the configuration using the failing NPS server as a base, and it authenticates fine..

    Client config is done by group policy, nothing has changed there.  If I point my APs to the new RADIUS server, everything connects, so I don't think it's on the client side.

    Next I'm going to try deleting and recreating the policy configuration from scratch on the failing NPS server to see if that changes things at all.
    Friday, February 12, 2010 1:14 PM
  • I deleted the Connection Request Policy and the Network Policy and re-created them.  Still Reason Code 22 and no EAP-Friendly-Name.  I'm completely stumped.
    Friday, February 12, 2010 6:55 PM
  • I just exported the NPS setting from NAP on my working server and imported them to the server that isn't working, but no change.
    Friday, February 12, 2010 7:08 PM
  • There hasn't been a swtich between the client using EAP-MSCHAPv2 and PEAP-MSCHAPv2 has there?

    You can also try enabling NPS tracing by running 'netsh ras set tr * en' and checking the log files under %SystemRoot%\tracing\*.log (fyi, notepad will try to open the log files as UNICODE encoded when they are in fact UTF8 encoded so manually select the encoding).


    This TechNet forum post is provided "AS IS" with no warranties, and confers no rights. This entry reflects my own personal views and does not necessarily reflect the view of my employer.
    Friday, February 12, 2010 11:28 PM
  • I just noticed from the data you posted initially, a successful auth yields:

    <Authentication-Type data_type="0">5</Authentication-Type>

    while a non-successful auth yields:

    <Authentication-Type data_type="0">11</Authentication-Type>

    5 is EAP
    11 is PEAP

    This further supports my theory that you originally configured your policies to handle EAP-MSCHAPv2 and now your client is trying to use PEAP-MSCHAPv2 which you haven't configured support for.

    PEAP-MSCHAPv2 is EAP-MSCHAPv2 inside of a protected SSL tunnel and requires a slightly different configuration. You will need a PKI infrastructure to provide the certificates necessary for PEAP if you wish to use it.

    You can configure your NPS policies to use PEAP-MSCHAPv2 by adding the EAP type "Microsoft: Protected EAP (PEAP)" to your policy constraints and edit the Protected EAP Properties to include "Secured password (EAP-MSCHAP v2)".
    This TechNet forum post is provided "AS IS" with no warranties, and confers no rights. This entry reflects my own personal views and does not necessarily reflect the view of my employer.
    Friday, February 12, 2010 11:54 PM
  • We had an issue where our windows 7 computers would no longer authenticate over wireless to the 2008 R2 NPS (radius) service.  Smartphones connected ok.  After considerable troubleshooting we were seeing Event ID 36855 on the server and the wirless controller reporting Reason-Code = 226  Reason = The message received was an unexpected or badly formatted message (similar to http://support.microsoft.com/kb/933430).  Sure enough, it was because the schannel communications was truncating the list of trusted root CA's it was sending to the client.  Upon examination we found over 300 certs (mmc > add remove snap-in > certificates >computer account > local computer > check the trusted root certificate authorities) on the NPS server.  Normally we were expecting under 50.  It looks similar to the list from microsoft update KB931125 (follow the link in this update to see the list and yes, it's huge).

    We performed the following actions:

    Create Registry key at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL"  with value name "SendTrustedIssueList" REG_DWORD value data = 0 (false).

    The computers started poping back onto the wireless.  We exported and removed a significant number of entries in the computers certificate store\trusted root certificate authorities (basically, all expired CA certs and left the roughly 40 something that we found to exist on another computer.  We undid the registry key change and the computers still connected fine.  Only till later did we track it down to this update so removing the update may solve your issue.

    Wednesday, October 23, 2013 3:07 PM

  • Hi,

    We spent many hours trying to solve this problem.

    Our setup:

    Cisco wireless setup, using windows NPS for 802.1x authentication.

    Certificate base auth, with an internal PKI sending out client machine certs, and also the server cert.

    Auth was failing with "reason code 22, The client could not be authenticated  because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server."

    It turned out to be a GPO setting on the server, that was enforcing key protection.

    There is this note on the below technet article:

    Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as Encrypting File System (EFS) and wireless (802.1X) authentication that cannot display UI. For more information, see article 320828 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115037).

    http://technet.microsoft.com/en-us/library/cc725621(v=WS.10).aspx

    Hopefully this helps someone out, if you have the same annoying error.

    Thursday, December 12, 2013 11:58 PM