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.“.
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.
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:
- 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:
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.
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"
I found out that there is a PowerShell script in the installation folder of the MFA extension.
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.