locked
NPS - RADIUS authentication works locally, but access-request identified as "malformed" when proxied over the WAN RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi all,

    We are using a pair of Microsoft 2012 NPS servers as RADIUS proxy servers, behind which are another pair of NPS servers as RADIUS authentication servers. Users on our local wireless network can authenticate via this infrastructure, using Active Directory accounts, without problems. Authentication is PEAP/EAP-MSCHAP v2.

    However, the NPS infrastructure is also used when our users are at other organisations that offer the academic eduroam service, with their authentication requests being proxied back to our authentication servers. These roaming users are failing to authenticate nearly all the time, though occasionally a successful authentication is observed in the event viewer on the authentication servers. The failed authentication attempts typically generate an event viewer message:

    Network Policy Server discarded the request for a user.

    The reason in this event viewer message is given as:

    The RADIUS Request message that Network Policy Server received from the network access server was malformed.

    Because the authentication server discards the request and so does not respond to the proxy server, the proxy server also discards the request.

    The problem is evident on RADIUS authentication servers running on both Windows 2008r2 and Windows 2012.

    I'd be grateful for any advice on how to discover what it is that makes the authentication servers consider the access-requests as "malformed", or indeed what might be causing this for so many users when authenticating remotely over the WAN, even though local authentication is fine.

    One possible problem is described in

    https://technet.microsoft.com/en-us/library/cc755205(v=ws.10).aspx

    We have applied the relevant configuration described in

    https://technet.microsoft.com/en-us/library/cc771164(v=ws.10).aspx

    but the problem remains.

    There are also postings that suggest malformed requests can be related to server certificate issues, but I understand that if there were such an issue it would affect local authentication as well.

    Thanks in advance for any help anyone can offer.

    Stuart

    Monday, May 16, 2016 9:28 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Stuart,

    According your description,the RADIUS request message format has been changed  when it sent from RADIUS Proxy to RADIUS server.

    Network corruption, latency, or other network problems unrelated to NPS might produce this condition.

    To verify that ,you may need to perform a netword capture and analyze the message packet.Here is the link of Windows network monitor:
    https://www.microsoft.com/en-us/download/details.aspx?id=4865

    And the following is the RFC link and the NAS-Port attribute definition:

    http://tools.ietf.org/html/rfc2138#page-25

    “A summary of the NAS-Port Attribute format is shown below.  The fields are transmitted from left to right.

    Rigney, et. al.             Standards Track                    [Page 25]

    RFC 2138                         RADIUS                       April 1997

        0                   1                   2                   3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |     Type      |    Length     |             Value

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Value (cont)         |

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type

          5 for NAS-Port.

       Length

          6

       Value

          The Value field is four octets.  Despite the size of the field, values range from 0 to 65535.

    ________________________________________
    Best Regards,
    Cartman
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Tuesday, May 17, 2016 6:26 AM