Azure MFA with NPS extension

KDKITKDKIT
in Firebox - VPN Mobile User

Hi,

I have a weird problem.. For some reason the TOTP token is not being accepted..

Message on Watchguard
admd Authentication of SSLVPN user [xxx@RADIUS] from xxx.xxx.xxx.xxx was rejected, user isn't in the right group msg_id="1100-0005"

However, if I change the registry key "OVERRIDE_NUMBER_MATCHING_WITH_OTP" value to False I'm getting an Approve or Deny push message from the Microsoft Authenticator. This also is the only change I've made to get it to work.

Why is the group not recognized when I go for the TOTP option instead of push message?

I've been working on this for days now and can't seem to find the solution to this weird problem. Is the group, I suppose that is the "SSLVPN-Users" group, only looked at when going for TOTP or is it somehow bugged?

Filter ID 11 is populated with the AD group "SSLVPN-Users" in the NPS Network Policy (case matched).

OTP is enabled in Azure for the tenant.

AuthZOptCh logs:
1. NPS Extension for Azure MFA: CID: blablabla : Challenge requested in Authentication Ext for User xxx with state blablabla
2. NPS Extension for Azure MFA: CID: blablabla : Access Accepted for user xxx@dekuyper.nl with Azure MFA response: Success and message: session blablabla

Can someone help me out? It would be much appreciated.

Kind regards,

Gary

Comments

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @KDKIT

    If the firewall is saying that the group doesn't match, that's the problem.
    -If you're sending multiple groups via the access-accept message, the firewall may only parse the first depending on length.
    -The group name is case sensitive. If the firebox is looking for "SSLVPN-Users" and gets "sslvpn-users" for example, that won't match.

    It may help to use a tool like TCPDUMP or Wireshark to capture your RADIUS access-accept messages and see what is actually in them for RADIUS attribute 11. RADIUS is clear text (aside from the password) so it's easy to look at the packet in wireshark and verify it's there.

    -James Carson
    WatchGuard Customer Support

  • KDKITKDKIT

    Hi @james.carson

    There is the problem. NPS doesn't sent Attribute 11 back to the Watchguard.
    I have no clue why that is tho.. Do you have any idea?

    The group has been copy paste so it's exactly the same in regards to your case-sensitive comment.

    Kind regards,

    Gary

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @KDKIT
    If you've configured NPS to send the group, and it isn't, I'm not sure why it might be doing it. It's likely you're not matching that part of the NPS policy, or it's being overridden by something else.

    Our support team may be able to provide limited help with NPS via a support ticket. If you're having trouble with NPS, it may be best to contact Microsoft support for assistance, as they're the experts on that product.

    -James Carson
    WatchGuard Customer Support

  • kimmo.pohjoisahokimmo.pohjoisaho

    Azure MFA authentication options.

    PAP supports all authentication methods of Azure AD MFA:

    • Phone call
    • One-way text message
    • Mobile app notification
    • Mobile app verification code

    CHAPV2 and EAP support only:

    • Phone call
    • Mobile app notification

    WG sslvpn uses PAP and IKEv2 uses CHAPv2.
    WG mobilevpn needs from the radius server a Filter-ID attribute, so that it knows what policy’s it should open….

    https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-nps-extension

    “…when the MFA Extension is installed on the NPS server, the NPS is unable to send back user defined attributes to the RADIUS
    clients when the users Auth Method requires the use of a One Time Passcode(OTP), such as SMS, Authenticator App Passcode or Hardware FOB.”

    “regardless of the authentication protocol that's used (PAP, CHAP, or EAP), if your MFA method is text-based (SMS, mobile app verification code, or OATH hardware token) and requires the user to enter a code or text in the VPN client UI input field, the authentication might succeed.
    But any RADIUS attributes that are configured in the Network Access Policy are not forwarded to the RADIUS client (the Network Access Device, like the VPN gateway).”

    Luckily there’s a workaround.

    “As a workaround, you can run the CrpUsernameStuffing script to forward RADIUS attributes that are configured in the Network Access Policy and allow MFA when the user's authentication method requires the use of a One-Time Passcode (OTP), such as SMS, a Microsoft Authenticator passcode, or a hardware FOB.”

    https://github.com/OneMoreNate/CrpUsernameStuffing
    https://www.youtube.com/watch?v=7be2yuOwUHs

    For a quick test you can only configure in the ”Connection Request Policy” the mobilevpn Username with the right Filter-ID.

Sign In to comment.