Table of Contents
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.

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.

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

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.

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.
Thank you! Saved my day!
Hey Bas,
probleem was bij ons wat anders. Maar wellicht helpt het iemand.
We had this issue with NPS and Azure MFA. The problem wasn’t actually with the extension, it just logged this error.
We use client certificate based authentication (AlwaysOn VPN with user certificates).
Temporarily removing the extensions revealed the real error. Which was that certificate revocation checking didn’t work. Customer had an offline root CA, with a CRL on a intermediate (one no longer in use but still running) on HTTP.
Anyways, if you run into this, check your certificate chains for the CRL on the certs and intermediate certs and run:
certutil -URL
Check if the CRL is retrievable and valid.
You shouldn’t have to check it for the root cert itself as NPS by default is configured not to check the root CA certificate CRL. Unfortunately the intermediate cert at this customer referenced that as well.
Great Feedback Ferry, thanks!
Bas!
Dank, dank, dank!!! MFA weer werkend na verlopen self signed certificaat.
Klinkt goed! 😉
How did you get this:
The MFA extension ServicePrincipal already exists under applicationID: 981f26a1-7f43-403b-a875-f8b09b8cd720
Seems missing a step.