Here are some troubleshooting steps that might help when implementing Azure MFA with an existing RDS infrastructure.
There are many steps to take to implement Azure MFA with an RDS infrastructure. Try to copy and paste as many as possible. Especially shared secrets can be a problem to type correctly. The shared secret is the key that is used to encrypt and decrypt the authentication request. So even if the user types in the correct password, the system might fail the authentication request when the shared secret is incorrect.
The gateway server has the NPS role already pre-installed. Open the Event viewer, Custom Views, Server Roles, Network Policy and Access Services view. This view shows the NPS role events.
During installation of the NPS extension, a log is created to store events for secondary authentication. Open the Applications and Services Logs node, Microsoft, AzureMFA, AuthZ, AuthZOptCh log to view those events.
Eventlogs (Failure and Succes?)
While troubleshooting I noticed I was not seeing failure events from NPS even though it was selected on the NPS server. I am not sure if rejected is the same as a failed event, but here’s the setting from NPS:
Using a command prompt, I was able to enable log events for failures.
The command auditpol /get /subcategory:”Network Policy Server” shows the currect settings.
The command auditpol /set /subcategory:”Network Policy Server” /success:enable /failure:enable enables both success and failures.
MFA Extension and Event logging process
Once the NPS extension for Azure MFA is installed on the NPS server, it changes the way logs are handled. During installed, two DLL files are loaded by NPS. Log entries in the NPS custom view will contain less and different information. Log entries in the AuthZOptCh log will appear, but they contain different information. Troubleshooting might become a bit tricky.
It is possible to temporarily disable the two DLL files from loading, restoring the normal logging process. To do so, open up Registry Editor and navigate to HKLM\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters
Export the Parameters key to a known location, then proceed to delete the two DLL entries from the registry. Restart the NPS service. From this point on, the server will log the NPS entries as it would without the MFA plugin.
Once the troubleshooting is done, import the registry export we did in the first step. Remember to restart the NPS service for the DLL’s the be loaded by NPS again.
This application allows us to test RADIUS traffic from a client to the NPS server. Enter the server, port, RADIUS Shared Secret, Username and Password and hit the Send button.
Here is a screenshot where NTRADPING is waiting for approval. At this point, my authenticator was asking me to validate the request.
If you are troubleshooting without the DLL’s loaded, you should see the following;
The response is Access-Accept. This tells us the authentication was a success.
Windows Server 2019 – Firewall
If there’s a communication error, it might be due to a known error in the Windows Firewall. Once installing the role, it will configure the appropriate Firewall rules to allow traffic. But those rules will not work, as it is a bug.
There is a workaround for this bug, open up an administrative prompt and enter the following command:
sc.exe sidtype IAS Unrestricted
Reboot the server for this to take effect.
This is specifically for Windows Server 2019. If you have earlier versions, you should be fine.