Thank you! Saved me a lot of time and frustration while teaching how to troubleshoot rather than just providing the answer without an explanation. Extremely helpful!
Thank you Nate. Your video was much appreciated and the way you approached and explained and reiterated important modules is what helped me so much today. Thank you! Wish you all the best
Thanks Nate, I tried removing the reg keys and restarting the NPS service, however I only see event ID 4400: A LDAP connection with domain controller ... for domain ... is established. I don't get an events like the ones in your video ie, 6273 or 6272 btw, this NPS server is also a domain controller, not sure if that's an issue
That's probably due to the audit policy on the machine. Open an elevated cmd prompt and run " auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable " then run the test again. If it still fails goto github.com/OneMoreNate/NpsMfaHealthCheckScript/blob/main/MFA_NPS_Troubleshooter_v2.0.ps1 and pull down the NPS Healthcheck script. Run it and choose option 4 then reproduce the issue. After that go back to the script window and hit a key to stop the script from gathering info. Once it bundles everything up you can send it to me at nathar-at-microsoft.com. I'll take a look at it as soon as I get a few minutes free.
Not in any way that I am aware. The NPS server extension talks to Azure for this process, so it isn't processing it locally. So if the NPS server can't reach Azure then MFA auth is going to fail and thus the RADIUS request will ultimately fail.
@@Navin.R.Johnson Yes, that makes sense. However, I read that it is possible to use RADIUS with offline MFA authentication, but indeed uses another flow than is presented in this video.
Thank you for this great troubleshoot video. We have this setup running. But still have some issue and the video is very helpful. In the AuthZ eventlog section I get several entries like this: NPS Extension for Azure MFA: CID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx : Access Rejected for user user@domain.tld with Azure MFA response: PhoneAppNoResponse and message: Authentication method failed.,,,yyyyyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy To my understanding this entry reports that the user did not approve the MFA request and thefore the Azure MFA NPS extension rejected the authentication. I would like to check that. The MFA requests do not show up at the sign-in logs for the user in Azure AD. Is there way to check in Azure AD if the user got a MFA request and their response? What do the CID id xxxx and the other id yyyyyy mean? Can you use these ids to get more info?
Glad it helped out! Yes, that error message means that Azure sent a notification to all Device IDs registered for that user account and got no responses. The way to see more insight into these MFA requests is to go to Azure AD/Security/MFA/Activity Log and you will see all requests from NPS servers there. As for the correlation IDs, you may see them in the activity report, but the only way to dig further into a specific sign-in failure would be to open a support case with the Azure team. My recommendation would be to have the user delete the old device (aka.ms/mfasetup) and re-register, then try again.
Thanks for the info Nate! I found the MFA section in Azure AD (only as global admin btw). Very useful for troubleshooting. When you export the overview you get a lot of extra columns; including the ID that is also shown in the AuthZ eventlog on the NPS server (yyyyy…). We have quite a lot of users that get multiple MFA requests within 2 minutes even when they approve the first one. We use this setup for VPN client connection. Do you know a cause for this?
@@wilbertsteller9445 I would recommend checking the AuthZ logs and seeing if there are multiple requests during that time for the user. If yes, and I suspect there will be, then you need to check the RADIUS timeout values on the RADIUS client and extend all of them to at least 60 seconds. There should be 2 timers; Request timeout and retransmit timeout. The retransmit timeout usually is a cumulative value of "try X times every X seconds", so make sure the total of this matches or exceeds the Request timeout, which will determine how long a Request will wait before a new request is sent. But the Retransmit timer can override that and time out a request too.
@@nate.harris , I don't know if this the right place to go into detail like this. If you have another way to contact you please let me know. Yes, there are multiple requests in the AuthZ logs and also approved (in 2 min timespan). In the NPS server settings, I can't find the timeout values that you refer to. Not in the RADIUS client settings (our VPN server / firewall) or the CR / Network policy settings. We don't have a remote radius server. I am missing something? On the firewall itself in the RADIUS server settings there is just 1 timeout setting. set on 120sec (since a month).
@@wilbertsteller9445 So whether the device's GUI is showing two timers or not, there will be two-timer settings; Request Timeout and Retransmit Time. The first is how long the request is good before the device considers it invalid. In your case, it's 120 seconds which is plenty of time. The second timer is how long it waits before resending the request. In some cases, this timeout also controls the first timeout. In other words, your Request Timeout is 2 mins, but in rare cases, I've seen a device where it would resend X times every X seconds before marking the request as dead. So if the Request Timeout were 2 mins but the Retransmit Timers totaled 15 seconds and then marked the request bad, then you really only have 15 seconds before the request is no good. In most of those instances, the retransmit timer can be set through the command line, but I've seen a couple where it couldn't be changed at all. So this means that even if the NPS server sends back an ACCESS ACCEPT after the device has determined the request is dead, then it will still fail. I would take some network traces on the NPS server looking at RADIUS traffic to see what the behavior really is between the NPS server and RADIUS client.