Azure MFA NPS Extension: brute forces via non allowed accounts

Question

Dear,

We've setup NPS with Azure MFA 3rd party extension for our SSLVPN. Via the network policy in NPS we've limited VPN access to a specific security group.

However: now we see that our onpremise Administrator account locks out frequently. Further research leads us to the source: brute forces via SSLVPN on the administrator account.

The strange thing is that our administrator account is not in the specific VPN security group we've defined in the connection request policy.

In the event vwr we see this as an error on the administrator brute force attempt: ""The request was discarded by a third-party extension DLL file"

How does this come? I expected that the administrator connection attempt was denied before contacting Azure AD or before the login was attempted through onpremise AD because administrator user was not in the specific security group.

Any ideas? Is this normal behavior when Azure AD MFA 3rd party MFA extension was installed?

Thank you so much!

Pieter

Answer 1

Hello Pieter Huygens,

Thank you for posting your query on Microsoft Q&A.

We understand that you have NPS with Azure MFA for SSL VPN and limited access to a security group in which your administrator is not added in the group.

Administrator account locks out frequently with brute force attacks. The event shows "The request was discarded by a third-party extension DLL file".

This behaviour is expected, and the NPS Extension correctly discards duplicate requests to avoid unnecessary load and multiple responses.

This is due to duplicate RADIUS requests to NPS Server and how the NPS Extension, handles these requests. This situation arises when multiple RADIUS clients retry their requests due to a delayed response, potentially leading to the NPS Extension (involved with the Security Assertion Server (SAS)) discarding duplicate requests as expected behaviour.

Duplicate Handling in NPS:

When a duplicate RADIUS request reaches the same NPS server, the NPS Extension (which interacts with the Security Assertion Server) will discard the duplicate request.

This is done to avoid processing the same authentication request multiple times and to prevent multiple responses being sent to the RADIUS client.

Expected Behaviour:

This handling of duplicate requests is expected and normal. It's part of the RADIUS protocol's resilience mechanism and the NPS Extension's efforts to ensure the system doesn't return multiple responses for the same authentication request.

RADIUS Clients retry requests for better fault tolerance and to ensure successful authentication if the first request fails.

NPS Extensions ensure no duplicate authentication responses are sent, thereby maintaining security and performance.

Why This Happens:

RADIUS clients don’t know whether a request was lost or delayed, so they resend the request.

If a request is delayed in processing or a server experiences a timeout, retry attempts are made.

NPS Extensions detect and discard duplicates to ensure that authentication processing doesn’t occur multiple times for the same request.

How to Mitigate:

Adjust Retry Settings: On the RADIUS clients, adjust the retry logic and timeouts to avoid excessive retries.

In your case you can mitigate the issue by adjusting retry settings on Radius Clients to avoid excessive retries.

I hope this information is helpful. Please feel free to reach out if you have any further questions.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". Thanks,

Venkata Jagadeep