The request was discarded by a third-party extension DLL file RRS feed

  • Question

  • Hi Folks,

    Have a Win2K16 RRAS\VPN server running which sends RADIUS auth requests to a Win2K16 DC with NPS and the Azure NPS Extension V installed. We are an Office 365 Customer with Azure Premium.

    Non MFA-enabled users are able to authenticate and connect via the VPN. MFA-enabled users cannot. The extension sends an authentication approval request to the user's device, but when approved, it doesn't authenticate the user, and a 6274 error is generated in the security log from NPS with "The request was discarded by a third-party extension DLL file".

    Ran the script at and things seemed generally OK.

    This used to work when I first installed the NPS extension, but stopped at some indeterminate time thereafter.

    Any ideas?



    Friday, August 23, 2019 6:43 PM

All replies

  • Hi Ian,

    This may seem too simple, but sometimes this error can happen with the NPS Extension if you have the wrong version of the installer which older docs used to recommend.

    Can you confirm that you are using NpsExtnForAzureMfaInstaller.exe?

    If you are saying that MFA-enabled users cannot authenticate, can you confirm that these users have the right licenses for MFA and are enabled for it? 

    Also, please make sure you install the latest Windows update to see if that fixes the issue. See related threads:

    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Monday, August 26, 2019 6:48 PM
  • Hi Marilee and thanks for your response.

    To address your questions:

    1) As mentioned, we have Azure premium, so have the correct license. I have enabled MFA on my own account (among others) and have been testing with it. It works for the Office and Azure portals, OWA, etc. using the MS authenticator on my phone.

    2) As mentioned, we are in fact using the latest version which you reference:, and I downloaded it in my troubleshooting efforts from the link you included. Prior to this we were running

    3) I too saw some cases where installing winupdates had alleviated the problem, so I did that on Fri. before posting. No effect.

    Other suggestions please?



    Monday, August 26, 2019 7:26 PM
  • Hi Ian, 

    Can you check the MFA AuthZ and AuthN logs from the EventViewer/Applications and Services Logs\Microsoft\AzureMFA? 

    These logs should give us more information about why the request was rejected by the extension. 

    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Tuesday, August 27, 2019 4:55 AM
  • Hi Manoj,

    Thanks for the response.

    I've checked out those logs as you requested. The AuthN logs are pretty generic. Lots of this:

    The AuthZAdminCH log was jam-packed full of these however:

    Not sure what the no userName business is about: when prompted for creds by the VPN connectoid, I've tried user (works with non MFA accts), domain\user and UPN. None work. The link in the error doesn't give much help:

    "This error usually reflects an installation issue. The NPS extension must be installed in NPS servers that can receive RADIUS requests. NPS servers that are installed as dependencies for services like RDG and RRAS don't receive radius requests. NPS Extension does not work when installed over such installations and errors out since it cannot read the details from the authentication request"

    This is a separate NPS installation on a DC, not on the VPN server.

    AuthZOptCh gives this when an MFA-enabled user attempts to connect:

    Does that help? Thanks,


    • Edited by ianc3 Tuesday, August 27, 2019 5:42 PM
    Tuesday, August 27, 2019 5:31 PM
  • OK, I've continued to tinker with this and am no longer getting the errors above. In fact, the only message appears in the AuthZOptCh log, and according to it, things should be rosy:

    Unfortunately, they're not. The client is still getting shot down with this:

    I've recreated the connectoid multiple times. It and the NPS server are both set to use MS-CHAP V2. Also, non MFA-enabled users continue to work and be authenticated.

    Not sure what else to look at? Thanks for any info,


    Friday, August 30, 2019 9:25 PM
  • Hi Ian, 

    Is the end-user getting prompted for MFA? If he is successfully finishing MFA then it should not be discarded. 

    Are you following any doc for creating the connection request policies and network policies?

    Based on the error, it looks like the authentication method configured does not match the policy. Can you validate that as per this doc?

    Also, take a look at this doc for reference.

    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Tuesday, September 3, 2019 6:56 AM
  • Hi Manoj,

    As mentioned, the MFA-enabled user is getting prompted for MFA and entering it without error, but the VPN connectoid throws the above error only for MFA-enabled users. Non MFA users can authenticate and connect without issue using the same VPN connectoid.

    I used both those docs in configuring the connection request and network policies.

    Here are the conditions & constraints tabs of the network policy on the NPS server:

    Security tab of the client connectoid:


    VPN\RRAS server auth setup:

    It seems all goes well on the NPS server, but somehow the response doesn't make it back correctly to auth the MFA-enabled user? Remember that non-MFA users authenticate correctly.

    Further ideas or troubleshooting steps please?


    Tuesday, September 3, 2019 5:34 PM
  • No more ideas then?
    Tuesday, September 10, 2019 7:48 PM
  • Hi Ian, 

    I would recommend collecting IAS logs and A network capture to investigate this further.  The steps are available in this doc. 

    Also, if you have access to a support plan, please create a support request to troubleshoot this further. If you do not have access to a support plan, we can continue this over email. Email:

    Please take a moment to "Mark as Answer" and/or "Vote as Helpful" wherever applicable. Thanks!

    Wednesday, September 11, 2019 5:53 AM
  • Hi Manoj,

    I don't have access to a support plan unfortunately. I will go ahead and grab logs and some packet captures and get back with you over email over the next few days. Thanks again for your help,


    Thursday, September 12, 2019 5:27 PM