group-lock for VPN users on Microsoft radius server with NPS extension

[k.dixon]

Hi-

Anyone here able to configure group-lock for Office 365 MFA-enabled users? I've seen several articles here on steps how to configure group-lock/tunnel-group-lock on Microsoft Radius server and steps works fine but not for Office 365 users that has MFA enabled.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-vpn

I suspect Radius attributes are not being sent to ASA as there is a second authentication that goes to Azure MFA.

Anyone experienced this?

[Rahul Govindan]

What does the output of "debug radius all" show on the ASA when you connect? I have not done this, but the document mentions that Radius is used for authorization, so I can't think of how they would enforce that if they do not return something back to the NAS.

[k.dixon]

Hi Rahul,

I've attached the output for the user without MFA and the one with MFA. What's weird is that whenever I tried to run it on a user with MFA the putty session disconnects with an error "Incoming packet was garbled on decryption". Already tried below but no luck.

Go to Connection -> SSH -> Protocol options. Set “Preferred SSH protocol version:” to SSH version 2.
Go to Connection -> SSH -> Encryption options. Promote Blowfish to the top of the list of “Encryption cipher selection policy:”

BTW as you can see on the output, the one without MFA works fine. ASA was able to assign it on a certain group policy.

Thanks,

[Rahul Govindan]

From your output, it looks like the Radius Challenge is sent back to the ASA instead of being sent to the client for the secondary auth. 

ADIUS packet decode (response)

--------------------------------------
Raw packet data (length = 98).....
0b dc 00 62 d4 78 e1 16 c0 7b a8 b2 5f cb 9b 16    |  ...b.x...{.._...
b0 23 7f 5f 12 28 45 6e 74 65 72 20 59 6f 75 72    |  ._.(Enter Your
20 4d 69 63 72 6f 73 6f 66 74 20 76 65 72 69 66    |   Microsoft verif
69 63 61 74 69 6f 6e 20 63 6f 64 65 18 26 63 35    |  ication code.&c5
34 34 63 32 62 65 2d 64 66 63 34 2d 34 33 62 62    |  44c2be-dfc4-43bb
2d 39 65 39 62 2d 34 62 32 33 33 66 32 38 30 37    |  -9e9b-4b233f2807
31 34                                              |  14

Parsed packet data.....
Radius: Code = 11 (0x0B)
Radius: Identifier = 220 (0xDC)
Radius: Length = 98 (0x0062)
Radius: Vector: D478E116C07BA8B25FCB9B16B0237F5F
Radius: Type = 18 (0x12) Reply-Message
Radius: Length = 40 (0x28)
Radius: Value (String) =
45 6e 74 65 72 20 59 6f 75 72 20 4d 69 63 72 6f    |  Enter Your Micro
73 6f 66 74 20 76 65 72 69 66 69 63 61 74 69 6f    |  soft verificatio
6e 20 63 6f 64 65                                  |  n code
Radius: Type = 24 (0x18) State
Radius: Length = 38 (0x26)
Radius: Value (String) =
63 35 34 34 63 32 62 65 2d 64 66 63 34 2d 34 33    |  c544c2be-dfc4-43
62 62 2d 39 65 39 62 2d 34 62 32 33 33 66 32 38    |  bb-9e9b-4b233f28
30 37 31 34                                        |  0714
rad_procpkt: CHALLENGE
radius mkreq: 0x25e5
    old request 0x25e5 --> 221 (0x00002aaad4dd1948), state 3
wait pass - pass '***'. make request
RADIUS_REQUEST
radius.c: rad_mkpkt
rad_mkpkt: ip:source-ip=68.111.123.9

Are you getting the text/phone call for the secondary authentication ? The ASA should only receive the Access-Accept or Access-Reject in the end which has the attributes for the user from what the flow shows.

[k.dixon]

we've use the "mobile app" for the secondary authentication. This is how it looks like since I capture it also on wireshark.

10.50.16.3(internal) is the ASA and the other IP is for the Radius.

Here is the actual screenshot,(sorry I tried to change IP for security reasons but anyway here it is.:

112.199.74.38 is the IP where I tried to connect to VPN.

Thanks,

[Rahul Govindan · Accepted solution]

Ok, are you using the OTP mechanism via mobile-app or one-way-text? If so, the Radius-challenge is sent back to the ASA so that the Anyconnect client can prompt you to enter the OTP. If you use the Mobile-app notification (no OTP required), then the ASA does not receive the challenge message and only receives the Access-Accept with all the attributes. 

My theory is that the ASA takes the attributes from the Access-Challenge message instead of the final Access-Accept message that you receive. The Challenge message does not contain the Class (Group-Policy) attribute, so the ASA does not lock it to that group-policy. 

Can you try two way text or Mobile app notification as secondary authentication in your environment? 

[k.dixon]

We're using the verification code from mobile app for the secondary authentication. Okay, we'll try the other verification options. I'll let you know. Thanks

[Rahul Govindan]

Try using the notification through mobile app method described below:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#selectable-verification-methods

This should be the same from the ASA perspective as using no MFA. 

[k.dixon]

Thanks Rahul. That did the trick. :)

[Egert]

I am having the same issue but in my case 90% on people prefer to use txt messages. Any workaround for this issue to make it work with TXT messages.  The phone call and APP notification method work fine. 

[Egert]

I am having the same issue but in my case 90% on people prefer to use txt messages. Any workaround for this issue to make it work with TXT messages.  The phone call and APP notification method work fine. 

[opusone]

I just spent an afternoon re-discovering this bug in NPS.  The NPS server is the problem here; it is not actually respecting the settings and sending the attributes back down to the RADIUS client.  If you take a close look at the logs on the NPS server, you'll see that when the MFA authentication succeeds, the log does NOT contain the name of the NPS policy---this is a signal that the NPS server has somehow lost the context surrounding the MFA authentication.  It still has the right policy in its little MicroHead, but it does not follow through on the other parts of the policy.  You can try complaining to Microsoft about it---this is very clearly a bug in NPS that is triggered by the MFA. 

Joel Snyder