locked
How do I return the normalised, inner identity of a user in the User-Name AVP of an Access-Accept? RRS feed

  • General discussion

  • Is it possible to configure NPS to return the normalised, inner identity of a client in the User-Name AVP of an Access-Accept to cope with anonymous outer identities?

    Where 802.1X authentication takes place and an anonymous outer identity is used (meaning that it differs from the inner identity) with a TLS based EAP, such as PEAP, it should be possible to return the inner identity in the Access-Accept so that the NAS has the ability to work with the 'real' identity of the user. Can NPS do this? How would this be configured?

    The User-Name AVP of an Access-Accept also provides a RADIUS server the ability to return a users' identity normalised. (For example, where domain\user is supplied by a user, the RADIUS server can always respond with user@fqdn.) Can NPS do this? How would this be configured?

    Increasing numbers of features are being implemented in switches and access points, such as L7 application visibility and control, so it is a significant operational concern that such devices work with an accurate identity, one that cannot be spoofed with an anonymous outer identity and is consistent for a discrete user.

    If this is not possible today, how would one go about making a design change request to Microsoft to accomplish this or talk to the development team? Is this an oversight? Competing RADIUS servers such as FreeRADIUS and Radiator have this ability when configured.

    For reference, this is RADIUS standard behaviour.

    RFC 2865 states in Section 5.1:

    [The User-Name AVP] MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session.

    RFC 3579 states in Section 3:

    The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access-Request.

    Furthermore, where federated authentication has taken place, such as in eduroam, and a User-Name AVP has not been returned in the Access-Accept yet a Chargeable-User-Identity has after being requested, it should be possible to configure the RADIUS implementation to add a User-Name AVP set to cui@realm to the Access-Accept it sends on to the NAS so that it gets an identity that identifies the user with a constant identifier.

    Is support for Chargeable-User-Identity (RFC 4372) support ever planned for NPS?

    See:

    https://community.ja.net/library/janet-services-documentation/chargeable-user-identity-eduroam-freeradius-implementation

    Thanks!

    Nick

    • Edited by Nick Lowe Monday, April 29, 2013 11:26 PM
    • Changed type Jeremy_Wu Wednesday, May 1, 2013 6:17 AM
    Monday, April 29, 2013 2:40 PM

All replies

  • I have opened a support case to get this looked at.
    Tuesday, April 30, 2013 12:52 PM
  • Hi Nick,


    Thanks for the post.


    As you have opened a support case with Microsoft Technical support, I would like to archive this thread if you do not mind.


    If you have any further concern, please feel free to let us know.


    In addition, it is appreciated that if you can post solution when the issue is resolved so that it can benefit others.


    Best Regards.


    Jeremy Wu
    TechNet Community Support

    Wednesday, May 1, 2013 6:17 AM
  • That's more than fine. Sorry if I have messed the system around! After posting, I realised I wanted a more formal response so opened a case.

    I will post back here to let others know the outcome.

    Thanks,

    Nick

    (The support case number, for anybody who is interested, is SR 113043010404466, titled "Normalising and returning inner identity in the User-Name AVP of a RADIUS Access-Accept".)

    Wednesday, May 1, 2013 11:16 PM
  • This had been escalated to a support team lead and is now awaiting comment from a debugging engineer.

    As I see NPS as being the facilitator of an identity spoofing vulnerability here, although I do not expect a quick resolution, I am quietly hopeful for the team to be amenable to reasoned argument and for some good news at the end of it!

    Will continue to update back here as and when I hear more.

    Monday, May 13, 2013 12:06 AM
  • Try this Extension for Microsoft NPS adding attributes for compatibility with eduroam.

    It adds "User-Name" attribute to Access-Accept.

    https://github.com/sola-prihodnosti-maribor

    Monday, June 24, 2013 5:05 PM
  • Hi Nick,

    I know this is an oldie, but did you ever get a resolution / answer to your question?

    Kind regards,

    Dimitry Schoenmakers

    Wednesday, December 9, 2015 11:02 AM
  • Hi Nick,

    Any news about this issue?

    Best regards,

    Hugo Veiga

    Monday, December 28, 2015 4:12 PM
  • Was this ever fixed or replied to by Microsoft.
    Thursday, July 28, 2016 2:20 PM
  • Would love to hear back concerning the outcome of this.

    Thanks.

    Tuesday, August 16, 2016 6:33 PM
  • FYI - Can confirm the Eduroam-MS extension code works as intended in NPS on Windows 2012 R2 Server for anyone else in a similar situation as myself. 

    Also, anyone who's not a developer, but knows just enough to compile some code... I ran into the following when trying to test this out myself, so I'm sharing my struggles in the hopes it helps some other poor Googler out there:

    "

    Dependency Walker was key here for me.  After successfully compiling my NPS extension DLL (Remember to match your server platform re: 32/64 bit!), I really struggled to get NPS to load it.  It would simply respond with a 0x7E error (Event Log).  This was initially interpreted as NPS somehow not being able to properly locate the DLL I was trying to load (Is it in a PATH variable location?  Did I screw up the NPS Extension registry keys somehow?), but in reality, actually meant that a dependency /within/ the DLL wasn't able to be located.

    Running Dependency Walker *on the target NPS server* and pointing it at the extension DLL will indicate which dependency the server isn't able to source.  In my particular case it was MSVCR120.DLL, and will likely vary depending on whether you are compiling a Release or Debug build of your DLL and what version of the Build Tools was used to compile it (version 120 in my case).  A quick google for the missing DLL will usually point you in the direction of a Visual C++ Redistributable package you can install on the server to meet the dependency.

    I hope this information helps someone else.  I sure wish I could have found it about 3 days ago myself.

    "

    Cheers!


    newp

    Friday, October 28, 2016 1:01 PM