MFA NPS ext - Support for Network policies via RADIUS-Challange msg via SMS & OTP
When you have NPS extension, The problem is that when a user is using SMS or OTP, the user is not granted access based on the network policies that are defined in RADIUS server.
This is known limitation (MS says) with NPS where the network policies are not applied for SMS or OTP Flows.
If you use a challenge method it does not support the NAP policies. These are only evaluated during primary authentication.
When using Radius Challenge(for SMS or OTP), the Challenge response skips primary auth and so these policies are not evaluated.
But when the users have chosen MFA method PhoneAppnotification or VoiceCall, the user is granted acces bases on the right network policy.
Marcos Saraiva commented
@Shawan Bishop the claim is accurate. I've faced this limitation myself. In the deployment I did, I saw the same behavior when using OTP as the 2nd factor of authentication. RADIUS would send the Access-Challenge request, the firewall I was using as the RADIUS client presented the user with the dialog to input the code, Azure AD validated it, but the NAP policies were not checked, so NPS didn't send back the additional attributes the firewall was expecting to grant access (group name, in this case). The same did not happen when using push or phone calls as the MFA.
Shawn Bishop commented
I don't think the claim in this request is accurate. When NPS receives the RADIUS Access request, it does primary authentication first, before the NPS extension gets any control and before it is known what default method of MFA the user has registered. If primary authentication fails, the NPS extension doesn't do anything and an Access-Reject response is returned to the client.
If primary authentication succeeds, then the NPS extension connects to Azure AD, discovers the user's default MFA method and performs that method of authentication. When the user's default method is phone call or Authenticator push notification, it performs that method and then returns the result to the NPS extension and the Access-Accept or Access-Reject response is sent back to the client.
However, if the user has SMS or Authenticator OTP configured as their default method of MFA, the NPS extension must send an Access-Challenge response back to the client. In order to do that, you must have configured PAP as the RADIUS protocol between the client and NPS. If not using PAP, you can't use Access-Challenge. Also, the client system (e.g. VPN) must be able to handle the Access-Challenge response so that it can prompt the user for the OTP that's either in their Authenticator app or that was sent to them via text message.
Most major VPN systems support the Access-Challenge response. But those systems also typically support authenticating via SAML. If so, that's a much better option than using RADIUS. All methods of MFA are supported without the requirement of using PAP (not a very secure protocol) and without having to support RADIUS Access-Challenge responses. It's also a better user experience. It also allows you to use conditional access policies so you can use other controls besides MFA if desired.
Same issue in UK, is there an update on this ? It works perfectly with Authenticator App and phone calls but not with SMS verification code. This is really urgent.
Any update on this ? Push and Voice calls is not acceptable in out organisation.
This is not acceptable. We allow our users to pick various different factors for MFA but due to this we can only limit them to Push or Voice call... please fix this!
Any update on this? I've been battling getting the 6 digit verification code to work for a while now and just found this post
Matthijs Vader commented
After having ran into this ourselves, I'd think this is super urgent. SMS and OTP are the simplest to use in countries where its difficult to obtain internet access (think being in an hotel in West Africa, Cameroun for example).
And the other bad thing about this is that its totally opposite of what you expect; so a security flaw / issue.