NPS supports multiple Connection Request Policies, each can have condition(s) which must be met for the Policy to be applied. NPS will try to match the Policies one after another in the order you can control. If none matches the user is rejected otherwise the first matched Policy is applied.


Mi-Token can be enabled or disabled on each Connection Request Policy. What happens next can be summarized as follows:

1. When NPS is set to "Authenticate requests on this server":
- If Mi-Token is enabled then a user must type both password and OTP. Practically this means in Radius Tester both input boxes (for OTP and password) must be filled in, in UI displayed by a VPN client the password and OTP must be concatenated e.g. secret123456.
- If Mi-Token is disabled then a user must type password only. Practically this means in Radius Tester the OTP box must be left blank and in the VPN client only password must be typed.
- NPS looks at Network Policies and tries to find the first matching one. If no Network Policy matches then the user is rejected. If a matching Network Policy has been found, then its settings are enforced (and the user can be rejected as a result).

2. When NPS is set to "Accept users without validating credentials":
- If Mi-Token is enabled then a user must supply OTP only. Practically this means that in Radius Tester the password box must be left blank, in the VPN client OTP must be typed in instead of password.
- If Mi-Token is disabled then users can type anything instead of password and/or OTP and they still will be accepted (cause both NPS and Plugin have been prevented from checking credentials, therefore neither OTP nor password is verified) so this combination must never be used.
- NPS always ignores all Network Policies regardless of Mi-Token being enabled/disabled or being installed or uninstalled.