FIX: The request was discarded by a third-party extension DLL file

RDS with Azure MFA as extra security layer.

Yesterday I had a wonderful problem again! It was about Remote Desktop Service again, but this time at one of our customers.

We use an RDS environment with Azure Multi Factor Authentication as an extra security layer. When logging in, we were asked to enter our credentials for the RDS gateway, but in the next step we were getting a time-out instead of the familiar MFA notification in the Microsoft Authenticator app.

FIX: Logging in to RDS with MFA enabled time-out.

Let’s fix “The request was discarded by a third-party extension DLL file.“.

Explanation

To configure MFA on an RDS environment you use NPS. You can install a NPS Extension for Azure MFA, which then uses the policies in NPS.

It took a while before I found out that RDS uses NPS for this. If you want to know more about my search, go to section ‘I have to admit, It took me a while to sort it out‘.

The certificate has probably expired for the MFA extension. This means that your login can no longer be forwarded to the Microsoft Authenticator app.

When you open Certificates snap-in there is a self-signed certificate under Computer Certificates that has an IssuedBy and IssuedTo name that matches your AzureAD tenantID.

This is not just about the Certificate. The MFA Extension uses a ServicePrincipal in AzureAD that also has an expiration date.

In the steps below I completely re-create the ServicePrincipal. If you do not want to do this, you can also try to remove the ServicePrincipalCredential first.


Solution

If your virtual machines are on Azure and you don’t know how to logon now, please go to section ‘I’m using Azure and I cannot log on to my virtual machines.‘.

  • First open the Certificates Snap-in and delete the old certificate on NPS.
  • Download the latest version of the MFA Extension for NPS and install it on NPS.
    MFA Extension direct download
  • Start PowerShell and login to MSOnline.
    The module for MSOnline can be found here.

The MFA extension ServicePrincipal already exists under applicationID: 981f26a1-7f43-403b-a875-f8b09b8cd720

You do not need to adjust anything in the following cmdlets.
Copy and paste these to PowerShell and press F5.

Remove-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720"

New-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720" -DisplayName 'Azure Multi-Factor Auth Client'

This first removes the old ServicePrincipal and re-creates it with the same properties.

Now go to the following location on the NPS server:

“C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1”

  • Start the PowerShell script,
  • Log in to AzureAD,
  • Enter your TenantID,
  • and wait for the script to finish.

You can find the Tenant ID in AzureAD.

FIX: Logging in to RDS with MFA enabled time-out.
FIX: Logging in to RDS with MFA enabled time-out.

You should now be able to log on your RDS environment with MFA again.


I’m using Azure and I cannot log on to my virtual machines.

We only have virtual machines in Azure for our customers aswell.

  • Login to the Azure portal,
  • Go to the Virtual machine,
  • Go to Reset Password,
  • Enter a Username and Password,
    If the account does not exist on the local machine, a new account will be created.
  • Click Update,
  • Download the RDP to the relevant machine and log in locally with:
    .\USERNAME
    PASSWORD
FIX: The request was discarded by a third-party extension DLL file.

If you still can’t log on, make sure you have the following configured:

  • A public IP address configured in your Network Interface.
  • Port 3389 needs to be open on your Network Security Group or Azure Firewall.

I have to admit, It took me a while to sort it out.

I didn’t do the configuration for an extra security layer, so I had no idea how this was configured.

I know that you can exclude locations within Azure MFA. I thought I would be smart by excluding Wortell from MFA to logon, but that still didn’t work.

FIX: The request was discarded by a third-party extension DLL file.
FIX: The request was discarded by a third-party extension DLL file.

This caused me to believe the issue was in RDS itself.

In the end I went through the documentation and found out that it is an MFA extension for NPS. The policies within NPS determine whether you can log in or not, and then your login gets forwarded to Azure MFA.

I already read on the internet about a certificate that could have been expired, so I looked into the Certificates snap-in and saw a certificate with the TenantID as IssuedTo and IssuedBy that had expired.

I checked to see if there was a module to configure the certificate, and lucky me there was.

Import-Module azureMfaClientCertProvider
New-AzureMfaTenantCertificate -TenantId 'XXXXXXXXXXXXXXXXXXXXXXXXX'

Re-newed the certificate and I still couldn’t log on.

I first tried installing the newest version, but as you can guess this didn’t work either.

I noticed there was an Enterprise Application that had the same expiritation date.

Get-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720

Because it didn’t work anyway, I chose to remove the ServicePrincipal.

Remove-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720"

Big mistake!

I found out that there is a PowerShell script in the installation folder of the MFA extension.

“C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1”

When running this script, it could no longer find the ServicePrincipal.

Fortunately I first made a backup of the ServicePrincipal.
After I re-created the ServicePrincipal,

New-MsolServicePrincipal -AppPrincipalId "981f26a1-7f43-403b-a875-f8b09b8cd720" -DisplayName 'Azure Multi-Factor Auth Client'

And then when the script was run again it worked.


Complete error message

This was the error message in NPS, but it took me awhile before I know that Azure MFA for your RDS was synchronized with Azure MFA extension for NPS.

Network Policy Server discarded the request for a user.
 Contact the Network Policy Server administrator for more information.
 User:
     Security ID:            XXXXXXX\XXXXXXX
     Account Name:           XXXXXXX\XXXXXXX
     Account Domain:         XXXXXXX
     Fully Qualified Account Name:   XXXXXXX.local/XXXXXXX/AdminAccounts/XXXXXXX/XXXXXXX (XXXXXXX)
 Client Machine:
     Security ID:            NULL SID
     Account Name:           XXXXXXX
     Fully Qualified Account Name:   -
     Called Station Identifier:      UserAuthType:PW
     Calling Station Identifier:     -
 NAS:
     NAS IPv4 Address:       -
     NAS IPv6 Address:       -
     NAS Identifier:         -
     NAS Port-Type:          Virtual
     NAS Port:           -
 RADIUS Client:
     Client Friendly Name:       XXXXXXX
     Client IP Address:          10.132.4.138
 Authentication Details:
     Connection Request Policy Name: Use Windows authentication for all users
     Network Policy Name:        XXXXXXX
     Authentication Provider:        Windows
     Authentication Server:      XXXXXXX.XXXXXXX.local
     Authentication Type:        Unauthenticated
     EAP Type:           -
     Account Session Identifier:     -
     Reason Code:            9
     Reason:             The request was discarded by a third-party extension DLL file.

Published by

Bas Wijdenes

My name is Bas Wijdenes and I work as a Senior Services Engineer @ Wortell. In my spare time I write about the error messages that I encounter during my work. I am currently occupied with Azure infrastructure and automating with PowerShell.

One thought on “FIX: The request was discarded by a third-party extension DLL file”

  1. How did you get this:

    The MFA extension ServicePrincipal already exists under applicationID: 981f26a1-7f43-403b-a875-f8b09b8cd720

    Seems missing a step.

Leave a Reply

Your email address will not be published. Required fields are marked *